Intro

At the upcoming October Swarm Community Call, Swarm dev team will speak about multi-chain support among other development updates. This feature was announced earlier this year and Swarm founder Viktor Trón talked at length about it at Swarm Summit in June 2024.

Let’s revisit his presentation and talk about realisation of multi-chain functionality on Swarm. Developers on the team have been thinking about it for years and came up with a simple and elegant solution for interoperability between the parts of the wider crypto ecosystem.

General Description

Multi-chain allows uploading content on Swarm without exchanging $BZZ and buying $xDAI on the Gnosis chain that hosts the relevant smart contracts. However, $BZZ token holders should not be afraid that multi-chain is getting around $BZZ, it is included in the mechanism.

Swarm aims to offer seamless integration of a storage solution that is possible to use with a native currency of any external chain and thus increase the solution’s adoption. Adding multi-chain will allow users of DApps on other chains to use Swarm for storage and communication.

The Approach & Mechanics

The approach of Swarm is very simple: it’s a combination of a decentralised exchange (DEX) and delegated transaction execution. For each native blockchain coin, a $BZZ trading pair is created and a liquidity pool or at least one liquidity provider is needed. The pool or provider has access to both their native chain and the Swarm host chain. On the Swarm side, there are scanners prompted by certain circumstances that can execute the postage stamp batch purchase in the name of users from another blockchain. Users just need to generate an address for them, while the rest is taken care of for them.

This functionality requires the possibility to implement an escrow type of wallet and SHA-256 hash algorithm. Payment of something to such a wallet enables the freeze functionality that locks a particular asset until the wallet owner submits a preimage of a hash. EVM blockchains, Cardano, and Bitcoin are eligible for this. At first, Swarm will provide an MVP with EVM compatibility.

How It Works

Basically, there are three user roles: a liquidity provider, a new Swarm user with a native chain wallet, and scanners that have access to Swarm and the host chain. The transaction steps are as follows. One is a commit when the new Swarm user commits their need for a postage stamp and deposits some money in the escrowed wallet of the liquidity provider on the native chain. As a response, the liquidity provider sends an authorization to the host chain, which sets a validator to accept a request to buy postage stamps if the committed hash preimage is revealed. The original requester, the new swam user, deposits a secret in the analysis chain, and only reveals the secret which ultimately authorises the postage stamp purchase if the authorization lands on the host chain. This guarantees that once the authorization is there, because of the mechanics and deterministic nature of the host chain smart contract execution, the purchaser, the new Swarm node, can make sure that if they reveal the secret, they will get the postage stamp.

When the secret is revealed on the host chain, the original liquidity provider can release the frozen deposit, their escrowed amount, and get rewarded. This is the settlement step (if successful) or redemption (if failed). If after the commit the liquidity provider fails to authorise the transaction because they are late, got offline or are malicious, then after some time when the time lock expires and authorization/reveal does not happen, the new Swarm user can reclaim, i.e. redeem, the escrowed amount. Without the authorization, reveal doesn’t happen and settlement on the side of the liquidity provider cannot happen. 

Implementation

To realise this functionality, Swarm needs four smart contracts: one existing contract in the storage incentive infrastructure, a liquidity pool contract, a verifier contract, and a postage batch purchase registration contract. At the process timeline above, you can see several preparation steps. First, a liquidity provider creates their escrowed wallet contract on the native chain. Then the new Swarm user submits a commitment to the native chain that is watched by the liquidity provider who acts on it by sending the authorization to the host blockchain. 

Then, once the new Swarm user sees that the authorization arrived on the blockchain, they can safely reveal their secret — send reveal. The reveal is watched by the scanners, which submit and reveal and create the batch. This step notifies the liquidity provider to start the settlement and release the funds. It also notifies the new Swarm user that they can now post content. This is the happy path. In case of failure, the new Swarm user can redeem funds from the native chain where they deposited it in escrow of the liquidity provider. It happens when they don’t reveal.

Failure depends on whether the user got the envelope and whether they got the authorization. If either of these didn’t happen, then they are allowed to redeem their funds, minus extra transaction fee. However, the liquidity provider is incentivized to complete their part and earn their fee. It is assumed that money taken from the pool is smaller than the amount of native deposits of the new Swarm user. When there is a difference in price, liquidity providers arbitrage.

The bottleneck of this solution is trigger events, their incentive, and hosting security. Since all three roles are connected to their relevant blockchains, events and transactions are logged. There is a possibility to check whether the transaction happened; and such a tool has to be existing on the native chain as well. When these transaction events are listened to, one can have the trigger for the next step.q This can be listened to with polling for a SOC address. A SOC address is a single-owner chunk, so it can be seen as a feed. The scanners also listen to the reveals; and once they get the reveal from the Swarm upload, then they can submit a transaction that purchases the postage batch. That transaction has a log event and notifies the Swarm user that they can now upload. The payment transaction notifies the liquidity provider that they can start the settlement.

There is a step where the new Swarm user posts an envelope. This is a kind of a vicious-circle problem because in order for the Swarm user to do a reveal on Swarm, they have to post an envelope. This is one particular post to a very particular stock address. It can be prepaid and pre-addressed by anyone, e.g. by the liquidity provider. This construct is called a prepaid pre-addressed envelope. On this step, the liquidity provider monetizes and facilitates the information coming from the new Swarm user to reveal their secret by posting it on Swarm. This act is paid for and has to be factored into the fee structure.

The economic incentives of the liquidity providers are hidden in the fee structure. Liquidity providers regularly top up their liquidity on the host chain. If their liquidity is not enough, their authorization is not accepted and they have no income. The scanners that submit transactions on behalf of the new Swarm user also take a fee from the liquidity pool.

The whole process can be seen as a $BZZ-making machine with a DEX-like experience. The economic incentive is not really needed from users, their motivation is to just avoid the complexity. They don’t even know what Swarm is using. They can just use Bitcoin and store data with Bitcoin (or any other public-chain coin).

Operational feasibility can be narrowed down to the economic incentives and the question whether the scanner’s potential non-engagement causes any problems. Suppose that the equity provider correctly submits the authorization and the new Swarm user submit their reveal, but nothing happens because there is no scanner, so no one actually puts in a transaction for the user. As soon as the secret is revealed, the liquidity provider is free to settle. This could lead to a situation when the new Swarm user might lose their money and not actually get their postage batch. One of the possible solutions for this issue is to let the liquidity providers run scanners. Thus, they will be the last link in the chain and provide that service themselves.

Outro

For blockchain adoption to happen, the respective web3 solutions must offer a seamless convenient experience so that end users have no idea the solution they use actually runs on blockchain. By adding

multi-chain support, Swarm takes a leap towards adoption and eliminates the hurdles of acquiring $BZZ and $xDAI required to post content. Swarm can possibly support not only native assets of other blockchains, but tokens issued on those other blockchains, too. If a blockchain runs tokens, in most cases it has a sophisticated smart contract that can also support the escrow and hashing mechanisms needed by Swarm. Also, the addition of liquidity providers into the multi-chain solution marks the start of DeFi exploration by Swarm.

Join the upcoming Swarm October Community Call on Discord to know more about multi-chain on Swarm. You can submit questions for the AMA segment in this form.

This article is created by the Swarm Announcements channel based on the presentation Multichain support by Viktor Trón.