Validation & Finality Services

The Validation & Finality Services layer ensures that every Bitcoin-linked state change on Sova reflects confirmed data on the Bitcoin blockchain. Its purpose is to synchronize EVM state with Bitcoin finality, ensuring that transactions which depend on Bitcoin confirmations cannot finalize prematurely or be exploited for double-spends.

This layer is composed of two core components:

Component

Purpose

Sentinel

Locks and tracks contract storage slots tied to Bitcoin transactions, exposing a queryable API for finality status.

Signing Service

Constructs, signs, and broadcasts native Bitcoin transactions for withdrawals initiated on Sova.

Together, these form the “finality guardrails” for the network — confirming that every mint, burn, or cross-chain operation on Sova corresponds 1:1 to verified Bitcoin state.

Overview

The Sentinel is the off-chain service responsible for Bitcoin transaction tracking and EVM storage slot locking. It prevents the same Bitcoin transaction from being reused across multiple on-chain actions and provides a verifiable record of each slot’s state transition.

Core Responsibilities

  • Confirmation monitoring: Query Bitcoin nodes for transaction validity and confirmation depth (no longer scoped to validator-local nodes).

  • Slot management: Lock, unlock, and revert contract storage slots associated with Bitcoin transactions.

  • API endpoint: Provide a query interface for sova-reth to request the lock status and revert values of specific storage slots.

  • Audit trail: Maintain a historical ledger of slot transitions for replay and debugging.

By design, Sentinel is stateless from the protocol’s perspective — any node can independently verify slot states by querying its connected Sentinel service.

Internal Data Model

The Sentinel maintains a relational database tracking the lifecycle of each locked slot. Its schema is defined in migrations.rs.

Notable Fields

Field

Description

start_block

The Sova block height where the slot was first locked.

end_block

The Sova block height where the slot was unlocked (finalized or reverted).

btc_block

The Bitcoin block that included the submitted transaction; acts as the reference interval for confirmation checks.

contract_address

The on-chain contract associated with the locked storage slot.

slot_index

The raw slot index (in bytes) identifying which storage key was locked.

slot_index_int

Integer representation of slot_index for internal use.

btc_txid

The Bitcoin transaction ID associated with the lock.

revert_value

The previous value of the storage slot (used if reversion occurs).

current_value

The updated slot value written at lock time. This value remains staged until Bitcoin finality.

🔍 This structure ensures that every Bitcoin-linked state change on Sova is fully traceable — from lock creation to release.

Slot Lifecycle

A storage slot on Sova can be in one of two states:

  • Unlocked – Default state, available for new Bitcoin-linked writes.

  • Locked – Slot is frozen pending confirmation of a referenced Bitcoin transaction.

Lifecycle Flow

  1. Lock Creation

    • When a contract operation references a Bitcoin transaction (e.g., minting sovaBTC), the SovaEVM requests Sentinel to lock the relevant slot.

    • Sentinel records current_value, revert_value, btc_txid, and metadata fields above.

    • Returns a LOCKED status to sova-reth.

  2. Monitoring (Periodic)

    • Sentinel queries configured Bitcoin nodes periodically to check confirmation depth via getrawtransaction, getblock, or equivalent RPCs.

    • Once a transaction reaches the required confirmation threshold (default: 6), Sentinel marks the slot as confirmed.

  3. Reversion (Lazy Evaluation)

    • If a transaction remains unconfirmed beyond 21 Bitcoin blocks, Sentinel performs a lazy reversion.

    • The next time sova-reth queries the slot’s status, Sentinel detects the timeout, unlocks the slot, and returns the revert_value so that SovaEVM can perform a local state rollback.

  4. Unlocking

    • Upon confirmation or reversion, Sentinel updates end_block and removes the active lock.

    • The slot becomes writable again.

⚙️ Reversions occur only when SovaEVM requests the slot status — Sentinel does not proactively trigger reverts. This reduces unnecessary writes and keeps synchronization efficient.

Sentinel API

SovaEVM (sova-reth) interacts with Sentinel over gRPC or HTTP. The key functions exposed by the Sentinel server include:

Method

Description

lock_slot(contract, slot, txid, revert_value, current_value)

Locks a storage slot for a pending Bitcoin transaction.

get_slot_status(contract, slot)

Returns the lock state, confirmation status, and revert value if applicable.

unlock_slot(contract, slot)

Releases a slot after Bitcoin finality or timeout.

query_tx_status(txid)

Returns confirmation depth and BTC block height.

All responses are deterministic — every validator connected to the same Bitcoin network will observe identical slot states for confirmed transactions.

Signing Service (Recap)

The Signing Service operates alongside Sentinel but serves the outbound direction of Bitcoin traffic — withdrawals. It constructs and broadcasts Bitcoin transactions when users burn sovaBTC or redeem Bitcoin from vaults.

Responsibilities

  • Build and sign raw BTC transactions (HSM, MPC, or TSS).

  • Broadcast via Bitcoin Core or configured RPC endpoint.

  • Report the resulting btc_txid to Sentinel for confirmation tracking.

  • Support multiple signers or key shards for distributed security.

Protocol Flow

This ensures Bitcoin consensus defines Sova’s finality — every storage change referencing BTC is verified, replayable, and provably consistent.

Operator Notes

  • Bitcoin Nodes: Sentinel can query multiple Bitcoin nodes; redundancy improves accuracy and uptime.

  • Polling Frequency: Configurable — described as “periodic” rather than fixed intervals.

  • Schema & Storage: Uses relational DB migrations (migrations.rs) for versioned tracking.

  • No Cleanup Phase: Finalized locks remain archived indefinitely for auditing and state-root reconstruction.

Summary

  • Sentinel is the finality oracle for Bitcoin-linked state on Sova — preventing double spends and enforcing deterministic synchronization between Bitcoin and SovaEVM.

  • It now supports querying any Bitcoin node, not just local validator instances.

  • Reversions are lazy, triggered only when queried by SovaEVM.

  • Its schema records granular slot metadata (start, end, BTC block, revert/current values).

  • Together with the Signing Service, Sentinel ensures that Sova’s entire cross-chain lifecycle is governed by Bitcoin truth.

Next → Security & Finality Model

See how these services integrate with consensus rules to give Sova deterministic, Bitcoin-level security guarantees and shared finality with the Bitcoin network.

PreviousConsensus Layer: Optimistic RollupNextSecurity & Finality Model

Last updated