sovaBTC: Canonical Bitcoin Asset

sovaBTC is the canonical representation of Bitcoin on the Sova Network — a bridgeless, protocol-enforced 1:1 Bitcoin derivative that serves as the foundation for all on-chain activity.

Unlike wrapped Bitcoin models (e.g., WBTC, LBTC), sovaBTC is not issued by a custodian. It is minted and burned directly through validated Bitcoin transactions, ensuring that every token on the Sova Network corresponds exactly to a confirmed Bitcoin UTXO on the Bitcoin blockchain.


Purpose

sovaBTC is the base asset that enables:

  • Yield generation: Used in vaults and structured strategies within Sova Prime and SovaX.

  • Collateralization: Provides the Bitcoin-backed unit for DeFi protocols (lending, liquidity, derivatives).

  • Programmability: Acts as a Bitcoin-native ERC-20, enabling composability with existing EVM applications.

  • Auditability: Maintains transparent on-chain proof of minting, burning, and backing transactions.

Through sovaBTC, Bitcoin becomes natively usable capital — not just stored value.


Token Standard

sovaBTC is implemented as an Upgradeable ERC-20 with 8 decimal precision, matching Bitcoin’s divisibility. It uses OpenZeppelin’s upgradeable contracts pattern (ERC20Upgradeable, ERC20PermitUpgradeable, UUPSUpgradeable) for secure and extensible deployment.

Technical Summary

Property

Value

Token Symbol

sovaBTC

Decimals

8

Standard

ERC-20 (Upgradeable)

Upgradeable Pattern

UUPS Proxy

Permit Support

EIP-2612 (gasless approvals)

Underlying Asset

Bitcoin (1:1 backing)

Smart Contract Name

SovaBTCv1

Upgradeable Admin

Controlled by Governance Multisig

These design decisions balance developer familiarity with institutional-grade control and upgradability.


Minting Process

sovaBTC minting occurs automatically after a Bitcoin transaction depositing BTC to the network has reached sufficient confirmations.

Minting Lifecycle

  1. Deposit Initiation

    • User signs both a Bitcoin transaction and a Sova transaction.

    • Bitcoin transaction sends BTC to a network-derived deposit address.

  2. Transaction Detection

    • Validators (via Bitcoin Core) detect the broadcasted tx.

    • Sentinel records the txid, locking corresponding EVM storage slots.

  3. Confirmation Enforcement

    • Sentinel monitors Bitcoin block confirmations (default: 6).

    • If unconfirmed after 21 blocks, the operation reverts.

  4. Mint Event

    • Upon reaching the threshold, the Inspector unlocks state.

    • sovaBTC is minted 1:1 to the user’s address.

Minting Event Schema

event Minted(
    address indexed to,
    uint256 amount,
    bytes32 indexed btcTxid,
    bytes32 indexed btcBlockHash
);

Each mint record contains the corresponding Bitcoin transaction hash and block hash for deterministic cross-chain verification.


Burning & Redemption

Users redeem BTC by burning sovaBTC on Sova and specifying a Bitcoin address for withdrawal.

Burn Lifecycle

  1. User Burn: The user calls the burn(uint256 amount, string btcAddress) function.

  2. Inspector Validation: Verifies that the user’s sovaBTC balance is unlocked and eligible.

  3. Signing Service Broadcast:

    • Constructs a native Bitcoin transaction.

    • Signs it using validator custody keys (HSM / MPC).

    • Broadcasts through Bitcoin Core.

  4. Confirmation Tracking: Sentinel monitors the BTC txid until confirmation.

  5. Finalization: Once confirmed, the withdrawal record is finalized and on-chain burn marked complete.

Burn Event Schema

event Burned(
    address indexed from,
    uint256 amount,
    bytes32 indexed btcTxid,
    string btcAddress
);

This creates a transparent audit trail between Sova and Bitcoin for every redemption.


Proof of Backing

The total supply of sovaBTC is mathematically guaranteed to equal the total BTC confirmed in Sova-monitored UTXOs.

Invariant

totalSupply(sovaBTC) == Σ(Confirmed BTC Deposits) - Σ(Confirmed BTC Withdrawals)

This invariant is continuously enforced by the Sentinel, which:

  • Tracks all confirmed deposit and withdrawal txids.

  • Publishes periodic state proofs linking UTXOs to Sova block anchors.

  • Can be independently verified by any third party using public Bitcoin data.

This gives sovaBTC on-chain proof-of-reserve — no manual attestations or external audits required.


Integration with Sova Prime and SovaX

While sovaBTC is the canonical on-chain Bitcoin representation, it also serves as the base asset for Sova’s higher-level products:

  • Sova Prime:

    • Permissionless yield vault layer.

    • Accepts sovaBTC as collateral.

    • Generates spBTC (yield-bearing sovaBTC vault shares).

  • SovaX:

    • Institutional app-chain for qualified custody clients.

    • Uses sovaBTC as underlying asset for USD or yield strategies.

    • Provides triparty agreement integrations with custodians (Anchorage, BitGo, etc.).

Both build on the same invariant: every sovaBTC is tied to verifiable Bitcoin collateral.


On-Chain Functions Overview

Function

Purpose

Access

mint(address to, uint256 amount, bytes32 btcTxid)

Mint sovaBTC after confirmed Bitcoin deposit.

Sentinel / Inspector only

burn(uint256 amount, string btcAddress)

Burn sovaBTC and trigger BTC withdrawal.

User

pause() / unpause()

Emergency controls for halting mint/burn.

Governance only

_authorizeUpgrade(address newImpl)

Upgrade authorization per UUPS pattern.

Governance only

All state-changing mint/burn operations are executed via verified Bitcoin transactions — never manual or discretionary actions.


Security and Failure Handling

Deposit Reorg Handling

  • If a deposit transaction becomes invalid due to a Bitcoin reorg before reaching 6 confirmations, Sentinel automatically marks it as expired.

  • Locked contract storage reverts, and minting is cancelled.

Double-Spend Protection

  • The Inspector prevents duplicate txids from being processed.

  • Sentinel maintains a global set of confirmed UTXOs to prevent replay.

Emergency Pausing

  • Governance can trigger a global pause in extreme conditions (e.g., Sentinel desync, upstream reorg beyond threshold).

  • Pause halts all mint/burn operations without affecting balances or transfers.

Recovery and Replay

  • Sentinel data can reconstruct the entire mint/burn history from Bitcoin RPC + Sova logs.

  • This guarantees deterministic recovery of all supply data in case of node failures.


Example Deposit & Redemption Flow

BTC User → Deposit TX → Bitcoin Core (Validator)

Sentinel detects tx → locks storage

6 confirmations → Inspector finalizes

Mint sovaBTC to user

User interacts with vaults / DeFi

User burns sovaBTC with BTC address

Signing Service constructs BTC tx

Sentinel verifies confirmations

Withdrawal complete, state finalized

Every mint and burn follows this pattern — deterministic, auditable, and Bitcoin-anchored end to end.


Advantages Over Wrapped Models

Property

sovaBTC

Wrapped Bitcoin (e.g., WBTC)

Backing Model

Verified on Bitcoin chain

Custodial (BitGo, etc.)

Custody Requirement

None

Centralized

Mint/Burn Logic

Protocol-level via Sentinel

Manual custodian attestations

Verification

Public Bitcoin RPC replay

Private audits

Native Environment

EVM-compatible

ERC-20 on Ethereum only

Finality Source

Bitcoin PoW confirmations

Off-chain attestations

sovaBTC therefore inherits Bitcoin’s immutability while remaining as composable as any ERC-20 — a combination no other token currently offers.


Summary

  • sovaBTC is the native Bitcoin representation within the Sova Network.

  • Every token maps to a real, confirmed BTC transaction — no bridges, no wrapping, no custodians.

  • Minting and burning are enforced by the network’s Inspector–Sentinel–Consensus pipeline.

  • The total supply is always provably equal to the sum of confirmed BTC deposits minus withdrawals.

  • This creates a self-verifying Bitcoin standard for DeFi, treasury management, and institutional yield.


Next → SovaEVM Modules Detailed

Explore how the SovaEVM’s Inspector, Sentinel interface, and precompiles work together to bring native Bitcoin validation into smart contracts.

Last updated