Starport is the all-in-one platform to build, launch, and maintain any crypto application on a sovereign and secured blockchain. Starport CLI is a powerful developer tool for scaffolding blockchains, generating code, running a node in development, and much more. Builders will need to implement new scaffolding functionality or improve the functionality, reliability, or flexibility of Starport CLI or introduce new functionality that is useful for a large number of developers



One of the core features of Starport is code scaffolding. Starport can scaffold a new blockchain from scratch, create new modules, add messages, queries, packets to modules, and much more. This functionality allows developers to prototype advanced modules with just a few commands. Currently, Starport depends on string placeholders being present in modules’ files. Placeholders work, but if another solution (likely, based on code analysis) is found, this could improve Starport's reliability even further.



  • Reengineer Starport’s code scaffolding to avoid relying on placeholders as much as possible

  • There should be no placeholders in proto files

  • The goal is to make Starport more resilient and less fragile

  • Solution should gracefully handle if required files are not found

  • Use Starport's list as an example command to showcase functionality

  • Try keeping backwards compatibility with Starport v0.18




Starport chain serve is the most convenient way to start a blockchain node for development purposes. Currently, this command sets up a single node testnet with automatic code reloading. Enhance this functionality of Starport, for example, to support multi-node local testnets.



  • The enhanced version of serve should support existing features of Starport (for instance, code reloading)

  • Multi-node testnet is just an example, find other creative ways to improve developer experience

  • Command shouldn’t require flags to run, but you can use the config file to customize its behavior

  • Try keeping backwards compatibility with Starport v0.18



Starport uses an advanced build process to compile the source code of a chain into a binary. It’s both sophisticated and easy to use, but there is always room for improvement. To win this challenge, enhance the build process so that it’s more flexible, yet can be used even by beginner developers.



  • Do not rely on Makefiles. Makefiles are very flexible, but this flexibility makes it harder for us to control the build process (for example, we can’t know the name of the binary produced by make). Instead, consider using config.yml to customize the build process. For inspiration: goreleaser, taskfile, etc.

  • Add customization options declaratively, like toggling support for Ledger devices, passing flags, etc.

  • Think of other config.yml improvements that can enhance the developer experience.


All of Starport’s functionality right now is implemented in packages within the Starport code repository. From a maintenance perspective this is convenient, but a program like Starport can definitely benefit from a flexible plugin system that will allow developers to add functionality to Starport on-the-fly.



  • Each plugin is a Go Plugin, and hosted in a repo. There can be multiple plugins inside a single repo.

  • Users will need to add their desired plugins to their config.yml in the new plugin section.

  • A plugin needs to comply a certain interface defined by core Starport developers.








On blockchains, the goal of smart contracts is to simplify transactions between both anonymous and identified parties. Smart contracts are executed when predetermined conditions are met, such as the fulfillment of an agreement or completion of a task. Smart contracts are typically used to automate the execution of an agreement so that all participants can be certain of the outcome, without depending on any intermediary involvement. Smart contracts that currently live on the Ethereum Virtual Machine (EVM) are written in Solidity. Developers will explore among others rewriting an existing Solidity project as a Cosmos SDK blockchain that automates transactions on the blockchain or any other dedicated solution that could bridge the two ecosystems.



BitSong is a project dedicated to musicians and their fans that aims to overcome the bureaucratic and economic obstacles within this industry and reward artists and users for simply using the platform. Bitsong's HackAtom VI challenge proposes the migration of smart contracts on the popular OpenSea ( NFT marketplace to Cosmos SDK. Participants should use the new NFT module that BitSong developed for its own blockchain, which contains an extraordinary feature—the introduction of perpetual royalties (a new standard for splitting royalties). Specifications can be found here

In addition to BitSong's NFT module, there is an Auction where users can buy and sell their NFTs through a marketplace, providing participants with everything they need to bring Ethereum-based NFTs to Cosmos. Specifications can be found here.



  • The module development must be done using Golang.

  • Participants must follow the basic specs as per every Cosmos SDK module development.

  • The module is expected to be completed during the HackAtom, otherwise at least an MVP with integrated tests and CLI (even without UI) is required.

  • The module has to be importable to all ecosystem chains.

  • The NFTs Auction must respect the royalties system present in BitSong's base module.



The source code and the whole ecosystem is available on Github:

BitSong's Developer Portal can be found here:

The module must be created from scratch.  A simple gaia local chain or a simple bitsong local chain can be used



Evmos is an application-agnostic chain that will be interoperable with the Ethereum mainnet, EVM-compatible environments, and other BFT chains via IBC, making it easy for users and developers to interact seamlessly between chains. Evmos aims to be the EVM Hub of Cosmos, making it easy for smart contracts to deploy and communicate within the Cosmos ecosystem.


To jumpstart the growth of the Evmos ecosystem, we have created a helpful list of topics that could be eligible for the Evmos prizes during HackAtom VI:

  1. NFT: Build an NFT smart contract project, Marketplace (dApp), or other supportive tooling (e.g. NFT fractionalization, rentals, etc.) to support the burgeoning NFT ecosystem on Evmos. Judges will be looking for projects with a usable UI and broad support for multiple Ethereum NFT standards.

  2. Wallets: Build an EVM+Cosmos+IBC-compatible wallet that integrates Evmos’ JSON-RPC and gRPC services and is able to display ERC20 tokens, Cosmos coins, and IBC vouchers. Bonus points: Multisig support, WalletConnect V2 support.

  3. Dashboards and Visualizations: Build a block explorer for displaying Cosmos data alongside EVM data (transactions, blocks, etc.). Judges will be looking for projects that push the envelope on “seamless cross-chain UX."

  4. EVM DeFi: Port an existing open-source DeFi smart contract project or build and deploy your own DeFi smart contract application onto Evmos. As with the NFT challenge, your smart contracts must have a usable UI. Support integrations with as many other projects as possible for maximum consideration.

  5. IBC-EVM interoperability: Build an IBC SDK application module to be deployed on Evmos, that is able to handle EVM or smart contract interoperability between two connecting chains that integrate the Ethermint library’s EVM module. The module should be able to process cross-chain contact calls.

  6. Cross-chain (Ethereum/EVM) challenge: Port or build an EVM bridge and deploy it on Evmos so that Ethereum assets (ERC20, ERC721, ERC1155) can be bridged to the Evmos EVM and vice versa.



  • Solidity or other smart contract languages (Vyper, Fe, etc.)

  • Ethereum tools (Hardhat, Truffle, Remix, etc) and libraries (web3, go-ethereum, ethersjs, etc.)

  • Evmos JSON-RPC and gRPC services



Evmos is currently in testnet with additional functionality rolling out over time and leveraging the upcoming features of the testnet and incentivized testnet will have an added bonus.

The applications submitted must have had the significant majority of its development done after the date of the initial Evmos Arsia Mons testnet launch (Oct 12) as verified by Github commits. If you used a previous project as a starting off point, you must detail which components you developed during the hackathon (Nov 11-Dec 8).

Projects must be deployed on a live Evmos testnet (Incentivized testnet or Arsia Mons) by the end of the hackathon on December 8, 2021.

The projects MUST follow the following checklist to be eligible for the prizes:

  • Open source, deployed on Github or Gitlab

  • Have a working UI (if applicable)

  • Have a working functionality

  • Clear documentation in the form of a, for how to interact and run the project


  1. Developer Docs

  2. Discord

  3. Telegram

  4. Medium

  5. Testnet





Alongside the Tendermint high-performance Byzantine fault-tolerant (BFT) consensus engine, one of the main innovations of the Cosmos Network is the robust and secure Inter-Blockchain Communication protocol (IBC), the Cosmos standard for interoperability. This protocol enables communication and digital asset transfers across an ever-expanding network of interconnected blockchains. Developers will need to create new, innovative ways to highlight the possibilities of blockchain interoperability using the IBC protocol such as viable implementations, use cases, data formats or others.



Censorship-resistant, permissionless, and self-sovereign, Akash Network is the world's first open source cloud. One of the biggest values that Akash can provide to other blockchains is the ability to run hard-to-deplatform durable blockchain nodes. Removing blockchains' dependence on centralized hosting providers is one of the biggest steps blockchains can take toward further decentralization. To this end, the Akash community and core developer team have put together the following GitHub repo:  


This repo contains the deployment scripts and references to working images to deploy nodes on a number of different Cosmos chains in a matter of seconds. Akash's HackAtom VI challenge asks participants to develop the container images, SDL files, and documentation needed to run chain nodes from Cosmos chains that are not currently in the repository. Deliverables will be in the form of a PR to the repo.



Deliverable must include the following:

  • Configured SDL for deployment 

  • Working container image

  • Complete documentation in the form of the

  • Working Github account for the pull requests

  • Access to the internet for the deployment and testing of the image on the Akash network 



Network website:

Network Discord:

Network forum:

Mainnet and Testnets:



Sentinel is a network of independent dVPN applications, not just a single consumer-facing dVPN. Sentinel's IBC challenge is a tough one to tackle but could help to solve an important problem in the wider Cosmos ecosystem. Participants must build a fast, reliable, and unbiased randomness generator which could ideally be used for validator selection. 


A randomness generator will be very useful for many other applications, from consumer-level apps to DeFi protocols, and Sentinel believes that the Cosmos Hub would benefit heavily if it could provide on-demand randomness through IBC.



  • Submissions must use a Cosmos module and integrate with the chain as low-level as possible, ideally able to be integrated in the core Cosmos SDK.

  • Tools/Framework - any

  • Development phase - at least a Proof of Concept with a realistic actionable plan of implementation based on the DFINITY solution


SOURCES (this is one previous attempt)


Sifchain is a robust, Decentralized cryptocurrency exchange (DEX) for executing cryptocurrency transactions across chains. Earlier this year Sifchain launched its Betanet with a live DEX and cross-chain support to the Ethereum network, allowing users to swap Cosmos and Eth tokens on the same DEX. Sifchain proposes the following challenge for submission to the Cosmos HackAtom contest:



Exchange crypto currencies regardless of the underlying blockchain or token.

Sifchain’s goal is to become the leading omni-chain DEX, with flexible trading capabilities across dozens of the top blockchains.



Accelerate the pace adoption for new chains and tokens by making them discoverable to 3rd parties.

When a new Cosmos project is launched it takes time for the project to build an audience and encourage use. Projects building on the Cosmos SDK would benefit greatly from automatic chain and token listings. Automatic advertisement and listing of new tokens and chains allow new projects to list on DEXs without requiring project engage one-on-one.



Implement IBC chain name and metadata synchronization service as a Cosmos IBC module.

With the inception of Web 1.0 came IP addresses: strings of numbers which were useful to engineers but useless for the vast majority of users. The invention of DNS (domain name service) enabled users to easily identify a valid server without the need to maintain a client side list. Similarly, this project aims to enable users to easily identify a valid IBC client and its tokens without the need to maintain a client side list of chain id’s, channel id’s, connection id’s, and token denom mappings.


Secret Network has a variety of different tokens, each with their own name, display name, image url, precision etc. Imagine that Secret Network connects to Sifchain, as it will in the near future. Sifchain users transfer over Secret tokens. Currently, these tokens are useless because they still need to be added to a frontend asset whitelist (e.g. or or on-chain whitelist (e.g. before they can be parsed by wallets, apps, exchanges, etc.


The first challenge of this project is to sync over the name, display name, image url, and precision of tokens to and from cooperating blockchains, making these tokens immediately accessible to applications built on the counterparty chains.


Then imagine someone forks Secret Network, creating Fake Secret Network with indistinguishable copies of all Secret tokens. Then they connect to Sifchain as well. How do we tell the difference between tokens from Secret Network and tokens from Fake Secret Network? 


The bonus challenge of this project is to create a governance-driven chain name service that defines which connection chain (which IBC client) is the legitimate one. Once this is complete, chains can update their own token data locally and automatically sync the updates across to counterparty chains.



  • Full stack application
    • Build prototype blockchain with Starport

    • Golang + Cosmos SDK (.44+)

    • Provide a basic test harness via HTTP

      • Browse and exercise REST API
  • Discovery API
    • Implement using REST GET requests and RPC/Protobufs for chain and token metadata entities (examples)
      • Chain
        • Name (domain name esque format)
        • Description
        • image url (or arweave file hash etc)
      • IBC Meta
        • Source channel ID
        • Source chain ID
        • Source client ID
      • Tokens
        • Name
        • Symbol
        • Description
        • Decimials
        • Image url (or arweave file hash etc)
        • Etc
      • Etc
  • Persistence Layer

    • Chain & Token metadata should be stored

    • Command Line Interface (CLI)

      • Provide CLI to update and query chain & token metadata to be synced across chains
      • If used properly, Starport with scaffold most of this for you
    • REST/RPC
      • Provide REST/RPC interface to update and query chain & token metadata to be synced across chains
      • If used properly, Starport with scaffold most of this for you
  • IBC Layer
    • Synchronize chain name and metadata across IBC clients

    • For the minimum viable product, IBC client id’s may be hardcoded and this hardcoded list would naturally need approval via a chain upgrade.

  • Governance Layer (bonus)
    • Utilize governance to form a consensus on the canonically identified IBC client for a given counterparty chain from the source chain
  • Web Interface (bonus)
    • A prototype web interface to display how
  • Document the architecture, decisions and build & run steps a at the root of your project
  • Provide a video demo using the product


RESOURCES: Tips & resources for a great submission

A successful submission provides sufficient detail of the ‘who, what, when, why, and how’ of the service. The following questions should be considered in the design of the solution.

Who is using the API? When would the API be used? Why does the service need to exist? How does the service address the problem? Does the API appropriately solve the question being asked by why? How does the service benefit the Cosmos community? What happens when the service fails? 

The following resources can be used to aid your development.


Cosmos SDK documentation

Cosmos SDK on Github

Cosmos IBC documentation

Design Patterns for Dapps

Design Patterns for GoLang (Self-documenting REST)

Google RPC (gRPC, lightweight HTTP/2)


Peers for the testnet:

  • b4caebe07ab25126e4e6053bf955833198f18ed0@

  • b6f113a30e7019b034e8b31cd2541aebebaacb60@

  • ffcc2fab592d512eca7f903fd494d85a93e19cfe@



Built on Cosmos, Pylons is a fast and interoperable system for brands and creators to build engaging products and with meaningful NFT experiences. For this challenge, Pylons wants you to build new, innovative ways to highlight the possibilities of blockchain interoperability using the IBC protocol—such as viable implementation, use cases, and data formats—using the Cosmos SDK. 

Be the developer that unlocks the potential of interoperability for IRL applications—on Cosmos with the Pylons SDK. Reinvent centralized ticketing systems using NFTs.



Build a ticketing experience on the blockchain that promotes authenticity, transparency, and monetization. Integrate administration that allows for significant resale rake that remits more $USD/$ATOM to the artist. 

Utilizing the Cosmos SDK + Pylons SDK, create a ticketing sales and distribution system with the following attributes:

  1. Ticket tiers and relevant price categories

  2. On-chain redemption upon venue entry/check-in

  3. Distribution of royalties upon execution of secondary sales

  4. Mobile or web client. 

  5. Relatively unobtrusive chain interaction; chain state is saved on chain and updated with real time venue entry dynamics

  6. The prize can be paid in either ATOM or Pylons (native token) at a parity according to a fixed day market price set ahead of time.




Block Explorer:

User Endpoint:



Twitter: @Pylonstech_support

Reddit: /r/pylonstech






Agoric is an open-source development company launching an interoperable Proof-of-Stake chain and economy. Agoric's hackathon challenge is to build a set of Agoric smart contracts on Agoric that use Osmosis LP tokens brought over IBC to provide additional defi capabilities to holders of those tokens.  Example use cases could be:

  • More flexible liquidity mining options for projects - contract accepts Osmosis LP tokens for different lockups than are available on Osmosis and provides different reward tiers

  • Loan protocol which allows Osmosis LP tokens as collateral to borrow against

  • An OlympusDAO-style protocol which accepts Osmosis LP tokens as bonds

  • Any other creative use case you can imagine!


Submissions must include a link to the github project and a basic video walk through of the code and use case. 

A successful project must: 

  • Accept Osmosis LP tokens into a contract

  • Provide a novel defi-related use case for those tokens

  • Include Agoric JavaScript contracts which successfully complete the intended use case! A UI is optional. 

Use cases do not need to be limited to the examples provided above.

To qualify, the contract(s) must be written in JavaScript using the Agoric SDK.  Either local or testnet deployments will be accepted, but Agoric testnet deployments are preferred.


Agoric ERTP Documentation

Agoric Zoe Documentation

IBC Documentation


Getting Started Docs





Accessibility is a primary driver to entering the blockchain ecosystem, yet one of the most challenging tasks in blockchain is to make cryptocurrency and digital asset ownership accessible to end-users. Applications should manage keys in a secure manner allowing users to access their assets in an easy way and improving the overall user experience for beginners and advanced users. Developers are expected to build applications that make features more accessible or provide a more intuitive experience for an end-user.



Nym is a privacy platform. The Nym Mixnet provides network-layer privacy for users and applications by hiding the metadata (IP addresses, device types, timings, etc.) of the data packets that are sent through it. Creating a file storage application over the Nym Mixnet will allow users to store files in the cloud in a secure and private manner. The title of Nym's challenge is ‘The Eternity Service 2.0’. 


The challenge is to create a Nym service provider (application) which offers cloud file storage, and a GUI where users interact with the service provider, all via the Nym mixnet. 


Users must be able to do the following via the GUI: 

  • Store an encrypted file on the service provider

    • Users must be able to encrypt a file and upload it to the service provider’s storage via the Nym mixnet. Whether new keys are generated for this encryption or whether the user can import existing keys is up to the developer. 

    • This step will also hash the contents of the file and store the resulting hash in local storage on the user’s machine, and be represented in the GUI.

  • Verify their file has been uploaded and stored:  

    • Users must be able to poke the service provider with the hash of the file they uploaded in order to verify that the encrypted file exists with this hash as its identifier. 

    • If the service provider answers in the affirmative, users should have the option of having their client-side application overwrite the bytes of their local storage where the file is to remove it. 

  • Retrieve their encrypted file from the service provider

    • Users must be able to request their file from the service provider using the hash as proof of ownership. 

    • Users must be able to decrypt the retrieved file locally. 

  • Request for the service provider to delete its copy of their encrypted file

    • Users must be able to ask the service provider to delete the file it is storing, and verify there is no identifier remaining, again using the content-hash of the encrypted file. 

  • [Optional bonus feature 1] Users are able to securely share the hash & decryption key of uploaded encrypted files with friends via the Nym mixnet!

  • [Optional bonus feature 2] Users are able to choose between uploading private files or public files for archiving: 

    • Users have the option of also uploading an unencrypted file to the service provider.

    • Users can then upload the hash of the file to the Nym blockchain, with plaintext information about what the file is. How this information is best uploaded and stored in the blockchain is left to the developers to decide. 

    • This information is stored in a publicly accessible manner.

A note regarding Nym testnet development: Nym is likely to upgrade to a new testnet and/or to mainnet release during the time period of the hackathon. New networks will require bandwidth credentials to be created and used by both the client-side Nym client and the service provider’s Nym client in order to send packets through the mixnet. Integrating these updates will involve a small amount of extra work, but Nym will offer support by providing any necessary information!



  • Submissions must be usable/workable via the Nym testnet, but not necessarily production-ready.

  • Submissions must include a working service provider and desktop GUI application.

  • No specific language or framework requirements. 

  • Good security practices will be an integral part of the judging criteria.



The best place to start is using Nym's network overview documentation. It will also be helpful to look at how Nym's existing network requester service provider is set up in the documentation

Further reading regarding each node type in the Nym network can be found here, and a simple easy-to-read introduction to mixnets here

For historical/contextual information regarding the title of this challenge, Nym recommends reading Ross J. Anderson’s The Eternity Service.


Injective Protocol is pioneering a new decentralized economy to create a freer and more inclusive financial system. Injective has created a solution that allows crypto exchanges to become a decentralized public utility, giving users and their community much-needed value-capture in the exchange landscape.

Injective's HackAtom VI challenge is to build a new simple single-page application trading interface for trading spot and perpetual markets. The purpose of this is to provide mass market users (not pro traders) an accessible, user-friendly interface for trading (Like Matcha on Ethereum, for example). This will allow novice traders to access Injective easily.

On Injective such frontend interfaces are referred to as a Relayer. A relayer is essentially a frontend interface that allows users to interact with Injective Protocol. Relayers are able to earn 40% of all trading fees generated. So if you build a relayer you can continue to earn fees in perpetuity. Relayers come in all forms. Currently there exists a number of different relayers such as Injective Pro and Picasso Exchange. A relayer can include new features and even be region specific (for instance there is currently a relayer being built entirely in Chinese).

The easiest way to get started without worrying about underlying business logic implementations is to fork our [injective-dex](<>) repo. This repository already contains two of the three components required for the application. It also has a lot of example usage of our [injective-ts](<>) monorepo packages that are used to easily build user interfaces that consume and interact with the Injective Chain.

You can find tips and more details in the following page:


  • Make a meaningfully unique/better designed product. Submissions that simply restyle a few components will not be awarded.

  • Proper project structure.

  • Clean and readable codebase.





ISCN is a NFT-like content registry record running on the LikeCoin chain. We allow content creators to register their content metadata on the chain through ISCN transactions. 

Currently, there are three ways for creators to register their content metadata to the LikeCoin chain, 1) register via, 2) ISCN batch uploader, 3) LikeCoin Wordpress plugin. Unlike traditional NFT, ISCN owners might have to view, manage or edit ISCN records in batch, since talented creators can produce creative works quickly, and have a huge collection of series of metadata.

In this challenge, we hope developers can develop a wallet interface to allow users to manage their pre-NFT credentials (metadata) records. Useful features include visualization of the metadata records, and organizing them into directories or groups; interface for viewing and editing metadata records, and sending and trading of metadata records (change of owner).



  • Develop a dApp interface for users to view and manage their ISCN records

  • Visualization of users’ ISCN records, allow users to organize their collection in UI

  • Editor for ISCN records, figure out a user-friendly way for editing in batch mode

  • View-only mode to discover contents of a specific address/creator

  • Global ISCN browsers, preferably with a way to discover groups, series, and relationships between works

  • Other features that might be useful for content creators to manage their ISCN records





ISCN batch uploader:​.

LikeCoin WordPress plugin:

Mainnet LCD:

Mainnet RPC:


Mainnet with actual wallets with ISCN records:

Other useful information about LikeCoin mainnet:

LikeCoin chain repo:


Archway is a smart contract platform that rewards developers, ushering in next gen dApps. Archway's HackAtom VI challenge is to create a base NFT marketplace on Archway’s testnet. This entails the marketplace smart contracts as well as front-end that will allow users to buy, sell, and trade CW721 tokens in exchange for CW20 tokens.


Key features to include:

  • A generic NFT marketplace smart contract

  • Listing CW721 tokens for sale for any CW20 token

  • Buying CW721 tokens with CW20 tokens

  • Trading any CW721 token with any other CW721

  • Any additional marketplace capabilities you’re keen to experiment with—auctions, fractionalization, royalties, etc. 









DeFi is a blockchain-based alternative financial system to the legacy system of banks, exchanges, insurance companies, mortgage providers, etc., but reimagined from the ground up with no intermediaries in the middle. Unlike traditional finance, with no gatekeepers to turn down your application, DeFi lowers the barrier to entry, allowing more people to access financial services, take out a collateralized loan, or earn a yield on their assets. Help expand the capabilities of DeFi by building an app or module with the Cosmos SDK.



Kava is a software protocol that uses multiple cryptocurrencies to allow its users to borrow and lend assets without the need for a traditional financial intermediary. Kava's HackAtom VI challenge asks you to build a fully autonomous options protocol as a Cosmos SDK module. You can assume that you have access to a price oracle.



All projects must be built using the Cosmos SDK, version 0.39+. Submissions should have at least minimum-viable functionality (ie, the main user actions are all supported by the protocol).



Testnet: Hackers can run a local testnet themselves


Tendermint builds and maintains critical state-of-the-art infrastructure for decentralized applications, such as Tendermint Core, Cosmos SDK, Starport, and Emeris. Tendermint is a core contributor to the Cosmos Network and organizer of HackAtom VI. Find the details of Tendermint's DeFi challenge below:


  • Build a general tool for Loan or Insurance modules

  • Collateral-less loan (Flash Loan)

  • Non-custodial asset borrowing (earn interest on deposit)

  • Examples for inspiration are Cosmos SDK Loan or Insurance Module

  • Use Gravity DEX and the Cosmos SDK to build a new Loan or Insurance Module





Cosmos Testnets:




The Ki Foundation bridges CeFi and DeFi through an innovative range of products that provide users with an easy and seamless way to engage in DeFi operations, including its flagship Ki Chain blockchain and bridges to other blockchain ecosystems. The Token transfer capability of IBC was the first step showcasing the power of interoperability between Cosmos SDK-based chains. In order to grow the value of this thriving ecosystem, we need to implement the next step of cross-chain interoperability through the Interchain Account feature. 

For this challenge, developers will need to implement the module enabling cross-chain interoperability with features such as delegating, undelegating, sending coins, or operating an application-based action such as swapping on a chain like Osmosis.

The idea is to leverage IBC capabilities and be able to use application-specific features on different sovereign chains in the Cosmos ecosystem. Specifically, we would like to be able to call any custom Cosmos SDK message on any IBC-enabled chain from an interchain account. 

A concrete use case we want to implement is the possibility to interact with the Osmosis GAMM module. For instance, we would need to deposit liquidity in pools and swap tokens. Another important aspect is the first class support of Interchain Accounts on CosmWasm smart contracts. We would like to use InterChain Accounts features from a CosmWasm smart contract and be able to interact through IBC with a CosmWasm smart contract on another chain.



Here is how we see the global architecture of the project and how we imagine the delivery. Basically, the challenge will include the below major tasks:


  • Specifications:
  • IBC Relayers Implementation:

    • Analyze the ongoing initiatives from different parties regarding ICS-27 support in the different relayers implementations

    • Identify the missing features to fully support ICS-27

    • Submit a PR to at least one major relayer implementation (Hermes, Go relayer, or confio typescript relayer)

  • Cosmos SDK:

    • Identify if the Interchain Account feature could be designed as a Cosmos SDK module, easily integrable to any IBC-enabled Cosmos chain

    • Submit a PR to Cosmos SDK with the implementation of an Interchain Account module

  • CosmWasm / Wasmd:
    • Identify the ongoing initiatives from different parties regarding ICS-27 support in CosmWasm contracts
    • Identify the missing features to fully support ICS-27
    • Submit a PR to wasmd with the implementation of ICS-27 specification
  • MVP: Implement an MVP showcasing the different features

    • End to end test repository with a working demo

    • Documentation and guides on how to use the product

    • Interoperable product

    • Deployed on Juno testnet






Build something cool with Osmosis. Bonus points if you incorporate ION. 







Blockchain has the potential to completely restructure the gaming industry. Blockchain gaming uses true item ownership from the same technology that lies at the core of cryptocurrencies. Be the game developer that unlocks the potential of gaming with Cosmos. Build the future of gaming with the Cosmos SDK. Builders will explore ideas using the Cosmos tech like creating a game with meaningful gameplay behavior mediated through state changes, a decentralized virtual world or others.



Blockchain has the potential to completely restructure the gaming industry. Blockchain gaming uses true item ownership from the same technology that lies at the core of cryptocurrencies. Be the game developer that unlocks the potential of gaming with Cosmos. Build the future of gaming with the Cosmos SDK. Builders will explore ideas using the Cosmos tech like creating a game with meaningful gameplay behavior mediated through state changes, a decentralized virtual world or others.


Build a game with meaningful gameplay behavior mediated through state changes using the Cosmos SDK blockchain framework, or build a decentralized virtual world with Cosmos network -- utilizing the Cosmos SDK + Pylons SDK.



Build a gaming experience on the blockchain that follows the crafting experience of a Strange Clan character. Players should be able ro  farm, craft, and quest using Cosmos SDK + Pylons SDK. Gamers can create, purchase and trade with other players as well.  Further requirements include:

Seamless chain integration (check out Pylons cookbooks and recipes)

Implement farming

Create direct trading and listing platform (bonus)



Characters should be able to create their own items/list them on trade for other Strange Clan Holders

Characters should be able to interact with the 3d Strange Clan environment and develop their Clan/plots of land

Cosmos SDK/Pylons SDK is used to for on-chain implementation of creation and trading

Purchases should be reflected in-game and on-chain



Strange Clan Website

Unreal Engine 5 Early Access


Block explorer:

User Endpoint:

Pylons Discord:

The Strange Clan Discord:


Twitter: @Pylonstech_support, @thestrangeclan





Secret Network is an open-source protocol that performs computations on encrypted data, brining privacy to smart contracts and public blockchains.  Secret's challenge is to build a game on Secret Network using CosmWasm, Secret NFTs, and on-chain randomness.


Blockchain NFT gaming is taking off, even though main components of gaming are non-existent with traditional blockchains, namely private data and randomness. To create Games of Incomplete Information, private data must be utilized, and to create fair games, randomness must be utilized. Randomness can also be utilized to generate unpredictable mazes, puzzles and maps, to roll dice, to shuffle cards and cubes, to create gaming AIs, and to add "chaos" in order to enhance in-game experiences.


Traditional blockchains like Ethereum don’t have data privacy or on-chain randomness, therefore gaming creators resort to centralized solutions. This makes for less fair and transparent games, and also leads to non-ideal UX at times (getting randomness from off-chain sources takes time).


On Secret Network, all contract’s data is private by default. Only the contract can read its own state, and only the transaction sender can read the transaction inputs and outputs. By utilizing private state, contracts can store a private entropy pool and from it derive private random numbers instantly and at will.

The participants to this challenge will need to build a game on Secret Network using CosmWasm, Secret NFTs and on-chain randomness.



Implementation of blockchain gaming app on Secret Network

Write contracts using CosmWasm

Utilize private data (Game of Incomplete Information)

Utilize on-chain randomness 

User interface in a mobile app or a web browser

Using Keplr is optional

May implement a simple local wallet for better UX



Use Secret NFTs (SNIP-721)

Use query permits

Don’t use viewing keys



Awesome Secret


Secret NFTs:



Keplr + query permits example:  


On-chain randomness examples:

Maintaining a private entropy pool and get random numbers at will:

Shuffling a deck of cards:

Running a local test chain: 

Compiling a contract: 

Implementing a simple local wallet for better UX

Don’t require prompting the user to sign transactions 







The ultimate purpose of the Internet of Blockchains is to empower people everywhere with digital technologies that enable communities to prosper. When communities prosper, they can regenerate the planet, and respond more effectively to the climate crisis. Change the state of the planet by building modules, accessible apps and integrations for local currencies, self-sovereign identity, non-fungible impact tokens, verification oracles, decentralised impact exchanges, and earth intelligence data. This is the Interchain Earth Mission!



Regen Network is a platform for a thriving planet, that aligns economics with ecology to drive regenerative land management. Regen Network is soon approaching its first mainnet upgrade, which will include the launch of the first module for representing carbon credits (“ecocredits” on Regen Network) as on-chain assets on a Cosmos SDK-based blockchain.


Regen Network's challenge for HackAtom VI under the EARTH category is to bridge ecocredits into the interchain ecosystem—by implementing an IBC application that allows users to move these new types of ecological assets across different blockchains.


Ecocredits are more feature rich than other familiar standards such as ERC-20 tokens, and allow for additional ecologically pertinent metadata, as well as the ability for a holder to “retire” these credits—thus claiming the credit as an “offset” in carbon accounting terms. As such, your submission should take into account these nuances and provide for cross-chain access to metadata, as well as cross-chain capabilities for retiring credits.



The challenge submission should include:

A complete IBC application in its own repository

Documentation of the specification and functionality

A readme with instructions for use

A demo showcasing cross-chain ecocredit transfer & retirement using a fork of regen-ledger and a testnet of another IBC ecocredit enabled blockchain.

Bonus points will be provided for extending this functionality into a dApp where end-users can issue, transfer, and retire ecocredits in a cross-chain capable way.



Regen Ledger:

Ecocredit Module Implementation: 

Ecocredit Module Docs:

IBC Custom Application Docs:

Getting Started Tutorial:

Redwood Testnet:

regen-redwood-1 is the chain ID for Redwood Testnet

Redwood Testnet launched with the v1.0.0 release tag of regen-ledger


When starting a full node or a validator node from genesis, you will need to start the node with the v1.0.0 version (the "genesis binary"). For more information about preparing your node to migrate to the v2.0.0 version, see Upgrade Guide v2.0


 The following URL is the node address for a full node operated by RND:




Juno is an interoperable smart contract network that is highly scalable, robust, secure, and easy to deploy. is a validator operated by that has launched with the Cosmos Hub 3 upgrade. Both believe that the ultimate purpose of the Internet of Blockchains is to empower people everywhere with digital technologies that enable communities to prosper. When communities prosper, they can regenerate the planet and respond more effectively to the climate crisis. 


For this important challenge, Juno and are teaming up to ask you to change the state of the planet by building modules, accessible apps, and integrations for local currencies, self-sovereign identity, non-fungible impact tokens, verification oracles, decentralized impact exchanges, and earth intelligence data. 


Create something that can leverage the power of the Juno platform and Cosmos IBC functionality that can support carbon emission reduction initiatives. Identifying ways to tie in existing Juno functionality with regenerative-focused networks like Regen Network could be a great opportunity as well.

Use the Juno platform and Cosmos IBC. 

You may find it helpful to use the Regen Network as well for its specific use case in regenerative climate-focused applications.



Testnet information:

Juno version: v2.0.0-alpha.3

Cosmos-SDK: v0.44.3

Wasmd: v0.20.0

Wasmvm: v1.0.0-beta

Endpoints LCD Tendermint RPC




Humanity is on the brink of a fundamental state-transition into planetary chaos. Erratic weather patterns and natural disasters resulting from flooding, droughts and wild-fires are becoming more frequent each year, as climate-change accelerates. Mass human migrations away from disaster zones are already beginning and we see conflicts and famine. Re-emerging tropical diseases and lethal new infectious agents, such as COVID-19, threaten human and animal life. Natural resources are being depleted at an alarming rate, way beyond the planetary boundaries for sustainability, and imperial wars to control and own these resources have already begun! 


What can we do to avoid mass extinctions of life-forms on Earth and to reverse the threat of losing centuries of human progress?


We must develop responses to the Earth Crisis using anti-fragile digital technologies and data about the state of the world that is verifiable and increases our intelligence. The ultimate sense-and-response system must become globally distributed and enable intelligent, rapid, effective local coordination, with incentives for people to take action, and to get sufficient resources to flow where these are most needed. 


The ixo-Cosmos Internet of Impact Hub and connected sovereign Impact Zone networks can provide the blockchain infrastructure needed to respond to the Earth Crisis. ixo describes the Internet of Impact as a global digital immune system for humanity.


Your challenge is to build and demonstrate applications using the Internet of Impact, or software components that add capabilities to The Impact Stack, for preventing and responding to specific types of real-world Earth Crisis events. 


You will collaborate with Problem-owners who have place-based or domain-specific knowledge and expertise about use cases that may range from making earth state observations for early-warning systems, to financing earth state-changes, to enable local citizen action, and to create global change. 


This is an enormous, urgent opportunity space of the highest priority, in which to apply your skills, connect and interoperate with existing systems, integrate the latest AI technologies, and build better alternative decentralized financing and data verification mechanisms.



Demonstrate a solution for a specific real-world use-case that is ideally built in collaboration with a problem-owner who understands an Earth Crisis events domain. For instance, The Red Cross International Disaster Bonds insurance mechanism for rapidly delivering relief financing to communities threatened by natural disasters. The Earth Crisis problem space is rich with opportunities, so we look forward to seeing really interesting use cases that address real needs.  

Build your solution on the Internet of Impact using the ixo-Blockchain SDK. The blockchain base layer can either use the current Go modules and capabilities implemented in the ixo Pandora-4 Testnet (which has the same configuration as the ImpactHub-3 main-net), or you can build and configure new chains that include base ixo-Blockchain modules, with additional modules imported from the Cosmos SDK, or other projects. You may even decide to build your own custom module/s, using the Cosmos SDK framework, or implement smart contracts–for instance, using the CosmWasm module.

Create entities with specific roles and capabilities in your solution, using ixo Decentralized Identifiers (DIDs) and combinations of the following entity types:

Agents that are Individuals or groups with Self-sovereign Digital Identity.

Projects for managing agents to finance, deliver, claim and verify pre-defined results. 

Investments for forming and distributing capital assets to invest into other entities, using sustainable DeFi mechanisms, such as ixo Alphabonds.

Oracles that provide trusted information from the real-world, or offer prediction services for proofing and verifying claims, personalising services, prescribing interventions, preventing risks, protecting against threats, and enabling more effective human participation in decision-making. 

Assets that are tokenized using Interchain Identifiers, to represent any digital asset types such as tokenized Carbon Credits or other classes of Impact Tokens, tokenized titles and rights over physical assets, tokenized data assets, etc.

Templates that encode the claims and data models for the Internet of Impact Linked-data Graph, which enable users to quickly configure new entities from template libraries.

Cells for coordinating groups of agents with a shared purpose, including through DAOs mechanisms.

Provide a compelling user interface to demonstrate from the target user’s perspective how the solution works to meet their needs. Using personas and user journey maps would be helpful in your presentation of the solution. You can build your interface using the ixo-Webclient (React, Typescript), with the option to add new features and systems integrations into the current version of the web-client. Alternatively, you can build entirely new client applications, using the ixo-Client SDK and javascript libraries. For instance, an IoT device client that feeds information into the  integrating IoT devices with the ixo system.

Consider building service integrations that extend the capabilities of the Internet of Impact to receive information and services from other Web3 or Web 2.0 networks, and/or to provide information and services into other networks.



The ixo Foundation Github Repo contains code and documentation for all the necessary base software components for the Internet of Impact and related Impact Stack.

ixo Developer Documentation

Risk-Adjusted Bonding Curves

Pandora Testnet

ixo Web Application UAT instance

ixo Discord community 

ixo Discourse discussion forum 

Developers Slack for HackAtom

Code with Us workshop on the ixo Bonds Module

AI for Good Neural Network - connecting problem owners to problem solvers


The Earth Tokens Challenge

For this challenge “Earth Tokens” are defined as classes of tokens that are created and used for the purpose of sustainable socio-economic development, climate action, and ecological regeneration.

Tokenization is transforming how people are incentivised, how decentralised economies and communities are secured and governed, how capital gets formed and allocated, how products and services are financed, and how digital or physical assets are used for financial or non-financial applications. 

Across this wide range of applications there are many different classes of tokens. 

Each token class has a unique set of token properties and token behaviours.

The Interchain Identifier (IID) Specification describes how to configure various classes of tokens, using token templates and standards that are designed to be interoperable across all blockchain networks, and addressable from the web.


Consider these 3 use-cases as examples of how different classes of Earth Tokens could be configured,:

Community Currency Tokens enable people to exchange their time, goods and services to grow a local economy. A token issuer may define a class of fungible, fixed-supply tokens that can only be transacted between identified accounts with verifiable credentials.

Mutual credit Tokens enable small businesses to transact with less reliance on external capital and this token class may have more characteristics of non-fungible tokens, when they are linked to verifiable claims about the provenance of goods produced–for instance, in sustainable supply-chains, or if these tokens accord the holder an automated right to be paid for invoices when orders are delivered.

Renewable Energy Tokens enable independent power producers to sell certified green electricity, or to claim Carbon Credits that can be sold as offsets. Non-fungible Renewable Energy Certificate (REC) tokens may include the right for a token-holder to mint fungible fractional units of the REC tokens, to trade for electricity supply.


These examples only begin to demonstrate the incredible potential for configuring classes of tokens for different Earth Token use-cases. For this challenge you will build and demonstrate innovative ways for Earth Tokens to be issued, traded and used in Sustainable DeFi and Regenerative Finance (ReFi) applications. 


Suggested areas for innovation include (but are not limited to):


Great UX for creating and using Token Templates to mint and different classes of Earth Tokens.

Decentralised marketplace mechanisms for trading different classes of Earth Tokens. This may include new types of services that enable tokens of different classes to be bought or sold, auctioned, used as collateral, lent or borrowed, used as offsets, etc. 

Automated market-makers for trading heterogeneous token classes, such as a liquidity mechanism for pooling fungible with non-fungible token classes.

Authorisation Capabilities (zCaps) to provide secure delegated authorisation mechanisms for interacting with token services.

Clever ways of using Liquid Staking or other token derivatives, to unlock capital for sustainable development and ecological regeneration.

Software tooling or integrations that further enable Earth Tokens use-cases.



Address a real-world need that is relevant to the Interchain Earth Mission, based on a real or fictitious use-case that has a great user story.

Implement the Interchain Identifiers (IID) specification and Token Templates.

Use the standard Cosmos SDK modules, and/or add new features to existing Cosmos modules, and/or create new module/s.

(Optionally) build on the ixo-Webclient, with the possibility of adding new features and/or integrations. 

(Optionally) contribute new software tooling for implementers of Earth Tokens applications.



Interchain Identifiers and Tokens Specifications

Cosmos SDK Modules

InterWork Alliance Token Taxonomy Framework

BlockScience Community Currencies 

The ixo Foundation Github Repo.

ixo Developer Documentation

Risk-Adjusted Bonding Curves

ixo Pandora Testnet

ixo Web Application UAT

ixo Discord community

ixo Discourse discussion forum 

Developers Slack for HackAtom

Code with Us workshop on the ixo Bonds Module

Peoples Money describes the call-to-action from the UN, to create sustainable digital finance ecosystems