SovaEVM

Sova's execution client sova-reth (built with Reth SDK) implements a custom EVM inspector module. The Inspector's job in the SovaEVM is to enforce Bitcoin transaction finality. The Inspector hooks into the REVM execution flow to examine all SSTORE operations during transaction execution and enforces a set of finality rules on Bitcoin transactions that are tied to EVM storage slots.

The inspector intercepts calls to Sova's Bitcoin precompile contracts and tracks storage slots written as part of Bitcoin deposit/withdrawal logic. Before allowing a Bitcoin-related call (e.g. broadcasting a BTC transaction) to proceed, the inspector queries a database to check whether the involved contract storage slots are "locked" (tied to a pending Bitcoin tx). This database we call the Sentinel.

There is a mandatory waiting period of 6 Bitcoin block confirmations for state to be confirmed on Sova. If after 21 Bitcoin blocks, the Bitcoin transaction is still no confirmed, the inspector reverts the execution and returns all the storage slots connected to that Bitcoin transaction back to their previous state.

After a successful transaction execution, the Inspector sends updates the Sentinel providing it with new lock data. The lock data comprises of all storage slots written to during the transaction execution. It is the sentinels job to tie these storage slots to a specific BTC txid and Sova block number so that all chain state can be deterministically replayed in the future.

L1 Block Anchoring

In addition to per-transaction locks, the Sova Sequencer adds a Bitcoin finality anchor in every block. Each new Sova block includes a system transaction to the SovaL1Block contract that records the latest Bitcoin block info. This call stores the current Bitcoin chain height and block hash. During block execution, the node validates block hashes are equivalent by querying it own Bitcoin RPC. If it doesn’t match (meaning an invalid or outdated anchor), the block is rejected. This design ensures Bitcoin-native confirmation and finalization at the chain level. A Sova block is only considered valid if it’s anchored to a recent Bitcoin block that eventually becomes deeply confirmed.

Auditable Trail of Deposits

The node architecture is intended to provide an end-to-end auditable trail of BTC deposits and withdrawals on Sova. There is a chained relationship between the locks in the sentinel database, the L1 block anchor, and the rules of the inspector that can directly affect how a Sova block is built. This design is built such that these components create a deterministic outcome that in the end directly affects the resulting block hash of that Sova block. The key is the determinism, without this third parties could not validate the chain and challenge invalid block execution.

Independent Verification

Any third-party node operator can run their own instance of the Sova chain and validate state roots. Node operators run their own Sentinel database and provide their own Bitcoin RPC connection. This architecture is critical for decentralization and trustless validation.

During block validation, each node independently:

• Queries its own Bitcoin RPC to verify L1 block anchors match the claimed Bitcoin block hash and height

• Replays all transactions through its local EVM inspector, enforcing the same storage slot locking rules

• Maintains its own Sentinel database of locked slots tied to pending Bitcoin transactions

• Computes state roots deterministically based on the inspector's enforcement of Bitcoin finality

If any node detects a mismatch (invalid Bitcoin anchor, violated lock rules, or incorrect state transition), it rejects the block. The deterministic nature of the inspector rules and L1 anchoring ensures all honest nodes reach the same conclusion about block validity. This design prevents any single entity from manipulating Bitcoin-related state on Sova, as invalid blocks cannot achieve network consensus.