SwapBlok Wallet: Non-Custodial Key Management

The SwapBlok Wallet is the embedded, non-custodial key management layer for SB Chain. It is built on dfns.io, a Wallet-as-a-Service (WaaS) infrastructure provider whose architecture is defined by a single critical property: non-delegated signing. Every transaction on SB Chain requires the explicit cryptographic participation of the user's own device. dfns cannot sign on the user's behalf, and SwapBlok holds no key material whatsoever.

6.1 The Wallet Problem in DeFi

Crypto wallets exist on a spectrum between two failure modes:

Custodial wallets (exchange accounts, custodial WaaS): the provider holds the private key. One hack, one subpoena, or one insolvency event will leave user funds inaccessible. This is the exact failure mode SwapBlok is designed to eliminate at every layer.

Seed-phrase self-custody (MetaMask, Phantom, Ledger): the user holds the key as a 12–24 word mnemonic phrase. A single exposure event (a photo, a cloud backup, a phishing page) permanently drains the wallet with no recovery mechanism. This places an unreasonable security burden on users and is a near-zero error tolerance model unsuitable for mainstream adoption.

dfns.io closes this gap through Multi-Party Computation Threshold Signature Scheme (MPC-TSS): a cryptographic architecture that distributes key material across multiple parties without ever assembling the full private key in any single location, while still requiring the user's active participation in every signing event.

6.2 dfns.io: Non-Delegated Signing Architecture

dfns.io operates a distributed signing network using MPC-TSS. The private key for a user's SB Chain account is never generated or assembled in full; it exists only as mathematically related shares held by separate parties:

Key Share A  →  held on the user's registered device (passkey-secured)
Key Share B  →  held across dfns.io distributed signing network

Valid signature  =  MPC-TSS protocol combining Share A and Share B
Full private key =  never reconstructed: does not exist in any single location

The security guarantees are mathematical, not organisational:

• dfns cannot sign independently. The dfns network holds Key Share B only. Without Key Share A from the user's device, no valid signature can be produced. dfns has no ability to execute transactions on behalf of users, regardless of any legal, regulatory, or operational pressure applied to dfns.
• SwapBlok cannot sign independently. SwapBlok operates exclusively as the application layer: it constructs transaction payloads and presents them to the user for approval, but holds no key material of any kind.
• Only the user can authorise transactions. Every swap, deposit, withdrawal, governance vote, or SBT transfer requires the user's explicit co-signature from their registered device. This cannot be waived, delegated, or overridden.

The non-delegated property is the defining distinction from custodial wallet services. A custodial WaaS provider can sign on the user's behalf, by design. dfns cannot, also by design. SwapBlok uses dfns specifically because of this property.

6.3 Passkey Authentication and Device Security

Key Share A is secured by the device's native cryptographic hardware using WebAuthn passkeys, the same authentication standard that underlies Apple FaceID, Windows Hello, and hardware security keys such as YubiKey. The security properties of this construction are:

• Hardware-bound. Key Share A resides inside the device's secure enclave (Apple Secure Enclave, Android StrongBox, or equivalent certified hardware). It cannot be extracted by software, including malware.
• Biometric or PIN protected. Signing requires biometric authentication (fingerprint, face scan) or device PIN before Key Share A participates in the MPC-TSS round.
• Non-exportable. Key Share A cannot be copied, photographed, screenshotted, or transmitted. It does not exist outside the secure enclave in any recoverable form.

There is no mnemonic seed phrase. Users never see, write down, or store a recovery phrase. This removes the single most common vector for user-side crypto fund loss.

6.4 Signing Flow for SB Chain Transactions

When a user initiates any action on SwapBlok (a trade, a pool deposit, a governance vote, an SBT transfer), the following signing sequence executes:

1. User initiates action in SwapBlok interface
2. SwapBlok constructs the SB Chain transaction payload
3. Transaction details presented to user for review
4. User approves: device biometric/PIN authentication triggered
5. Key Share A participates in MPC-TSS signing round (never leaves device)
6. dfns network (Key Share B) participates in MPC-TSS signing round
7. Valid threshold signature assembled: full private key never exists
8. Signed transaction broadcast to SB Chain node
9. SB Chain consensus nodes verify signature and include in next block

The MPC-TSS protocol produces a cryptographically valid signature without key reconstruction. From SB Chain's perspective, the resulting signature is indistinguishable from one produced by a traditional private key; it verifies correctly against the account's public key.

6.5 Key Recovery Without a Seed Phrase

dfns.io implements a distributed recovery protocol that enables wallet recovery without a seed phrase while preserving non-custodial guarantees:

At wallet creation, the user designates one or more recovery factors: a secondary device, a hardware security key, or a set of trusted recovery contacts. These recovery factors are cryptographically encoded and distributed across the dfns network using secret sharing. dfns cannot read the underlying recovery data.

On recovery initiation, the user authenticates with their designated recovery factor(s). The dfns network uses the encoded recovery data to reconstitute Key Share A access on the new device, without ever directly holding or transmitting the key share itself.

6.6 Wallet Scope and Integration

The SwapBlok Wallet manages key material for SB Chain exclusively. It is not a general-purpose multi-chain wallet.

In scope, managed by SwapBlok Wallet via dfns:

• SB Chain account signing key
• All SB Chain transactions: swaps, pool interactions, governance votes, SBT transfers
• SB Chain-side bridge operations (the on-chain half of sBridge deposit and withdrawal flows)

Out of scope, managed by the user's own external wallet:

• External chain accounts (MetaMask for Ethereum, Phantom for Solana, etc.)
• sBridge 2MPC vault keys on external chains, managed by ika.xyz (Section 5.2)

For cross-chain bridge operations, the user connects both the SwapBlok Wallet (for the SB Chain side) and their external chain wallet (for the source chain side). The two wallets co-sign their respective halves of the bridge flow independently. Neither wallet has visibility into or control over the other.

6.7 Non-Custody by Construction

The SwapBlok Wallet's non-custodial property is an architectural fact enforced by dfns's MPC-TSS protocol, not a policy statement or a terms of service commitment. Neither SwapBlok nor dfns can access, freeze, redirect, or spend a user's SB Chain funds under any circumstances.

This is the SB Chain-layer equivalent of the sBridge non-custody property described in Section 5.2. Together, both layers mean that at no point in any SwapBlok operation, on-chain or cross-chain, does any party other than the user hold sufficient key material to act unilaterally on their behalf.