Skip to content
kUSDT

Architecture overview

kUSDT has parts on three kinds of system: smart contracts on two EVM chains, covenants on Kaspa L1, and off-chain services run by the bridge operators. The user’s apps sit on the user’s device.

kUSDT architectureThree columns. Left, the EVM chains: a KusdtVault on Ethereum, a KusdtVault on BNB Chain, and the vault owner. Middle, the off-chain operators: the monitor with the guardian key, five independent signers, and the coordinator. Right, Kaspa L1: the kUSDT covenant family (BridgeMint, KCC20 states, TokenSeed) and the KasPool covenant family (Pool and Position), where the pool observes the kUSDT family. Bottom, the user's device with the web app and the planned wallet extension. Numbered arrows show deposits, reads, signatures, mints, releases, user transactions, pauses, owner changes and status.EVM chainsKusdtVault · Ethereumholds USDT; 3 of 5 to pay outKusdtVault · BNB Chainholds BSC-USD; 3 of 5 to pay outVault ownera Safe behind a 48 h timelockbounded parameters, signer setBridge operators (off-chain)Monitor and guardianchecks INV-1 continuouslyguardian key: pause only5 independent signerseach with its own Kaspa node andEVM RPCs; one Schnorr and oneECDSA key eachCoordinatorcollects signatures, submits txsserves status; moves no fundsKaspa L1kUSDT covenant familyBridgeMintthe only issuerKCC20 statesbalances, burnsTokenSeedempty statesKasPool covenant familyPoolKAS reservePositionLP shareskUSDT reserve: one KCC20 stateowned by the pool's covenant IDobservesUser deviceWeb appbridge, swap, pool, reservesWallet extension (planned)KCC-20 tokens; keys stay localBoth pin the deployment: the kUSDT covenant ID and the vault addresses.12234567789
Solid arrows send transactions or messages; dashed arrows read state or pause. Numbers refer to the list below the figure.
  1. Deposit. A user deposits USDT into a vault, from the web app or any EVM wallet.
  2. Read. Each of the 5 signers reads vault events and Kaspa state from its own nodes.
  3. Sign. Signers send their signatures to the coordinator.
  4. Mint. The coordinator submits mint transactions to BridgeMint on Kaspa.
  5. Release and refund. The coordinator submits release and refund transactions to the vaults.
  6. Use kUSDT. Users send kUSDT, swap in KasPool, add liquidity and burn to redeem, all as Kaspa L1 transactions.
  7. Pause. The monitor checks backing against supply, mints against deposits and releases against burns, from its own nodes. The guardian key can pause both vaults and BridgeMint, and do nothing else.
  8. Configure. The vault owner sets each vault’s parameters within hard bounds, its signer set and its guardian.
  9. Status. The coordinator serves status to the web app.

The pieces in one table

Section titled “The pieces in one table”
Part Runs on Trusted with
kUSDT covenant family: KCC20, TokenSeed, BridgeMint Kaspa L1 The token itself. BridgeMint is the only issuer
KasPool covenant family: Pool, Position Kaspa L1 The pool’s KAS and kUSDT reserves
KusdtVault, one per chain Ethereum, BNB Chain All locked USDT; pays out only with 3 of 5 signatures, within a daily allowance
Signers (5, independent) Each on its own machine, with its own Kaspa node and EVM RPCs One Kaspa Schnorr key and one EVM ECDSA key each
Coordinator Bridge server Nothing that moves funds. It collects signatures, submits transactions and serves status
Monitor and guardian Monitoring server One key that can pause the vaults, the minter and the pool, and nothing else
Vault owner An AccessManager whose admin is a Safe (mainnet; 48-hour delays) Vault parameters within hard bounds, and the vault’s signer set
Web app and wallet The user’s device The user’s keys. They pin each deployment

Components describes each part in detail, and Communication describes every message between them.

Design choices

Section titled “Design choices”
  • Kaspa L1 only. Every Kaspa-side rule runs in Kaspa’s script engine. See Kaspa L1, not a layer 2.
  • A federation, rate-limited on both sides. Kaspa nodes cannot verify Ethereum or BNB Chain, so 5 signers attest to deposits and burns. Both sides cap what a bad quorum could move per day. Zero-knowledge light-client verification is the planned upgrade, not part of v1.
  • The coordinator is not trusted. Each signer checks every request against its own nodes. Anyone may submit a correctly signed mint or release.
  • The payout is fixed at burn time. A burn commits to the payout chain and address, so a release cannot be redirected.
  • Standard token code. kUSDT’s KCC20 actor is the unmodified reference, so existing KCC-20 wallets and indexers work with it.