Historically, protocols have accrued value through the launch of a governance token or by charging user protocol fees. However, these methods are misaligned with the nature of public goods. Governance tokens rely on speculation rather than usage to generate value, and user fees make accessing the protocol more expensive.

Builders who aim to create protocols for the common good, without relying on these methods, lack a viable way to be compensated for their work. Currently, they are limited to non-scalable and unsustainable options such as community grants.

In order to create an ecosystem that encourages builders to develop public goods, a new mechanism for incentivization must be introduced. Canto contributors have introduced Contract Secured Revenue (CSR) to achieve this.

What is CSR?

CSR is an opt-in module that allows a portion of the gas fee spent on a smart contract interaction to be collected in a CSR NFT designated by the smart contract developer. The CSR NFT’s owner can redeem the accumulated Canto at any time, and can specify how much of the available Canto they desire to withdraw.

Initially, 20% of the base fee will be allocated to the designated CSR NFT, but this can be adjusted through governance. An individual CSR NFT can accumulate fees from multiple smart contracts, but each smart contract can only direct its transaction fees to one CSR NFT.

We are excited for the launch of CSR because it enables developers to focus on maximizing good for the ecosystem by providing them with a sustainable form of compensation that does not involve playing token games or imposing protocol fees on users. Instead, developers can solely concentrate on promoting usage and enhancing their products.

Furthermore, unlike community grants, CSR scales with a protocol's growth. As the protocol becomes more successful and attracts more usage, the revenue generated from CSR will also increase.

Potential Applications of CSR:

We believe CSR opens up a new set of opportunities in protocol development, along with improving incentives for developers. Let’s dive into a few.

CSR creates a new structure for financing and investing in protocols. CSR NFTs can be fractionalized and sold, allowing the community to support protocols they believe in. CSR benefits public goods specifically because they can directly generate revenue through gas fees, making them a much more appealing investment opportunity. Additionally, CSR NFTs can be wrapped in ways that allow free flowing customizability, such as adding governance powers, voting escrow and gauges, and any other complex token mechanism. Here is an example of how a CSR NFT’s ownership might be fractionalized:

We expect this to drive a significant increase in capital investment for protocols and public goods projects. To determine the value of CSR NFTs, investors will have to consider various factors such as the projected price of Canto, the projected average cost of gas, the projected number of transactions on Canto, and the projected usage of the specific protocol.

The use of CSR NFTs as collateral can open up a range of lending opportunities and enable liquidity. For example, a protocol can lock up a CSR NFT and allow the owner to borrow against the predicted future earnings of it. Interest rates for this type of loan will likely be high due to the level of risk, but well-established blue-chip protocols will have access to better rates and greater borrowing power. A new lending market centered around providing leverage for CSR NFTs is entirely possible. The broader impact of this will be an increase in liquidity across the ecosystem, especially for developers.

CSR also provides an easy way to share compensation amongst a team working on a protocol. One CSR NFT can accrue revenue from multiple different smart contracts, allowing a team to more easily pool its revenue from multiple protocols. Furthermore, when Canto is withdrawn from a CSR NFT, the recipient can be specified, creating an easier means for sending and tracking compensation across multiple stakeholders.

CSR lowers the barrier to entry for protocol development. CSR enables key pieces of infrastructure to generate revenue while also being free and publicly available to other users. This allows builders to utilize existing infrastructure to develop their own protocols at a much lower cost. Additionally, as teams no longer need to compete for liquidity, we will see an increase in the development of integrations and infrastructure across Canto. Teams can utilize freely available liquidity from FPI, and will be incentivized to build on top of existing FPI versus competing for liquidity. This will create an ecosystem where liquidity is less dispersed and used far more efficiently.

These are just a few of the endless possibilities created by CSR. We are excited to see how developers will implement CSR across a plethora of other use cases!

How to use CSR?

After learning about various potential use cases for CSR, it might be helpful to give a general overview of how to implement CSR in your protocols. When a smart contract developer wants to enable CSR for a protocol, they need to register the desired smart contract with the CSR Module Store. The CSR Module Store is a Cosmos SDK module that holds a registry of all the deployed CSR contracts and CSR NFT IDs.

Since the CSR Module Store exists on the consensus layer (Canto Native), we need a way to interact with it on the Canto EVM during contract deployment. To solve this issue, contributors developed the Turnstile.sol smart contract which registers contracts on behalf of the CSR Module Store. To do this, contract deployment transactions need to call the register function from Turnstile.sol and specify the address of the CSR NFT (a new one is minted if not specified).

Once this is done correctly, the transaction flow for a smart contract registered with CSR will look like the following:

When a smart contract interaction occurs, the Ethermint module will process the transaction and check if that smart contract is registered in the CSR Module Store. If it is, 20% of the base fee paid will be sent to the CSR NFT.

To learn more about implementing CSR, check out the Canto documentation. Contributors plan to release more documentation soon on using CSR to make it as easy as possible for developers to implement.

We are excited to see how CSR will impact the Canto ecosystem and are eager to see the protocols that will be launched with this technology! To read more about CSR click here.

About Plex

Plex is a group of builders with backgrounds in HFT, mechanism design, and software development. We are currently exploring the intersection of decentralized finance and social coordination. If interested in collaboration, please reach out at twitter.com/Plex_Official.

Canto’s journey dates back to March of last year when several contributors got together and discussed the vision for Canto: a DeFi focused L1 powered by Free Public Infrastructure (FPI). Contributors saw issues with the existing incentives for liquidity providers, and realized that core DeFi infrastructure is optimal when operating as FPI funded by the network.

At the time, there was no other blockchain that operated in this way, and contributors saw an opportunity to create something new and innovative. So, along with other contributors, we decided to turn our thoughts into actions and began building the initial version of Canto.

Fast forward to July, contributors unveiled Canto to the public and announced the first major community event: Settlers of Canto. This was Canto’s testnet event, and while it only ran for a single weekend, it was exciting to see tens of thousands of users interacting with Canto’s FPI. Importantly, we received valuable user feedback throughout the event and saw first hand the broader community join in on the discussion surrounding sustainable infrastructure and incentives.

Canto mainnet was launched 1 month later, and it began to quickly gain traction.

In less than 1 month, Canto’s TVL grew to over $100M. 2 month’s later, Canto’s TVL reached $150M+.

However, while TVL growth is amazing, what’s been more meaningful to us is the growth of the Canto Ecosystem.

Canto Ecosystem

Since the launch of Canto, a primary focus of contributors has been growing the ecosystem. A blockchain cannot thrive without a strong community of builders. We’ve seen strong growth in the number of teams developing projects on Canto, and this number is increasing month over month.

NFTs have started to grow on Canto – projects such as Canto Longnecks and CanToes have been picking up traction. Canto Longnecks have already minted out and experienced over 1.3M $CANTO of trading volume on secondary markets such as provenant.art and Alto.

We have also seen several projects being developed across DeFi, Gaming, Infrastructure, and other sectors. These projects include an auto-harvesting protocol, a decentralized naming service, and even an on-chain game of roulette.

The Canto Online Hackathon, which runs on a monthly basis, has also played a major role in growing the Canto ecosystem. It's been amazing to watch 35+ projects actively developed through the Hackathon, and we are excited to see the many more to come in 2023.

Free Public Infrastructure

In the 5 months since launch, it has been exciting to see significant usage of Canto’s FPI.

The total trading volume across the Canto DEX’s 5 LP pairs has been over $650M. The best part is, this has saved users a significant amount of money because the Canto DEX has zero swap fees.

Assuming a fee of 0.3% for volatile pairs on most DEXs, and 0.05% for stable pairs, over $1M has been saved due to no swap fees over this period.

$NOTE, Canto’s unit of account, has also seen significant traction. In order to introduce Note into circulation, users must borrow it from the Canto Lending Market, and provide a stablecoin asset as collateral. Over the past 5 months, there has consistently been over $15M Note in circulation, and as of today, there is over $18M Note in circulation.

Key Canto Upgrades

Since Canto’s launch, contributors have not lost sight of Canto’s vision, and have continued to improve Canto’s FPI. One of our key focuses has been engaging with users to understand their pain points. We have spoken with hundreds of users through platforms such as Twitter and Discord.

One of the most common issues users have brought up is that they have found it difficult to bridge assets onto the Canto network. To help users improve their bridging experience, contributors reached out to the team at Synapse Protocol, and Canto was successfully integrated with the protocol last month.

Additionally, after compiling specific feedback on the Canto FPI experience, we started working alongside other contributors to develop a second version of the interface for Canto’s FPI. We rolled V2 out in December, and included features such as an interactive walkthrough on the bridging flow.

Another initiative we began with several contributors in 2022 is the development of CIP-1: Contract Secured Revenue (CSR). Ultimately, a network’s ability to attract developers is only as strong as the incentives it provides to them. We are excited by the possibilities of how CSR will change the way smart contract developers earn from their work, and provide incentives in a manner that aligns with Canto’s vision for Free Public Infrastructure. CSR is planning to launch very soon, stay tuned!

As a team, building Canto has been a transformative experience for us. We are thankful for the opportunity to work with amazing contributors who believe in the vision of Canto. 2022 has been a strong year for Canto, and we look forward to an even more prosperous year in 2023.

About Plex

Plex is a group of builders with backgrounds in HFT, mechanism design, and software development. We are currently exploring the intersection of decentralized finance and social coordination. If interested in collaboration, please reach out at twitter.com/Plex_Official.

The following outlines some of the specific changes we’ve made.

Canto Bridge

• The Convert Coin page has been deprecated.

  • We’ve merged the Covert Coin webpage and the Canto Bridge into a singular bridging interface, where users can bridge from Ethereum through the Canto Bridge, and into the Canto EVM on the same webpage.

• A transactions tab has been added to track the status of funds that are being bridged.

  • Users will be able to see funds that are currently being bridged, and all funds of theirs that have been bridged in the past.

• Capability to bridge directly to the Cosmos Hub.

  • Users can now use the Canto Bridge to bridge directly to the Cosmos Hub, and no longer need to use Gravity Bridge to send funds from Canto → Cosmos Hub.

• Bridge In and Bridge Out are now individual tabs.

  • The direction of bridging is now two separate tabs, making the flow of assets increasingly clear.

Canto LP Interface

• Supply LP tokens into the Canto Lending Market in the same modal as providing liquidity.

  • We’ve made it easier to earn rewards for providing liquidity, by allowing users to also supply the LP tokens they receive to the Canto Lending Market on the same modal.

Canto Lending Market

• Rewards for supplying assets are now more clear.

  • Users can now more clearly see their accrued rewards from supplying in the Canto Lending Market.

Canto Staking

• Search for validators by name.

  • Users can more quickly find any validator of their choice through a search bar on the validators tab.

• Filter between active and inactive validators.

  • Users can now filter between active and inactive validators, and avoid accidentally delegating to validators that are no longer active.

• Better overview of current staking positions.

  • All current staking positions are displayed under the “my staking” tab. Users can now view all validators they are currently staked to and in the process of undelegating from in one page.

• Staking delegation modal includes separate tabs for delegating, undelegating, and redelegating Canto.

Canto Governance

• Improved proposal voting experience.

  • Users can now see the impact their vote will have on the governance proposal, as well as an improved pie chart of the current voting status.

  • Proposal details are easier to view since they are now expanded further after being clicked.

Other than these specific changes, the frontends have also received changes in fonts and overall design for an enhanced experience.

We appreciate all of your feedback and will continue utilizing the community's feedback to improve Canto's FPI on an ongoing basis. Please feel free to report any feedback here.

About Plex

Plex is a group of builders with backgrounds in HFT, mechanism design, and software development. We are currently exploring the intersection of decentralized finance and social coordination. If interested in collaboration, please reach out at twitter.com/Plex_Official.

In the weeks since, the Plex team has conducted an extensive audit of the Canto codebase, and specifically our custom GovShuttle module. We are pleased to confirm we have identified the cause of the bug – non-determinism in the GovShuttle module – and mitigated it with the release of the v4.0.0 Canto validator binary.

Below, we provide a post-mortem of the bug in the interests of furthering the Cosmos SDK and Ethermint ecosystems and providing transparency to both Canto users and validators.

Timeline

• September 18 – Block 804214

  • On submission of proposal 16: a GovShuttle proposal intended to update comp speeds in CLM caused some nodes to fail.

  • Nodes that failed used a snapshot from block height > 804214 originating from a node that did not fail in order to run their nodes again.

• October 18 – Block 1244562

  • On execution of proposal 23: a GovShuttle proposal that passed in the voting stage did not append a lending market proposal to the mapContract .

  • All nodes were intact

  • Proposal appeared successful with no error messages

Description of Issue:

The AppendLendingMarket function of the GovShuttle module is a function that is called on submission and execution of lending market proposals and is intended to append the proposal metadata to the mapContract on the Canto EVM. In Canto v3.0.0, the address of the mapContract is stored in the keeper using the following lines of code:

if nonce == 0 {
    *k.mapContractAddr, err = k.DeployMapContract(ctx,lm)
    if err != nil {
        return nil, err
        }
        return lm, nil
    }

This code checks if the nonce of the GovShuttle is 0, and if so, sets the mapContractAddr to the deployed mapContract’s address. The GovShuttle nonce is only 0 if no lending market proposals have been submitted. On execution of the first lending market proposal, the GovShuttle will deploy the mapContract to the EVM and the nonce will increment by 1.

The following lines of code show the CallEVM function call that is used to append the lending market proposal metadata to the mapContract:

_, err = k.erc20Keeper.CallEVM(ctx, contracts.ProposalStoreContract.ABI, types.ModuleAddress, *k.mapContractAddr, true, "AddProposal", sdk.NewIntFromUint64(m.GetPropId()).BigInt(), lm.GetTitle(), lm.GetDescription(), ToAddress(m.GetAccount()), ToBigInt(m.GetValues()), m.GetSignatures(), ToBytes(m.GetCalldatas()))

Since this EVM call uses the keeper storage to determine the mapContractAddr, non-determinism between nodes was introduced. Nodes that persisted the keeper storage on their memory would have the correct mapContractAddr, whereas nodes who lost the keeper storage would use nil as the address value.

This means that the first lending market proposal would always be successful, while subsequent proposals would have an increasing likelihood of failure as time went on. Eventually, it is likely that all nodes would lose the GovShuttle keeper storage on memory and all nodes would use nil as the address value.

This explains the behavior of the bugs that occurred on mainnet. The first 2 lending market proposals, 7 and 8, were successful and caused no issues for any nodes. Proposal 7 set the address in the keeper storage using the code from snippet 1, and because proposal 8 followed shortly after, the address persisted in each node’s memory. All nodes had the same correct map contract address during this time.

However, proposals 16 and 18 caused some nodes to appHash and fail. These proposals were submitted 30 days after proposals 7 and 8. During this 30 day period, it is likely that some nodes lost their keeper storage in memory due to reboots. As a result, the nodes that persisted the correct mapContractAddr stayed up and nodes with nil value as the address failed.

The most recent lending market proposal (proposal 23) did not cause any nodes to appHash and was submitted successfully. On execution it did not append the proposal metadata to the mapContract as intended. As this was 60 days after the address was first written to the keeper storage, it is likely that all nodes were using the nil value at this point. It is also possible that the recent chain upgrade from v2.0.0 to v3.0.0 and the planned upgrade halt cleared the keeper storage for all nodes. Since all nodes were using the nil value as the address to write the proposal metadata to, no nodes failed and the proposal was not successfully written.

Resolution

The fix for this bug was quite simple. The only code change required was to persist the mapContractAddr to the KV store. This ensures that the address stays consistent and prevents any non-determinism amongst nodes. 

For more information on the custom GovShuttle module, you can review Canto governance documentation as well as our initial overview.

About Plex

Plex is a group of chain-native builders with backgrounds in HFT, mechanism design, and software development. We are currently exploring the intersection of decentralized finance and social coordination. If interested in collaboration, please reach out at twitter.com/Plex_Official.

Participation:

• 26,000 unique settlers

• 34,000 unique visitors to the testnet site

• 43,000 transactions across the Canto DEX and Canto Lending Market

Settlers Feedback:

The reception we received allowed us to test how Canto’s nodes and primitives responded to a large volume of users. Additionally, thousands of settlers gave feedback through surveys, DMs, and messages in the Settlers telegram, allowing us to find issues in the UI/UX and rapidly iterate the protocols.

For example, one settler gave the following feedback:

1. Issue adding liquidity in the DEX LP page - i was adding CANTO + ETH - by default, CANTO was on the left side + ETH was on the right - i chose max ETH, and CANTO amount auto-populated as expected - but when i clicked "add liquidity," some kind of JSON error message came up on the webpage; MetaMask was never triggered - so i switched the order of the assets; i.e., i made it so ETH was on the left and CANTO was on the right - all worked fine after doing that.

2. Issue supplying CANTOETHLP tokens on the lending page - when i got to the step of generating a tx to supply my LP tokens, I clicked "max," and the total amount of LP tokens auto-populated - but then when i clicked the button to supply, the word "canceled" came up somewhere on the screen, and MetaMask wouldn't trigger - i tried again, and this time, i lopped off a bunch of decimal places at the end of the LP token amount - don't recall how many decimal places, but i think I left only 6 - after doing that, everything was fine + i was able to supply.

Other settlers gave feedback such as:

• a non-sticky cursor when entering values in modals

• hypothetical borrow limits not changing when supplying to a non-collateralized asset

• mobile UI/UX improvements

• resizing issues with the webpage on certain browsers

Using these insights, we were able to update our front ends to allow for more seamless interactions between users and Canto’s primitives.

Overall Reception:

Universal accessibility and ease of use are core values of Canto’s primitives. We were happy to see that many settlers experienced this during the Settlers of Canto testnet. One settler commented:

“It looks like a simple application united under one window. away from the complex structure of crypto is beautiful.”

Another said:

“I really like the way NOTE works. I also see very interesting the possibility of being able to add collateral LP tokens.”

Settlers of Canto allowed us to thoroughly test our platform with thousands of real users. We were able to engage with our community and introduce Canto’s primitives in an interactive manner.

Will testnet contributors join the genesis block?

Be sure to follow and turn on notifications for @CantoPublic.

About Plex

Plex is a group of chain-native builders with backgrounds in HFT, mechanism design, and software development. We are currently exploring the intersection of decentralized finance and social coordination. If interested in collaboration, please reach out at twitter.com/Plex_Official.

Passing information from SDK Module to EVM:

The GovShuttle module is a Cosmos SDK module that unifies network and DApp governance. The module allows stakers of Canto to create and vote on governance proposals that can be transported to a proposal store contract called Port on Canto’s EVM. On initialization, GovShuttle’s keeper checks to see if the Port exists. If it hasn’t been deployed, the keeper will use the DeployMapContract function to deploy the Port.

if nonce == 0 {
  *k.mapContractAddr, err = k.DeployMapContract(ctx, lm)
  if err != nil {
    return nil, err
  }
  return lm, nil
}

This contract is wholly owned by the module itself and cannot be modified by any other account. Deployment of this contract is handled by the GovShuttle’s keeper and at its core utilizes the Create function in Geth.

After deployment of the Port, users have the option to submit special proposal types that are routed to the GovShuttle. On passing, the GovShuttle’s keeper calls a function called AppendProposal , which uses Geth’s Call function to add the proposal’s data to the Port. The Port can then propagate these proposals to DApps on the EVM.

func handleLendingMarketProposal(ctx sdk.Context, k *keeper.Keeper, p *types.LendingMarketProposal) error {
  err := p.ValidateBasic()
  if err != nil {
    return err 
  }
  _, err = k.AppendProposal(ctx, p)
  if err != nil {
    return err 
  }
  return nil 
}

Reading Shuttled Data in EVM:

Reading a proposal written to the Port is as simple as querying the contract using the function QueryProp. This function takes in a proposal id as an argument and returns the corresponding proposal’s data. In doing so, contracts on Canto’s EVM can now read data from proposals passed from the Cosmos SDK. This allows any application to become a Free Public Good by integrating its governance directly into network governance with very little modification. Technically speaking this system can be generalized for any form of cross runtime information passing including additional proposal types allowing for a highly flexible, application-agnostic interface.

Below is a visual representation of how this system works:

By using GovShuttle and generalizing it further for additional data types, Canto stakeholders can govern an arbitrary number and type of applications on the EVM. This will allow our community to have the control and flexibility over Free Public Infrastructure that is necessary for the stability and growth of Canto.

About Plex

Plex is a group of chain-native builders with backgrounds in HFT, mechanism design, and software development. We are currently exploring the intersection of decentralized finance and social coordination. If interested in collaboration, please reach out at twitter.com/Plex_Official.