Cosmos SDK chains can be scaffolded, built and interacted with using the [Ignite CLI](https://docs.ignite.com/).

Canto is EVM-enabled, utilizing a module called  which deploys an EVM execution environment enabling Solidity code to be deployed directly from the Ethereum network. Canto enables a native bridge between CosmWasm tokens and ERC-20 standard tokens using the ERC-20 Module.

This is it how it works:

1. The x/erc20module maintains a canonical one-to-one mapping of native Cosmos Coin denomination to ERC20 Token contract addresses (i.e sdk.Coin  ←→ ERC20), called TokenPair. The conversion of the ERC20 tokens ←→ Coin of a given pair can be enabled or disabled via governance.
2. A native Cosmos Coin corresponds to an sdk.Coin that is native to the bank module (which controls account balances and token supply in Cosmos SDK). It can be either the native staking/gas denomination (eg: EVMOS, ATOM, etc) or an IBC fungible token voucher (i.e with denom format of ibc/{hash}). When a proposal is initiated for an existing native Cosmos Coin, the erc20 module will deploy a factory ERC20 contract, representing the ERC20 token for the token pair, giving the module ownership of that contract.
3. During the registration of a Cosmos Coin the following bank Metadata is used to deploy a ERC20 contract:
4. Holders of native Cosmos coins and IBC vouchers on the Canto chain can convert their Coin into ERC20 Tokens, which can then be used in the ethermint EVM, by creating a ConvertCoin Tx. Vice versa, the ConvertERC20 Tx allows holders of ERC20 tokens on the Canto chain to convert ERC-20 tokens back to their native Cosmos Coin representation.
5. The EVM hooks allows users to convert ERC20s to Cosmos Coins by sending an Ethereum tx transfer to the module account address. This enables native conversion of tokens via Metamask and EVM-enabled wallets for both token pairs that have been registered through a native Cosmos coin or an ERC20 token.

The Canto network is a sovereign chain built using the Cosmos SDK and custom modules. 

Architecture and Design

At genesis, the initial total supply of $CANTO is 1,000,000,000 (one billion) tokens. Of this, the initial circulating supply of $CANTO is 150,000,000 (one-hundred and fifty million) tokens.

### Token Distribution

The initial circulating supply of $CANTO tokens is allocated as follows:
- 130,000,000 $CANTO (13%) for initial contributors
- 20,000,000 $CANTO (2%) for Settlers of Canto who took part in the launch of the testnet
- The remaining total supply of $CANTO is allocated as follows, pursuant to governance votes by the Canto DAO:
- 450,000,000 $CANTO (45%) for long-term liquidity mining to be distributed over the next 5-10 years
- 350,000,000 $CANTO (35%) for medium-term liquidity mining to be distributed over the upcoming months and years
- 50,000,000 $CANTO (5%) for future public goods grants

### Inflation

In order to maintain the security of the Canto network, the total max supply of $CANTO inflates over time at a rate that is constantly decreasing. All tokens from inflation are distributed to $CANTO stakers, proportionally to their stake in the network.

Early Canto contributors propose these emissions be structured in 30 day periods, with rewards distributed daily:
- For the first 30 day period, $CANTO will inflate at a 19.84% APR.
- For subsequent periods, the Canto DAO will vote to adjust emissions as appropriate.

Over time, the inflation of $CANTO should tend to zero.

$CANTO is the native token of the Canto network. It is used to pay gas fees for transactions and can also be  to help secure the network.

Tokenomics

1. The proposals are initiated on the Network side (Cosmos runtime) and voted on by network Validators as specified in the SDK governance module. Lending protocol governance uses a custom Canto proposal type equivalent to Compound V2's governance proposal type.
2. When a proposal is approved, the GovShuttle module sends the proposal type to the EVM module where it can be retrieved by a smart contract call to a specific oracle address.
3. When the proposal is retrieved, it is stored in the queue and then executed in the same manner as traditional governance on Compound V2, outlined in Compounds Governor Bravo after a proposal is approved.

### Technical Overview & Details

Here is a technical overview of Canto Lending Market governance:
1. User uses cli to submit proposal.cantod tx unigov submit-proposal “proposal text here” --address="address to map contract"
2. This submits a proposal using the Governance keeper.
3. Users vote on the proposal.
4. If the proposal passes, the governance module handler sends the proposal to the GovShuttle proposal handler, which triggers the GovShuttle module to call the keeper function AppendLendingMarketProposal located in the proposals.go file.
5. AppendLendingMarketProposal function takes in the LendingMarketProposal from earlier and returns the address at which the Map Contract is deployed.
6. Lending Market can now use the QueryProp method on the map contract to return a proposal struct. Importantly, the lending market can only query proposals that have passed through GovShuttle governance.

Proposals are saved to the EVM as follows:
1. The DeployMapContract packs the arguments contained in the proposal using ProposalStoreContract.ABI.Pack 
2. Then it creates a contract address using CreateAddress(types.ModuleAddress, nonce) 
3. It then creates a byte array with the packed data and passes that into a keeper call to the EVM with CallEVMWithData(ctx, types.ModuleAddress, nil, data, true) 
4. Finally it returns the address where the Map Contract (shown below) with the initial proposal is deployed

![Screen Shot 2022-11-08 at 7.42 1.png](https://res.cloudinary.com/pentaclexyz/image/upload/v1668090930/Screen_Shot_2022_11_08_at_7_42_1_13e35f0127.png)

5. If a GovShuttle proposal has passed before, add a proposal to the Map Contract by using

![Screen Shot 2022-11-08 at 7.42 2.png](https://res.cloudinary.com/pentaclexyz/image/upload/v1668090930/Screen_Shot_2022_11_08_at_7_42_2_87bba8db2c.png)


Here is a high level overview of how the Canto Lending Market is governed: 

Lending Market Governance

It's based on [Compound Protocol](https://compound.finance/) v2. The main differences between Canto Lending and Compound are:

1. There is no Canto Lending specific token. (Comp is Compound's ERC-20 token.) Instead, Canto’s ERC20 network token is used as the incentive token on Canto Lending. Comptroller smart contract gives out the token rewards. This file is modified to instead give out Canto rewards.
2. Governance on Canto Lending is controlled by Canto network validators rather than the Decentralized Application. Here is how it works:
- Proposals are initiated on the Network side (Cosmos runtime) and voted on by network Validators as specified in the SDK governance module. The lending protocol governance has a specified proposal type that is custom to Canto and exactly matches Compound's proposal type.
- After the proposal is approved, Canto's custom UniGov then sends the proposal type to the EVM module where it can be retrieved by a smart contract call to a specific address (”oracle address”).
- When the proposal is retrieved, it is stored in the queue and then executed in the same manner as traditional governance outlined in Compound's Governance Bravo after a proposal is approved.
3. Canto Lending Market will allow LP tokens from Canto’s native decentralized exchange to be used as collateral. This collateral will be deposited in a lending market as supply but users will not be allowed to borrow LP tokens.
Since the Canto Lending Protocol is closely based on Compound, you can find more information about its architecture in the Compound Protocol documentation.

Canto’s Lending Protocol is deployed on the network's native EVM (Ethermint)

Lending Protocol

Since Note cannot be created, only borrowed, and the Supply rate is the same as the Borrow rate, a new mechanism was necessary to keep track of how much of the interest paid by to borrow Note goes to the Accountant (and ultimately the Community Treasury) versus how much is paid to external suppliers of Note.

This is achieved by supplying and redeeming liquidity during every action taken by an external user of cNote, using an additional call implemented in the mintFresh/redeemFresh, borrowFresh/repayBorrowFresh internal methods in CToken.sol:
1. When users borrow Note or redeem cNote, the function in CNote will call another function in the Accountant to supply cNote in the exact amount required to offset the request.
2. When Users supply or repay Note to the market, the function in CNote will call another function in Accountant to redeem exactly the same amount of Note from the market.

As a result, there is never any Note present in the CNote market other than during function calls, but there is an infinite amount of Note that can be borrowed or redeemed.

This also prevents supply inflation, as idle Note in the lending market pool would otherwise earn interest despite not being lent out.

It is important to note that the internal price in the lending market used to calculate liquidity for Note is always set to 1 USD regardless of the value of Note in the DEX.

### Architecture diagram

Our implementation of Note’s architecture is described below:

![image 73.png](https://res.cloudinary.com/pentaclexyz/image/upload/v1668089734/image_73_f8c3b1ceae.png)

Since Note cannot be created, only borrowed, and the Supply rate is the same as the Borrow rate, a new mechanism was necessary

$NOTE Design

Projects

Contributors

Events

Resources

Docs

Articles

Canto, built to deliver on the promise of DeFi.