Introduction: The Pain of IBC Development
1. Abstract v0.22: Your IBC Hero
2. CosmWasm IBC vs. Abstract
3. Streamlined Experience for IBC Pros
4. Enhancing The Abstract Experience
Conclusion: Abstract — Making IBC a Breeze!

Introduction: The Pain of IBC Development

Back at Cosmoverse Istanbul 2023, I wore a T-shirt proclaiming Debugging IBC is such a PAIN!

And you can’t disagree with that. The lack of tooling, the various complicated handshakes and endpoints (Channel , Packet , Client , packet_receive…) are indeed challenging when developing simple IBC applications. Despite its strengths in security and decentralization, IBC presents significant difficulties due to insufficient tooling and abstraction, similar to forcing an app developer to manage TCP and HTTP protocols for every StackOverflow query they have.

Abstract v0.22: Your IBC Hero

As underlined in every written piece about Abstract:

Abstract builds tooling to streamline the on and off-chain CosmWasm developer experience in building Interchain applications

For over a year, the Interchain Abstract Accounts have provided users with a single account across the entire IBC ecosystem, enabling transactions across multiple blockchains without leaving their home-chain. This eliminates the need for bridging, managing gas tokens, and switching wallets, offering a seamless IBC experience within users’ comfort zones. The Abstract 0.22 release further simplifies sending and composing IBC messages without multiple transaction signatures.

Now, we also aim to simplify IBC for developers. This update introduces essential features and simplifications to facilitate creating IBC applications without delving into protocol specifics.

CosmWasm IBC vs. Abstract

CosmWasm smart contract all have the capability to send IBC messages. However, as a developer, regular IBC inside smart-contracts requires :

• Implementing 6 additional entry-points, 2 of which should never fail
• Creating and maintaining IBC channels, which is a huge Dev-Ops challenge on its own (and what smart-contract developer really likes Dev-Ops anyway ?)
• An extra mind-juggling effort to understand and remember all the IBC lingo.
• Learn more about all the necessary steps here

With Abstract and for simple IBC applications, you simply need to add 1 endpoint to receive packets. This allows for simpler and more composable applications thanks to simple implementation patterns and the diminished overhead.

Streamlined Experience to make you an IBC Pro

More advanced IBC applications will obviously need more tooling than a single IBC endpoints. Abstract also provides a simplified interface for experienced IBC developers to allow for a modular and inter-operable experience. Let’s dive in some code to illustrate the Abstract Interchain developer experience. If some of the single-chain endpoints are not familiar to you, check out the official documentation to learn more. The following sections present the difference between the single-chain and multi-chain experience inside Abstract smart-contracts.

Module to Module IBC

Abstract 0.22 introduces a feature to allow modules to communicate with one another seamlessly over IBC, without you as a dev having to worry about authentication, callback logic, channels, packets, clients, or anything related to IBC. It just works. How?

Sending Messages

Sending IBC messages is easy. You need to specify, the chain you want to communicate with, a receiver, the message and an eventual callback parameter. The structure looks like this :

// Single-chain experience
let msg = wasm_execute(contract_addr, msg, funds)?;
// IBC experience
let msg = app
      .ibc_client(deps.as_ref()) 
      .module_ibc_action(host_chain, target_module, exec_msg)?;

With this syntax, you see that it’s as easy to send a message as you would any CosmosMsg.

Receiving Messages

Abstract introduces an additional endpoint in its framework that can only be called by Abstract core contracts when another modules sends an IBC message. This endpoint looks like this:

// Single-chain experience
fn execute(deps: DepsMut, env: Env, info: MessageInfo, msg: ExecuteMsg)
// IBC experience
fn module_ibc(deps: DepsMut, env: Env, info: ModuleIbcInfo, msg: Binary) 

pub struct ModuleIbcInfo {
  pub source_chain: ChainName,
  pub source_module: ModuleInfo,
}

Similarly to receiving a message through the execute endpoint, you get the deps , env variables. The info variable in the IBC case contains information allowing to identify the original caller of the messages, just like the usual MessageInfo variable. It allows simplifying access-control for developers.

Action callbacks

In some cases, you want to be able to execute code depending on the execution result of an IBC message. You can specify the need for a callback in the original message using the callback_info field. Here is its structure:

pub struct CallbackInfo {
    /// Used to identify the callback that is sent (acts like the reply ID)
    pub id: String,
    /// Used to add information to the callback.
    /// This is usually used to provide information to the ibc callback function for context
    pub msg: Option<Binary>,
}

Similar to reply , you have an id which will be propagated back to the Abstract callback endpoint to identify which callback handler should be used. The additional msg field allows you to pass additional information to the callback (for example some context, the original message you sent…).

To receive the callback, you implement an additional endpoint :

// Single-chain experience
fn reply(deps: DepsMut, env: Env, reply: Reply);
// IBC experience
fn ibc_callback(deps: DepsMut, env: Env, msg: IbcResponseMsg);

pub struct IbcResponseMsg {
    /// The ID chosen by the caller in the `callback_info.id`
    pub id: String,
    /// The msg sent with the callback request.
    /// This is usually used to provide information to the ibc callback function for context
    pub msg: Option<Binary>,
    /// The execution or query result (because YES you can also query remote chains !)
    pub result: CallbackResult,
}

Callbacks are secure because they can only be received on the module that dispatched them. This ensures security of execution and makes sure that all the IBC interactions are secure !

Enhancing The Abstract Experience

In addition to onboarding every dev to the Interchain, Abstract has simplified the developer experience throughout its framework. Here is a non-exhaustive list of the additional changes that were brought to the framework in the last month:

- Multiple API changes were made (interface macro, re-exports…) in order to making the library more accessible to all developers, new or experienced.
- We made the namespace claiming process permissioned on Mainnet to avoid namespace pollution, squatting and impersonation.
- We tested and iterated on the Abstract client library to smooth the on-boarding of all kinds of developers. We added numerous features and simplified the API (Name Service builder, IBC helpers, apps, accounts retrievers…)
- We added an Authz API to facilitate the use of this complicated module inside Abstract Apps

Conclusion: Abstract — Making IBC a Breeze!

Abstract v0.22 comes with wonderful new IBC features that Abstract everything complicated about cross-chain communication :

• No more Dev-Ops for IBC interactions (say bye to channels, relayers,…)
• The execution flow is exactly the same as the CosmWasmsubmessage-reply flow, developers don’t need to learn more things to use IBC !

To learn more about it, check out:

• The v0.22 Changelog
• Our official documentation
• The Abstract IBC documentation
• Our Discord channel for support, we want to help you !
• Our Twitter for more announcements
• Our YouTube channel for workshops and tutorials!

Be Abstract. Think Interchain.

Abstract v0.22: Simplifying The IBC Experience was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Cosmic Encounter

At Cosmoverse, Howard was the first human with whom I dared talk (albeit awkwardly) at the conference, where we discovered a mutual obsession with Terra and Luna. LFG! Like many others, this stemmed from the incredibly lucrative “risk-free” yield farming opportunities on Anchor and Mirror (may they rest in peace).

Cosmoverse was my first IRL crypto conference, my roots having been in the EVM space. I ended up in Cosmos due to its truly decentralized ethos which is starkly different from other globalist ecosystems — and shoutout to Cryptocito for highlighting it! On the other side, Howard was CTO at White Whale, a protocol delivering some of the most advanced DeFi products in Cosmos at the time. I was a bit starstruck by him and Sunny to say the least, my professional software experience only having been as a corporate cog.

Bidding Adieu to Big Corporate

At the time, I was part of an amazing team at AWS: a giant corporate structure with startup-like teams and a culture that matched. I loved my team and my autonomy, though the limitations of web2 quickly became glaring. One could have a tremendous impact on customers and profitability, though web2 is not a meritocracy and the cog reaps no rewards from the performance of the engine. I booked a flight to Belgium to work with Howard IRL. Good morning su… cloudshine?

A Problem with Web3

Decentralization is inevitable. Though by definition, decentralization means fragmentation, and this is ever-clear with the development of the Cosmos ecosystem and web3 at large. On Ethereum, everyone is building on the same protocol, hence why collaboration is is incentivized to drive value to that protocol. Cosmos is a different story. Application-specific protocols — read applications — are the basic unit of value-capture, and therefore teams are incentivized to build in silos. Collaboration is secondary as it may lead to others beating your application to market. Every team starts from scratch, makes the same mistakes, and wastes effort!

The Idea

Howard ideated DAO-OS as a modular standard in building CosmWasm applications on Terra, aimed at solving the problems with fragmented development. “DAO” because organizations are the base unit of collaboration, and “OS” as it enables execution of applications and control of data flow. This later became Abstract OS as an homage to the abstraction of OSes. Next up: Abstract Hypervisor?

We unveiled Abstract OS at Cosmoverse 2022 in Medellín as a modular application development platform. Its potential was evident with our victory at the first CosmWasm hackathon with Equilibrium, a cross-chain, auto-balancing portfolio application. However, we weren’t satisfied.

Thinking Bigger

The web3 design space is relatively unexplored. Ethereum is not a global compute platform, and Cosmos has yet to realize its localist vision as the “internet of blockchains.” In comparison to the timeline of computing, it seems that we are in the 1970s with use of “general-purpose” blockchains akin to computer timesharing. It follows that decentralized personal computers, personal virtual machines (VMs) will become more prevalent, with value-creating applications preceding their adoption. The future of computing is self-sovereign.

Abstract is built with the personal VM in mind, allowing each individual to have their own personal chain, the new era of the PC.

A Holistic Application Platform

Abstract’s vision is to align the incentives between developers and users, forming a symbiotic ecosystem that fosters collaboration. Innovation comes as a natural byproduct.

For developers, Abstract offers a modular approach to building applications. This is reminiscent of microservices in the web2 realm, enhancing scalability and flexibility, while significantly reducing total engineering time. These components can be monetized, providing sustainable income and incentivizing continued maintenance. And when it comes to applications’ go-to-market, Abstract provides a solution for the cold-start problem — that initial hurdle of attracting users to new applications — with its application platform.

On the other hand, Abstract is the end-user’s personal application platform, serving as a portal to a wide variety of consumer applications. It’s an environment where they can directly impact development by providing direct feedback, enabling rapid iteration and improvements.

Technically, Abstract is a Wasm VM-agnostic application layer, using CosmWasm for its robust framework and IBC for seamless interoperability. For the end-users? They just use the apps. Much like the internet, the interchain is abstracted away.

Closing Thoughts

And so why do Howard and I get along so well? Well, anybody that knows me will tell you that my head is always in the clouds. I love everything about the ideation process, diving deeper and deeper and finding new ways to transform our lives. Howard is an incredibly grounding force, with a basis in reality, being highly logical and calculated in his actions.

I’m the ideas man, and Howard is the logic man. And this makes us the absolute perfect co-founder combination.

Cheers.

Adair Kelley

Footnotes

1. This day also happened to be when and where I met Vanessa Pestritto, now a lifelong friend and beloved mentor.
2. Howard, along with my dear sister Adele, is one of the few people on this planet crazy enough to learn programmer dvorak at a casual recommendation.

The Founding of Abstract Money was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract

As the technology for decentralization evolves, so should the ideas that surround it. MyFi, short for My Finance, is a new era of decentralized finance (DeFi) that promotes self-sovereign financial applications. MyFi’s inception was sparked by technical advances in smart-contract application development. At its core, MyFi allows developers to vend their decentralized applications (dApps) as consumer software while reducing users’ trust assumptions about that software.

DeFi dApps: A Pragmatic Analysis

Decentralized Applications, dApps in short, are applications hosted on distributed systems, the most common of which are blockchains. Each dApp defines a set of unbreakable rules in code, broadly called smart-contracts. Smart-contracts can be deployed to a blockchain network which ensures that they are executed correctly.

After the application is deployed, any user is free to interact with it by initiating a transaction on that blockchain network. Blockchains use these transactions to share the network’s compute with its users. As applications often get upgraded with new features or bug fixes, the original developers typically remain in full control over these dApps, giving them responsibility for the safety of the contracts’ code.

These properties: a secure execution environment, the monolithic deployment of applications, and the shared access to those applications through transactions is what makes blockchain applications so different. These unique features lead to the birth of Decentralized Finance (DeFi) and the creation of hugely successful dApps. Examples include Uniswap , an automated market maker protocol, and Compound, a lending and borrowing protocol, both of which have attracted billions in capital. So what’s next for this industry as it matures? History has us convinced it lies in software distribution.

Software Distribution

The act of making an application available to users, promptly named “software distribution” has seen its fair share of evolution since the introduction of programmable computers.

In the early days of software development, programs were written and made available through mainframes, big and expensive computers that were shared between user like a valuable commodity. The process of distributing the software written for these behemoths wasn’t very different from how software is deployed and managed on modern blockchains. Developers would:

1. Write their software.
2. Test it on a mainframe (when one was available).
3. Finally, deploy it to a mainframe for others to use the next day.

The process for dApp developers today looks the same:

1. Write their smart-contract.
2. Test it on a public testnet (testing blockchain).
3. Finally, if all seems fine, push it to a mainnet blockchain for public use.

Luckily software distribution have moved a long way since the mainframe era. In the modern age, people have ownership of their own devices like a smartphone or a PC, allowing them to install whichever applications that they like.

Software distribution platforms like the Apple App Store and Google Play Store enabled these device owners to discover and “own” their software by installing it on their own devices. These practices lowered the barrier for users to try out new software and for developers to get their software in the hands of users. This ability to publish software on widely-used app marketplaces enabled smaller teams to compete with software monoliths, launching the era of software startups operated out of musky basements.

While DeFi dApps are technically decentralized as they exist on blockchains, their management is fairly centralized, as most dapps are still hosted services. dApp creators maintain the ability to update their dApps at any time, risking users funds and robbing them of the sovereignty Web3 should bring to users. DeFi as a service is not decentralized.

Abstract Money is bringing dApp ownership back to users and paving way for MyFi: a new era of decentralized personal finance.

MyFi

Self-sovereignty and ownership are foundational values of Web3, nonetheless our status-quo has partly relinquished these responsibilities to on-chain financial services providers. Blockchains give us the tools we need to create public financial infrastructure (DeFi), and using these same tools, we can build sovereign personal financial infrastructure (MyFi).

Over the past two years, we’ve developed the Abstract SDK, a modular framework for dApp development. The Abstract SDK is designed for organizations and individual developers to build composable, distributed applications in a fast, secure, and cost-effective manner.

For maximum composability and extensibility, Abstract Apps are built upon Abstract Accounts, our smart-contract accounts. If you’re coming from EVM, these are similar to a Gnosis Smart Accounts, though far more interoperable (more on that later). Developers using the Abstract SDK build modules: standardized smart-contracts that isolate shared logic and can extend the functionality of an Account, making it an application. These modules can be composed, allowing teams to collaborate in building more advanced applications, component by component.

So every Abstract App is account-based. What difference does it make?

First, it allows users to be in full control of their funds and their applications. Similar to how mobile apps are installed directly on user’s devices, Abstract apps are installed directly on user’s Accounts. The user remains in full control over their installation at all times, and can choose to upgrade to new versions should the developers publish bug fixes or otherwise. And because the contract instance is owned by the user, they can have much finer control over the settings of their applications.

And for developers, letting users self-custody their funds in their personal apps has enormous legal advantages. As teams never gain control over or custody funds, they are much better protected from legal scrutiny. Knowing this up-front can save teams tens of thousands of dollars in legal costs! Contrary to what some people might think, developers don’t actually want the risk of managing funds that are not theirs. Until now, this responsibility has been assumed.

The MyFi model inverts the traditional relationship between users and dApps. As users are now in control, they need a way to discover and manage their applications. Enter the Abstract dApp Launcher: a multi-chain dApp distribution and discoverability platform.

Dapp Distribution and Discovery

With Abstract MyFi, instead of deploying dApps themselves, developers publish their dApps on-chain to the Abstract App Store (shown below).

Interacting with the Abstract App Store will feel familiar. Available dApps are showcased and new releases are featured on the home page. Upon discovery, users can install the dApp directly on their Account, making it available as a shortcut in the Launcher for immediate use.

We’ve designed this experience to be as seamless as possible, hiding all the complexities of the underlying technology to let users focus on apps, not chains. Cross-chain transactions, bridging, and even gas expenditure are hidden from the user, making it as seamless as downloading and using an app on a smartphone.

Chain abstraction is native to our platform. With Abstract Accounts, users can manage their dapps and accounts on any chain, though they are none the wiser. For devs, they can write their apps once, distributing them to users of any chain in the overarching CosmWasm ecosystem.

Let’s see a concrete example of how this is used.

MyFi Case Study: Carrot Savings

To showcase MyFi and flex the power of our multi-chain platform, we’ve developed Carrot Savings, a multi-chain stablecoin yield aggregator.

Carrot Savings is an Abstract App that gives users access to high stablecoin yield opportunities from protocols and chains across Cosmos.

You can onboard to Carrot Savings in 2 easy steps:

1. Create a new Abstract Account with any sign-in method.
2. Install the Carrot App with initial funding, giving immediate access to yields.

Once installed, the app itself performs the yield strategy directly on your assets without them sending them out of your Accounts! So just like on your phone, the Carrot App will request certain permissions — not your location or access to your photos — but permissions to interact with external protocols on your behalf.

V1 of Carrot Savings leverages an Osmosis stableswap pool, providing liquidity from a user’s wallet using AuthZ for proxied permissions. Each user is in full control of the underlying contract and has the ability to revoke permissions at any time. After the setup, a bot will execute compounding actions on the user’s behalf. The user can inspect their position on the Osmosis frontend itself or through our web-app.

V2 of Carrot Savings, currently under development, will integrate additional yield sources and allow for multiplexing across multiple protocols. The process of migrating from V1 to V2 will be simple and the custody of the funds always remains with the user.

Closing Thoughts

From a confusing multi-chain UX to the struggles of creating brand awareness, the Web3 landscape is plagued by challenges effecting both users and developers.

MyFi is a wholistic response to these challenges. Users can discover and interact with the interchain through our launcher without being confronted with technicalities. In turn these users become an attractive audience for developers to target through our built-in app-store. By creating personalized blockchain products, developers have an easier time identifying the needs of their users and iteratively pushing updates to those who are willing to experiment.

In the end, our goal is to foster experimentation and ideation by significantly lowering the barrier to bring a dApp to market.

Do you want to help us make this a reality or are you interested in building with our software? Follow up with us on Discord, start reading our docs or discover our open positions!

Abstract Introduces “MyFi”: A Case Study was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract Money is offering a $2,500 prize to the team who implements the best SocialFi-focused rollup with apps built using the Abstract SDK, deployed on a CosmWasm rollup using Rollkit’s sovereign rollup framework.

Celestia Infinite Space Bazaar is a hackathon from April 2nd to May 17th, 2024, rewarding applications on Celestia and its rollups across DeFi, NFTs, Gaming, and General Applications. It values creativity and innovation. Extra points for projects that push the boundaries of what’s possible on Celestia. Sounds crazy, right? Read on to learn more

Track: Abstract MyFi — Best SocialFi Application built using Rollkit and Abstract SDK

Abstract Money

Abstract Money is a multi-chain development and distribution platform for dapps. Our goal is to enable developers to build more powerful interchain dApps through collaboration, convention, and modularity. We provide a full-stack CosmWasm app development experience, including smart-contract, middleware, and frontend tooling.

Rollkit

Rollkit is a sovereign rollup framework that allows anyone to launch their own sovereign, customizable blockchain as easily as a smart contract. Our mission is to empower developers to quickly innovate and create entire new classes of rollups with minimal tradeoffs. We’re setting the bar high for developers’ flexibility and ability to customize rollups however they see fit. Developers can deploy and interact with CosmWasm Rollkit rollups using cw-orchestrator, with a guide available here.

Abstract SDK

The Abstract SDK is our modular CosmWasm framework, built to streamline the development of interchain applications. Using this SDK, devs can build modules that extend the functionality of Abstract Accounts, our IBC-native smart-contract wallet. And then using our on-chain application management infrastructure, you can publish apps that span and control the entire interchain.

Abstract applications are account-based, meaning that every Abstract App is just an Abstract Account with Modules installed on it. When an Abstract App is “installed” by the end-user, they are creating a sub-account on their main account and literally instantiating the application components, meaning all apps are “self-hosted” and non-custodial. This opens up the doors for highly unique applications where the users always remain in full control, such as in social media or community-based platforms, oft-coined “SocialFi,” though as Abstract infra is fully owned by You, it’s “MyFi.” This works very well with rollups, as the rollups themselves can scale as the social media platform scales in size.

MyFi

Why MyFi? In DeFi, we are using decentralized, but still custodial, applications for our finances. Web3 is about self-sovereignty and ownership, and those rights are still being relinquished to now on-chain financial services. These services can update the contracts, migrate ownership, and all can potentially rug you. Using Abstract, every app you interact with is fully controlled by YOU. Blockchain gives us the tools we need for public financial infrastructure, and using these same tools, we can build personal financial infrastructure. As a user, I’d want this financial infrastructure to be customized to ME, and feel like MINE. Abstract MyFi brings this dream to reality.

Bounty

🎈 We encourage all hackers to be as creative and innovative as possible for this. If you have an idea and are unsure how it can be built, please reach out to us on Discord.

Social finance focuses on the social applications of DeFi. Its goal is to create a more fair and financially inclusive online ecosystem where users have greater control over their content and can directly benefit from their online activities.

On traditional social media platforms, users create accounts on their servers, relinquishing control of all content and activities to the platform. With Abstract, Apps are literally installed on users’ Accounts, meaning that meaning that they’re fully sovereign and controlled by them. This flips the control model, and the platform simply provides an interface that accesses functionality available on the users’ Accounts.

For example, let’s say that we were building a social media platform on Abstract. This Abstract App would include:

• Profile module — allowing for creation and management of of a user-profile NFT
• Posts module — allowing for publishing of NFT posts on a specific profile, with means of “purchasing” the posts from end-users
• Social points module — allows other users to buy “shares” in an individual via bonding curves or other mechanism.
• Marketplace module — allowing for users to list and sell items

For this track, create a socialFi application that would require a user to install it on their Account before they can access the platform. We’d like you to think about novel incentive mechanisms, media ownership, and NFTs.

To Qualify

• Deploy a CosmWasm Rollup using Rollkit
• Use cw-orchestrator to deploy Abstract’s on-chain app infrastructure
• Use the Abstract SDK to write a novel application using it’s Account-based application model. Users must install it to participate in something socially (like FriendTech, reviews, etc.).
• Create a frontend where users can install the app on their own account and interact with other installations of the app

Disqualifiers

• Single-app instances, where the application is “hosted” on one Account.
• This app should be fully owned by the end-user, with the platform conforming to their installation.
• Apps can have factories and other contracts that orchestrate information like multi-queriers or -executors.

Interchain MyFi BONUS (reach out to us):

One of the best use cases for Abstract (and the reason our original name was Abstract OS) is for personal rollups. Using Interchain Abstract Accounts (ICAAs), you can use this rollup to control any account on any blockchain connected via IBC. Here’s an overview and code walkthrough. You can also use these ICAAs to interact with any other DeFi primitive on the interchain, using our DeFi adapters. This means you can create fully self-sovereign DeFi strategies spanning multiple chains. If you are interested in pursuing this, please reach out to us on Discord and we can guide you through the process of working with them. This requires knowledge of IBC and cross-chain execution. We have advanced tooling to support this use case.

Resources

• Website: abstract.money
• High Level Overview of Abstract’s Infra: https://medium.com/@abstractmoney/a-high-level-overview-of-abstract-moneys-interchain-app-platform-d30813c7a1b4

Rollkit

• Documentation: https://rollkit.dev/learn/intro
• Get Started: https://rollkit.dev/tutorials/cosmwasm#🗞️-cosmwasm-rollup
• GitHub: https://github.com/rollkit/rollkit

Abstract SDK

• Documentation: https://docs.abstract.money
• Get Started: https://docs.abstract.money/4_get_started/1_index.html
• GitHub: https://github.com/AbstractSDK/abstract

CW-Orchestrator

• Documentation: https://orchestrator.abstract.money/
• GitHub: https://github.com/AbstractSDK/cw-orchestrator
• Get Started: https://orchestrator.abstract.money/setup/index.html

Social

• YouTube: https://youtube.com/@AbstractMoney
• Discord: https://discord.gg/uch3Tq3aym
• Twitter: https://twitter.com/AbstractSDK

Abstract SDK + Rollkit Hackathon Track | Celestia Infinite Space Bazaar was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: this article is outdated and will be updated shortly.

This guide will walk you through the steps to create a CosmWasm smart-contract module using Abstract. You will be able to leverage other modules, interact with OSes, and deploy your contract all from one repository.

Overview

Scaffold Generation

Open a terminal window and run the following command to generate the scaffold app on your machine:

If you don’t yet have it installed you can install it with cargo install cargo-generate

cargo generate gh:Abstract-OS/app-module-template \
               --branch template \
               --name <module-name>

The above will clone the template repository into <module-name> which will be the name of your Abstract module.

All message structs will be prefixed with this module name as well. Ex: ModuleNameInstantiateMsg. This is to differentiate from the actual InstantiateMsg (the true entry point) imported from abstract_os.

This name will also be the base name for most module-specific variables in the app. From here-on-out, the examples in this guide will be using “balancer”. This name will be the base name for most app-specific variables in the app as mentioned above.

Project Structure

Open the module-name folder, where you will find the following folders:

• contracts: your CosmWasm smart contracts
• interfaces: Rust deployment interfaces for your smart contracts
• scripts: scripts for deploying your module to Abstract Version Control and for writing tests

Now that you have a fresh template, you are ready to start writing your module.

cargo fmt # cleanup any template residuals
cargo build

Contract Structure

All the following files are referenced from contracts/src directory. If you’ve ever written a CosmWasm smart contract before, this should be pretty standard aside from the contract.rs entry point.

msg.rs

Message declarations for your module. Here you will find the entry-point msg declarations as well as their responses.

error.rs

Human-readable error declarations for the module.

state.rs

The actual state stored on-chain for your smart-contract. Item and Map are both from the cw-storage-plus library, which provides powerful storage abstractions.

Commonly-used state like the Admin and Contract Version are already provided natively by the Abstract-SDK and exposed to your handlers (details below 👀)

contract.rs

This file serves as the overall entry point into your module. Abstract provides a wrapper around the CosmWasm entry points, and exposes their configuration to you through the AppContract type. Your module-specific types for error, messages, and receive are then all encapsulated into a single new type: <ModuleName>App.

pub type BalancerApp = AppContract<
    BalancerError,
    BalancerExecuteMsg,
    BalancerInstantiateMsg,
    BalancerQueryMsg,
    BalancerMigrateMsg,
>;

Further down, we can see that our APP is an instance of this <ModuleName>App which declares each of the handlers for instantiate, query, execute, migrate, and replies.

const APP: BalancerApp = BalApp::new(MODULE_NAME, MODULE_VERSION)
    .with_instantiate(handlers::instantiate_handler)
    .with_query(handlers::query_handler)
    .with_execute(handlers::execute_handler)
    .with_migrate(handlers::migrate_handler)
    .with_replies(&[(EXAMPLE_REPLY_ID, handlers::example_reply_handler)])
    .with_dependencies(&[EXCHANGE]);

The dependencies specify which modules your users need to have installed in their OS to interact with the module. By default, the template declares the abstract:dex module as a dependency.

Finally, a Rust macro takes the type and const declaration of your app to export the actual CosmWasm entry points from your contract.

export_endpoints!(APP, BalancerApp);

handlers

All of the handlers for the messages sent to your contract (declared in msg.rs) are held within the handlers directory, and the appropriate messages can be handled via match statement.

Below is the ExecuteMsg handler for Equilibrium’s balancer module.

pub fn execute_handler(
    deps: DepsMut,
    _env: Env,
    info: MessageInfo,
    balancer: BalancerApp,
    msg: BalancerExecuteMsg,
) -> BalancerResult {
    match msg {
        BalancerExecuteMsg::Rebalance {} => rebalance(deps, info, balancer),
        BalancerExecuteMsg::UpdateAssetWeights { to_add, to_remove } => {
            update_asset_weights(deps, info, balancer, to_add, to_remove)
        }
        BalancerExecuteMsg::UpdateConfig { deviation, dex } => {
            update_config(deps, info, balancer, deviation, dex)
    }
}

The <ModuleName>App acts as an adapter between your contract and the Abstract SDK, exposing Abstract Name System, other module functionality, asset value calculation, and much more. Read more in the Abstract docs.

Deployment

Interfaces

Within interfaces is a template.rs file that declares the deployment interface for your module. By default, the new function should be enough to deploy the contract but you can add additional functions to perform more advanced actions. See abstract-boot for more examples.

Scripts

To make your module available for other OSes to install on a local, Testnet, or Mainnet network, you can deploy your module directly from the template repo.

1. Configure Deployment Env

Rename the example env

# in the root
mv .env.example .env

Configure the variables (this example uses uni-5 Juno testnet)

# human-readable name of the chain
CHAIN="juno"
# name of the deployment to be exported 
DEPLOYMENT="v0.0.1"
# "local" | "testnet" | "mainnet"
NETWORK="testnet" 

# Mnemonic of the account that will be used to deploy the contracts (admin)  
TEST_MNEMONIC=""
# Abstract version control address for app deployment  
VERSION_CONTROL_ADDRESS=junoxxx

The Abstract version control address can be found on https://beta.abstract.money/deployments (check our discord for when it is available)

2. Configure the Deployment Network

In src/bin/deploy_app.rs, configure the network to instantiate the daemon to be UNI_5 for Juno testnet or JUNO_1 for Juno mainnet. Other available networks are exported from boot_core (docs).

use boot_core::{instantiate_daemon_env, networks::juno::{JUNO_DAEMON, UNI_5, JUNO_1}};

pub fn deploy_app() -> anyhow::Result<()> {
    let network = UNI_5;
    //...
}

3. Deploy to Version Control

Run the following command:

cargo deploy

…and your module will be registered to Abstract Version Control. You can verify this by going to https://beta.abstract.money/ans (soon) and checking the registered modules.

Need help?

Connect with us on Discord! We’d be happy to help you with any questions, feedback, or suggestions.

References

• Introduction | CosmWasm Documentation

Getting Started with Abstract — How to create your own App Module was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

BOOT (by Abstract) simplifies all of this by providing a type-safe library and a standard way of deploying and interacting with your CosmWasm smart contracts.

Getting Started

The following sections detail setting up a library for interfaces and a separate package for the scriptsso that publishing the contract interfaces is easy.

Contract Interface Library

To get started with BOOT, create a new folder anywhere (though we often do it alongside our contracts in the same repository) called interfaces by running:

cargo init --lib interfaces

Following this example, the file structure will now look like:

.
├── Cargo.toml
├── contracts
│   ├── Cargo.toml
│   └── src
│       ├── contract.rs
│       └── ...
└── interfaces
    ├── Cargo.toml
    └── src
        └── lib.rs

If your cargo project is a workspace, be sure to add interfaces to the [workspace].members array at the workspace root.

Install boot-core

cd interfaces
cargo add boot-core
cargo add --path ../contracts

Then add any other dependencies, which should look similar to the following:

[dependencies]
boot-core = "0.1.3" # latest version as of writing this article
my-contract = { path = "../contracts" }
# common
cosmwasm-std = "1.1"
serde = { version = "1.0.103", default-features = false, features = ["derive"] }

Defining Contract Interfaces

The contract interface is what your scripts will be interacting with to deploy and manage the deployed instance of your contract. It provides accessible methods for interfacing with the contract entry points and can maintain state between script runs based on the deployment configuration.

First, create a new file in the src directory of the interfaces package, and add it to the library declaration file:

touch src/my-contract.rs
echo 'pub mod my_contract;' >> src/lib.rs

In your new contract file, define a struct for your contract interface and provide the [Instantiate|Execute|Query|Migrate]Msgs to the boot_contractmacro, which will generate fully-typed instantiate, execute, query, and migrate methods.

use boot_core::prelude::boot_contract;
use my_contract::{InstantiateMsg, ExecuteMsg, QueryMsg, MigrateMsg};

#[boot_contract(InstantiateMsg, ExecuteMsg, QueryMsg, MigrateMsg)]
pub struct MyContract<Chain>;

The generic “<Chain>” argument is to help the rust-analyzer with type analysis because sometimes the macro-expansion engine does not fully understand generically typed macros.

If your entry point Msgs have any generic arguments, pull them out into newtypes before passing into the macro.

Next, you’ll want to define the constructor for the struct defined above. In the following example:

use boot_core::prelude::{BootEnvironment, Contract};

// ...

impl<Chain: BootEnvironment> MyContract<Chain> {
    /// Construct a new instance of MyContract
    /// * `contract_id` - what your contract should be called in local state (*not* on-chain)
    /// * `chain` - the chain to deploy to
    pub fn new(contract_id: &str, chain: &Chain) -> Self {
        let crate_path = env!("CARGO_MANIFEST_DIR");
        // This can be the absolute path of the file like it is below
        // or it can simply be the name of the contract file like "my-contract",
        // and the path of that file set via WASM_DIR env variable
        let wasm_path = "../../target/wasm32-unknown-unknown/release/my-contract.wasm";
        Self(
            Contract::new(contract_id, chain)
                .with_wasm_path(wasm_path),
        )
    }
}

Notice that we build the Contract instance with_wasm_path, where we provide the contract name. This contract name will be used to search the artifacts directory (set by ARTIFACTS_DIR env variable) for the .wasm file of your contract. Alternatively you can specify a path to the released wasm after running RUSTFLAGS=’-C link-arg=-s’ cargo wasm . See the CosmWasm documentation on compiling your contract for more information.

Script

Now that we have the interface written for our contract, we can start writing scripts to deploy and interact with it.

Setup

Like before, we’re going to setup a new folder for our scripts. This time, we’ll call it scripts and initialize it as a binary crate:

cargo init --bin scripts

If your cargo project is a workspace, be sure to add scripts to the [workspace].members array at the workspace root.

Your scripts will have basically the same dependencies as your contract interfaces, but with a few additions:

cargo add --path ../interfaces

and also add the anyhow and dotenv crates:

cargo add anyhow dotenv log

Env Configuration

The dotenv crate will allow us to load environment variables from a .env file. This is useful for setting up the chain configuration for your scripts.

# .env
# info, debug, trace
RUST_LOG=info

# where the contract wasms are located
ARTIFACTS_DIR="../artifacts"

# where to store the output state data
DAEMON_STATE_PATH="./daemon_state.json"

# Mnemonics of the account that will be used to sign transactions
LOCAL_MNEMONIC=""
TEST_MNEMONIC=""
MAIN_MNEMONIC=""

IMPORTANT: Make sure to exclude the .env file in your gitignore.

Main Function

Now that we have our dependencies setup, we can start writing our script. Either create a new file in the src directory of the scripts/src package, or use the main.rs file that was created by default.

This function is mostly just boilerplate, so you can copy and paste it into your new script file. It will just call your function and give you nicer error traces:

fn main() {
    dotenv().ok();
    env_logger::init();

    use dotenv::dotenv;
    if let Err(ref err) = deploy_contract() {
        log::error!("{}", err);
        err.chain()
            .skip(1)
            .for_each(|cause| log::error!("because: {}", cause));
::std::process::exit(1);
    }
}

Deployment Function

First, we’ll define a function that will deploy our contract to the chain. This function will setup the environment (connecting to the chain), deploy the contract, and return a Result with the contract address.

// scripts/src/my_contract.rs
use anyhow::Result;
use boot_core::networks;
use boot_core::prelude::{instantiate_daemon_env, NetworkInfo};
// Traits for contract deployment
use boot_core::interface::*;
use interfaces::my_contract::MyContract;

// Select the chain to deploy to
const NETWORK: NetworkInfo = networks::juno::UNI_5;
const CONTRACT_NAME: &str = "my-contract";

pub fn deploy_contract() -> anyhow::Result<String> {
    // Setup the environment
    let (_, _sender, chain) = instantiate_daemon_env(network)?;

    // Create a new instance of your contract interface
    let contract = MyContract::new(CONTRACT_NAME, &chain);
    // Upload your contract
    contract.upload()?;

    // Instantiate your contract
    let init_msg = InstantiateMsg {
        // ...
    };
    // The second argument is the admin, the third is any coins to send with the init message
    contract.instantiate(init_msg, None, None)?;

    // Load and return the contract address
    let contract_addr = contract.address()?;
    Ok(contract_addr)
}

Additional Scripts

So you have your contract deployed, but what now? You can write additional scripts to interact with your contract. For example, you can write a script to query the contract state, or to execute a contract method.

Here’s an example of a script that queries the contract state:

// scripts/src/my_contract.rs
// use ...
use my_contract::{QueryMsg};
// ...

pub fn query_contract() -> Result<()> {
    // Setup the environment
    let (_, _sender, chain) = instantiate_daemon_env(NETWORK)?;

    let contract = MyContract::new(CONTRACT_NAME, &chain);
    // Load the contract address (this will use the address set from the previous deploy script)
    let contract_addr = contract.address();
    // Query the contract
    let res = contract.query(QueryMsg::Balance {
      address: contract_addr,
    })?;
    // Print the result
    println!("{:?}", res);
    Ok(())
}

And one that executes a contract method:

// scripts/src/my_contract.rs
// use ...
use my_contract::{ExecuteMsg};
// ...

pub fn execute_contract() -> Result<()> {
    // Setup the environment
    let (_, _sender, chain) = instantiate_daemon_env(NETWORK)?;

    
    let contract = MyContract::new(CONTRACT_NAME, &chain);
    let contract_addr = contract.address();

    // Execute a contract method
    let res = contract.execute(ExecuteMsg::UpdateBalance {
      address: contract_addr,
      balance: Uint128::from(1000000u128),
    })?;
    // Print the result
    println!("{:?}", res);
    Ok(())
}

Refinement

You can also refine your contract interface to make it easier to use. For example, you can create a function that will execute a specific contract method and return the result, instead of having to call contract.execute and contract.query separately.

// interfaces/src/my_contract.rs
// Import the boot traits
use boot_core::interface::*;
// ...


impl<Chain: BootEnvironment> MyContract<Chain> {
    pub fn new(contract_id: &str, chain: &Chain) -> Self {
      // ...
    }
    
    /// Query the balance of an address
    /// `address` - the address to query
    pub fn balance(&self, address: Addr) -> Result<BalanceResponse> {
        let balance_query = QueryMsg::Balance { address };
        self.query(balance_query)
    }
    
    /// Update the balance of an address
    /// `address` - the address to update
    /// `balance` - the new balance
    pub fn update_balance(&self, address: Addr, balance: Uint128) -> Result<ExecuteResult> {
        let update_balance_msg = ExecuteMsg::UpdateBalance {
            address,
            balance,
        };
        self.execute(update_balance_msg)
    }
}

References

• Boot Core
• Boot Cw-plus
• Abstract Contract Interfaces

Deploying and scripting your smart contract using BOOT was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract’s goal is to enable developers to build more powerful interchain dApps through collaboration, convention, and modularity. We provide a full-stack CosmWasm development experience, including smart-contract, middleware, and frontend tooling. The Abstract SDK streamlines the development of interchain applications with a powerful and easy-to-use modular application framework whose capabilities are fully realized via account-abstraction and our on-chain application infrastructure.

To learn more about our framework and our full developer vision, please check out our official documentation.

Introduction

The Cosmos SDK changes the game for blockchain-based applications. It allows for scalable development and deployment of application-specific chains by providing a well-defined framework emphasizing modularity. The “appchains” coincide with the fat application thesis, which states that the value lies in the applications themselves rather than in a shared, fat protocol like Ethereum or Solana. IBC enables interoperability between these appchains, and CosmWasm allows for the programmability of cross-chain interactions through a secure and efficient smart-contract environment. “inter-chain”

The Problem

It is difficult and slow to build CosmWasm applications. Teams start from scratch, and waste valuable time integrating primitives such as DEXes, money markets, oracles, and other DeFi building blocks. The fat app thesis encourages teams to drive value to their applications, consequently creating an environment of siloed development. This lack of inter-team collaboration hinders innovation and experimentation, and is partially why the CosmWasm ecosystem is relatively immature compared to the Ethereum and Solana ecosystems.

Secondly, while CosmWasm application updates (“migrations”) don’t require a replacement binary like chain upgrades, updates remain highly manual and dangerous, especially when multiple contracts are involved. This leaves user funds and team reputations at risk.

Finally, developing a cross-chain application requires deep prerequisite knowledge of IBC, proper handling of callbacks, error cases, and knowledge of interchain smart-contract security. Even for an experienced IBC developer, cross-chain interactions require new IBC ports, as well as channel and asset identification on both sides.

The Solution

We bring the modularity and scalability of the Cosmos SDK to CosmWasm applications with the Abstract SDK, our interchain application framework. The Abstract SDK is designed for organizations and individual developers to build composable, distributed applications in a fast, secure, and cost-effective manner. We place an emphasis on standardization and composability, congruent with well-studied smart-contract design patterns such as Ethereum’s Diamond Proxy Pattern (EIP-2535) and Web2 microservices and customized to the extensive capabilities of CosmWasm.

The foundation for every Abstract application is an Abstract Account, a smart-contract wallet. Modules, the smart-contracts built using the SDK, isolate shared logic and extend the functionality of the Account. This transforms it into an application. Module version management is performed via a permissioned on-chain module registry, allowing for dynamic application upgrades with protections against incorrect migrations. Inter-team collaboration is incentivized because modules can be monetized, providing sustainable income for developers and rewarding continued maintenance. Complex logic can be imported rather than rewritten.

The Abstract SDK provides easily-understandable abstractions for local and cross-chain interactions over IBC. Via an on-chain name service, assets, chains, and other resources can be referenced by name, rather than their complex identifiers. Abstract Accounts (and applications) can create and execute upon multi-hop interchain outposts developed specifically for chain-abstracted protocols and wallets.

Why?

Read about Abstract’s origins here.

Our goal is to help realize the ideal of full user sovereignty in ushering in the next generation of interoperable applications. The interchain becomes ubiquitous not only via technical superiority, but via a thriving developer ↔ user economy, the most important multi-sided market in Web3.

Our team consists of 7 highly experienced Web3 software engineers, and both our founders are technical. Abstract’s tooling has been in development for over 2 years.

Abstract’s framework and on-chain infrastructure is open-source, chain-agnostic to any CosmWasm-enabled chain, and allows control of and interoperability with any chain connected to IBC.

Abstract’s Interchain CosmWasm Tooling

Below we’ll go over the different components of the Abstract stack, servicing interchain developers.

Features TL;DR:

Production-Ready

• Abstract Account: Multi-chain smart-contract wallet
• Version Control: On-chain module registry with version management
• Name Service: On-chain name service for assets, contracts, addresses, chains (channels), and DEX pairs
• Abstract SDK: Modular CosmWasm application framework
• Console: Developer interface for managing Accounts, applications, and modules
• API: GraphQL API for quick contract queries and indexed information
• Interchain Abstract Accounts: Cross-chain smart-contract accounts

Pre-Release

• Abstract.js: Typescript SDK for use alongside the Abstract SDK
• EVM Interchain Accounts: Control and interact with any EVM chain

Abstract Accounts

Read more about Abstract Accounts here.

Abstract’s application architecture is centered around our smart-contract wallet, coined an Abstract Account. This serves as a secure vault for asset management and provides a base upon which modules can be installed, creating an application. Applications can be installed upon Accounts via sub-accounts. The Account is also responsible for cross-chain communications, handling creation of and communication with interchain Accounts.

This enables Account owners to “self-host” their applications on fully sovereign smart-contracts. This follows the natural evolution of decentralized finance (DeFi) to a new era of personalized, sovereign finance, which we’re coining MyFi.

Modules

Read more about Abstract modules here.

A module in Abstract is a smart-contract that can be installed on an Abstract Account to extend its capabilities. Modules can be installed, removed, and configured by the Account’s owner, allowing for a high degree of customization. Additionally, modules can take on dependencies on other modules and securely interact with each other.

App modules are instantiated and owned by one Account.

• Ex: ETF module allows the owner to manage the Account as an ETF. The module handles value calculation for deposits and withdrawals, and the owner manages the allocation.

Adapter modules serve as standard interfaces that facilitate communication between Accounts and various external services. They adapt a service to an interface.

• DEX Adapter: Provides a standard interface for performing actions on DEXes.
• CW-Staking Adapter Provides a standard interface for interacting with LP positions across Cosmos.

Integrations

Developers using the Abstract SDK can interact with the following services via standardized interface through Abstract’s adapter modules within minutes:

• Osmosis
• Kujira
• Astroport
• Wyndex
• Astrovault

Module Registry (On-Chain)

See the live module registry or read more on the Version Control docs.

On-chain registry of versioned contracts to their code ids and metadata. Allows developers to register and monetize their modules.

• abstract:dex:0.20.0 => juno...xxx
• abstract:etf:0.3.0 => 205

This “package registry” is one of the most important components in enabling truly composable apps. All Abstract Apps can pull updates from the modules registry, allowing applications to be dynamically updated with the Account owner retaining full sovereignty.

Abstract Name Service (On-chain)

See the live name service or read more on the ANS docs.

The ANS is a smart contract that stores the following data:

Assets: The most relevant assets on the local blockchain.

• osmosis>osmo on Osmosis => uosmo
• osmosis>osmo on Juno => ibc/...XYZ
• juno>dao on Juno => juno...xxx
• juno>dao on Osmosis => ibc/...YZA
• berachain>bera on Berachain => 0xAul...E3a
• berachain>bera on Union => factory/union...nkz

Contracts: Contracts related to certain protocols or applications that could be dynamically resolved. This could be used to store the address for an asset-pair for a dex.

• croncat/factory on Osmosis => osmo...xxx
• berachain>bex/crocsw on Osmosis => 0x9...osu

Channels: IBC channel data to map a protocol + destination chain to a channel id. This allows for dynamic IBC transfers without having to know the channel id beforehand.

• osmosis on Neutron => channel-5

Pools: Essential liquidity pools for DeFi protocols, mapping ANS-ID to pool-id or contract.

• astroport/neutron>ntrn,osmosis>osmo on Neutron => neutron...ua5
• berachain>bex/berachain>bera,union>uno on Union => 0xYo...b7a

Abstract SDK (Framework)

Read more about the SDK via its technical documentation and get started by building an app!

The Abstract SDK itself is the Rust-based CosmWasm framework with which developers write and test application modules. Applications using the SDK work seamlessly with the on-chain infrastructure. It provides common abstractions via traits for maximum ease-of-use and modularity.

All Abstract modules are easily testable using cw-orchestrator with out-of-the-box abstractions for Abstract Accounts and all other on-chain infrastructure.

IBC Capabilities

Abstract Accounts can create single- and multi-hop outposts on IBC-enabled chains, enabling cross-chain applications. Our on-chain IBC abstractions ensure that all actions are authenticated and relayed to the proper destinations, and allow for single-chain management of complex multi-chain infrastructure.

Typescript + React Developer SDK (Pre-Release)

Abstract.JS provides comprehensive means for interacting with applications built using the Abstract SDK. It is also provider-agnostic, meaning that developers can use either Graz or Cosmos Kit in their frontend development. The design patterns used by Abstract.js are largely based on high-quality Ethereum packages such as wagmi and viem. It additionally provides code-generation plugins for ts-codegen for readable clients.

EVM IBC (Pre-release)

We enable control and interaction with EVM-based chains with our proprietary implementation for interchain accounts on EVM via Union, one of our core partners. This gives the EVM ecosystem unfettered access to the Interchain and visa-versa, enabling the development of advanced cross-chain liqudity orchestration, application protocols, and even cross-chain SAFEs.

Application Console

Feel free to check out the mainnet and testnet Consoles, both of which are currently live.

The developer console allows teams to manage their applications built using Abstract. It provides GUIs for all on-chain infrastructure and Abstract Accounts. It also serves as the marketplace upon which devs can list and monetize their modules as described earlier.

Abstract API

Query the API here.

A chain-agnostic GraphQL API for accessing all of Abstract from anywhere. Supports custom configurations for any CosmWasm network with Abstract.

Case Studies

XION

Mint an NFT on Neutron directly from XION here! This demonstration walks you through each step of the process, though all actions can be fully abstracted away in practice.

XION is consumer-oriented chain focused on eliminating the complexities of Web3 interaction through “generalized abstraction,” offering users the ability to interact with apps and liquidity on any chain.

XION uses Abstract’s ICAAs to enable chain abstraction and for full control and programmability of any chain over IBC. We’ve had over 160K Abstract Accounts and over 400K transactions executed using Abstract’s infrastructure in just a few weeks of release.

FortyTwo Finance

FortyTwo is the interchain’s DeFi yield aggregator. It offers a single interface where users can manage their yield positions and understand their portfolios spread across any IBC-enabled chain.

One of FortyTwo’s primary products is a dex-agnostic autocompounder, which achieves maximum yield on pools across IBC. This leverages Abstract’s DEX and Staking adapters and scales to any pair on any dex on any chain.

Abstract makes developing single- and multi-chain applications easy. Developers should be able to focus on their business logic, and not the bulls**t. Users should be able to focus on the application, and not care the tech. Both of these ideals are realized through Abstract’s comprehensive interchain platform, all-the-while abstracting away the complexities of multi-chain development and interaction.

Additional Resources

Abstract Money Chain Abstraction

Acknowledgementns

We wish to give thanks to the open-source community and the many teams that we’ve worked with in improving the Abstract SDK to make the development experience as amazing as possible, including (but not limited to):

• Confio
• FortyTwo
• Yieldmos
• DaoDao
• Cosmology
• Xion

Abstract Changelog

Get in touch!

Follow Us on Twitter

A High-Level Overview of Abstract Money, Interchain App Platform was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract builds tooling to streamline the on and off-chain CosmWasm developer experience in building Interchain applications. We offer a scalable full-stack framework emphasizing modularity, enabling better maintainability and seamless composability between teams, applications, and blockchains.

Why is Abstract not built on the Ethereum Virtual Machine (EVM)?

The introduction of Solidity and the EVM have undoubtedly transformed the world. The concept of a decentralized, Turing complete global computer enabled developers and degens alike to create unique applications ranging from decentralized finance (DeFi) to art collections valued at multiple millions of dollars.

Ethereum did a great job at drawing in developers and attention to a technology that has the potential to be extremely transformative to our society at broad. Nonetheless it has shown time and time again that the EVM struggles to uphold the technical values that are so important for the types of applications that need to be built out with this technology.

At its essence CosmWasm aims to be a response to those inadequacies.

Reentrancy

The EVM is notorious for its broad attack surface related to reentrancy. Attacks that exploit this vulnerability occur so often that a lists exists that keeps track of them. The fact that reentrancy is a well-known attack vector, yet is still exploited on a regular basis shows that there is an inherent flaw in the technology (EVM).

CosmWasm follows the actor model which, as a model for computation, doesn’t allow for any form of reentrancy. This ensures that individual contracts can securely manage their internal state without the risk of in-process interference by an attacker.

🔒 There has only been one known exploit of a CosmWasm contract while CosmWasm was the main technology behind Terra’s meteoric rise in 2021. A prime example is Astroport, which reached a peak Total Value Locked (TVL) of 1.8 Billion US Dollars.

Migration

Smart-contract migrations are a necessity when responding to bug-reports and expanding a product’s feature set. Sadly, migrations are not a first-class feature in the EVM. Different libraries are used to allow developers to migrate their contracts in a way that’s often complex and error prone.

Learning from that experience CosmWasm supports migrations natively by allowing developers to change out the binary executable that defines the contract’s logic with another binary while retaining the contract’s address and state. In this way developers can easily apply patches and roll out upgrades.

WASM and The Rust Language

Where CosmWasm really shines is in it’s inherent composability as a result of it using WebAssembly (WASM).

WebAssembly is a platform-agnostic bytecode instruction set. At a glance, it allows developers to write code in any language while being as platform agnostic as Java but 1000x faster. As a result it can be used in browsers, mobile devices, embedded systems, micro-services and, if its execution is made to be deterministic, as a computation platform for smart-contracts.

As WASM is still undergoing heavy development, only a few languages really support it in a reliable and usable way. The current favorite is Rust, and for all the right reasons.

The Rust Language is an expressive, fast and safe language that allows contracts to be small and cheap to execute. As a result of it being a full-blown programming language, developers who create CosmWasm contracts can put all the available (and rapidly developing) libraries to their use.

As a language Rust can be hard to learn but very rewarding to work with. Rust has been the most loved language for the 7th year in a yearly survey on StackOverflow. Not to mention its recent adoption in the Linux kernel, Microsoft Windows and others.

The Problem with Building from Scratch

While CosmWasm was able to address a lot of the problems that plagued Solidity, it did so with its own shortcomings. Abstract is the only application framework that properly addresses these issues and in doing so allows developers to experiment and innovate at a pace that just hasn’t been possible before.

Tooling and Infrastructure

Creating a new smart-contract framework from scratch requires rebuilding all the tooling that other framework’s developers have grown so accustomed to. Over the years we’ve seen developers create their own bandaid solutions with regard to contract testability, deployment pipelines and monitoring tools. It’s fair to say that most of these projects addressed a specific need without addressing the broader scope of the framework’s problems in this regard.

This uncoordinated approach, while decentralized in nature, causes a lot of confusion within its user base. As a result, public goods funding flows to developers and projects that keep re-inventing the wheel, only to eventually abandon it.

🗣 The ecosystem’s biggest shortfall has been its inability to properly coordinate its network of passionate developers. This results in a fragmented and uncollaborative community.

This same criticism extends to much of the Cosmos ecosystem. An ecosystem touted as the internet of blockchains that aims to simplify the creation of blockchains in a modular fashion. In its current state CosmWasm is bound to the Cosmos ecosystem as the CosmosSDK is its only supported environment, although this could soon™️ change.

Abstract aims to tackle the tooling and community fragmentation by creating incentive structures that foster collaboration as an inherent consequence of the system’s architecture. In other words, Abstract is the golden standard for collaborative smart-contract development.

What We’ve Built

Abstract aims to be the interchain application platform. To achieve this, we’ve developed on-chain infrastructure and Software Development Kits (SDKs) for both smart-contract and front-end development.

The Abstract Framework

Abstract’s framework primarily facilitates the creation of Abstract Accounts, which are smart-contract wallets with installable modular applications. Developing applications in this modular manner offers several significant benefits:

• Code Reusability: Developers can reuse contracts in other applications. Moreover, Abstract provides a library of contracts for integrating with the most popular protocols, saving both time and money.
• Security: The logic of an application is simplified to its bare minimum, making it easier to audit and maintain. Additionally, its dependencies are often battle-tested smart contracts, reducing the attack surface.

The following example demonstrates an auto-compounder application, shown in the diagram below. This application provides liquidity to a DEX pool and re-invests the received rewards back into the pool. The application’s functionality can be divided into three contracts:

• DEX: Offers an interface for performing DEX operations, such as swapping tokens and providing liquidity.
• Staking: Provides an interface for conducting staking operations, such as claiming rewards and staking or unstaking.
• Auto-Compounder: Coordinates the DEX and staking contracts to execute the auto-compounding logic.

The strength of this approach lies in its separation of concerns. Your team can focus on problem-solving and feature development without the burden of integrating all possible dependencies. With Abstract, you can rely on shared on-chain infrastructure that is actively maintained to ensure your application’s uptime.

Another aspect of this application development approach is the ability to self-host applications. Imagine being able to publish an on-chain application in the same way as an iOS/Android app. This is achievable with our smart-contract app store.

Below is the self-hosted version of the previously mentioned auto-compounder application. Both Sarah and Alex have created an Abstract Account on our platform and installed the auto-compounder application from our app store. The app’s creator may choose to charge an installation or usage fee for their work.

With this setup, Alex and Sarah can both utilize the auto-compounder application and customize it according to their preferences. For instance, Alex can set the application to compound his rewards every 24 hours, while Sarah can set hers to do so every 12 hours. Updates to the application are done through a “pull” based system, as opposed to the current “push” based system. This means that both Sarah and Alex need to actively perform an upgrade if they wish to update their application. The developers cannot force new code onto the users. We believe this approach yields significant technical and potential legal benefits.

In conclusion, Abstract’s modular smart-contract development framework provides a streamlined process for the creation of complex smart-contract based applications through smart-contract composition.

Our Tooling

To demonstrate our commitment to a more collaborative development ecosystem, we’ve created cw-orchestrator. This scripting tool for CosmWasm-based applications enables developers to share and collaborate on their projects.

At its core, cw-orchestrator allows teams to create interfaces for their contracts. These interfaces can be used to interact with the contracts in any environment that supports CosmWasm execution, including live networks, mock environments, and everything in between.

Additionally, we’ve developed powerful features that allow other developers to easily deploy applications to any of these environments. Below is a snippet of how Abstract, a large multi-contract framework, can be deployed to a mock environment by any developer who wishes to integrate:

// Create a sender
let sender = Addr::unchecked(ADMIN);

// Create the mock
let mock = Mock::new(&sender);

// Deploy Abstract to the mock
let abstr_deployment = Abstract::deploy_on(mock.clone(), sender.to_string())?;

You can read more about this powerful tool in our dedicated docs.

Closing Thoughts

Up until this point developers have been building web3 applications from scratch, monetizing their creations through ponzinomics and marketing. These practices have been great for meme and internet culture (3,3) but they have shown to fall short for any meaningful and long-term alignment between builders and users alike.

At some point systems must be put in place that foster long-term collaboration. We believe that Abstract is a major step in that direction and we’re counting on your support.

Let’s collaborate and make the interchain great again!

👀 We’re looking for teams or investors that have a specific use-case that they would want to see built out. If that’s you, please book a meeting with us to see if we can help you out!

Links

Join our Discord!

Check out our Github.

And follow us on Twitter(X).

Abstract for CTOs was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.