Sentinel & Signing Architecture

The Sentinel and Signing Service are the operational backbone of the Sova Network’s Bitcoin integration. They ensure that every deposit and withdrawal on Sova corresponds exactly to a real Bitcoin transaction, fully verified by the Bitcoin network.

Together, these services provide:

  • Deterministic finality enforcement — no sovaBTC is minted or burned without proof of on-chain confirmation.

  • Auditable transaction trails — all actions are linked to verifiable Bitcoin txids.

  • Secure BTC redemption — withdrawals are signed and broadcast trustlessly, without custodians.

Sentinel Overview

The Sentinel is a validator-operated, off-chain service responsible for tracking Bitcoin transactions related to the Sova Network. It forms the link between Bitcoin’s proof-of-work finality and the EVM’s deterministic state machine.

Core Responsibilities

  • Monitor Bitcoin transactions tied to Sova contracts.

  • Lock or unlock EVM storage slots based on confirmation depth.

  • Detect expired or reorged Bitcoin transactions.

  • Maintain a permanent audit database of Bitcoin-linked events.

  • Feed status updates to the Inspector and Consensus layers.

Each validator runs its own Sentinel instance, meaning no single source of truth exists off-chain — all nodes independently verify and enforce Bitcoin-linked state.

Sentinel Architecture

Core Components

Subsystem

Purpose

Watcher

Monitors Bitcoin mempool and block data for matching txids.

Lock Manager

Maintains mapping between contract storage slots and Bitcoin transactions.

Confirmation Tracker

Polls Bitcoin Core for block confirmations and reorg detection.

Database (Ledger)

Stores transaction states and metadata.

API Service

Provides query and event endpoints for EVM (Inspector) communication.

Data Flow

Bitcoin Node → Watcher → Lock Manager → Database
                           ↓
                        Inspector RPC

Every detected Bitcoin transaction tied to a contract triggers a lock event, which persists until the transaction’s confirmation threshold is reached or expired.

Sentinel Database Schema

Field

Description

txid

Bitcoin transaction ID being tracked.

contractAddress

Sova smart contract address linked to the tx.

slotKey

EVM storage key locked by the transaction.

sovaBlockNum

Block number when the event was registered.

confirmations

Current Bitcoin confirmation count.

status

pending, confirmed, or expired.

btcBlockHash

Bitcoin block that currently contains the tx.

timestamp

Time the record was last updated.

This schema allows the Sentinel to replay historical state transitions for audits or node recovery.

Confirmation & Reorg Handling

Confirmation Process

  1. Watcher detects new transaction and writes it to the ledger.

  2. Tracker polls Bitcoin Core every N seconds for confirmation depth.

  3. When depth ≥ 6 → marks transaction “confirmed.”

  4. Notifies the Inspector to unlock the corresponding contract slot.

  5. Logs confirmation event for future audits.

Reorg Response

If Bitcoin reorgs:

  • Sentinel verifies whether the tracked txid still exists in the canonical chain.

  • If missing → marks as “expired,” instructs Inspector to revert the slot.

  • Logs reorg details (old and new block hashes).

  • Re-synchronizes from the latest valid Bitcoin block.

This makes Sova resilient to temporary forks or race conditions on Bitcoin.

Signing Service Overview

The Signing Service is the second half of the off-chain system. It securely generates, signs, and broadcasts Bitcoin withdrawal transactions initiated by sovaBTC burns on Sova.

Key Responsibilities

  • Receive burn requests from the SovaEVM.

  • Construct Bitcoin transactions referencing network-controlled UTXOs.

  • Sign transactions using secure, isolated key infrastructure.

  • Broadcast transactions via Bitcoin Core.

  • Report txid to Sentinel for confirmation tracking.

Because the Signing Service operates deterministically and independently per validator, withdrawals can be verified and reproduced across the network.

Signing Infrastructure

Supported Signing Models

Method

Description

Security Profile

HSM (Hardware Security Module)

Dedicated signing hardware controlled by validator.

Enterprise-grade, low-latency.

MPC (Multi-Party Computation)

Private key shards distributed among multiple validators.

Decentralized, robust.

TSS (Threshold Signature Scheme)

Signatures only valid once quorum threshold reached.

Most decentralized option.

All signing models prevent any single validator from unilaterally withdrawing BTC.

Default Implementation:

As of Q4 2025, Sova Chain uses an HSM model.

Withdrawal Lifecycle

  1. Burn Event:

    • User burns sovaBTC via the on-chain contract, specifying a Bitcoin address.

  2. Event Detection:

    • EVM emits a WithdrawalRequested event.

    • Sentinel records the event and forwards it to the Signing Service.

  3. Transaction Construction:

    • Service aggregates available UTXOs under validator control.

    • Creates raw Bitcoin transaction matching the requested withdrawal.

  4. Signature & Broadcast:

    • Transaction signed via MPC/TSS or HSM.

    • Broadcasted to the Bitcoin network via Bitcoin Core RPC.

  5. Confirmation Tracking:

    • Sentinel monitors the txid until it reaches ≥6 confirmations.

    • Once finalized, the EVM marks withdrawal complete.

Withdrawal Events

event WithdrawalRequested(address indexed user, uint256 amount, string btcAddress);
event WithdrawalCompleted(address indexed user, bytes32 btcTxid);

This cycle ensures that redemption is automatic, auditable, and fully traceable.

Communication Model

The Sentinel and Signing Service communicate with the Execution Layer (SovaEVM) through authenticated, encrypted RPC channels.

Interfaces

Component

Protocol

Purpose

Sentinel → Inspector

gRPC / WebSocket

Lock, unlock, or revert contract storage.

Inspector → Sentinel

HTTP POST / JSON-RPC

Emit new Bitcoin transaction locks.

Inspector → Signing Service

HTTP POST

Submit withdrawal requests.

Signing → Sentinel

gRPC / Pub/Sub

Register broadcasted tx for confirmation tracking.

All messages include a cryptographic signature (HMAC or ECDSA) and nonce to prevent replay or tampering.

Operational Safeguards

To ensure continuous reliability, both services implement redundancy and recovery strategies.

Sentinel

  • Runs in active-active mode across multiple nodes.

  • Database replicas updated via periodic snapshots.

  • Lock history replayable from chain + logs.

Signing Service

  • Isolated from validator host system via separate container or hardware enclave.

  • Key shards rotated quarterly (configurable).

  • Automatic failover to standby signer in case of outage.

Bitcoin Core

  • Multiple RPC endpoints supported for redundancy.

  • Automatic re-sync if data corruption detected.

  • Peer connection threshold maintained (min 8 peers).

These safeguards guarantee that even if individual nodes fail, network finality and user funds remain unaffected.

Monitoring and Auditing

Both Sentinel and Signing emit continuous logs for transparency and diagnostics:

Event

Logged Data

LockRegistered

txid, slot, contract, timestamp

ConfirmationUpdated

txid, confirmations, btcBlockHash

WithdrawalBroadcasted

txid, btcAddress, signerID

WithdrawalConfirmed

txid, confirmations, completionTime

Logs can be exported to monitoring platforms like Prometheus, Grafana, or custom dashboards. Auditors can verify that every mint and burn corresponds to a unique, confirmed Bitcoin transaction.

Developer & Operator Guide

For Developers

  • Always emit standardized events (DepositRegistered, WithdrawalRequested).

  • Avoid hard dependencies on synchronous confirmations — design async callbacks.

  • Use Sentinel APIs to query confirmation status from your applications.

  • Test using Bitcoin regtest or signet networks for realistic confirmation simulation.

For Node Operators

  • Run one Sentinel and one Signing Service per validator.

  • Ensure each has access to a full Bitcoin Core node.

  • Maintain monitoring for confirmation lags or anchor mismatches.

  • Periodically rotate signing keys and back up Sentinel database.

Advantages of the Sentinel–Signing Model

Category

Sova Approach

Conventional Model

Finality Enforcement

Real-time via Bitcoin confirmations.

Off-chain attestations or trusted bridges.

Withdrawal Execution

Signed and broadcast deterministically.

Manual custodian release.

Auditability

Fully reconstructible from public data.

Requires private attestations.

Security Model

No single custodian, decentralized verification.

Centralized trust intermediaries.

Transparency

Logs every mint, burn, and broadcast event.

Often opaque and off-chain.

This architecture makes Sova’s off-chain layer as decentralized and verifiable as its on-chain one.

Summary

  • Sentinel = the “Bitcoin watcher” — tracks deposits, confirmations, and reorgs.

  • Signing Service = the “Bitcoin executor” — constructs and broadcasts withdrawals.

  • Both are deterministic, auditable, and validator-operated.

  • Together, they enforce Sova’s central invariant:

    If Bitcoin doesn’t confirm it, Sova doesn’t finalize it.

Next → Governance & Network Parameters

Discover how Sova’s governance system manages validator sets, network parameters, and upgradeability — without compromising Bitcoin-anchored immutability.

PreviousSovaEVM ModulesNextGovernance & Network Parameters

Last updated