Mint

The Utexo Mint is a cross-chain minting service that moves USDT between supported source networks and the Bitcoin RGB layer. It is built around Arbitrum as the single EVM settlement hub, integrating with the USDT0 / LayerZero protocol so that USDT arriving from supported EVM networks or Tron is transparently converted to USDT0 on Arbitrum before being locked and minted as USDT on Bitcoin. Minted USDT is represented as USDT on Bitcoin — a real on-chain asset that can be transferred or exchanged against BTC with on-chain settlement guarantees, without relying on centralised exchanges or custodial intermediaries.

​

How It Works

The Mint is composed of modular, stateless components that together coordinate a fully cross-chain transfer:

​

Mint Orchestrator

The Mint orchestrator is the central coordinator. It tracks all in-flight transfers in a persistent database, processes FundsIn events reported by Connectors, and instructs the appropriate destination Connector to issue aFundsOut transaction. If a transfer cannot be completed, the orchestrator drives it to safe cancellation.

​

Connectors

Each supported chain has a dedicated Connector, a stateless gRPC service that watches the chain for FundsIn smart contract events and issuesFundsOut transactions on the destination chain. Connectors do not hold keys or funds. All signing is delegated to the signer enclaves.

​

Mint signer

Minting RGB USDT is authorized by a single mint signer. Its AWS Nitro Enclave holds the keys that control the RGB mint rights. Before signing, its enclave fetches the deposit receipt from a pinned Arbitrum RPC and waits until the deposit is covered by the configured EVM finality head. It then checks the BridgeFundsIn event, the deposit’s binding to the RGB mint operation and its recipient, and the mint the PSBT commits to: one mint of the pinned asset that pays the deposit less the commission to the user’s seal. The mint signer does not validate RGB history; every receiver does that. Every mint is also verifiable by anyone who later receives the asset: RGB validation checks that each mint in the asset’s history is backed by a matching, successful, and finalized deposit on the configured Arbitrum bridge contract. A mint without that backing is not valid RGB USDT.

​

Release signer federation

Releasing USDT0 after an RGB burn requires an M-of-N quorum of independent signer nodes, each in its own AWS Nitro Enclave. The MultisigProxy contract on Arbitrum verifies the quorum before the bridge releases funds. No single node can authorize a release. Key properties of the signer enclaves:

• Keys never leave the TEE in plaintext. All signing happens inside the enclave, with no shell access. The mint signer gets its seed through attested AWS KMS and keeps it only encrypted, in S3. Release signers create their seed inside the enclave and pass it to replicas only through an attested enclave-to-enclave cloning handshake.
• In-enclave RGB validation. Release signers validate the full burn consignment inside the enclave before signing.
• In-enclave SPV verification. The host feeds Bitcoin block headers into each release signer enclave, which builds its own header chain and checks that every Bitcoin transaction of the burn is included and at least 6 blocks deep.
• Memory safety. Secrets are zeroized on drop; the enclave crate enforces #![deny(unsafe_code)].

​

Enclave Signer

The Enclave Signer (utexo-bridge-enclave) is the cryptographic service the signer nodes are built on. It runs inside an AWS Nitro Enclave, an isolated compute environment with no persistent storage and no shell access. It is built as two separate images, mint-signer and burn-signer, each with its own seed and its own PCR0 measurement; a mint signer refuses burn requests and a burn signer refuses mint requests. The untrusted host talks to the enclave over vsock, and the enclave reaches the outside only through host vsock proxies pinned to fixed upstreams: an Arbitrum JSON-RPC endpoint (TLS ends inside the enclave), a Bitcoin indexer, and AWS KMS for the mint signer.

​

Bitcoin headers and BtcRelay

Each release signer enclave keeps its own Bitcoin header chain. The untrusted host sends it block headers, and the enclave links them from a checkpoint block compiled into the image, so the checkpoint is bound to the PCR0 measurement and the host cannot choose it. On mainnet the enclave checks proof of work and difficulty rules; on signet it checks chain linkage and the reorg and work rules, but not proof of work or the signet challenge signature. The chain tip must be less than 2 hours old. Separately, a relayer service (btc-relayer) feeds headers to BtcRelay, an on-chain Bitcoin light client on Arbitrum. The bridge’s RGBVerifier checks each release’s Bitcoin proof against BtcRelay, and the release signers check the same proof against their own header chain before they sign.

​

Transfer Flow

​

Mint: USDT0 → USDT on Bitcoin

1. The user’s RGB wallet creates an RGB invoice. Utexo prepares the RGB mint for that invoice and returns its operation ID (OpId).
2. The user locks USDT0 in the Arbitrum bridge contract with fundsIn, including the RGB OpId in the deposit’s settlement data. USDT from other supported networks reaches Arbitrum as USDT0 through USDT0 / LayerZero first.
3. After the deposit is covered by the configured EVM finality head, Utexo verifies the bridge events and their binding to the RGB OpId.
4. The mint signer independently verifies the deposit, its binding to the mint, and the PSBT inside its enclave, then signs. The Bitcoin transaction anchoring the mint is broadcast.
5. Once the transaction confirms, the minted USDT appears in the user’s RGB wallet.

​

Burn: USDT on Bitcoin → USDT0

1. The user burns RGB USDT from an RGB wallet, naming the payout destination. The destination and amount are committed in the burn and cannot be changed afterwards.
2. The user submits the burn consignment to Utexo. The release waits until the Bitcoin transaction anchoring the burn has 6 confirmations.
3. Each release signer enclave validates the burn, the full RGB history, the EVM deposit behind every earlier mint, the asset’s reject list (if the asset names one), and the Bitcoin inclusion proofs, then signs the release.
4. With an M-of-N quorum of signatures, MultisigProxy calls the bridge. The bridge checks the burn identifier, that enough USDT0 is locked to cover the release, rate limits, and the BtcRelay proof, then releases USDT0 with fundsOut to the recipient on Arbitrum, or with lzFundsOut through USDT0 / LayerZero to another supported network.

A burn names its payout target in a 32-byte burn reason. A legacy value (12 zero bytes plus a 20-byte EVM address) can be paid only on Arbitrum. A release to any other network needs a V1 burn destination: a hash of the destination chain, LayerZero endpoint and recipient, with the matching record sent along with the burn. See Mint and Burn Integration.

​

Supported Networks

Additional USDT0-supported networks can be enabled based on business need. See USDT0’s contract deployments for its current network coverage.

​

Supported Assets

​

Fees

Commissions are managed on-chain through the CommissionManager contract. Fees can be applied on both FundsIn (lock) and FundsOut (unlock). At launch, the bridge commission is 0.1% (10 bps) of the amount plus a base fee of 0.5 USDT. The staging environment uses test fee settings, so its quotes differ. Network costs are charged separately: gas on the EVM network, the USDT0 / LayerZero fees on routes through Ethereum, Polygon PoS, Plasma and Tron, and the Bitcoin fee paid by the RGB wallet. GET /mint-burn/estimate returns the exact amounts for a route and amount.

​

Security

The Utexo Mint performs all signing inside hardware-isolated Trusted Execution Environments (TEEs) and binds every mint and every release to independently verifiable evidence on the other chain. Verifiable mints. The mint signer signs only after the USDT0 deposit is covered by the configured EVM finality head and verified, and every RGB recipient re-validates the deposit behind each mint in the asset’s history. Quorum-authorized releases. Every EVM release requires an M-of-N quorum of independent release signer enclaves, verified on-chain by MultisigProxy. No single node can release funds. TEE-enforced key isolation. Private keys are generated inside each enclave and never leave the TEE hardware boundary. There is no shell access, and all network access goes through host vsock proxies pinned to fixed upstreams (an Arbitrum RPC, a Bitcoin indexer, and AWS KMS for the mint signer). The mint signer’s seed is stored only encrypted, through attested AWS KMS. The enclave code is reproducibly buildable and bound to a verifiable PCR0 measurement. In-enclave RGB validation. Before signing a release, each release signer enclave validates the burn consignment and the full RGB asset history, confirming the burn amount and payout destination against the release parameters, and refuses a burn whose coins descend from an output on the asset’s reject list. The TEE independently verifies the burn on Bitcoin before authorising any EVM release of funds. In-enclave SPV verification. Each release signer enclave builds its own Bitcoin header chain from a compile-time checkpoint block and verifies transaction inclusion via SPV proofs without relying on any external indexer. On mainnet it checks proof of work, so an operator cannot present a fake burn on an alternative chain without the matching work. On signet, proof of work and the signet challenge are not checked, so header integrity there rests on chain linkage, the reorg and work rules, and the freshness limit. Burn replay protection. Each release carries the RGB burn operation ID. The bridge derives a burnId bound to it, stores it, and rejects any release that reuses a previously seen burnId. Public attestation. The enclave binary is reproducibly buildable, and each node publishes a verifiable attestation binding its public key to the PCR0 measurement of the deployed code. The enclave-signer guides docs/verify-a-signer.md and docs/pubkey-attestation.md, with the attest-verify tool, show how to confirm independently that the signer keys registered in the EVM smart contract belong to attested enclave code.

​

Guide