sBridge: Trustless Cross-Chain Bridge

5.1 The Custodial Bridge Problem

Prior to SwapBlok, moving assets between blockchains required trusting a custodian. The canonical bridge architecture involves depositing funds into a smart contract or multisig wallet controlled by a known set of signers, receiving a receipt token in return, and trusting that the signers will release the original funds on withdrawal.

This architecture has failed catastrophically at scale:

In each case, the fundamental vulnerability was the same: a single party, or small set of parties, held enough key material or authority to be compromised. Whether through stolen keys, code bugs, manipulated signing interfaces, or a single verification point, the bridge security model was ultimately a trust model. Lazarus Group (North Korea) is responsible for a confirmed majority of total losses.

Consider what this means in practice. Moving USDT from Tron to Ethereum requires Binance today: an account, KYC, and full custody of your funds. Every bridge alternative has been hacked because someone held the keys. SwapBlok is the first solution where nobody holds the keys. Not us, not our partners, not anyone.

SwapBlok's sBridge eliminates the custodian entirely through two-party multi-party computation (2MPC).

Why sBridge Solves the USDT Tron → USDT ETH Problem

Every bridge that lost money had the same flaw: someone held the keys. Ronin had a 5-of-9 multisig. Wormhole had a single exploitable contract. Multichain's CEO held the keys and was arrested. The attacker just needed to compromise that one party.

SwapBlok's 2MPC model via ika.xyz breaks this entirely:

Key Share A  →  user's device (never leaves)
Key Share B  →  ika.xyz distributed node network

Valid signature = A + B   (2-of-2, both required)

SwapBlok holds: nothing
ika.xyz alone can do: nothing
User alone can do: nothing without ika.xyz

For the USDT Tron → USDT ETH swap:

1. User deposits USDT on Tron into their 2MPC vault: requires their Key Share A to authorise
2. Permissionless relayer detects deposit, builds Merkle proof, submits to SB Chain
3. SB Chain verifies the proof independently: the relayer cannot fabricate it
4. wUSDT(TRC20) minted on SB Chain
5. User swaps wUSDT(TRC20) → wUSDT(ERC20) on the exchange
6. User withdraws: 2MPC signing requires their device and the ika.xyz network
7. Real USDT released on Ethereum

Nobody in the chain can steal the funds. Not SwapBlok, not ika.xyz, not a relayer, not a rogue employee.

Why This Market Gap Is Enormous

Tron holds more USDT than any other chain, over $60 billion as of early 2026. The vast majority of that is retail, often in jurisdictions where Ethereum DeFi is attractive but CEX KYC is a barrier. The entire flow today is:

USDT on Tron  →  deposit to Binance (KYC, custody)  →  withdraw to ETH  →  DeFi

SwapBlok replaces the Binance step with a cryptographic proof. No account. No KYC. No waiting for withdrawal approval. No counterparty holding your funds.

MetaMask cannot do this because MetaMask is a single-chain wallet with no bridge architecture. Every cross-chain swap MetaMask shows you routes through a custodial bridge behind the scenes. They just hide it.

5.2 2MPC dWallets via ika.xyz

Every cross-chain vault on sBridge is a two-party multi-party computation (2MPC) wallet provided through ika.xyz, a dWallet network built on the Sui blockchain. The 2MPC construction splits the cryptographic key required to sign transactions on external chains (Ethereum, Solana, Bitcoin, Tron) into two shares, held by two independent parties.

Key Share A  →  held permanently by the USER (never leaves their device)
Key Share B  →  held by ika.xyz dWallet network (distributed across nodes)

Valid signature = Share A + Share B  (threshold: 2-of-2)

The security properties of this construction are mathematical, not organisational:

• SwapBlok cannot move funds. SwapBlok holds neither key share. It has no ability to sign a transaction on any external chain.
• ika.xyz cannot move funds unilaterally. The dWallet network holds only Key Share B. Without Key Share A from the user, no valid signature can be produced.
• Only the user can authorise a release. Every deposit and withdrawal requires the user's explicit co-signature. This cannot be waived, overridden, or circumvented.

This is non-custody by construction, not by promise. No policy document, terms of service, or regulatory filing is needed to establish non-custody; it is enforced by the mathematics of threshold cryptography.

The ika.xyz dWallet network distributes Key Share B across a decentralised set of nodes using threshold cryptography internally. Compromising Key Share B would require a simultaneous supermajority attack on the ika.xyz network, and even then, Key Share A (held by the user) remains intact.

5.3 The Relayer

The relayer is the message-passing layer of sBridge. It is a stateless proof messenger with no authority, no keys, and no control over any transaction. Its sole function is to detect events on source chains and deliver cryptographic proofs of those events to SB Chain.

The relayer is permissionless. Anyone can run a relayer node. SwapBlok operates primary relayers, but the bridge does not depend on any specific relayer being online. If every SwapBlok-operated relayer went offline simultaneously, any third-party relayer could continue submitting proofs and the bridge would function normally.

The relayer workflow:

1. Monitor source chain block headers (Merkle root)
2. Detect a lock event (user depositing assets into a dWallet vault)
3. Wait for minimum confirmation depth
4. Construct a Merkle proof of the lock transaction
5. Submit the proof to SB Chain
6. SB Chain independently verifies the proof
7. If valid: mint wrapped asset to user
   If invalid or duplicate: reject silently

The relayer has no ability to fabricate valid proofs; Merkle proof validity is verified by SB Chain's own consensus nodes, not taken on the relayer's word.

5.4 Merkle Proof Verification

A Merkle tree is a cryptographic data structure in which every transaction in a block is hashed, pairs of hashes are recursively hashed together, and the process repeats until a single root hash (the Merkle root) is produced. This root is included in the block header and represents a cryptographic fingerprint of every transaction in that block.

A Merkle proof demonstrates that a specific transaction is included in a specific block by providing the transaction data and a path of sibling hashes up to the known Merkle root. Anyone who knows the Merkle root can verify the proof independently.

SB Chain receives the block headers (and therefore the Merkle roots) of supported external chains. When a relayer submits a Merkle proof of a lock event, SB Chain verifies:

1. The Merkle root matches the known block header for the claimed block
2. The transaction hash traverses correctly to that root
3. The transaction is a valid lock event to a registered dWallet vault
4. The claimed confirmation depth has been reached

If all four checks pass, SB Chain mints the corresponding wrapped asset to the user's account. No human authorisation step is involved. The verification is deterministic and fully on-chain.

5.5 Replay Protection

Without replay protection, a valid Merkle proof of a lock transaction could be submitted multiple times, minting wrapped assets repeatedly for a single deposit.

SwapBlok prevents this by storing the hash of every processed lock transaction permanently on SB Chain. Before minting, the bridge module checks whether the transaction hash has been seen before. Duplicate proofs are rejected unconditionally. Because SB Chain is an immutable ledger, this record of processed hashes can never be deleted or modified.

5.6 Chain Reorganisation Protection

A chain reorganisation (reorg) occurs when a previously confirmed block is replaced by a competing chain with more accumulated proof of work or stake. A shallow reorg could cause a transaction that appeared confirmed to disappear from the canonical chain.

sBridge mitigates this risk through minimum confirmation depth requirements. SB Chain will not mint wrapped assets until a lock transaction has been confirmed under the following minimum depths:

These thresholds are set conservatively to make a reorg attack economically infeasible given the respective chains' finality characteristics.

5.7 Supported Chains and Assets

Each external chain has its own bridge contract or on-chain program managing lock/unlock logic on the source side. SB Chain handles the minting and burning of wrapped representations on the destination side.

5.8 UI Abstraction

From the user's perspective, wrapped assets are invisible. The bridge abstraction layer presents all assets by their native names throughout the entire user journey.

What the user sees: ETH → swap → SOL What SB Chain processes: wETH → wSOL What the user receives: SOL in their Solana wallet

wETH, wSOL, wBTC, and wUSDT are internal SB Chain ledger entries, issued by SwapBlok as asset issuances on the chain, with their supply precisely tracking the value locked in the corresponding dWallet vaults. Users never need to understand, hold, or interact with a wrapped token directly.