[IDEA] Enshrined Infra for Neutron dApps


Since it’s inception in May this year, Neutron has grown and evolved quite tremendously.

One particular change that has come to mind with the approval of the Neutrality proposal has been a shift from providing cross-chain infrastructure solely to a more holistic approach of the services the network can provide to smart-contract builders.

In this new mindset, Neutron’s core mission could be phrased as “bringing application specific infrastructure to smart-contracts”, or, as a contributor from Skip Protocol cheekily put it “the power of an appchain into the form factor of a contract”.

Interestingly, such a shift has implications on ecosystem building initiatives from the DAO. Application specific infrastructure is a tool: its value isn’t intrinsic, it lies within the applications that couldn’t be built without it.

Not every builder in DeFi has the depth of knowledge/design to hit the limitations of their underlying platform. But some, usually among the best/most ambitious ones, do. Duality’s story is a great example in this regard: their journey started on Ethereum, where the limitations of the EVM prevented them from bringing their vision to life. They moved to Cosmos explicitly to leverage ABCI++, shape consensus etc. to build a breakthrough product.

Focusing on app-specific infrastructure and the advanced developers that can effectively wield it should be an intentional decision. Neutron is currently well positioned to pursue this direction, given its close relationship with some of the few Cosmos teams that have operated DeFi products at scale (Astroport, Mars, Apollo, etc), its early ecosystem recognition as the best CW smart-contract platform to be building onto in the ecosystem, and its close ties to Ethereum and Celestia developer pools.

For the sake of conversation, I thought it would be useful to share where Neutron currently stands on app-specific infrastructure and where it could get within the next few quarters.

App-Specific Infrastructure on Neutron

[Live] Interchain Transactions (ICTX)

The Interchain Transactions module manages the creation of IBC Accounts and executing interchain transactions on behalf of CosmWasm smart contracts. The current implementation allows a smart contract to:

  1. Register multiple interchain accounts on a remote zone using an existing IBC connection;
  2. Execute transactions with multiple messages on a remote zone;
  3. Process the OnChanOpenAck, Acknowledgement and Timeout events as they are delivered by a relayer.

Example applications

  1. Liquid Staking: Receive and delegate native tokens on other domains remotely from smart-contracts on Neutron
  2. Lending/Borrowing: Receive and manage collateral deposits from any domain
  3. Governance: Control contracts deployed on other domains via a central governance instance on Neutron

Useful resources

  1. Docs: Overview | Neutron Docs
  2. Github (x/ICTX): neutron/x/interchaintxs at main · neutron-org/neutron · GitHub
  3. Neutron SDK: GitHub - neutron-org/neutron-sdk

[Live] Interchain Queries (ICQ)

A smart-contract can register two types of Interchain Query for particular chain with some query payload and update_period:

  • Key-Value query (KV-query) - to read values from Cosmos-SDK KV-storage on remote chain which are stored under a set of keys;
  • Transactions query (TX-query) - find transactions on remote chain under by condition (transactions filter).

ICQ Relayer keeps track of registered Interchain Queries by querying all existed ICQs at the start of work and by subscribing on Update and Delete events which are emitted in corresponding Neutron handlers. When the ICQ Relayer sees that it’s time to perform an interchain query, it makes a necessary RPC call to a remote chain and makes the results available for the Neutron’s smart contracts by submitting the result to the module. Read more about it at the Relayer’s page.

Neutron verifies the data and processes the query result depending on the interchain query type:

  • in case of a KV-query, the ICQ module saves the result into module’s storage, and passed the query id to the contract’s SudoKVQueryResult handler;
  • in case of a TX-query, the ICQ module does not save the result to the storage, finds the contract that registered the query, and passes the full result to the contract’s SudoTXQueryResult handler.

Example applications

  • Airdrops: Distribute tokens based on remote conditions such as staking balances or trading activity
  • Oracle: Retrieve price feeds for exotic assets not supported by traditional web3 oracles by query remote dexes
  • Membership: Provide privileged access to a DAO or dApp to holders of specific NFTs on Stargaze or other remote networks.

Useful resources

[Live] CRON Module

Example applications

  • Auto-compounding: automate the compounding of liquidity or staking positions on Neutron (or combine with the ICTX to do so across an arbitrary number of networks).
  • Trustless conditional execution: replace keepers with automated conditional execution. This generally helps reduce reliance on potentially inconsistent bot networks to trigger liquidations, execute governance proposals, and perform other important tasks.

Useful resources

[Dec 23] Block SDK

Skip has built out a number of plug-and-play lanes on the SDK that your protocol can use, including in-protocol MEV recapture and Oracles! Additionally, the Block SDK can be extended to add your own custom lanes to configure your blocks to exactly fit your application needs.

Example applications

  1. Free/reduced fee txs: transactions with certain properties (e.g. from trusted accounts or performing encouraged actions) could leverage a free lane to facilitate good behavior or user onboarding.
  2. Dedicated oracle space Oracles could be included before other kinds of transactions to ensure that price updates occur first, and are not able to be sandwiched or manipulated.
  3. Enhanced and customizable privacy: privacy-enhancing features could be introduced, such as threshold encrypted lanes, to protect user data and maintain privacy for specific use cases.
  4. Fee market improvements: one or many fee markets - such as EIP-1559 - could be easily adopted for different lanes (potentially custom for certain dApps). Each smart contract/exchange could have its own fee market or auction for transaction ordering.

Useful resources

[Dec 23] Duality DEX

Duality seeks to solve problems associated with liquidity and orderflow fragmentation for application developers, flexibility for liquidity providers and preference expression for traders.

Traders are able to express their preferences through various order types (e.g., fill-or-kill, good-until, limit…)

Liquidity providers are able to approximate any feasible AMM curve (liquidity distribution)

Application developers can piggyback off of the existing, shared orderflow and liquidity already in the Duality module.

Example applications

  • Orderbook-out-the-box: Applications can integrate with Duality to provide orderbook functionality and order types out of the box. Aggregators and alternative front-ends can monetize the trading flow they bring in by routing orders through their own contract.
  • Any AMM (Weighted pools, Stableswaps, Constant Product) : Build and monetize any AMM curve you can imagine.
  • Liquidity Vaults : Vault protocols can run strategies that seek to accomplish objectives such as maximizing fee revenue or supply liquidity on a DAO’s behalf. For example, a vault can manage an LST liquidity position

Useful resources

[Q1-Q2 24] Slinky Oracle

Example applications

  • Sports betting: retrieve off-chain sports result to run trust-minimized on-chain betting applications.
  • Perps: list exotic assets by retrieving prices in consensus
  • Futarchy: create governance systems that reward/punish voters based on the accuracy of their decisions

Useful resources


Under considerations

The following contain very high level, mostly pre-spec ideas of features which might be valuable to advanced developers looking to build breakthrough apps/rollapps. Inclusion here doesn’t mean it should be built or is a good idea.

  • Decentralized Front-Ends: A system to free core teams from the burden and risk of operating front-ends for dApps by enabling them to contribute to open source code which gets ran by validators in a decentralized manner. Potentially could leverage capacities from other projects in the ecosystem such as Akash etc.
  • In-protocol DA attestation: A system to enable contracts on Neutron to retrieve DA attestations from Celestia to enable dApps/Rollups/Bridges on Neutron to verify data availability for specific data on Celestia, to improve the security guarantees of rollups/bridges on Neutron and such. This is definitely possible as it has already been specced out by Neutron contributors.
  • In-protocol zk verification for CosmWasm contracts
  • Enshrined dispute resolution mechanism for rollups, similar to that being worked on by Dymension
  • Etc.

How can Neutron help?

Calling all builders - your feedback helps us improve. What app-specific infrastructure do you need to build applications that are 10x better than the competition?