# Table of Contents - [Welcome to Sova | Sova Docs](#welcome-to-sova-sova-docs) - [Node Design & Architecture | Sova Docs](#node-design-architecture-sova-docs) - [Bitcoin Precompiles | Sova Docs](#bitcoin-precompiles-sova-docs) - [Network Operation Manual | Sova Docs](#network-operation-manual-sova-docs) - [Sova Contracts | Sova Docs](#sova-contracts-sova-docs) - [Connecting to Sova | Sova Docs](#connecting-to-sova-sova-docs) - [OP Chain Configuration | Sova Docs](#op-chain-configuration-sova-docs) - [How It Works | Sova Docs](#how-it-works-sova-docs) - [Execution Client & Sentinel | Sova Docs](#execution-client-sentinel-sova-docs) - [SovaBTC | Sova Docs](#sovabtc-sova-docs) - [Why Sova? | Sova Docs](#why-sova-sova-docs) - [Sova Network | Sova Docs](#sova-network-sova-docs) - [Double Spend Protection | Sova Docs](#double-spend-protection-sova-docs) - [For Solidity Developers | Sova Docs](#for-solidity-developers-sova-docs) - [Sova Whitepaper | Sova Docs](#sova-whitepaper-sova-docs) - [Use Cases | Sova Docs](#use-cases-sova-docs) - [Contributing | Sova Docs](#contributing-sova-docs) - [Frequently Asked Questions (FAQ) | Sova Docs](#frequently-asked-questions-faq-sova-docs) - [For Frontend Developers | Sova Docs](#for-frontend-developers-sova-docs) - [Node Design & Architecture | Sova Docs](#node-design-architecture-sova-docs) - [Network Operation Manual | Sova Docs](#network-operation-manual-sova-docs) - [Connecting to Sova | Sova Docs](#connecting-to-sova-sova-docs) - [For Frontend Developers | Sova Docs](#for-frontend-developers-sova-docs) --- # Welcome to Sova | Sova Docs Sova is a next-generation blockchain network purpose-built for **Bitcoin interoperability**. It combines the programmability of Ethereum with direct access to Bitcoin’s native state, allowing developers and institutions to deploy BTC into productive use cases without relying on centralized bridges or custodians. Sova is more than an L2 - it’s a **hybrid model** that merges two core functions: * A **blockchain execution layer** optimized for Bitcoin-based smart contracts * A **Bitcoin treasury platform** that securely deploys capital into real-yield strategies ### [](https://docs.sova.io/#architecture-dive) **Architecture Dive** ![](https://docs.sova.io/~gitbook/image?url=https%3A%2F%2F2693970916-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fm6Tmu9at8xIB0V3QJw6P%252Fuploads%252FmibLqxZIqbq6ShzgW5Py%252Fsova%2520network%2520treasury%2520%282%29%2520%281%29.png%3Falt%3Dmedia%26token%3D77c0a92d-c1f1-489d-96b5-d9af4795c288&width=768&dpr=4&quality=100&sign=9bb48145&sv=2) * **Sova Network:** * an OP-Superchain stack L2 (EVM) with direct Bitcoin execution and interoperability * **$SOVA:** * Onchain BTC Treasury Network * **sovaBTC: Interoperable, Unified BTC Clearing House** * Mint sovaBTC with BTC, WBTC, cbBTC, LBTC, or FBTC on the Sova Network * Able to swap between sovaBTC and BTC natively * 90% BTC held in qualified custody, 10% held on network (rebalancing as needed based on redemption queue) * **stsovaBTC: Earns $SOVA** * fixed staking duration allows for easier yield generation as its known how much BTC doesn't need to be available for withdraw at anytime * **stSOVA:** * Earns network fees (clearing house offramp) + BTC yield from strategies [](https://docs.sova.io/quickstart) ![Cover](https://docs.sova.io/~gitbook/image?url=https%3A%2F%2F2693970916-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fm6Tmu9at8xIB0V3QJw6P%252Fuploads%252Fu8DtgQKn1n9vfBRLzNEb%252FSova%2520Gradient%25204.png%3Falt%3Dmedia%26token%3Db7c34ee5-a5bc-4425-adbe-2279d4e6eb96&width=245&dpr=4&quality=100&sign=1f1480d3&sv=2) **Intro** What is Sova? [](https://docs.sova.io/quickstart/publish-your-docs) ![Cover](https://docs.sova.io/~gitbook/image?url=https%3A%2F%2F2693970916-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fm6Tmu9at8xIB0V3QJw6P%252Fuploads%252FcAh0FEC1Nn7unj0zFcJm%252FSova%2520Gradient%25202.png%3Falt%3Dmedia%26token%3D8c25c732-8a75-4b15-88bf-d277c6d6f0e5&width=245&dpr=4&quality=100&sign=5c8e64a5&sv=2) **How It works** Core concepts [](https://docs.sova.io/technology/node-design-and-architecture) ![Cover](https://docs.sova.io/~gitbook/image?url=https%3A%2F%2F2693970916-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fm6Tmu9at8xIB0V3QJw6P%252Fuploads%252F41IU6hoRJeel1CCVEY1q%252FSova%2520Gradient%25203.png%3Falt%3Dmedia%26token%3Dd71f4db8-c51b-4daa-a57c-c6cb68d6be11&width=245&dpr=4&quality=100&sign=64f87e53&sv=2) **Technology** Bitcoin Precompiles [NextWhy Sova?](https://docs.sova.io/why-sova) Last updated 8 days ago --- # Node Design & Architecture | Sova Docs Sova nodes operate as multi-service systems that coordinate EVM smart contract execution with native Bitcoin precompile bindings. Each validator runs the following core components: #### [](https://docs.sova.io/technology/node-design-and-architecture#sova-execution-client-sova-reth) **Sova Execution Client (**`**sova-reth**`**)** A customized EVM execution engine based on Reth, extended to support native Bitcoin precompiles and slot-locking logic. It enforces Bitcoin finality through direct coordination with the Sentinel and tracks state updates tied to BTC transactions. #### [](https://docs.sova.io/technology/node-design-and-architecture#consensus-client-op-node) **Consensus Client (**`**op-node**`**)** The canonical Optimism consensus client responsible for sequencing, block building, and L2-to-L1 rollup logic. On the sova network this service has the very important job of anchoring each Sova block to a Bitcoin by including confirmed Bitcoin block headers. #### [](https://docs.sova.io/technology/node-design-and-architecture#bitcoin-core) **Bitcoin Core** Each validator connects to a full Bitcoin core node. This ensures that all Bitcoin-related operations (e.g. tx confirmation, block hash validation, UTXO availability) are verifiable directly from the Bitcoin network without having to trust the sequencer's Bitcoin connection. #### [](https://docs.sova.io/technology/node-design-and-architecture#finality-provider-sentinel) **Finality Provider (**`**sentinel**`**)** An off-chain database-backed service that tracks the confirmation status of Bitcoin transactions. It locks or reverts contract storage slots based on whether associated BTC transactions have been confirmed on-chain. Critical for enforcing 1:1 BTC-sovaBTC minting guarantees. [](https://docs.sova.io/technology/node-design-and-architecture#sequencers) Sequencers ------------------------------------------------------------------------------------------- Sequencers on the Sova Network are responsible for block production, transaction ordering, and coordination of Bitcoin-related operations. In addition to executing EVM transactions, Sova sequencers play a unique role: they operate the network’s Signing Service API, which securely generates Bitcoin transactions during user withdrawals. ![](https://docs.sova.io/~gitbook/image?url=https%3A%2F%2F2693970916-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fm6Tmu9at8xIB0V3QJw6P%252Fuploads%252FO6pkQY9FSSX7jmKOg3TH%252FSova%2520Node%2520Arch%2520%28L1%29%2520%281%29.png%3Falt%3Dmedia%26token%3Dbe85550f-e955-4f33-bfcf-fb7f2b7bfeaa&width=768&dpr=4&quality=100&sign=dbd0dbe8&sv=2) #### [](https://docs.sova.io/technology/node-design-and-architecture#bitcoin-utxo-indexer) **Bitcoin UTXO Indexer** An indexer which tracks all spendable UTXOs associated with Sova’s native deposit address and third party bitcoin addresses. All UTXOs that are tracked are spendable by the network for servicing user BTC withdrawals. It provides a real-time, block-by-block UTXO lookup API used by `sova-reth` to construct valid Bitcoin transactions during withdrawals. #### [](https://docs.sova.io/technology/node-design-and-architecture#signing-service-api) **Signing Service API** A restricted signing gateway used exclusively by sequencer nodes. It handles multi-input Bitcoin transaction signing and ensures signatures comply with consensus rules and proof-of-reserve integrity. The signing service is designed such that it does not use a single public/private key pair and instead sources signatures for a host of trusted custodians. ### [](https://docs.sova.io/technology/node-design-and-architecture#deposit-transaction-with-slot-locking-flow-diagram) Deposit Transaction with Slot Locking Flow Diagram _Scenario: Doublespend Bitcoin transaction_ [PreviousUse Cases](https://docs.sova.io/use-cases) [NextBitcoin Precompiles](https://docs.sova.io/technology/bitcoin-precompiles) Last updated 8 days ago --- # Bitcoin Precompiles | Sova Docs [](https://docs.sova.io/technology/bitcoin-precompiles#overview) Overview ------------------------------------------------------------------------------ A blockchain precompile refers to a set of special, pre-defined functions built into the native blockchain client software. These precompiles are available to blockchain developers via smart contract calls and can be used for a variety of use cases. The common use case for these features in an EVM execution clients is to perform complex cryptographic operations such as hashing, digital signature verification, and mathematical operations. On Sova we have created our own set of "Bitcoin precompiles". These precompiles have the ability to interact with the Bitcoin network via and rpc connection to a full Bitcoin node. Every node connected to the Sova Network is responsible for running a full Bitcoin node for the purpose of validating the chain and also broadcasting Bitcoin transactions if necessary. You can think of a precompile as a "pre-deployed" contract on the Sova blockchain. Precompiles are special in that at the genesis of the chain, the 'contract logic' is already apart of every validator. Our Bitcoin precompile 'contract' allows Solidity developers to integrate directly with a Bitcoin node. ### [](https://docs.sova.io/technology/bitcoin-precompiles#technical-details) Technical Details Essentially a precompile is a "predeployed" contract on the Sova blockchain and at the genesis of the chain, the precompile is apart of every validator. On the Sova network, all Bitcoin precompiles are located at address `0x0000000000000000000000000000000000000999`. This address accepts a bytes payload consisting of a 4-byte method identifier followed by additional data required for the specific Bitcoin action. Name Method ID (bytes) Data (bytes) Description sendrawtransaction `0x00000001` Signed raw transaction data Sends a raw Bitcoin transaction decoderawtransaction `0x00000002` Signed raw transaction data Decode a raw Bitcoin transaction convertaddress `0x00000003` EVM address Converts a Sova address to corresponding BTC address createandsignrawtransaction `0x00000004` See decoding scheme for input data structure Create and sign a BTC transaction using network keys ### [](https://docs.sova.io/technology/bitcoin-precompiles#smart-contracts) Smart Contracts When writing smart contracts for the Sova Network you can import [SovaNetwork/contracts](https://github.com/SovaNetwork/contracts) as a dependency in your smart contract: Copy import {SovaBitcoin} from "@sova-network/src/lib/SovaBitcoin.sol"; ### [](https://docs.sova.io/technology/bitcoin-precompiles#foundry) Foundry When using [Foundry](https://getfoundry.sh/) , one way to interact with the precompile is to use [cast](https://book.getfoundry.sh/reference/cast/) . Here are example for how to call precompiles using cast: ### [](https://docs.sova.io/technology/bitcoin-precompiles#sendrawtransaction) sendrawtransaction Copy cast call 0x0000000000000000000000000000000000000999 \ --data 0x00000001${raw_tx_hex} \ --rpc-url http://localhost:8545 ### [](https://docs.sova.io/technology/bitcoin-precompiles#decoderawtransaction) decoderawtransaction Copy cast call 0x0000000000000000000000000000000000000999 \ --data 0x00000002${raw_tx_hex} \ --rpc-url http://localhost:8545 ### [](https://docs.sova.io/technology/bitcoin-precompiles#convertaddress) convertaddress Copy cast call 0x0000000000000000000000000000000000000999 \ --data 0x00000004${eth_address} \ --rpc-url http://localhost:8545 ### [](https://docs.sova.io/technology/bitcoin-precompiles#createandsignrawtransaction) createandsignrawtransaction Copy cast call 0x0000000000000000000000000000000000000999 \ --data 0x00000005${abi_encoded_params} \ --rpc-url http://localhost:8545 [PreviousNode Design & Architecture](https://docs.sova.io/technology/node-design-and-architecture) [NextExecution Client & Sentinel](https://docs.sova.io/technology/execution-client-and-sentinel) Last updated 1 month ago --- # Network Operation Manual | Sova Docs ### [](https://docs.sova.io/node-operators/network-operation-manual#overview) Overview There are various docker compose file variants in the running-sova repository. These files are used for internal testing as well as testnet and mainnet deployment. This guide provides instructions for running Sova Testnet and Mainnet nodes. See Github [repo](https://github.com/SovaNetwork/running-sova) for more detailed information. #### [](https://docs.sova.io/node-operators/network-operation-manual#mainnet-validator) Mainnet Validator * Comming soon! #### [](https://docs.sova.io/node-operators/network-operation-manual#testnet-sepolia-validator-dockerfiles-sova-op-validator-node) Testnet (Sepolia) Validator - [dockerfiles/sova-op-validator-node](https://github.com/SovaNetwork/running-sova/blob/main/dockerfiles/sova-op-testnet-validator-node.yml) * Used to run a full Sova full node. * When the 'core' and 'op-stack' profiles are specified sova-reth, sova-sentinel, op-node, op-batcher, op-proposer all run alongside the Sova auxiliary services. Copy # run Sova OP validator docker-compose -f dockerfiles/sova-op-testnet-validator-node.yml -p sova-op-testnet-validator --profile core --profile op-stack --env-file ./.env up --build -d # stop all containers docker-compose -f dockerfiles/sova-op-testnet-validator-node.yml -p sova-op-testnet-validator --profile core --profile op-stack --env-file ./.env down [](https://docs.sova.io/node-operators/network-operation-manual#setup-guide) Setup Guide --------------------------------------------------------------------------------------------- This guide will walk you through the process of setting up and running a local Sova devnet node using Docker Compose. ### [](https://docs.sova.io/node-operators/network-operation-manual#prerequisites) Prerequisites * Software * Docker (version 20.10.0 or higher) * Docker Compose (version 2.0.0 or higher) * Git * Hardware Requirements * A modern multi-core CPU. * 32 GB RAM. * A locally attached NVMe SSD drive. Note: Requirements may vary based on network activity, transaction volume, number of connected peers, and chain state growth. ### [](https://docs.sova.io/node-operators/network-operation-manual#running-the-node) Running the Node #### [](https://docs.sova.io/node-operators/network-operation-manual#id-1.-clone-the-repository) 1\. Clone the Repository Copy git clone https://github.com/SovaNetwork/running-sova cd running-sova # checkout release version git checkout v0.0.7 #### [](https://docs.sova.io/node-operators/network-operation-manual#id-2.-configure-environment-variables) 2\. Configure Environment Variables Copy # Edit the following .env files: # env.shared # env.validator #### [](https://docs.sova.io/node-operators/network-operation-manual#id-3.-build-and-start-testnet-validator) 3\. Build and Start Testnet Validator #### [](https://docs.sova.io/node-operators/network-operation-manual#dockerfiles-sova-op-testnet-validator-node.yml) [dockerfiles/sova-op-testnet-validator-node.yml](https://github.com/SovaNetwork/running-sova/blob/main/dockerfiles/sova-op-testnet-validator-node.yml) Copy # run Sova OP validator docker-compose -f dockerfiles/sova-op-testnet-validator-node.yml -p sova-op-testnet-validator --profile core --profile op-stack --env-file ./env.shared --env-file ./env.validator up --build -d # remove all containers and volumes with: docker-compose -f dockerfiles/sova-op-testnet-validator-node.yml -p sova-op-testnet-validator --profile core --profile op-stack --env-file ./env.shared --env-file ./env.validator down -v --rmi all [PreviousSova Contracts](https://docs.sova.io/network-information/sova-contracts) Last updated 20 days ago --- # Sova Contracts | Sova Docs ### [](https://docs.sova.io/network-information/sova-contracts#l2-contract-addresses) L2 Contract Addresses #### [](https://docs.sova.io/network-information/sova-contracts#sova-testnet-sepolia) Sova Testnet (Sepolia) Name Address SovaBTC 0x2100000000000000000000000000000000000020 SovaL1Block 0x2100000000000000000000000000000000000015 WETH9 0x4200000000000000000000000000000000000006 L2CrossDomainMessenger 0x4200000000000000000000000000000000000007 L2StandardBridge 0x4200000000000000000000000000000000000010 SequencerFeeVault 0x4200000000000000000000000000000000000011 OptimismMintableERC20Factory 0x4200000000000000000000000000000000000012 GasPriceOracle 0x420000000000000000000000000000000000000F L1Block 0x4200000000000000000000000000000000000015 L2ToL1MessagePasser 0x4200000000000000000000000000000000000016 L2ERC721Bridge 0x4200000000000000000000000000000000000014 OptimismMintableERC721Factory 0x4200000000000000000000000000000000000017 ProxyAdmin 0x4200000000000000000000000000000000000018 BaseFeeVault 0x4200000000000000000000000000000000000019 L1FeeVault 0x420000000000000000000000000000000000001a EAS 0x4200000000000000000000000000000000000021 EASSchemaRegistry 0x4200000000000000000000000000000000000020 ### [](https://docs.sova.io/network-information/sova-contracts#l1-contract-addresses) L1 Contract Addresses #### [](https://docs.sova.io/network-information/sova-contracts#ethereum-testnet-sepolia) Ethereum Testnet (Sepolia) Name Address AddressManager 0x5069b432c8ee51b08d25eac79eec3221c9d38ce7 AnchorStateRegistryProxy 0x0f29542406f80220f5a67cd381389f1f03357a31 DelayedWETHProxy (PDG) 0x34b239447c3257e1487206ae4e1d460262dd90b2 DisputeGameFactoryProxy 0xe1cf4ba4a04f7af49eab32eda62f9a903c52dc39 L1CrossDomainMessengerProxy 0xcd90a7fe885d26490aef71c029f8b27be5cc2679 L1ERC721BridgeProxy 0x78664b3f62fc3f51b2e1fc57f30bd46bbfb8de82 L1StandardBridgeProxy 0x22e040d829ed86e8f01f2906f6f4fd395c81a342 PrimageOracle 0x1fb8cdFc6831fc866Ed9C51aF8817Da5c287aDD3 MIPS 0xf027f4a985560fb13324e943edf55ad6f1d15dc1 OptimismMintableERC20FactoryProxy 0xb1373cf1806c6334c9a93aa5b1ae0ace015dbd45 OptimismPortalProxy 0x54467a873ab70934cc5119dec447df0a5b733e31 PermissionedDisputeGame 0x1a41c2a611bc07ee1f3015a98ee58082510e4d9d ProxyAdmin 0xf88e84728b0ca149cb0ba38427775418260ad0c9 SystemConfigProxy 0xe389b608da827f58249675c541a0b53781f4fcfd ### [](https://docs.sova.io/network-information/sova-contracts#admin-addresses) Admin Addresses #### [](https://docs.sova.io/network-information/sova-contracts#sova-testnet-sepolia-1) Sova Testnet (Sepolia) Primarily Multisigs & EOA's managed by Sova Labs. With the exception of the Batch Inbox address, which has no known private key. Admin Role Address Batch Sender 0xf598b6388eC06945021699F0bbb23dfCFc5edbE8 Batch Inbox 0x00E0CeEb893940a2B32A8bF223BcfD40F1d687aF Output Proposer 0x2A1add78145B73E785045198FA2C103B63A4aB45 Guardian 0x360AE051bBF8681d6Bcd8e26b3e0E3bC92543c19 Proxy Admin Owner (L1) 0x360AE051bBF8681d6Bcd8e26b3e0E3bC92543c19 Challenger 0x054dD688B09202Ff00Ce7aFeD640C8B55534BB02 System config owner 0xe87fDe144392e1d8cFf496b907830E77badc2914 SovaL1Block Admin 0xeE8BF5335b6c795B8922754C2bA88A5C44bAcB16 [PreviousOP Chain Configuration](https://docs.sova.io/network-information/op-chain-configuration) [NextNetwork Operation Manual](https://docs.sova.io/node-operators/network-operation-manual) Last updated 4 hours ago --- # Connecting to Sova | Sova Docs [](https://docs.sova.io/network-information/network-info#sova-testnet-sepolia) Sova Testnet (Sepolia) ---------------------------------------------------------------------------------------------------------- Parameter Value Network Name Sova Testnet (Sepolia) RPC URL [rpc.testnet.sova.io](https://rpc.testnet.sova.io/) Chain ID 120893 Native Token sovaETH Bitcoin Network Regtest Block Time 2s Block Explorer [explorer.testnet.sova.io](https://explorer.testnet.sova.io/) [PreviousContributing](https://docs.sova.io/contributors-and-community/contributing) [NextOP Chain Configuration](https://docs.sova.io/network-information/op-chain-configuration) Last updated 2 months ago --- # OP Chain Configuration | Sova Docs The Sova Network follows the [OP spec](https://specs.optimism.io/) . You can think of using Sova like using Base or Optimism. We are an Ethereum L2 at our core with the added ability to communicate with Bitcoin natively via the custom precompiles. This means all Ethereum and OP precompiles/ predeploy contracts are available on Sova. Users have access to all the same native ETH bridging, optimistic proofs, interop upgrades, etc... that all the other chains that follow the OP spec have. * [Opcodes](https://stack.optimism.io/docs/releases/bedrock/differences/#opcode-differences) * [Blocks](https://stack.optimism.io/docs/releases/bedrock/differences/#blocks) * [Network specifications](https://stack.optimism.io/docs/releases/bedrock/differences/#network-specifications) * [Transaction costs](https://stack.optimism.io/docs/releases/bedrock/differences/#transaction-costs) [PreviousConnecting to Sova](https://docs.sova.io/network-information/network-info) [NextSova Contracts](https://docs.sova.io/network-information/sova-contracts) Last updated 2 months ago --- # How It Works | Sova Docs ### [](https://docs.sova.io/quickstart/publish-your-docs#overview) Overview Sova is an Ethereum L2 running the OP rollup stack. The network's key innovation is providing native Bitcoin integration at the network level enabling smart contracts to directly interact with Bitcoin. The first use case for this network is servicing sovaBTC a native Bitcoin wrapper. Next we will dive into how the sovaBTC technology works. ### [](https://docs.sova.io/quickstart/publish-your-docs#bitcoin-interactions) Bitcoin Interactions #### [](https://docs.sova.io/quickstart/publish-your-docs#deposits-native-bitcoin) ⚡ Deposits: Native Bitcoin * Users initiate a deposit by signing both a Bitcoin and Sova transaction. * Validators broadcast the Bitcoin transaction and tentatively mint sovaBTC on Sova. * **Sentinel**, Sova’s finality oracle, locks the affected contract state until the Bitcoin transaction is confirmed (default: 6 blocks). * Once finalized, sovaBTC becomes fully transferable on the Sova Network and all OP Superchain networks always backed 1:1 by BTC. #### [](https://docs.sova.io/quickstart/publish-your-docs#withdrawals-bitcoin-redemption) 🔓 Withdrawals: Bitcoin Redemption * Users **burn** sovaBTC and specify a Bitcoin address for withdrawal. * Sova’s signing service generates and broadcasts the Bitcoin transaction using or threshold signatures. * All BTC withdrawals are verifiable against Sova's internal ledger and the Bitcoin blockchain. * If validators act dishonestly, **Operators** can submit fraud proofs and trigger slashing. ### [](https://docs.sova.io/quickstart/publish-your-docs#transaction-flow) Transaction Flow ![](https://docs.sova.io/~gitbook/image?url=https%3A%2F%2F2693970916-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fm6Tmu9at8xIB0V3QJw6P%252Fuploads%252F4vhOeNXqKhtVjBorckVd%252FSova%2520Docs%2520-%2520Tx%2520Flow.png%3Falt%3Dmedia%26token%3Dc1ab8e69-8497-4fa1-a480-c15b8bc09133&width=768&dpr=4&quality=100&sign=cc52fda&sv=2) Sova Transaction Flow Sova abstracts away the complexity of cross-chain interactions by integrating Bitcoin directly into the EVM runtime. When a user initiates a transaction—whether it's a deposit, a withdrawal, or a smart contract call involving Bitcoin—the process unfolds seamlessly across several internal components: 1. **Web3 Wallets and dApps** serve as the user interface. Users interact with familiar EVM wallets to send transactions on Sova. 2. The **Sova Mempool** collects and orders these transactions, ensuring proper sequencing and validation before block inclusion. 3. Once included in a block, the **SovaEVM Execution Engine** interprets and executes the transaction. If the transaction involves Bitcoin (e.g. minting sovaBTC or initiating a withdrawal), the engine communicates with Sova's custom precompiles and finality logic. 4. The **Inspector and Sentinel** modules determine whether the Bitcoin transaction associated with the operation has reached the required confirmation threshold. During this window, the related state is locked and cannot be mutated or reused. 5. For withdrawals, the **Signing Service** securely generates and broadcasts the corresponding Bitcoin transaction, ensuring that BTC is released to the correct address once sovaBTC is burned. 6. After Bitcoin confirmation, the contract state on Sova is finalized and fully unlocked, completing the transaction lifecycle. ### [](https://docs.sova.io/quickstart/publish-your-docs#core-components) Core Components 🔗 SovaEVM: Bitcoin-Native Smart Contracts SovaEVM is the first Ethereum-compatible execution layer with native access to Bitcoin Core. Through custom precompiles and the REVM inspector, smart contracts can directly: * Read from the Bitcoin network (e.g., check txids, block headers) * Broadcast real Bitcoin transactions * React to Bitcoin finality events This enables a new class of decentralized applications where Bitcoin is no longer just a wrapped asset—it’s a programmable first-class citizen. #### [](https://docs.sova.io/quickstart/publish-your-docs#validators-cross-chain-enforcers) 👷 Validators: Cross-Chain Enforcers Sova validators maintain the integrity of both the Sova and Bitcoin state. They are responsible for: * Synchronizing execution with Bitcoin finality * Locking and reverting state changes based on BTC confirmations * Broadcasting Bitcoin transactions on behalf of users Validators are subject to **slashing penalties** for misbehavior, ensuring honest participation. Their actions are cryptographically auditable and anchored to Bitcoin block hashes. [PreviousSova Network](https://docs.sova.io/quickstart) [NextSova Whitepaper](https://docs.sova.io/quickstart/sova-whitepaper) Last updated 8 days ago --- # Execution Client & Sentinel | Sova Docs ### [](https://docs.sova.io/technology/execution-client-and-sentinel#sovas-execution-engine-and-revm-inspector) Sova’s Execution Engine and REVM Inspector **Customized REVM Inspector:** Sova’s execution client (uses [Reth](https://github.com/paradigmxyz/reth) as a EL library) introduces a custom EVM inspector (`SovaInspector`) to enforce Bitcoin transaction finality rules within the EVM. The inspector hooks into the REVM execution cycle (via the `Inspector` trait) to monitor and control state changes related to Bitcoin bridging. In practice, it intercepts calls to Sova’s **Bitcoin precompile** (a special contract at `0x...0999` used for BTC integration) and tracks any storage slots that are written as part of Bitcoin deposit/withdrawal logic. Before allowing a Bitcoin-related call (e.g. broadcasting a BTC transaction) to proceed, the inspector checks with the Sentinel service whether the involved contract storage slots are “locked” (i.e. tied to a pending Bitcoin tx). This is done via a gRPC API call in `StorageSlotProvider` to the Sentinel, which returns the lock status of each slot. **Lock Enforcement and Reverts:** If the Sentinel indicates a slot is **already locked**, it means a Bitcoin transaction is still awaiting confirmation for that slot. In that case, the inspector will **revert** the execution to prevent double-spending or inconsistent state. It uses an internal checkpoint in the EVM journal to roll back any tentative state changes if needed. Only one BTC-broadcast operation is allowed per transaction – the inspector enforces this by caching the first call and rejecting subsequent ones in the same EVM transaction. When a Bitcoin precompile call finishes, the inspector verifies it executed successfully; if not, it produces a revert (with a failure message). For a successful BTC broadcast, the inspector caches the resulting Bitcoin txid and current BTC block height (from the on-chain L1Block contract). These cached values are later used to lock the affected slots. **Integration with Execution Layer:** After each transaction (and at end-of-block), Sova’s execution engine invokes the inspector to update the Sentinel with any new locks. The inspector’s `update_sentinel_locks()` will batch-lock all storage slots that were written during a Bitcoin-related operation, tying them to the specific BTC txid and the Sova block number. This call notifies the Sentinel to record (in its database) that those slots are now immutable until the Bitcoin transaction confirms or is finalized. In essence, the execution layer defers finalizing certain state changes until the Bitcoin network consensus is reached. The inspector and Sentinel together implement an **optimistic execution**: state is updated on Sova immediately, but can be rolled back by the inspector later if the BTC tx fails to confirm. This design tightly couples Sova’s EVM execution with Bitcoin’s state, ensuring that smart contracts cannot double-mint or double-spend BTC-pegged assets. It effectively extends Ethereum’s execution model with a _Bitcoin finality oracle_. ### [](https://docs.sova.io/technology/execution-client-and-sentinel#bitcoin-finality-via-the-sentinel-api-and-database) Bitcoin Finality via the Sentinel API and Database **Sentinel Service & Slot Locks:** The Sova Sentinel is an off-chain gRPC service (with a SQLite DB) dedicated to tracking Bitcoin transaction confirmations and locking contract storage until finality. Its core purpose is to prevent **double-spend or replay attacks** when minting or moving BTC-backed assets on Sova. The Sentinel maintains a record of each “slot lock,” which links a contract storage slot to a specific Bitcoin transaction (by txid) and the original value to revert to if needed. When the Sova node calls `LockSlot` (or batch variant) during a Bitcoin-related transaction, the Sentinel records the current slot value and the intended new value in its DB, marking it as _Locked_. This means the contract state associated with that BTC tx should not be altered by any other transaction until confirmations are achieved. For example, when a user submits a Bitcoin transaction to mint sovaBTC (Sova’s BTC-pegged token), the slot that records that BTC deposit is locked as soon as the mint is initiated. This ensures the same Bitcoin TX cannot be reused to mint twice, and the data cannot be tampered with mid-confirmation. **Confirmation and Finalization:** The Sentinel continuously monitors the Bitcoin blockchain (via an RPC Bitcoin node) to check the confirmation status of each tracked txid. By default it requires **6 confirmations** (configurable) for finality, aligning with Bitcoin’s standard safety threshold. Each lock record stores the Bitcoin block height when the tx was first seen. When a Sova node later queries `get_slot_status` (e.g. at the start of a new block or when a locked slot is accessed), the Sentinel compares the current Bitcoin tip to the saved height to determine confirmations. If the tx has reached the confirmation threshold, the Sentinel will mark the slot as **Unlocked** and allow state to be finalized. At that point, the previously tentative state change (e.g. minted tokens) becomes permanent. If the transaction is still unconfirmed and within the threshold, the slot remains **Locked** (further writes are rejected). **Reversion on Failure:** If a Bitcoin transaction fails to confirm in a reasonable time (e.g. after a certain number of extra blocks, default is 18 blocks as per `BITCOIN_REVERT_THRESHOLD`), the Sentinel can declare the slot **Reverted**. In a Reverted status, the Sentinel provides the original stored value and the current (tentative) value back to the execution client. The Sova inspector then uses this info to rollback the contract state to the **revert value**, effectively undoing the mint or state change as if the Bitcoin tx never happened. This mechanism is crucial: it protects Sova from a scenario where, for example, a user’s BTC deposit tx gets orphaned or double-spent on Bitcoin after sovaBTC was already minted on Sova. By reverting, the sovaBTC maintains a 1:1 backing. The Sentinel’s database keeps both the `current_value` and `revert_value` for each slot, so it can instruct the node exactly how to restore state. The inspector applies these reverts by injecting the prior values back into the EVM’s state journal for that contract slot. **L1 Block Anchoring:** In addition to per-transaction locks, Sova adds a **Bitcoin finality anchor** in every block. Each new Sova block includes a system “deposit” transaction to the `SovaL1Block` contract that records the latest Bitcoin block info. This `setBitcoinBlockData(uint64 blockHeight, bytes32 blockHash)` call stores the current Bitcoin chain height and the hash of the block that is _N blocks back_ (N = confirmation threshold, e.g. 6). Every block, Sova’s builder fetches Bitcoin’s tip height and the hash of tip−6 and injects that into the block’s first transactions. During block execution, the node validates this by querying a Bitcoin RPC: it checks that the provided block hash matches the actual hash at (height−6) on the Bitcoin node. 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. In effect, Sova cannot finalize its state changes beyond 6 blocks without a corresponding final Bitcoin checkpoint. This provides strong finality guarantees – a Sova block can’t be reversed unless the referenced Bitcoin block (with 6 confirms) itself gets reorganized, which is extraordinarily unlikely. **Auditable Trail of Deposits:** The architecture is intended to provide an **end-to-end auditable trail** of each BTC deposit and withdrawal. Each deposit’s details (BTC txid, amount, destination user) are captured on Sova – by an event log and a contract storage mapping. The Sentinel also keeps an off-chain record of every locked slot and associated txid. A third-party auditor (or a Sova full node operator) can correlate these records: for every sovaBTC minted, there should be a corresponding Bitcoin transaction in the Bitcoin ledger sending that exact amount to the sovaBTC contract address. By examining Sova’s on-chain state and events, one can list all BTC txids that led to sovaBTC mints and verify each tx on Bitcoin. Similarly, all sovaBTC burns (withdrawals) correspond to actual Bitcoin outputs sent out – and the precompile’s output includes the BTC txid, which could be logged or obtained by the user (the inspector returns the 32-byte txid on success). Because Sova’s L1Block contract regularly records the current Bitcoin block hash, one can also **verify independently** that the Sentinel is reporting confirmations correctly – the hash of the Bitcoin block at height H-6 is stored on-chain, so anyone running a Bitcoin node can confirm that any given Sova block was anchored to the correct Bitcoin state. **Independent Verification by Nodes:** A third-party node operator could run their **own Sentinel instance** pointing to their Bitcoin node to cross-verify all locks. (In practice, all validators must agree on lock status, so the “official” Sentinel is a source of truth. However, because Bitcoin data is globally available, any discrepancy would be detectable by comparing to one’s own Bitcoin node.) This means the trail of BTC deposits -> sovaBTC and back is transparent: at any time, the total sovaBTC supply on Sova should equal the total BTC that was sent into the system minus BTC withdrawn. This design allows an auditor to **track this total** and even map individual transactions. For example, if 100 sovaBTC exist on Sova, an auditor can find exactly which Bitcoin transactions contributed to that 100 and confirm those transactions had 6 confirmations. If an inconsistency is found (e.g. sovaBTC supply that isn’t backed by confirmed BTC), it would imply a breach of protocol by the operators – something the design is meant to prevent. [PreviousBitcoin Precompiles](https://docs.sova.io/technology/bitcoin-precompiles) [NextDouble Spend Protection](https://docs.sova.io/technology/double-spend-protection) Last updated 1 month ago --- # SovaBTC | Sova Docs SovaBTC is the network’s unified BTC representation - a Bitcoin-wrapped asset designed for maximum decentralization, capital efficiency, and onchain composability. ### [](https://docs.sova.io/sovabtc#id-1.-universal-bitcoin-token) **1\. Universal Bitcoin Token** Each sovaBTC token is **backed 1:1 by BTC or qualified BTC equivalents** (e.g. WBTC, cbBTC), held in secure validator-controlled custody. Minting and redeeming involves: * Verifiable Bitcoin deposits * Onchain multi-sig confirmation * Transparent and auditable reserve tracking > **No centralized bridge. No black box.** sovaBTC is a verifiable, permissionless, and programmatically controlled BTC wrapper. ### [](https://docs.sova.io/sovabtc#id-2.-unified-btc-clearing-layer) **2\. Unified BTC Clearing Layer** The sovaBTC infrastructure acts as a clearing layer for major Bitcoin wrappers, allowing: * Instant conversion between BTC wrappers * Seamless liquidity routing across Sova-native protocols * Frictionless entry/exit to the network with real BTC ### [](https://docs.sova.io/sovabtc#id-3.-native-btc-yield) **3\. Native BTC Yield** **Powered by Sova and** [**Fount Finance**](https://fountfi.com/) Yield strategies built on Sova use BTC natively - no wrapping, no rehypothecation. BTC is deployed into structured products, off-chain yield vaults, and onchain primitives to generate sustainable returns. > Built for **institutional-grade access**, capital protection, and long-term BTC holders. [PreviousWhy Sova?](https://docs.sova.io/why-sova) [NextSova Network](https://docs.sova.io/quickstart) Last updated 14 days ago --- # Why Sova? | Sova Docs Bitcoin is the world’s most secure asset - but it’s been idle for too long. Sova unlocks its next phase: a programmable, yield-bearing asset class. By combining native Bitcoin integration with EVM compatibility, Sova enables a new wave of capital-efficient applications powered directly by BTC. From execution to liquidity, Sova is built to serve as the foundational layer for Bitcoin-native finance. _**Here’s how:**_ ### [](https://docs.sova.io/why-sova#id-1.-a-bitcoin-native-execution-layer) **1\. A Bitcoin-Native Execution Layer** Sova’s architecture allows smart contracts to directly interact with the Bitcoin blockchain. Developers can submit BTC transactions, read UTXO state, and design DeFi protocols that treat BTC as a first-class citizen. This is made possible by: * **Custom precompiles** that decode Bitcoin state and UTXO sets * A **validator-set synchronized with Bitcoin** to verify real BTC transactions * Full **EVM compatibility**, enabling Solidity-based smart contract development > Unlike typical bridges or federated wrappers, Sova eliminates reliance on third parties, unlocking **true Bitcoin programmability** without compromising decentralization or composability. ### [](https://docs.sova.io/why-sova#id-2.-interoperable-btc-capital-markets) **2\. Interoperable BTC Capital Markets** Sova is built on the **OP Superchain**, making it natively interoperable with the Ethereum ecosystem. This enables seamless capital flow between Bitcoin and EVM environments, creating unified BTC markets for: > **Sova bridges Bitcoin and DeFi at the infrastructure level**, removing fragmentation and allowing institutional and onchain-native users to build in a unified capital market. ### [](https://docs.sova.io/why-sova#id-3.-growing-your-btc-wealth) **3\. Growing Your BTC Wealth** Sova transforms Bitcoin from a passive store of value into an active yield-bearing asset. By combining direct BTC integration with smart contract execution, users can deploy BTC into: * Onchain DeFi protocols * Tokenized real-world asset strategies * Capital-efficient credit markets > **Sovereign BTC yield, without compromise.** Built for institutional allocators, fund managers, and sophisticated retail users. ### [](https://docs.sova.io/why-sova#id-4.-btc-clearing-house-unified-liquidity-layer-for-btc) **4\. BTC Clearing House – Unified Liquidity Layer for BTC** Sova includes a protocol-level **clearing layer** for all major Bitcoin wrappers (e.g. WBTC, cbBTC, LBTC, FBTC). Through this, users can mint, redeem, and swap across BTC wrappers in a single pipeline, without friction. * **sovaBTC** serves as the universal BTC token across the network * Underlying reserves are held in a mix of native BTC and qualified BTC wrappers * Routing and clearing logic is embedded into Sova’s base layer > A **universal BTC interface** that abstracts away complexity and enables seamless liquidity routing across chains and wrappers. [PreviousWelcome to Sova](https://docs.sova.io/) [NextSovaBTC](https://docs.sova.io/sovabtc) Last updated 14 days ago --- # Sova Network | Sova Docs Bitcoin, despite its widespread adoption and robust security model, lacks a native virtual machine for complex smart contract execution. This limitation has hindered the development of programmable applications directly secured by Bitcoin. Sova closes this gap by introducing an EVM-compatible execution layer that natively understands Bitcoin. Unlike conventional wrapped asset bridges, which rely on external custodians or federations, Sova enforces Bitcoin transaction finality at the protocol level using cryptographic locks, native precompiles, and on-chain Bitcoin state anchoring. Through this architecture, Sova allows developers to build decentralized applications - DEXs, lending platforms, stablecoins, and more - that can custody, transfer, and interact with real Bitcoin without sacrificing security, auditability, or decentralization. [PreviousSovaBTC](https://docs.sova.io/sovabtc) [NextHow It Works](https://docs.sova.io/quickstart/publish-your-docs) Last updated 14 days ago --- # Double Spend Protection | Sova Docs [](https://docs.sova.io/technology/double-spend-protection#overview) Overview ---------------------------------------------------------------------------------- Sova's double spend protection mechanism ensures Bitcoin finality when interacting with Sova Smart Contracts. This document explains how the "storage slot locking system" works to prevent double spending and maintain cross-chain consistency. We named this service the "Sentinel". ### [](https://docs.sova.io/technology/double-spend-protection#problem-double-spending-in-cross-chain-systems) Problem: Double Spending in Cross-Chain Systems As a complementary Bitcoin layer, Sova faces a critical challenge: ensuring that Bitcoin deposits on Sova accurately reflect confirmed transactions on the Bitcoin blockchain. Without a proper protection mechanism: * Bitcoin transactions could be sent but never confirmed * This could lead to inconsistent or fraudulent states across chains * Users could potentially claim the same Bitcoin value multiple times ### [](https://docs.sova.io/technology/double-spend-protection#solution-storage-slot-locking) Solution: Storage Slot Locking Sova implements a storage slot locking mechanism that temporarily locks specific storage slots in Smart Contracts while waiting for Bitcoin transaction confirmation. This system, called **Sentinel**, acts as a guardian that watches over locked slots and manages their lifecycle. #### [](https://docs.sova.io/technology/double-spend-protection#how-it-works) How It Works 1. When a new Bitcoin transaction is included in a Sova transaction: * The node identifies storage slots that will undergo state changes * Sentinel verifies that the slots are not already locked * If any slot is currently locked, the Sova transaction is reverted and the Bitcoin transaction is not broadcast * Otherwise, Sentinel locks the slot and tracks the previous state to handle a potential revert 2. The lock remains until either: * The Bitcoin transaction confirms: the lock is released and the state change persists * The transaction fails or isn't confirmed within a timeout period: the state is reverted to the previous value ### [](https://docs.sova.io/technology/double-spend-protection#technical-implementation-sova-reth) Technical Implementation: sova-reth This diagram explains the overall block building modifications made to support the Sentinel service. ![](https://docs.sova.io/~gitbook/image?url=https%3A%2F%2F2693970916-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fm6Tmu9at8xIB0V3QJw6P%252Fuploads%252FDOzeyuEBDggRqjPULK7i%252Freth%2520block%2520building.png%3Falt%3Dmedia%26token%3D70c7623b-248c-4628-baa7-499493575f6b&width=768&dpr=4&quality=100&sign=c42f75db&sv=2) The sentinel and its slot locks are enforced by REVM Inspectors. These are essentially hooks that run before and after certain processes in payload building and block execution. The sova-reth inspector has a local cache that is checked during the main transaction loops. The final state of that cache is added to the sentinel database after the simulation and execution phases so that it can be enforced in the next block. Run the [script](https://github.com/SovaNetwork/sova-reth/blob/main/scripts/dev-double-spend-test-withdraw.sh) for running the sequence shown in the diagram. _Side Notes when running a node:_ * _Dev Mode (Single node): Payload Builder and Execution/ Validation are called in the same block building process._ * _Multi node: Only block proposer uses Payload Building flow. Everyone else validates the payload with Execution/Validation flow._ ### [](https://docs.sova.io/technology/double-spend-protection#technical-implementation-sova-sentinel) Technical Implementation: Sova Sentinel Sova Sentinel is a gRPC service that manages storage slot locks for EVM smart contracts on Sova. It provides the following key functions: Copy SlotLockService { rpc LockSlot(LockSlotRequest) returns (LockSlotResponse); rpc GetSlotStatus(GetSlotStatusRequest) returns (GetSlotStatusResponse); rpc UnlockSlot(UnlockSlotRequest) returns (UnlockSlotResponse); } #### [](https://docs.sova.io/technology/double-spend-protection#configuration) Configuration Sentinel can be configured with Bitcoin-specific parameters such as: * `BITCOIN_CONFIRMATION_THRESHOLD`: Number of confirmations required to unlock a slot (default: 6) * `BITCOIN_REVERT_THRESHOLD`: Number of blocks after which a locked slot will revert (default: 18) ### [](https://docs.sova.io/technology/double-spend-protection#benefits) Benefits The Storage Slot Locking mechanism provides several advantages for Sova: #### [](https://docs.sova.io/technology/double-spend-protection#cross-chain-atomicity) Cross-Chain Atomicity Ensures that state changes on Sova remain consistent with dependent Bitcoin transaction outcomes. #### [](https://docs.sova.io/technology/double-spend-protection#revertible-operations) Revertible Operations Unlike traditional blockchain operations which are immediately final, slot locking allows for a "pending" state that can be reverted if the corresponding Bitcoin transaction fails. #### [](https://docs.sova.io/technology/double-spend-protection#guaranteed-finality) Guaranteed Finality The node network running with the locking mechanism can guarantee that after a specific number of blocks, the network will provide the correct finalized outcome regarding whether a certain event happened on Bitcoin. ### [](https://docs.sova.io/technology/double-spend-protection#consensus-integration) Consensus Integration The storage slot locking mechanism is not just an application-level feature but is integrated directly into Sova's network consensus rules. This integration ensures that all nodes in the network maintain an identical view of which storage slots are locked and when they should be unlocked or reverted. #### [](https://docs.sova.io/technology/double-spend-protection#consensus-rules-enforcement) Consensus Rules Enforcement 1. **Database Synchronization**: Every Sova node maintains a synchronized database of locked slots. This database is part of the consensus-critical state. 2. **Block Validation**: During block validation, nodes verify that: * No transaction attempts to modify a locked slot * Unlocks only occur when proper Bitcoin confirmation evidence is provided * Reverts happen automatically after the configured timeout period 3. **Lock Propagation**: When a new lock is created, it is propagated to all nodes in the network as part of the transaction data. 4. **Deterministic Processing**: The rules for processing locks, unlocks, and reverts are deterministic, ensuring all nodes reach the same conclusion about the state of each slot. ### [](https://docs.sova.io/technology/double-spend-protection#technical-parallels-bit-masking) Technical Parallels: Bit Masking The implementation of Sentinel shares conceptual similarities with bit masking techniques in computer science: * Just as bit masks use binary operations (AND, OR, XOR) to atomically modify specific bits while preserving others, the Sentinel atomically manages slot states while preserving transaction integrity * Similar to how a bit mask can update specific bits in a register, our system uses Bitcoin block confirmations as a signal to update the state of locked slots * When new Bitcoin blocks are confirmed, we apply updates to our lock set, effectively "masking" our state to match Bitcoin's reality [PreviousExecution Client & Sentinel](https://docs.sova.io/technology/execution-client-and-sentinel) [NextFor Frontend Developers](https://docs.sova.io/contributors-and-community/for-frontend-developers) Last updated 8 days ago --- # For Solidity Developers | Sova Docs The tools we use to work on Sova are the same as any other EVM network. Developers can use Foundry, Tenderly, common web3 frontend libraries, and much more. This is one of the primary advantages of the network. Sova can easily integrate with any other EVM network while at the same time benefiting from the hard work of the largest Blockchain dev community in the world. [](https://docs.sova.io/contributors-and-community/for-solidity-developers#precompile-library) Precompile Library ---------------------------------------------------------------------------------------------------------------------- #### [](https://docs.sova.io/contributors-and-community/for-solidity-developers#sovabitcoin.sol) SovaBitcoin.sol Copy // SPDX-License-Identifier: MIT pragma solidity 0.8.15; /** * @title SovaBitcoin * @author Sova Labs * * A library for integrating with Bitcoin precompiles on Sova. */ library SovaBitcoin { /// @notice Bitcoin precompile address address public constant BTC_PRECOMPILE = address(0x999); /// @notice Bitcoin context contract address address public constant SOVA_L1_BLOCK_ADDRESS = 0x2100000000000000000000000000000000000015; /// @notice Native Bitcoin wrapper address address public constant UBTC_ADDRESS = 0x2100000000000000000000000000000000000020; /// @notice Bitcoin precompile selectors bytes4 public constant BROADCAST_BYTES = 0x00000001; bytes4 public constant DECODE_BYTES = 0x00000002; bytes4 public constant CHECKSIG_BYTES = 0x00000003; bytes4 public constant ADDRESS_CONVERT_LEADING_BYTES = 0x00000004; bytes4 public constant UBTC_SIGN_TX_BYTES = 0x00000005; struct Output { string addr; uint256 value; bytes script; } struct Input { bytes32 prevTxHash; uint32 outputIndex; bytes scriptSig; bytes[] witness; } struct BitcoinTx { bytes32 txid; Output[] outputs; Input[] inputs; uint256 locktime; } error PrecompileCallFailed(); error InvalidOutput(string expected, string actual); error InvalidDeposit(); error InvalidAmount(); error InsufficientInput(); error InvalidLocktime(); /// @custom:semver 0.1.0-beta.1 function version() public pure returns (string memory) { return "0.1.0-beta.1"; } /** * @notice Decodes a raw Bitcoin transaction into a structured format * * @param signedTx The raw signed Bitcoin transaction * * @return BitcoinTx Object containing the decoded transaction data */ function decodeBitcoinTx(bytes memory signedTx) internal view returns (BitcoinTx memory) { (bool success, bytes memory returndata) = BTC_PRECOMPILE.staticcall(abi.encodePacked(DECODE_BYTES, signedTx)); if (!success) revert PrecompileCallFailed(); return abi.decode(returndata, (BitcoinTx)); } /** * @notice Verifies the signatures in a Bitcoin transaction * * @param signedTx The raw signed Bitcoin transaction * * @return success Boolean indicating if payload is valid */ function checkSignature(bytes calldata signedTx) internal view returns (bool success) { (success,) = BTC_PRECOMPILE.staticcall(abi.encodePacked(CHECKSIG_BYTES, signedTx)); } /** * @notice Retrieves the unique deposit address for the corresponding EVM address * * @param addr The EVM address to convert * * @return returnData The Bitcoin deposit address in bytes format */ function convertToBtcAddress(address addr) internal returns (bytes memory) { (bool success, bytes memory returnData) = BTC_PRECOMPILE.call(abi.encodePacked(ADDRESS_CONVERT_LEADING_BYTES, addr)); if (!success) revert PrecompileCallFailed(); return returnData; } /** * @notice Broadcasts a signed Bitcoin transaction to the Bitcoin network * * @param signedTx The raw signed Bitcoin transaction to broadcast */ function broadcastBitcoinTx(bytes memory signedTx) internal { (bool success,) = BTC_PRECOMPILE.call(abi.encodePacked(BROADCAST_BYTES, signedTx)); if (!success) revert PrecompileCallFailed(); } /** * @notice Validates a Bitcoin transaction for deposit purposes and returns the decoded transaction * @dev Performs a series of checks on the transaction structure and content: * 1. Verifies the transaction has between 1 and 3 outputs * 2. Confirms the first output value meets the minimum amount * 3. Ensures the transaction has at least one input * 4. Validates the locktime is not in the future * 5. Checks that the first output address matches the network's receive address * * @param signedTx The raw signed Bitcoin transaction * @param amount The minimum expected amount in satoshis * * @return btcTx The decoded Bitcoin transaction */ function isValidDeposit(bytes memory signedTx, uint256 amount) internal returns (BitcoinTx memory) { BitcoinTx memory btcTx = decodeBitcoinTx(signedTx); if (btcTx.outputs.length < 1 || btcTx.outputs.length > 3) { revert InvalidDeposit(); } if (btcTx.outputs[0].value != amount) { revert InvalidAmount(); } if (btcTx.inputs.length < 1) { revert InsufficientInput(); } if (btcTx.locktime > block.timestamp) { revert InvalidLocktime(); } // Recover the callers unique bitcoin deposit address bytes memory convertedBtcAddress = SovaBitcoin.convertToBtcAddress(msg.sender); if (keccak256(convertedBtcAddress) != keccak256(bytes(btcTx.outputs[0].addr))) { revert InvalidOutput(btcTx.outputs[0].addr, string(convertedBtcAddress)); } return btcTx; } } [](https://docs.sova.io/contributors-and-community/for-solidity-developers#custom-smart-contract-example) Custom Smart Contract Example -------------------------------------------------------------------------------------------------------------------------------------------- #### [](https://docs.sova.io/contributors-and-community/for-solidity-developers#broadcast-a-bitcoin-transaction) Broadcast a Bitcoin Transaction Copy // SPDX-License-Identifier: MIT pragma solidity 0.8.15; import {SovaBitcoin} from "@sova-network/src/lib/SovaBitcoin.sol"; contract BitcoinSender { function broadcastBitcoinTx(bytes memory rawTransaction) public returns (bytes32) { // Decode the transaction first to get the txid SovaBitcoin.BitcoinTx memory btcTx = SovaBitcoin.decodeBitcoinTx(rawTransaction); // Broadcast the transaction SovaBitcoin.broadcastBitcoinTx(rawTransaction); return btcTx.txid; } } [PreviousFor Frontend Developers](https://docs.sova.io/contributors-and-community/for-frontend-developers) [NextFrequently Asked Questions (FAQ)](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq) Last updated 1 month ago --- # Sova Whitepaper | Sova Docs Learn more about Sova's technical architecture and vision in our [whitepaper](https://github.com/SovaNetwork/sova-whitepaper/blob/c8fed583b43a009454e62629f55d9898b9eaba40/Sova_Whitepaper_Draft_2_10_25.pdf) . ### [](https://docs.sova.io/quickstart/sova-whitepaper#overview) Overview The white paper introduces Sova, a blockchain designed to add programmability to Bitcoin through an EVM-compatible execution environment. Key sections cover: * **Technical Architecture**: Details on validator-level Bitcoin Core bindings combined with precompile-based VM extensions * **Asset Integration**: How Sova enables smart contracts to interact with Bitcoin-native assets like Runes and Ordinals * **Security Model**: Network security approach leveraging pooled security from Ethereum mainnet * **Execution System**: Comprehensive overview of the execution queue system and validator responsibilities * **Use Cases**: Detailed examples demonstrating Bitcoin-native DeFi applications * **Technical Specifications**: Complete documentation of precompiles and protocol design Developers and technical readers will find in-depth explanations of Sova's approach to bridging Bitcoin's settlement layer with EVM programmability while maintaining Bitcoin's security properties. [PreviousHow It Works](https://docs.sova.io/quickstart/publish-your-docs) [NextUse Cases](https://docs.sova.io/use-cases) Last updated 3 months ago --- # Use Cases | Sova Docs ### [](https://docs.sova.io/use-cases#id-1.-sovabtc-bridge) 1\. **SovaBTC Bridge** Mint or redeem sovaBTC through a **fully onchain, auditable process**, powered by validator-enforced custody and native BTC verification. No centralized intermediaries involved. ### [](https://docs.sova.io/use-cases#id-2.-enduring-btc-yield) **2\. Enduring BTC Yield** Deploy sovaBTC into **institutional-grade strategies** and earn real BTC-denominated yield — without leaving the Sova network. ### [](https://docs.sova.io/use-cases#id-3.-lending-and-borrowing) **3\. Lending & Borrowing** Use sovaBTC as **trustless collateral** in onchain credit markets. Borrow USDC, yield-bearing stablecoins, or BTC-native assets, all while maintaining BTC exposure. ### [](https://docs.sova.io/use-cases#id-4.-native-dex-and-derivatives) **4\. Native DEX & Derivatives** Trade BTC-native pairs and settle derivatives on a **UTXO-aware EVM rollup** designed for high-throughput Bitcoin finance. Unlock advanced hedging, leverage, and structured positions onchain. [PreviousSova Whitepaper](https://docs.sova.io/quickstart/sova-whitepaper) [NextNode Design & Architecture](https://docs.sova.io/technology/node-design-and-architecture) Last updated 14 days ago --- # Contributing | Sova Docs Sova welcomes contributions to its source code from anyone in the community, no matter how small the fix or upgrade may be. If you're interested in contributing, you can start by forking the [GitHub repository](https://github.com/sovanetwork) , making your fix or improvement, committing the changes, and then submitting a pull request for the maintainers to review and merge into the main code base. However, if you plan on submitting more complex changes, it's recommended to check in with the core developers on the [Sova Github Issues](https://github.com/SovaNetwork/sova-reth/issues) first to ensure that your changes align with the project's philosophy and to get some early feedback that can make the review and merge process smoother for both parties. It's important that your contributions adhere to Sova coding guidelines, which include: * Following the official Rust formatting and commentary guidelines, * Basing pull requests on the `main` branch, * CI/CD checks passing (tests, linting, formatting, etc.) We encourage an early pull request approach, where contributors create pull requests as early as possible, even if the fix or feature is not yet completed. This approach lets core developers and other volunteers know that someone is working on the issue and allows for more collaborative and efficient development. These early pull requests should indicate that they are "in progress". If you contribute to this project, your contributions will be made to the project under both Apache 2.0 and the MIT license. [PreviousFrequently Asked Questions (FAQ)](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq) [NextConnecting to Sova](https://docs.sova.io/network-information/network-info) Last updated 4 months ago --- # Frequently Asked Questions (FAQ) | Sova Docs ### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#general) General #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#what-is-sova) What is Sova? Sova is a network for native-Bitcoin asset programmability. It combines the programmability of Ethereum with the security and value of Bitcoin, allowing developers to create smart contracts that can directly interact with Bitcoin. #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#how-does-sova-differ-from-other-blockchain-platforms) How does Sova differ from other blockchain platforms? Sova's key innovation is its smart contract functions that allow direct, synchronous on-chain interaction with Bitcoin, offering a superior user experience over L2s which can only be accessed via bridge. It enables developers to write Solidity code while giving users wyas to do things directly on Bitcoin through existing EVM wallets. ### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#technology) Technology #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#what-is-sova-evm) What is Sova EVM? Sova EVM is the only EVM blockchain with Bitcoin read-write bindings, callable via smart contracts. These read-write bindings allow Sova smart contracts to send BTC, tranfer native assets such as Ordinals and Runes, create Bitcoin multisigs, and provide signatures to Bitcoin transaction inputs. #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#how-does-sova-ensure-security) How does Sova ensure security? Sova's security model is based on traditional EVM L2 security via the OP Stack, with additional consensus rules and slashing conditions derived from the validator expectations for Bitcoin interoperation. Validators run Sova EVM and either an internal or hosted Bitcoin Core node, managing state synchronicity and verifying cross-chain interactions. In addition to PoS economic security provided by $SOVA staking, Sova uses Eigenlayer for restaking - allowing operators to secure Sova with $ETH with seamless on-chain registration and minimal opportunity cost. #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#what-is-the-usdsova-token-used-for) What is the $SOVA token used for? $SOVA is the native token of Sova, used for gas fees, validator rewards, and sequencer incentives. ### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#development) Development #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#can-i-use-my-existing-ethereum-development-tools-with-sova) Can I use my existing Ethereum development tools with Sova? Yes, Sova is compatible with Ethereum development tools. You can use familiar tools like Foundry, Hardhat, ethers.js and Web3.js to develop on Sova. #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#how-do-i-interact-with-bitcoin-through-sova-smart-contracts) How do I interact with Bitcoin through Sova smart contracts? Sova provides Bitcoin precompiles that allow smart contract developers to directly interact with the Bitcoin network. These precompiles are accessible at a specific address and can be called from within your Solidity code. [Precompiles](https://docs.sova.io/technology/bitcoin-precompiles) #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#is-there-a-testnet-available-for-sova) Is there a testnet available for Sova? Yes. [Network Info](doc:network-info) ### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#ubtc) uBTC #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#what-is-ubtc) What is uBTC? uBTC is a universal Bitcoin ERC-20 token on Sova, representing 1:1 backed Bitcoin on the Sova network. #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#how-is-ubtc-different-from-wrapped-bitcoin-on-other-networks) How is uBTC different from wrapped Bitcoin on other networks? uBTC leverages Sova's native Bitcoin integration, allowing for more secure and efficient interactions with actual Bitcoin, rather than relying on external custodians or bridges. ### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#user-experience) User Experience #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#do-users-need-to-understand-both-ethereum-and-bitcoin-to-use-sova-dapps) Do users need to understand both Ethereum and Bitcoin to use Sova dApps? No, Sova aims to provide a seamless experience where users can interact with Bitcoin-based applications using familiar web3 interfaces, without needing to understand the underlying complexity. #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#can-i-use-my-existing-wallet-with-sova) Can I use my existing wallet with Sova? Yes, all the common Ethereum and Bitcoin wallets will work with Sova. ### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#economics-and-incentives) Economics and Incentives #### [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#how-does-sova-incentivize-network-participants) How does Sova incentivize network participants? Sova uses the $SOVA token to reward validators and incentivize good behavior on the network. The specific economic model includes \[insert details about staking, rewards, etc.\ \ #### \ \ [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#how-can-i-contribute-to-sovas-development)\ \ How can I contribute to Sova's development?\ \ We welcome contributions from developers. You can get involved by contributing to our GitHub repository, participating in our developer forums, and reaching out to us on socials.\ \ ### \ \ [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#support-and-resources)\ \ Support and Resources\ \ #### \ \ [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#where-can-i-get-help-if-im-stuck)\ \ Where can I get help if I'm stuck?\ \ We offer several support channels:\ \ * Telegram: @sova\_btc\ \ * Submit GitHub issues for technical problems\ \ \ #### \ \ [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#are-there-any-tutorials-or-guides-available-for-getting-started-with-sova)\ \ Are there any tutorials or guides available for getting started with Sova?\ \ Yes, we provide comprehensive guides and tutorials in our Developer Resources section.\ \ #### \ \ [](https://docs.sova.io/contributors-and-community/frequently-asked-questions-faq#how-can-i-stay-updated-on-sova-news-and-announcements)\ \ How can I stay updated on Sova news and announcements?\ \ Follow our official X account [@SovaBTC](https://x.com/SovaBTC)\ for the latest updates and join our Telegram.\ \ [PreviousFor Solidity Developers](https://docs.sova.io/contributors-and-community/for-solidity-developers)\ [NextContributing](https://docs.sova.io/contributors-and-community/contributing)\ \ Last updated 13 days ago --- # For Frontend Developers | Sova Docs [](https://docs.sova.io/contributors-and-community/for-frontend-developers#available-tools) Available Tools ---------------------------------------------------------------------------------------------------------------- There are a number of available tools for frontend dApp developers building on Sova. Being an EVM compatible chain, it's tool set is interoperable with the broader EVM ecosystem. Here are a few of the tools available for Sova: #### [](https://docs.sova.io/contributors-and-community/for-frontend-developers#wagmi.sh) Wagmi.sh [wagmi](https://wagmi.sh/) is a collection of hooks and helpers for rapidly developing evm frontend dApps. It provides out of the box wallet connection, data caching, and persistence. #### [](https://docs.sova.io/contributors-and-community/for-frontend-developers#web3react-and-ethers.js) Web3React & Ethers.js [Web3React](https://github.com/Uniswap/web3-react) is a lightweight framework for creating Ethereum dApps with React. It provides a simple interface for connecting to Ethereum wallets as well as some useful hooks for managing providers and accounts. When combined with [ethers.js](https://docs.ethers.org/v5/) , It provides a highly customizable tool set for building lightweight dApps. [](https://docs.sova.io/contributors-and-community/for-frontend-developers#bitcoin-wallet-providers) Bitcoin Wallet Providers ---------------------------------------------------------------------------------------------------------------------------------- User will need to sign Bitcoin transactions using their preferred Bitcoin wallet provider. Most Bitcoin wallets expose this functionality via a `signPSBT` api call. This signed transaction will be used as an input to Sova Network smart contract calls. #### [](https://docs.sova.io/contributors-and-community/for-frontend-developers#unisat.io) Unisat.io [Unisat](https://docs.unisat.io/) allows you to explore the world of Bitcoin and ordinals. You can deploy your own inscribing services, build wallet applications, develop browsers, and much more using the API. #### [](https://docs.sova.io/contributors-and-community/for-frontend-developers#phantom) Phantom [Phantom](https://docs.phantom.com/) is a crypto wallet that can be used to manage digital assets and access decentralized applications on Bitcoin [PreviousDouble Spend Protection](https://docs.sova.io/technology/double-spend-protection) [NextFor Solidity Developers](https://docs.sova.io/contributors-and-community/for-solidity-developers) Last updated 4 months ago --- # Node Design & Architecture | Sova Docs Sova nodes operate as multi-service systems that coordinate EVM smart contract execution with native Bitcoin precompile bindings. Each validator runs the following core components: #### [](https://docs.sova.io/technology#sova-execution-client-sova-reth) **Sova Execution Client (**`**sova-reth**`**)** A customized EVM execution engine based on Reth, extended to support native Bitcoin precompiles and slot-locking logic. It enforces Bitcoin finality through direct coordination with the Sentinel and tracks state updates tied to BTC transactions. #### [](https://docs.sova.io/technology#consensus-client-op-node) **Consensus Client (**`**op-node**`**)** The canonical Optimism consensus client responsible for sequencing, block building, and L2-to-L1 rollup logic. On the sova network this service has the very important job of anchoring each Sova block to a Bitcoin by including confirmed Bitcoin block headers. #### [](https://docs.sova.io/technology#bitcoin-core) **Bitcoin Core** Each validator connects to a full Bitcoin core node. This ensures that all Bitcoin-related operations (e.g. tx confirmation, block hash validation, UTXO availability) are verifiable directly from the Bitcoin network without having to trust the sequencer's Bitcoin connection. #### [](https://docs.sova.io/technology#finality-provider-sentinel) **Finality Provider (**`**sentinel**`**)** An off-chain database-backed service that tracks the confirmation status of Bitcoin transactions. It locks or reverts contract storage slots based on whether associated BTC transactions have been confirmed on-chain. Critical for enforcing 1:1 BTC-sovaBTC minting guarantees. [](https://docs.sova.io/technology#sequencers) Sequencers -------------------------------------------------------------- Sequencers on the Sova Network are responsible for block production, transaction ordering, and coordination of Bitcoin-related operations. In addition to executing EVM transactions, Sova sequencers play a unique role: they operate the network’s Signing Service API, which securely generates Bitcoin transactions during user withdrawals. ![](https://docs.sova.io/~gitbook/image?url=https%3A%2F%2F2693970916-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fm6Tmu9at8xIB0V3QJw6P%252Fuploads%252FO6pkQY9FSSX7jmKOg3TH%252FSova%2520Node%2520Arch%2520%28L1%29%2520%281%29.png%3Falt%3Dmedia%26token%3Dbe85550f-e955-4f33-bfcf-fb7f2b7bfeaa&width=768&dpr=4&quality=100&sign=dbd0dbe8&sv=2) #### [](https://docs.sova.io/technology#bitcoin-utxo-indexer) **Bitcoin UTXO Indexer** An indexer which tracks all spendable UTXOs associated with Sova’s native deposit address and third party bitcoin addresses. All UTXOs that are tracked are spendable by the network for servicing user BTC withdrawals. It provides a real-time, block-by-block UTXO lookup API used by `sova-reth` to construct valid Bitcoin transactions during withdrawals. #### [](https://docs.sova.io/technology#signing-service-api) **Signing Service API** A restricted signing gateway used exclusively by sequencer nodes. It handles multi-input Bitcoin transaction signing and ensures signatures comply with consensus rules and proof-of-reserve integrity. The signing service is designed such that it does not use a single public/private key pair and instead sources signatures for a host of trusted custodians. ### [](https://docs.sova.io/technology#deposit-transaction-with-slot-locking-flow-diagram) Deposit Transaction with Slot Locking Flow Diagram _Scenario: Doublespend Bitcoin transaction_ [PreviousUse Cases](https://docs.sova.io/use-cases) [NextBitcoin Precompiles](https://docs.sova.io/technology/bitcoin-precompiles) Last updated 8 days ago This site uses cookies to deliver its service and to analyze traffic. By browsing this site, you accept the [privacy policy](https://policies.gitbook.com/privacy/cookies) . AcceptReject --- # Network Operation Manual | Sova Docs ### [](https://docs.sova.io/node-operators#overview) Overview There are various docker compose file variants in the running-sova repository. These files are used for internal testing as well as testnet and mainnet deployment. This guide provides instructions for running Sova Testnet and Mainnet nodes. See Github [repo](https://github.com/SovaNetwork/running-sova) for more detailed information. #### [](https://docs.sova.io/node-operators#mainnet-validator) Mainnet Validator * Comming soon! #### [](https://docs.sova.io/node-operators#testnet-sepolia-validator-dockerfiles-sova-op-validator-node) Testnet (Sepolia) Validator - [dockerfiles/sova-op-validator-node](https://github.com/SovaNetwork/running-sova/blob/main/dockerfiles/sova-op-testnet-validator-node.yml) * Used to run a full Sova full node. * When the 'core' and 'op-stack' profiles are specified sova-reth, sova-sentinel, op-node, op-batcher, op-proposer all run alongside the Sova auxiliary services. Copy # run Sova OP validator docker-compose -f dockerfiles/sova-op-testnet-validator-node.yml -p sova-op-testnet-validator --profile core --profile op-stack --env-file ./.env up --build -d # stop all containers docker-compose -f dockerfiles/sova-op-testnet-validator-node.yml -p sova-op-testnet-validator --profile core --profile op-stack --env-file ./.env down [](https://docs.sova.io/node-operators#setup-guide) Setup Guide -------------------------------------------------------------------- This guide will walk you through the process of setting up and running a local Sova devnet node using Docker Compose. ### [](https://docs.sova.io/node-operators#prerequisites) Prerequisites * Software * Docker (version 20.10.0 or higher) * Docker Compose (version 2.0.0 or higher) * Git * Hardware Requirements * A modern multi-core CPU. * 32 GB RAM. * A locally attached NVMe SSD drive. Note: Requirements may vary based on network activity, transaction volume, number of connected peers, and chain state growth. ### [](https://docs.sova.io/node-operators#running-the-node) Running the Node #### [](https://docs.sova.io/node-operators#id-1.-clone-the-repository) 1\. Clone the Repository Copy git clone https://github.com/SovaNetwork/running-sova cd running-sova # checkout release version git checkout v0.0.7 #### [](https://docs.sova.io/node-operators#id-2.-configure-environment-variables) 2\. Configure Environment Variables Copy # Edit the following .env files: # env.shared # env.validator #### [](https://docs.sova.io/node-operators#id-3.-build-and-start-testnet-validator) 3\. Build and Start Testnet Validator #### [](https://docs.sova.io/node-operators#dockerfiles-sova-op-testnet-validator-node.yml) [dockerfiles/sova-op-testnet-validator-node.yml](https://github.com/SovaNetwork/running-sova/blob/main/dockerfiles/sova-op-testnet-validator-node.yml) Copy # run Sova OP validator docker-compose -f dockerfiles/sova-op-testnet-validator-node.yml -p sova-op-testnet-validator --profile core --profile op-stack --env-file ./env.shared --env-file ./env.validator up --build -d # remove all containers and volumes with: docker-compose -f dockerfiles/sova-op-testnet-validator-node.yml -p sova-op-testnet-validator --profile core --profile op-stack --env-file ./env.shared --env-file ./env.validator down -v --rmi all [PreviousSova Contracts](https://docs.sova.io/network-information/sova-contracts) Last updated 20 days ago This site uses cookies to deliver its service and to analyze traffic. By browsing this site, you accept the [privacy policy](https://policies.gitbook.com/privacy/cookies) . AcceptReject --- # Connecting to Sova | Sova Docs [](https://docs.sova.io/network-information#sova-testnet-sepolia) Sova Testnet (Sepolia) --------------------------------------------------------------------------------------------- Parameter Value Network Name Sova Testnet (Sepolia) RPC URL [rpc.testnet.sova.io](https://rpc.testnet.sova.io/) Chain ID 120893 Native Token sovaETH Bitcoin Network Regtest Block Time 2s Block Explorer [explorer.testnet.sova.io](https://explorer.testnet.sova.io/) [PreviousContributing](https://docs.sova.io/contributors-and-community/contributing) [NextOP Chain Configuration](https://docs.sova.io/network-information/op-chain-configuration) Last updated 2 months ago This site uses cookies to deliver its service and to analyze traffic. By browsing this site, you accept the [privacy policy](https://policies.gitbook.com/privacy/cookies) . AcceptReject --- # For Frontend Developers | Sova Docs [](https://docs.sova.io/contributors-and-community#available-tools) Available Tools ---------------------------------------------------------------------------------------- There are a number of available tools for frontend dApp developers building on Sova. Being an EVM compatible chain, it's tool set is interoperable with the broader EVM ecosystem. Here are a few of the tools available for Sova: #### [](https://docs.sova.io/contributors-and-community#wagmi.sh) Wagmi.sh [wagmi](https://wagmi.sh/) is a collection of hooks and helpers for rapidly developing evm frontend dApps. It provides out of the box wallet connection, data caching, and persistence. #### [](https://docs.sova.io/contributors-and-community#web3react-and-ethers.js) Web3React & Ethers.js [Web3React](https://github.com/Uniswap/web3-react) is a lightweight framework for creating Ethereum dApps with React. It provides a simple interface for connecting to Ethereum wallets as well as some useful hooks for managing providers and accounts. When combined with [ethers.js](https://docs.ethers.org/v5/) , It provides a highly customizable tool set for building lightweight dApps. [](https://docs.sova.io/contributors-and-community#bitcoin-wallet-providers) Bitcoin Wallet Providers ---------------------------------------------------------------------------------------------------------- User will need to sign Bitcoin transactions using their preferred Bitcoin wallet provider. Most Bitcoin wallets expose this functionality via a `signPSBT` api call. This signed transaction will be used as an input to Sova Network smart contract calls. #### [](https://docs.sova.io/contributors-and-community#unisat.io) Unisat.io [Unisat](https://docs.unisat.io/) allows you to explore the world of Bitcoin and ordinals. You can deploy your own inscribing services, build wallet applications, develop browsers, and much more using the API. #### [](https://docs.sova.io/contributors-and-community#phantom) Phantom [Phantom](https://docs.phantom.com/) is a crypto wallet that can be used to manage digital assets and access decentralized applications on Bitcoin [PreviousDouble Spend Protection](https://docs.sova.io/technology/double-spend-protection) [NextFor Solidity Developers](https://docs.sova.io/contributors-and-community/for-solidity-developers) Last updated 4 months ago This site uses cookies to deliver its service and to analyze traffic. By browsing this site, you accept the [privacy policy](https://policies.gitbook.com/privacy/cookies) . AcceptReject ---