The ixo blockchain provides a shared global infrastructure to program capital for sustainability using innovative financing applications, such as Smart Impact Bonds. We use Tendermint consensus and Cosmos modules as the backbone for running projects and data verification services. The Ethereum network provides the financial settlements layer and this also enables ixo projects to interoperate with the universe of Ethereum DApps.

Authors: Cedric Franz & Dr Shaun Conway

In this article we describe how we have built a 2-way bridging mechanism between the ixo Tendermint-Cosmos blockchain and smart contracts on Ethereum. We have innovated the use of universal identifiers with object capabilities, to synchronise state and achieve concurrency across the networks.

Using blockchains to program capital for sustainability

The ixo blockchain has been built to provide a shared, global, censorship-resistant, open data and finacing infrastructure for sustainable development. This provides data verification and capital liquidity mechanisms for programming capital to achieve sustainability objectives.

With blockchain ledgers, smart contracts, deterministic oracles and tokenization, we now have the technological means and economic mechanisms to program capital for sustainability.

The Cosmos-Ethereum Bridge

To achieve interoperability between the ixo-Cosmos network and Ethereum-based networks, we have built a bridging 2-way peg. We have launched this deployment in public beta, as an interim solution to provide a functioning utility, whilst more robust pegging solutions are being developed and proven by other project teams, including Tendermint-Cosmos. We hope to contribute to these developments by sharing our experiences of building this bridging mechanism and what we have learned about some of the known (and unknown) vulnerabilities of this approach.

How we have implemented 2-way pegging between Cosmos and Ethereum

The bridging mechamism for this 2-way peg is currently implemented with a custom Cosmos module on the ixo blockchain and custom smart contracts on Ethereum. We use universal identifiers (based on the W3C DID specification), to control concurrency across both networks.

Our primary application of this bridge is to create a project on the ixo blockchain and stake IXO tokens into this project to fuel the running-costs, which includes payment to ixo network node hosts for data processing and hosting and automated payments to evaluation agents per claim that these services process for verification (the verification fees charged are determined by evaluation agents and are market-based).

Settling payouts on ixo projects (Wireframe designs)

At specific project milestones, the fees are available to be settled and paid in IXO ERC20 tokens through the Ethereum smart contract instance associated with a project. As a side-note, we have elected to issue IXO ERC20 tokens for this purpose using a vanilla ERC20 contract, as we did not want to add functionality to this smart contract that could introduce security vulnerabilities.

The stake of IXO for each project is held in a separate smart contract for each project, to maintain transactions and financial integrity on a per-project basis. This remains under the control and ownership of the project founder, so ixo does not provide any custodianship over project assets.

To achieve this, we created a smart contract that operates on the principles of an escrow. IXO is transferred into the project smart contract by the project founder (or a third-party sponsor) and locked. When this transaction finalises, an equivalent number of IXO-native tokens (Cosmos Coins) are minted on the ixo blockchain and are associated with a project account.

As claims are processed on the ixo blockchain, the project’s IXO-native tokens move into fee accounts and the project account balance is reduced accordingly. This continues until the project wallet is depleted, or the project is stopped.

When a payout is requested by the project owner, IXO-native tokens are burnt on the ixo blockchain and ixo Validator Nodes sign authorisations on the corresponding Ethereum smart contract, to payout the ERC20 IXO token. A quorum of validators must sign-off on the multi-sig smart contract to release the escrow.

How the ixo bridge into Ethereum works

To stake IXO as fuel into a project so transactions can be settled on Ethereum is a two-step process:

Create a ProjectWallet on Ethereum to hold the tokens associated with a project. Transfer the IXO ERC20 token to the ProjectWallet and notify the ixo blockchain.

A ProjectRegistryContract creates and keeps track of all the ProjectWallets that are created. Each wallet is indexed using the project decentralized Identifier (DID) for this to be located, tracked and authenticated.Transfer of IXO tokens to the project wallet uses a standard ERC20 transfer. We designed this to keep the fueling workflow as simple as possible and for this to be supported by a wide variety of existing Ethereum wallets.

Schematic representation of the Ethereum Smart Contract System

Once a transfer has been confirmed, the transaction ID of the transfer is send to the ixo blockchain. The ixo chain checks that a set number of block confirmations have occurred, before minting the equivalent number of IXO-native tokens. We use the Cosmos accounts and coins modules, which include the built-in functionalities to mint, burn and transfer coins between accounts. For each project on the ixo chain, a set of accounts is created to hold the minted tokens for that project. This includes accounts for the project owner, as well as accounts that accumulate fees for agents authorized to participate in the project. As a project is fueled on the Ethereum network, IXO-native tokens are minted into the project account on the ixo network.

Staking of IXO tokens on Ethereum

Fees and accounting

We use the standard accounting and coins modules from Cosmos. However, we have not used the fees and gas functionality from Cosmos, but rather rolled out our own mechanism to meet the special requirements for project fees that are not standard functionality within the Cosmos SDK.

Each project has a set of accounts. These hold the IXO-native tokens associated to the project and the sum of these tokens is always equal to the sum of IXO tokens that are escrowed on Ethereum in the ProjectWallet.

Settlements on Ethereum

Projects have two types of settlements on Ethereum. The first is to automatically transfer tokens to a pre-configured set of addresses in the project Ethereum wallet, which pays for the network transaction fees. The second is to transfer tokens to wallet addresses that are dynamically specified by the project owner, as part of the project payout process to authorized evaluation agents working on the project.

The mechanism for both types of settlements works in the same way. Three Ethereum smart contracts are involved in a settlement. The ProjectWallet smart contract holds the escrowed ERC20 IXO token, a ProjectWalletAuth contract authorizes transfers from the ProjectWallet, and the AuthContract instructs the ProjectWalletAuth contract to initiate a transfer of tokens. The AuthContract is a generic contract configured with validator signatories who are authorized to sign off calls to other contracts. Each validator signs off on an action until a quorum is reach, when the transaction is triggered.

When a payout is triggered on the ixo Cosmos chain, we burn the equivalent number of tokens to the settlement amount and create a transfer action on the ixo chain. Then each validator calls out to Ethereum to sign off on the transfer action. The validator that is the last to reach the quorum triggers the transfer of the tokens out of the ProjectWallet to the project owner’s ProjectWallet. Subsequent sign-offs for a triggered action are ignored.

Gaps and vulnerabilities

Achieving concurrency across chains to match state is not trivial. An independent security audit of our mechanism has identified vulnerabilities that could create inconsistencies between the state of tokens on Ethereum and the ixo Cosmos network.

The main concern is that a quorum validators could fail to sign off on the requested actions. This can occur if there is insufficient ETH in the validator wallets to pay for transactions on Ethereum, or if there are are network performance issues.

As an interim fix, we have erred on the side of caution, burning tokens on the ixo chain but not paying out the ERC20 tokens from the escrow if conflicts occur, rather than having duplicated settlements on Ethereum.

At this stage of deployment, we still have central control over the ixo validator nodes, so we can mitigate this situation by manually overriding any valid failed transactions. We are working to develop fixes to this set of issues, before decentralizing the network of validator nodes.

Another theoretical vulnerability is that we rely on the performance of the probabilistic finality of the the Ethereum proof-of-work blockchain to make state-changes on the ixo Cosmos chain.

The Cosmos team is working on a module named ​Peggy​ to establish peg zones as an alternative mechanism, but this is not ready for production use.

As an interim solution, we have increased the block limit to 15 confirmations required before changing state on ixo. This needs to strike a balance between speed and security for the system and we will have to monitor how this performs from a user experience perspective, although settlements for projects are infrequent, so we do not anticipate this being a significant impediment for the time-being.

Conclusions (for now)

We hope that others will find value in the idea of using a universal identifier system, based on the W3C DID specification, with an Object Capabilities model, to secure cross-chain transactions and achieve concurrency.

We look forward to iterating on this foundation and would be grateful for collaborators to join these efforts to build a shared data and open financial infrastructure for sustainable development.