Smart Contracts

This documentation describes the Syntetika Two Token System for BTC Basis +. It outlines the Structure of our Smart Contracts and the external and internal functions, storage, and roles.

Components

• ComplianceChecker — defines what SBTs (soul-bound tokens) an address must hold to be compliant.

• CompliantDepositRegistry — assigns unique BTC deposit addresses to compliant EVM accounts; enforces a batch challenge window for new address lists.

• hBTC (token) — ERC-20 with 8 decimals, admin/role controls, mint/burn, and address blacklisting.

• Minter — mints hBTC when compliant users deposit the base asset (e.g., WBTC or a custody-backed flow), burns on redemption, routes protocol yield into the vault.

• StakingVault (ERC-4626) — users deposit hBTC and receive shares; protocol yield is streamed in and linearly vests over 8 hours for fair pricing; withdrawals use a cooldown then claim pattern.

High-level flow

1. Compliance & deposit address A user becomes compliant (meets SBT set in ComplianceChecker) and calls CompliantDepositRegistry.registerDepositAddress(). The registry assigns a BTC deposit address that passed its batch challenge window.

2. Mint

   • User-driven path: A compliant user calls Minter.mint(to, amount) and transfers the base asset in (e.g., WBTC). The Minter mints hBTC 1:1 in matching decimals (8).

   • Admin path: ownerMint(addressTo, amount) can be used by the admin to reflect off-chain BTC custody deposits.

3. Stake (optional) Users approve the vault and deposit hBTC into StakingVault to receive ERC-4626 shares. Protocol yield is sent in by Minter.distributeYield(), then vests over 8 hours inside the vault to prevent timestamp gaming; unvested yield is excluded from totalAssets() until it vests.

4. Withdraw & redeem Users withdraw/redeem from the vault: assets are moved to TokensHolder and become claimable after cooldown via claimWithdraw(receiver). With hBTC back in the wallet, users call Minter.redeem(amount) to receive wBTC.