Bridge Authority Wrapper Tokens

01Executive Summary

JIL Sovereign implements cross-chain wrapper tokens (jBTC, jETH, jUSDC) using a bridge authority account pattern that requires only the existing PaymentTx transaction type on the L1 ledger. This eliminates the need for any modifications to the Rust consensus engine, achieving full token wrapping and unwrapping functionality through a pre-funded authority account and standard payment operations.

Minting is accomplished by sending a PaymentTx from the bridge authority account to the user's account, while burning is accomplished by the user sending a PaymentTx back to the bridge authority. The bridge authority account is pre-funded with the maximum supply of each wrapper asset, and the bridge relayer holds the Ed25519 private key that authorizes mint transactions.

02Problem Statement

Cross-chain bridges typically require native mint and burn operations in the destination chain's consensus layer. Adding these primitives to a production blockchain engine introduces significant risk: new consensus rules must be validated by all nodes, new transaction types expand the attack surface, and any bug in mint logic could result in unlimited token creation.

2.1 The Bridge Implementation Dilemma

• Native Mint/Burn: Requires modifying the Rust L1 engine to support new transaction types, expanding the consensus attack surface and requiring a hard fork for deployment.
• Smart Contract Minting: Requires a smart contract execution environment on the L1, which may not exist or may introduce its own security risks.
• Wrapped Token Standards: Standards like WETH on Ethereum use deposit/withdraw contracts, but these assume a Turing-complete execution environment.

2.2 Why Existing Approaches Fail

03Technical Architecture

The bridge authority pattern operates with three components: a pre-funded authority account on the JIL L1, a bridge relayer service that holds the authority's signing key, and the existing PaymentTx validation logic in the Rust consensus engine.

3.1 Wrapper Token Registry

3.2 Authority Account Model

The bridge authority account (bridge_authority) is pre-funded with the maximum supply of each wrapper asset at genesis or via the development faucet. This account's Ed25519 private key is held exclusively by the bridge relayer service. When a user deposits BTC on the external chain, the relayer signs a PaymentTx transferring the equivalent jBTC from the bridge authority to the user. The total minted across all users can never exceed the pre-funded amount, providing a hard supply cap without consensus-level enforcement.

3.3 Transaction Flow Comparison

04Implementation

4.1 Deposit to Mint Flow

1. External deposit detected: Bridge watcher monitors the external chain for deposits to the bridge contract address and submits deposit records to the bridge relayer.
2. Confirmation tracking: The relayer tracks block confirmations on the external chain (e.g., 6 confirmations for Bitcoin, 12 for Ethereum) before considering the deposit confirmed.
3. Auto-mint trigger: Once the deposit reaches the required confirmation threshold, the relayer automatically constructs and signs a PaymentTx from bridge_authority to the user's JIL L1 account for the equivalent wrapper asset amount.
4. Ledger recording: The PaymentTx is submitted to the L1 ledger, validated by consensus (14-of-20 validators), and the user's account balance increases by the wrapper token amount.
5. Status update: The deposit record transitions to "minted" status and the wrapper token's total minted counter is incremented in the bridge database.

4.2 Unwrap to Burn Flow

1. User initiates unwrap: User requests an unwrap through the wallet API, specifying the wrapper asset, amount, and external chain destination address.
2. Passkey challenge: The wallet API generates a WebAuthn passkey challenge for the user to sign the burn transaction (PaymentTx from user to bridge_authority).
3. Transaction submission: The signed PaymentTx is submitted to the L1 ledger, transferring the wrapper tokens from the user back to the bridge authority account.
4. Withdrawal recording: A withdrawal record is created on the bridge relayer, triggering the validator signature collection process.
5. Release execution: Once 14-of-20 validator signatures are collected (BFT threshold), the equivalent amount is released on the external chain to the user's destination address.

4.3 Proof of Reserves

The bridge relayer exposes a /v1/reserves endpoint that reports the total minted vs. total deposited for each wrapper asset. Because the bridge authority account balance is publicly queryable on the L1 ledger, anyone can independently verify that total_minted = max_supply - bridge_authority_balance and cross-reference against external chain deposit records.

05Integration with JIL Ecosystem

5.1 Wallet API

The wallet API provides user-facing endpoints for the complete wrap/unwrap lifecycle: listing available wrapper tokens, getting deposit quotes with confirmation estimates, initiating unwrap with passkey authentication, and tracking unwrap progress through to external chain release.

5.2 DEX Trading

Wrapper tokens (jBTC, jETH, jUSDC) are tradeable on the DEX v5 retail lane and RFQ system. Pre-seeded trading pairs include jBTC/jUSDC and jETH/jUSDC, enabling users to trade wrapped external assets against each other using the batch auction clearing engine.

5.3 Settlement Consumer

Wrapper token transfers settle through the P2P zone-authorized settlement architecture. Each transfer is routed to the appropriate compliance zone topic on RedPanda, where the authorized validator processes settlement including compliance checks, ledger commits, and proof generation.

5.4 Protection Coverage

Wrapper token balances are included in the user's total protected value for protection coverage calculations. A Premium tier user holding jBTC worth $200K and JIL tokens worth $50K has $250K+ total protected value, all covered under the automatic protection coverage.

06Prior Art Differentiation

07Implementation Roadmap

08Patent Claim