Execution Layer: SovaEVM

The Execution Layer is the heart of the Sova Network. It’s where Bitcoin and Ethereum semantics converge — a fully compatible EVM runtime extended with Bitcoin validation logic, deterministic state locks, and a custom precompile suite.

This layer ensures that every transaction, contract call, and state change involving Bitcoin is cryptographically linked to the Bitcoin blockchain itself. It allows developers to use standard Solidity tooling while the network enforces Bitcoin correctness at runtime.

Overview

The Sova Execution Layer is implemented as sova-reth, a modified execution client built on the Reth SDK. It behaves like a standard EVM but includes modules that track Bitcoin transactions and apply additional validation rules.

Core Responsibilities

  • Execute all smart contracts and transactions on Sova.

  • Interface directly with Bitcoin Core via built-in precompiles.

  • Enforce Bitcoin transaction finality through the Inspector module.

  • Emit deterministic state transitions that can be verified by any node.

Every node running sova-reth must also run:

  • A Bitcoin Core node for real-time validation and anchoring.

  • A Sentinel database for tracking Bitcoin transaction confirmations and storage locks.

This coupling between the EVM and the Bitcoin network is what gives Sova its defining property: Bitcoin correctness is enforced at the protocol level, not by external oracles.

The Inspector Module

The Inspector is a custom runtime extension that integrates Bitcoin finality checks into the EVM execution flow. It operates at the level of the SSTORE operation (state write) to detect and manage contract variables tied to Bitcoin transactions.

Core Functions

  • Hooks into the REVM pipeline and monitors all storage operations.

  • Identifies contract writes associated with a pending Bitcoin transaction.

  • Locks those storage slots until the associated BTC transaction reaches required confirmations.

  • Communicates lock data to the Sentinel service via RPC.

  • On successful confirmation, releases the lock; if confirmation fails, reverts to the previous state.

Confirmation Logic

  • Default requirement: 6 Bitcoin block confirmations.

  • Lock expiry: 18 Bitcoin blocks (slots revert if expired).

  • Full reversion threshold: 21 Bitcoin blocks with no confirmation.

These thresholds are adjustable via governance but serve as the baseline for network finality enforcement.

Inspector Data Flow

EVM Transaction
   ↓
Inspector detects BTC-linked storage writes
   ↓
Slots locked, metadata (txid, block hash, contract) sent to Sentinel
   ↓
Sentinel monitors Bitcoin confirmations via RPC
   ↓
Once confirmed → Inspector unlocks and finalizes state
   ↓
If unconfirmed → Reverts slot to previous state

This system ensures that any smart contract state tied to Bitcoin cannot finalize until Bitcoin itself confirms the underlying transaction.

Sentinel Interface

The Sentinel acts as a co-processor for the Inspector and provides an API for sova-reth to query the lock status of any given storage slot. It manages a database of locked slots and their associated Bitcoin transactions, maintaining synchronization between the EVM state and Bitcoin confirmations.

Core Responsibilities

  • Slot tracking: Maintain the mapping of locked slots, their current and revert values, and their associated Bitcoin txid.

  • Confirmation monitoring: Query one or more Bitcoin nodes to determine transaction validity and confirmation depth (not limited to a local node).

  • API interface: Expose a deterministic API for sova-reth to retrieve slot status, confirmation data, or revert values when a slot timeout has occurred.

  • Finality reporting: Unlock or revert slots based on confirmation results when queried by the EVM.

Behavior

  • Periodic Monitoring: Sentinel periodically queries connected Bitcoin nodes (getrawtransaction, getblock, etc.) to track confirmation progress.

  • Lazy Reversion: If a Bitcoin transaction remains unconfirmed beyond 21 Bitcoin blocks, Sentinel performs lazy evaluation—when sova-reth next requests the slot’s status, Sentinel automatically unlocks it and returns the stored revert_value so that sova-reth can revert the affected contract state.

  • Unlocking: Once a transaction reaches the required confirmations (default: six), Sentinel marks the slot as unlocked, finalizing the state.

⚙️ Sentinel does not proactively roll back state. Reversions occur only when sova-reth queries a slot that has exceeded the timeout window.

Schema Reference See the Sentinel schema migration for field definitions including:

  • start_block, end_block, and btc_block (track Sova and Bitcoin block heights)

  • contract_address, slot_index, slot_index_int (identify the locked slot)

  • btc_txid, revert_value, current_value (define the transaction link and stored values)

This design allows sova-reth to validate contract state against confirmed Bitcoin data efficiently while maintaining deterministic replay and auditability.

Bitcoin Precompiles

Sova introduces a set of Bitcoin precompiles — lightweight, built-in system contracts that expose Bitcoin network functionality to Solidity developers. They function like cryptographic precompiles on Ethereum (e.g., SHA256), but here they handle Bitcoin-specific operations.

Name

Address

Input Data

Description

sendrawtransaction

0x999

Signed raw Bitcoin transaction

Broadcasts a Bitcoin tx through the node’s RPC connection.

decoderawtransaction

0x998

Raw Bitcoin transaction bytes

Decodes and returns Bitcoin tx metadata (inputs, outputs, amounts).

convertaddress

0x997

EVM address

Converts a Sova (EVM) address into a valid Bitcoin address (P2TR/P2WPKH).

These precompiles make it possible to:

  • Construct and send BTC transactions from Solidity.

  • Verify and interpret Bitcoin tx data on-chain.

  • Map Sova contract addresses to verifiable Bitcoin addresses.

Example Usage (Solidity)

import {SovaBitcoin} from "@sova-network/src/lib/SovaBitcoin.sol";

contract BTCDeposit {
    function broadcast(bytes memory rawTx) external {
        // Send Bitcoin transaction via precompile
        SovaBitcoin.sendRawTransaction(rawTx);
    }

    function decode(bytes memory rawTx) external view returns (bytes memory) {
        return SovaBitcoin.decodeRawTransaction(rawTx);
    }
}

These primitives make Bitcoin a first-class object in Solidity — without relying on wrapped tokens or custodial APIs.

Bitcoin Anchoring in the Execution Layer

During every block execution, sova-reth validates Bitcoin anchors through its integrated L1 Block Verifier:

  • Each block includes a system transaction to the SovaL1Block contract.

  • The contract stores:

    • bitcoinBlockHeight

    • bitcoinBlockHash

  • The execution client queries its local Bitcoin node to verify these values.

  • If the data mismatches (outdated or incorrect hash), the block is rejected.

This mechanism ties the state root of each Sova block directly to a specific Bitcoin block hash — enabling verifiable replay and independent validation by any node.

2.2.6 Developer Implications

Developers on Sova interact with a normal EVM, but must consider the implications of Bitcoin-aware state:

  • Time and confirmation delay: State changes involving Bitcoin will finalize only after required confirmations.

  • Gas costs: Bitcoin precompile operations are fixed-cost calls; their RPC latency doesn’t affect block gas accounting.

  • Reversion handling: Contracts should account for possible reverts if BTC transactions fail to confirm.

  • Determinism: Final state is guaranteed across all validators, but interim pending states may vary until Bitcoin settles.

  • Auditable linkage: Every Bitcoin-linked action can be traced by txid and block hash.

This design gives developers the same flexibility as Ethereum, but with Bitcoin’s trust model built in.

Benefits and Constraints

Benefits

  • Native Bitcoin programmability without bridges.

  • Deterministic auditability — every BTC-linked event can be revalidated.

  • Institutional-grade correctness for yield and treasury use cases.

  • Full compatibility with Solidity and EVM tooling.

Constraints

  • Bitcoin confirmation delays introduce latency.

  • Requires running a full Bitcoin node (heavier validator requirements).

  • Non-Bitcoin transactions are instant, but BTC-dependent logic must respect lock windows.

  • Debugging can be more complex when cross-chain states are locked.

In Summary

  • sova-reth extends the EVM with Bitcoin precompiles, finality locks, and anchor validation.

  • The Inspector and Sentinel enforce deterministic Bitcoin correctness.

  • Developers can build Bitcoin-native DeFi directly in Solidity.

  • Each EVM state change tied to BTC is verifiable on the Bitcoin blockchain.

Next → Consensus Layer: Optimistic Rollup

Learn how Sova’s consensus layer sequences blocks, embeds Bitcoin anchors, and maintains synchronization between Sova and Bitcoin networks.

PreviousOverviewNextConsensus Layer: Optimistic Rollup

Last updated