[IDEA] Enshrined Infra for Neutron dApps

[Spaydh]

Introduction

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 allows smart-contracts to register and control accounts on other domains, as well as pass, execute, track and callback transactions on other networks.

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)

💡 The ICQ module allows smart-contracts on Neutron to register queries for data stored on remote networks, to be delivered at set intervals by third party relayers.

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

• Docs: https://www.notion.so/hadron/Neutron-Enshrined-Features-Roadmap-eedf354a51524a5c9af1b47e62c7dd3c
• Github (x/ICQ): neutron/x/interchainqueries at main · neutron-org/neutron · GitHub
• ICQ Relayer: GitHub - neutron-org/neutron-query-relayer: Relays interchain queries inside Cosmos interchain

[Live] CRON Module

💡 The CRON module allows the Neutron DAO to register cosmwasm messages to be executed in EndBlockers every `x` blocks.

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

• Docs: Overview | Neutron Docs
• Github (x/CRON): neutron/x/cron at main · neutron-org/neutron · GitHub
• Neutron SDK: ‣

[Dec 23] Block SDK

💡 The Block SDK is a toolkit for building customized blocks. The Block SDK is a set of Cosmos SDK and ABCI++ primitives that allow chains to fully customize blocks to specific use cases. It turns your chain's blocks into a `highway` consisting of individual `lanes` with their own special functionality.

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

• Docs: ✨ Block SDK Overview | Skip Protocol Docs
• Github: GitHub - skip-mev/block-sdk: 🎨 Programmable Block Building

[Dec 23] Duality DEX

💡 Duality is an hybrid AMM - order book which allows any AMM curve, it’s liquidity and it’s orderflow to be aggregated into a single venue. This makes it easier to bootstrap new AMM-based protocols, reduces computational costs and strengthens the onchain oracle price.

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

• Docs: What is Duality? - Duality Documentation
• Github: GitHub - duality-labs/duality
• Upgrade proposal draft: [PROPOSAL #25] Neutrality Upgrade
• Vision: The End of Fragmentation. How Neutron, Astroport and Duality are… | by Neutron.org | Medium

[Q1-Q2 24] Slinky Oracle

💡 Developed by Skip, Slinky would leverage vote extensions to allow validators to attach price feed data to their votes. dApps can leverage the in-protocol oracle to ensure they rely on price data which the validator set has come to consensus over.

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

• Docs: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
• In active development, more will be shared when available!

Feedback!

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?