# Abstract

SatoshiVM is a decentralized Bitcoin ZK Rollup Layer 2 solution compatible with the Ethereum Virtual Machine (EVM) ecosystem, using native BTC as gas. Empowered with the ability to connect both Bitcoin and EVM ecosystems, it seamlessly merges the value anchoring of BTC with the programmability of EVM, bringing infinite possibilities to the evolution of the new ecosystem.

## Innovation-driven <a href="#innovation-driven" id="innovation-driven"></a>

SatoshiVM closely monitors the development of emerging technologies within the industry, committed to integrating the advantages of these technologies with its own characteristics. We continuously explore new possibilities to enhance SatoshiVM's capabilities. Recognizing the crucial role of rapid technological evolution in project development, we actively seek and adopt new technologies that can elevate SatoshiVM, ensuring that we remain at the forefront of the industry and provide users with an outstanding experience.

SatoshiVM is a Bitcoin Layer2 solution that incorporates the ZK Stark algorithm and Taproot script. Given that Bitcoin itself does not support overly complex programs, SatoshiVM executes complex smart contracts off-chain and utilizes the technical features of Taproot Script to verify the results of certain off-chain computations on the BTC blockchain. Similar to the concept behind [bitVM](https://bitvm.org/bitvm.pdf), SatoshiVM compiles high-level language programs into a series of low-level opcodes off-chain. Following the principles of electronic computing, these opcodes can be represented in the form of digital circuits (logic gates). Ultimately, by expressing the logic gate circuits in the form of Bitcoin Script, it is possible to simulate the operation of part of the logic gate circuit on the Bitcoin blockchain when necessary and observe its results.

The [SatoshiVM Yellow Paper](https://github.com/SatoshiVM/yellowpaper/blob/main/SatoshiVM_Advancing_On-Chain_Verification_for_Bitcoin_and_Enhancing_Layer-2_Implementation.pdf) highlights that, with the aforementioned approach, arbitrary computations can be executed off the BTC blockchain, and only when necessary, certain minor steps of the off-chain computation process are verified through on-chain validation. This achieves an effect similar to Ethereum Rollups like Arbitrum. Furthermore, SatoshiVM employs zkEVM as the execution environment to generate ZK Proofs, which are submitted to off-chain validators for verification, thereby reducing the computational pressure and bandwidth consumption of nodes. To address censorship resistance issues, SatoshiVM also proposes the SVMZK scheme to achieve censorship resistance for the sequencer.

## Community-driven <a href="#community-driven" id="community-driven"></a>

SatoshiVM is a community-driven project, and we look forward to achieving long-term stability and development of the protocol through the collaborative efforts of the community and the project. We firmly believe that community engagement and cooperation are key to the project's success.

SatoshiVM places a strong emphasis on early users and collaboration with ecosystem partners. We encourage their active contribution to the project. In SatoshiVM's Tokenomics and future decision-making, we will always prioritize the interests of all community participants. We are committed to establishing an open and transparent community to ensure fairness in the decision-making process, while fully respecting the community's voice, aiming for mutual long-term success.


# Layer2 Overview


# Architecture

Achieving technological breakthroughs and translating theory into practical applications has always been a challenging and formidable task. This holds particularly true for SatoshiVM as we embark on the development of a Bitcoin ZK Rollup Layer 2 solution.

In our pursuit of this ambitious goal, security takes precedence. To better drive the project forward, we've divided the technical development process into two key phases: [Alpha Mainnet](/satoshivm/layer2-overview/architecture/alpha-mainnet) and [Mainnet](/satoshivm/layer2-overview/architecture/mainnet). The developmental objectives for the Alpha Mainnet phase include minimizing system operation, developing, adapting, and integrating various components of SatoshiVM ZK Rollup. In the subsequent Mainnet phase, we aim to transform the on-chain validation part into Taproot scripts, perform the circuit conversion of the off-chain Prover and Verifier components, and implement Anti-Transaction Reordering based on SVMZK.

Simultaneously, at different stages of development, we will introduce corresponding Testnets, serving as a sandbox for comprehensive functionality and performance testing. This strategic approach ensures the reliability and stability of the system before major updates are implemented.

To delve deeper into the intricacies of each phase, the following sections will provide a more detailed explanation of the technical architecture designs. This added context aims to offer a thorough understanding of our meticulous development process.


# Alpha Mainnet

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FhANP28l6EvstPDWSgnap%2Fstage2-architecture.jpg?alt=media&amp;token=e4386ea5-c076-42f5-9cc7-894c4ecfd2c4" alt=""><figcaption></figcaption></figure>

### Transactions

* Deposit transactions: Pledge BTC on Bitcoin to the provided DHC on Bool Network for custody.
* Withdraw transactions: Initiate on SatoshiVM and receive the corresponding amount of BTC on Bitcoin.
* General transactions: Include regular transfers and interactions with contracts on SatoshiVM.

### Execution Layer

* Execution module: Handle deposit and withdraw transactions between Bitcoin and SatoshiVM, process general transactions in the SatoshiVM mempool, and construct new SatoshiVM blocks.
* Rollup module: Monitor the creation of new SatoshiVM blocks and compile the corresponding transaction data in a batch.
* Prover module: Monitors the generation of new SatoshiVM blocks and produces corresponding proofs.

### Settlement Layer

* Dynamic Hidden Committee (DHC): Securely custody assets on Bitcoin based on ZKP, MPC, and TEE technologies.
* Data Availability module: Securely store and make available the data generated within SatoshiVM.
* Verification contract: Verify the validity of transactions in SatoshiVM blocks through a batch of transaction data and corresponding proofs.
* Forced Exit contract: Ensure that, in extreme situations, the withdrawal of assets on the Bitcoin chain can be achieved through proofs provided by users and data already published in the DA layer.


# Mainnet

SatoshiVM is a decentralized Bitcoin ZK Rollup Layer 2 solution compatible with the Ethereum Virtual Machine (EVM) ecosystem, using native BTC as gas. Empowered with the ability to connect both Bitcoin and EVM ecosystems, it seamlessly merges the value anchoring of BTC with the programmability of EVM, bringing infinite possibilities to the evolution of the new ecosystem.

Currently, SatoshiVM's technological approach integrates the following concepts:

1. **ZK Rollup**: SatoshiVM utilizes Rollup technology to bundle multiple transactions into a single batch, which is then submitted to a Rollup Node for verification as a single transaction.
2. **ZK Verification**: Based on the BitVM framework, SatoshiVM introduces an enhanced scheme that does not rely on the challenge-response protocol. Without altering Bitcoin's consensus rules, it uses Taproot scripts to verify the execution of any function. This method effectively ensures the validity of transactions within SatoshiVM.
3. **Data Availability**: SatoshiVM needs to send block transaction data to the BTC mainnet, allowing anyone to independently verify the accuracy of computations performed on Bitcoin.
4. **BTC Native Gas**: Similar to how Ethereum OP Rollup/ZK Rollup Layer 2 solutions use ETH as Gas for the second layer, SatoshiVM uses BTC as Gas for EVM transactions.

The overall technical architecture of SatoshiVM is as follows:

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F7OzxRGJ1MNS7ahMbWqys%2Fimage%201.png?alt=media&amp;token=04130098-0e6c-47cc-a345-ba481da7f3d4" alt=""><figcaption></figcaption></figure>

## **Sequencing Layer**

Similar to the ZK Rollup on Ethereum, the architecture of SatoshiVM also includes divisions similar to execution and settlement layers. **The Sequencing Layer depicted above is analogous to the Execution Layer in Ethereum's Rollup**, encompassing the most critical components within the Layer 2 network.

The Execution module in the diagram is similar to Ethereum Layer 2's Sequencer, centrally receiving and processing user transactions to generate new Layer 2 blocks or transaction batches. The Rollup node, as illustrated, can be further divided into two categories: **ordinary Layer 2 full nodes and Proposers**.

In the designs of Ethereum Layer 2 and SatoshiVM, there is a certain degree of cooperation between the Proposer and the Sequencer. After the Sequencer has processed a batch of transaction commands, the Proposer attempts to synchronize the content of these transactions. In the design of Ethereum Layer 2, the data synchronization process can occur off-chain immediately or wait until the Sequencer publicly discloses the transaction content on-chain, at which point the Proposer can download it locally.

In the scheme of SatoshiVM, the additional data synchronization between the Sequencer and Proposer can occur off-chain or after the Sequencer publishes the data on the Bitcoin chain, at which point the Proposer can actively download it locally. It is important to emphasize that both the Sequencer and Proposer need to run Bitcoin nodes, meaning they must synchronize with the latest Bitcoin blocks for the Layer 2 system to operate smoothly.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FB3faXwilwAhK79cz2Ppu%2Fimage%202.png?alt=media&amp;token=67a376ae-e983-4b4c-af3b-f62a05bfb8e5" alt=""><figcaption></figcaption></figure>

Before releasing new transaction batches to the public, the Sequencer in SatoshiVM fixes their order. After completing the transaction sequencing, the following actions are triggered:

1. **Sequencer Executes Transactions**: The Sequencer executes transactions and completes state updates locally.
2. **Packaging Transaction Data**: The transaction data is packaged into a transaction batch (txn batch) / Block and sent to the Proposer (this step is optional) and the Prover.
3. **Uploading Transaction Batches to Bitcoin Chain**: The Sequencer uploads the transaction batch to the Bitcoin chain. The Proposer downloads this data locally and completes the state update.
4. **Publishing State Commitment**: The Proposer publishes the updated State commitment (State root) to the Bitcoin chain.
5. **Responding to Challenges**: If someone challenges the Commitment, the Proposer needs to respond to the Challenger's challenge.

It's worth noting that, similar to most Layer2 solutions, SatoshiVM's Sequencer uses a private mempool, meaning that, similar to mainstream Ethereum Rollups like Arbitrum, SatoshiVM does not make transaction data in the transaction pool public. The SatoshiVM Sequencer can guarantee the generation of a new Block off-chain every 3 to 60 seconds, regardless of whether new transaction requests have been submitted.

### **Censorship-Resistant Scheme for User Transactions**

Currently, users can submit transaction requests to the Sequencer in two ways:

1. **Direct Submission on Layer1**:

SatoshiVM allows users to directly publish transaction data in a specific format on the Bitcoin chain. Layer2 nodes synchronize Bitcoin blocks and search for transactions published by users in the specific format. If the Layer2 Sequencer ignores transaction requests published by some users, the new blocks it generates off-chain cannot pass the verification by Rollup nodes and Proposers. SatoshiVM achieves censorship resistance through this method.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FCsAX2YEjKqwFGnQ8IWdu%2Fimage%203.png?alt=media&amp;token=1ce785de-87ee-47b2-8c83-f257753042c4" alt=""><figcaption></figcaption></figure>

2. **Direct Submission within the Layer2 Network**

This method is more mainstream, where users directly send their transaction requests to specified RPC nodes via RPC calls, which then forward the requests to the Sequencer. This way of submitting transactions is much less costly than publishing transaction data directly on Layer1, but it might be subject to censorship or rejection by the Sequencer.

It is widely believed that the first method of transaction delivery can make Layer2 as censorship-resistant as possible, similar to Layer1. However, due to Bitcoin's inability to support full-fledged smart contract functionality, Bitcoin Layer2 solutions cannot include user transaction requests in a Layer1 Rollup contract like Ethereum Layer2 can. Specifically, Ethereum Layer2 can deploy fixed Rollup contracts directly on Layer1 to manage Layer2 ledger data and also directly incorporate user-submitted transaction requests, but current Bitcoin Layer2 solutions cannot adopt this approach.

SatoshiVM's transaction censorship-resistant scheme has essentially achieved the highest level of censorship resistance possible within Bitcoin Layer2. This technological approach is also employed by well-known Bitcoin Layer2 projects.

### **Rollup Node and Proposer**

As previously mentioned, a Rollup node is essentially a standard full node within Layer2, whereas a Proposer is a select few nodes among these full nodes with special permissions. SatoshiVM's Rollup nodes and Proposers can synchronize newly added transaction data from the Sequencer through the following two methods:

1. **P2P Network among Rollup Nodes**: Rollup nodes form a P2P network under the Bitcoin chain, where each node can directly request the latest Layer2 new blocks propagated by the Sequencer from its neighbor nodes in the P2P network to learn about the latest batch of transaction requests. This step is not mandatory; Rollup nodes can choose whether or not to synchronize data in this way voluntarily.
2. **Waiting for Sequencer to Publish on Layer1**: Rollup nodes can wait for the Sequencer to finish publishing the latest transaction batch (txn batch) on Layer1 and then parse the latest few Layer2 blocks from it. Compared to obtaining data directly in the off-chain P2P network, this method is slower but offers stronger censorship resistance. In some scenarios, the Sequencer or the majority of Rollup nodes could isolate certain nodes, preventing them from smoothly synchronizing data. However, if the Sequencer regularly publishes data on the Bitcoin chain, anyone can download and synchronize it, allowing isolated nodes to bypass other Layer2 nodes and successfully synchronize the data.

After a Proposer node synchronizes a batch of ordered transactions, it executes them in sequence to complete the corresponding state transitions, resulting in new state commitments (State root). We will detail the specific meanings and generation processes of commitments and State root later in the text.

For now, let's briefly explain that state commitments are characteristic values summarizing the status of all accounts. A change in the status of any account will cause a related change in the state commitments. The global state at different moments corresponds to different state commitments, with a one-to-one mapping relationship between the two.

The Proposer is responsible for publishing the Commitment, derived from off-chain computations, onto the blockchain. (For a more detailed explanation of State root and the Proposer, refer to the L2BEAT website).

In the design of SatoshiVM, certain nodes within the Rollup node act as Proposers, promptly publishing the commitment corresponding to each transaction batch (Txn Batch) to the Bitcoin blockchain.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2Fqu5wKvsJYtBGHjivGAUW%2Fimage%204.png?alt=media&amp;token=d7542f03-730d-45f8-bbfc-d2b810ccd22d" alt=""><figcaption><p>Source: <a href="https://l2beat.com/scaling/projects/arbitrum#permissions">https://l2beat.com/scaling/projects/arbitrum#permissions</a></p></figcaption></figure>

## **Settlement Layer**

In a modular blockchain architecture, the settlement layer is fundamentally crucial. According to Celestia's official perspective, the settlement layer encompasses two main functions: state transition verification and bridging components. Essentially, the settlement layer ensures that off-chain state updates in Layer 2 are valid and secures asset transfers between L1 and L2. Some technical teams further break down the settlement layer into arbitration and bridging layers. The arbitration layer is the module that verifies the commitment.

As previously mentioned in the SatoshiVM proposal, Proposer nodes regularly submit State Commitments to the Bitcoin chain, representing the completion of numerous off-chain transaction executions in Layer 2 and the attainment of a new state. State Commitment publication and ZK proof generation occur concurrently, with ZK proofs released in the form of Taproot-locked UTXOs on the BTC mainnet.

SatoshiVM employs a non-interactive on-chain validation scheme. Once a Proposer submits a Commitment on the BTC chain, Verifier nodes on the Bitcoin chain observe this Commitment value and off-chain attempt to acquire the complete original data set corresponding to the Commitment to verify its integrity. If errors are detected, Verifiers can initiate a one-time interaction to involve Bitcoin nodes directly, identifying specific errors within the original dataset associated with the Commitment submitted by the Proposer. Subsequently, the Verifier can transfer the Proposer's Bitcoin UTXO as a punishment.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FCgY8Ety8bl1PCqksLVnu%2Fimage%205.png?alt=media&amp;token=38379ee7-3e3d-4a53-9577-2c4f165b73f1" alt=""><figcaption></figcaption></figure>

It's important to note that unlike bitVM, SatoshiVM's single-time interactive penalty mechanism isn't based on a challenge-response mechanism. Verifiers can ascertain whether the Proposer engaged in malicious behavior in one interaction and immediately enforce penalties. This is achieved through the technical features of Taproot Script and time locks. External observers, apart from the Proposer and Verifier, can retrospectively observe the movement of specific UTXOs on the Bitcoin chain to determine the validity of Commitments. Once a Commitment is finalized, it becomes immutable. SatoshiVM employs this approach to inherit Bitcoin's finality for Layer 2 ledger data. Further details and the specific role of Commitments will be elaborated below.

We can understand the entire process as follows: The Sequencer informs everyone that the next transaction should compute "1+1=?". After receiving this message, each Rollup Node automatically computes "1+1=2" locally. Some nodes in the Rollup Node are predetermined by the system to be Proposers, and a Proposer is deemed obligated to announce to everyone on the Bitcoin chain that the next Layer2 state should be "2".

The Proposer submits the hash value of "2" on the Bitcoin chain, indicating that this is the result of hashing the current state of Layer2. Along with submitting the hash value, the Proposer also provides a ZK proof of the computation process in the form of Taproot-locked UTXOs, allowing anyone to verify the correctness of the current Layer2 state through the spending of the relevant UTXOs.

## Proving Layer (Circuits)

The Proving Layer is responsible for generating ZK Proofs and submitting them to the Sequencing Layer. Members within this layer mainly act as Verifiers to maintain the security of SatoshiVM, preventing the Sequencing Layer from acting maliciously. The Sequencing Layer sends L2 blocks to the Prover within the Proving Layer. The Prover generates ZK proofs and submits them to the Proposer.

Additionally, the Sequencer/Execution Node transmits the latest Layer2 blocks to the Prover node, allowing the latter to sync the latest Layer2 transaction records, know the latest state changes, and generate the corresponding ZK Proof. Simultaneously, the Sequencer and Rollup nodes also store the complete ledger data and global state of Layer2 locally.

After obtaining ZK proofs from the Prover, the Proposer will verify them. The verification process's corresponding Commitment is publicly posted on the BTC mainnet and downloaded by the Verifier for local verification. If verification reveals problems, challenges can be initiated through bit commitments Taproot and verification Taproot.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FraaHDjXY86DIGpMILdX1%2Fimage%206.png?alt=media&amp;token=6353059c-de11-4750-8873-c257e6cb3598" alt=""><figcaption></figcaption></figure>


# Commitment and Verification on Bitcoin

Here, it's important to emphasize the meaning and role of Commitment. In the technical schemes of BitVM, the Commitment is a significant element. For instance, suppose someone questions a transaction/state transition processed off-chain, demanding direct inspection of the disputed transaction/state transition result on the Bitcoin blockchain. This requires the parties involved to temporarily upload part of the data to the Bitcoin blockchain, where Bitcoin nodes act as "judges" to adjudicate the dispute. Within SatoshiVM, however, the Proposer sends the ZK circuit execution results to the BTC chain at once, further verified by the Verifier. However, the issue lies in how we ensure that the data temporarily uploaded by the parties is what the SatoshiVM Verifier needs, rather than random gibberish or other forms of junk data. To address this, a mechanism needs to be designed to allow Bitcoin nodes to independently determine whether the off-chain data submitted to the chain is relevant to the dispute at hand. This relies on some specific properties of Commitment.

The function of Commitment is as follows: The Proposer can periodically publish Commitment on the Bitcoin blockchain, which is associated with a series of state transitions/transaction processes that occur off-chain. In other words, the Commitment maps a large volume of off-chain data. Despite this, the Commitment itself is concise; even if associated with thousands of transactions/state transitions, the size of the Commitment can be very small. It can be roughly understood as a hash of a large batch of off-chain data (the actual situation is more complex than this analogy).

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FxzomTwIu8BdWQoaaKbnZ%2FCommitment%20and%20Verify%20on%20Bitcoin_1.png?alt=media&amp;token=180ce5eb-ce81-4ebb-8048-9abb837bf6ed" alt=""><figcaption><p>Source: <strong>Altoros</strong></p></figcaption></figure>

In blockchain-related scenarios, it's common to hash original data and use the hash value as a Commitment, publishing it on a designated platform. Taking some Layer2 projects in the Ethereum ecosystem as an example, after processing a batch of transactions off-chain, the Sequencer might not directly send the transaction data to the Ethereum blockchain. Instead, the Sequencer publishes the hash value of the new data (datahash) on-chain as a commitment, while the raw data corresponding to the datahash is published off-chain.

If someone cannot obtain the original dataset corresponding to the datahash from off-chain, they will request the Sequencer to disclose the data directly on the Ethereum blockchain. The datahash previously published on-chain as a Commitment then serves its purpose: after the Sequencer publishes the data on-chain, smart contracts or third-party observers can immediately determine whether the data corresponds to the datahash. This example illustrates a simple case of how a Commitment becomes effective. Light nodes or cross-chain bridge projects often use Merkle Proof and Merkle root, another form of Commitment, which has a broader range of applications. This will not be elaborated on here.

In the design of SatoshiVM and mainstream Ethereum Layer2, the Proposer periodically aggregates a large batch of transactions and state change data processed off-chain, generating a Commitment and then publishing this Commitment to the Bitcoin blockchain. This is equivalent to publishing a summary compression value of a large batch of off-chain data to the Bitcoin blockchain, significantly reducing the size of the data uploaded to the chain.

Generally, after a Commitment is submitted, it needs to be verified. For Ethereum Layer2, the Ethereum blockchain can run complex smart contracts that can verify the ZK Proof associated with the Commitment through smart contracts, determining whether the newly submitted Commitment is valid. If valid, the smart contract updates the recorded Layer2 State root. If the submitted ZK proof fails the smart contract's verification, we consider this state update invalid, reject this Commitment, and refuse to update the State root.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FRQG2JAR36P33w000FAnA%2FCommitment%20and%20Verify%20on%20Bitcoin_2.jpeg?alt=media&amp;token=fabe3293-d297-4e0f-a259-89817f3906a5" alt=""><figcaption><p>Source: <a href="https://hacken.io/discover/zk-rollups-explained/">https://hacken.io/discover/zk-rollups-explained/</a></p></figcaption></figure>

On the Bitcoin (BTC) blockchain, it's not possible to implement a Turing-complete smart contract system, so many scenarios cannot be directly realized. For example, it's currently not feasible for programs on the Bitcoin blockchain to directly verify the validity of ZK Proofs. This would require forking the Bitcoin mainnet to support new opcodes. Under the current circumstances, if Layer2 is to inherit the security of Layer1, or for Layer1 to guarantee the validity of Layer2 state updates, it would rely on an on-chain, trigger-based challenge mechanism.

As mentioned earlier, the Proposer will publish the state change Commitment to the Bitcoin blockchain. Generally, we optimistically assume that the Commitment submitted by the Proposer is correct, and the associated off-chain data is also without issues. However, we also allow anyone to question if there are problems with the Commitment and its associated data. The process of initiating a challenge and presenting evidence on-chain to prove that some data associated with the Commitment is problematic is known as a challenge.

In the BitVM scheme, a user challenging a particular Commitment needs to initiate a Challenge against the result of an off-chain state transition. The Proposer can find the complete dataset corresponding to the Commitment in the off-chain storage layer and select the data indicated by the Challenger to be sent on-chain.

Of course, both parties can determine which Commitment value is problematic through multiple rounds of interactive communication, then through on-chain and off-chain interaction and communication, pinpoint the extremely small data fragment associated with the problematic Commitment. The Proposer can then disclose this small piece of data on the Bitcoin blockchain, thus avoiding the need to disclose too much data at once.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FIELySRAvDZCfVXpaExG3%2FCommitment%20and%20Verify%20on%20Bitcoin_3.png?alt=media&amp;token=a5783f5e-6762-447c-b882-e1cc17793969" alt=""><figcaption><p>Source: <strong>Zerocap</strong></p></figcaption></figure>

Once both parties have determined which specific data is problematic, the next step involves using Bitcoin scripts to directly verify the newly submitted data on the Bitcoin blockchain to determine if there are any issues. If issues are found, it indicates that the node which published the Commitment released an incorrect commitment, demonstrating fraudulent behavior, and should be penalized.

If a Commitment remains unchallenged, it will inevitably be finalized. Once a Commitment is finalized, the large batch of off-chain data associated with it will also be finalized and become irreversible. Through this method, SatoshiVM can ensure that the ledger data has the same irreversibility as the Bitcoin mainnet.

Unlike BitVM, SatoshiVM significantly simplifies the process of "multiple rounds of interaction to confirm which small piece of data is problematic," requiring only one round of interaction to complete the verification process. In BitVM and Arbitrum, this process could last several hours.

The scheme where users initiate challenges and question the correctness of a Commitment is known as challenge-response protocol. When a Commitment is successfully challenged, it will be annulled on the Bitcoin chain, and SatoshiVM's off-chain Proposer node will propose a new state commitment, submitting it to the chain. Since the submission of state commitments is unilaterally determined by the Proposer and not bound to the transaction data published off-chain and on-chain by the Sequencer, even if a State Commitment is challenged and annulled, the transaction order already determined off-chain by SatoshiVM will not change. As long as the transaction order observed by each node remains unchanged, their local record of the current state will not change.

This is analogous to the Sequencer informing everyone in advance that the next transaction will calculate “1+1=?”. After receiving this transaction, each Rollup Node directly computes the correct result = 2. If a Proposer declares a hash on the Bitcoin chain, claiming this hash corresponds to the result of 1+1, but in reality, this hash corresponds to the number 3, then a node will initiate a challenge.

However, the Commitment published on the Bitcoin chain does not affect the Rollup node's own judgment. It merely means that the system will periodically disclose the current state hash (Commitment) on the Bitcoin chain, using Bitcoin as a log for Layer2's history. Once the state hash/Commitment is finalized on the Bitcoin chain, all past historical records are assumed to be irreversible.

A new node joining the Layer2 network only needs to review the historical data on the Bitcoin chain, parse out the transaction data and state hashes processed in Layer2 history, and can then catch up with the pace of other Rollup nodes, knowing the latest Layer2 state without relying on other Rollup Nodes to provide historical data. This essentially uses Bitcoin as a large bulletin board.


# Asset Bridge

Previously, we mentioned that users initially need to transfer assets to SatoshiVM to pay for transaction fees when initiating transaction requests within the Layer2 network. The bridging module of SatoshiVM is quite straightforward, currently mainly divided into deposit and withdrawal components.

### Assets Moving from Bitcoin to SatoshiVM Mainnet

In SatoshiVM terminology, transferring funds from Bitcoin (L1) to the SatoshiVM mainnet (L2) is called a deposit. Users need to transfer bitcoins to a deposit address specified by SatoshiVM. Once a deposit transaction is triggered on Layer1, the Layer2 Sequencer detects these deposit actions and subsequently incorporates them into Layer2 blocks, releasing an equivalent amount of assets to the user within the Layer2 network. Typically, such deposit transactions are processed within minutes after the Layer1 block is finally confirmed, generally waiting for the time equivalent to 6 Bitcoin blocks.

### Assets Moving from SatoshiVM Mainnet to Bitcoin

Compared to deposit transactions, withdrawing assets from L2 to L1 is more complex. Similarly to deposit transactions, any asset transfer from L2 to L1 is referred to as a withdrawal transaction.

Withdrawal transactions involve the following three steps:

1. The user initiates a Layer2 transaction, declaring a withdrawal and specifying the amount to be withdrawn.
2. After the Layer2 block containing this withdrawal transaction is finally confirmed, the user submits a withdrawal proof on Layer1, requesting the withdrawal of an equivalent amount of assets from a publicly managed account.
3. Waiting for the withdrawal challenge period to end (which can take several hours).


# BitVM and SatoshiVM Circuit

SatoshiVM adopts BitVM's approach to verifying arbitrary computations on the Bitcoin blockchain: using the primitive, non-Turing-complete Bitcoin Script code to simulate the effect of logic gate circuits, then utilizing a massive amount of logic gate circuits to achieve the functionality of complex virtual machines.

We know that computers/processors are input-output systems composed of a large number of logic gate circuits. BitVM attempts to simulate the input-output effect of logic gate circuits using Bitcoin Script. As long as the logic gate circuits can be simulated, in theory, it is possible to realize a Turing machine, completing all computable tasks.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FQQ9YTLvqaUqHdeVxJMS8%2FBitVM%20and%20SatoshiVM%20Circuit%20-%201.jpg?alt=media&amp;token=1ca5f4cf-cae1-4d30-8f19-28d9e32bf022" alt=""><figcaption></figcaption></figure>

In the interactive fraud proof protocol of Arbitrum, the disputing parties engage in multiple rounds of communication to continually subdivide a particular transaction instruction until they localize a disputed opcode. Then, this opcode, along with its input and output results, is executed directly on the Ethereum blockchain for verification. This process determines which party's claim is correct and penalizes the malicious party.

In the Bitcoin and BitVM schemes, due to the simplicity of Bitcoin Script, it's not feasible to directly verify EVM opcodes as done in Ethereum Layer2 solutions. Therefore, an alternative approach is employed: opcodes compiled from any high-level language are decoded again into the form of logic gate circuits. Then, Bitcoin Script is used to simulate the operation of these logic gate circuits. This allows for the indirect simulation of the operational effects of virtual machine opcodes, such as those of the EVM, on the Bitcoin blockchain. We can consider the logic gate circuits as an Intermediate Representation (IR) between EVM opcodes and Bitcoin Script opcodes.

SatoshiVM employs the `Bristol format` to illustrate its logic gate circuit structure. The `Bristol format` is a commonly used method in the field of circuit for expressing logic gate circuits. In essence, it provides a standardized way to describe the layout of complex logic gate circuits, including the inputs and outputs of digital circuits, the functions of logic gates (such as AND, OR, NOT gates), and their specific connections.The Bristol format typically includes the following parts:

1. Circuit Size Information: Describes the basic attributes of the circuit, such as the total number of logic gates, the number of input and output signals, etc.
2. Input and Output Information: Provides detailed information about the assignment of each input and output signal.
3. Gate Description: Gives a specific description of the function of each logic gate, including the gate type (AND, OR, NOT, etc.) and its connected input and output signals.

Here is an example of Bristol format code:

```VHDL
4 7
1 3
1 1
1 1 0 1 INV
2 1 1 2 4 AND
1 1 4 5 INV
2 1 3 5 6 AND
```

The visualization of the aforementioned `Bristol format` circuit is as follows:

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FGnF7xVRug5YADpq9cJlF%2FBitVM%20and%20SatoshiVM%20Circuit%20-%202.png?alt=media&amp;token=df330dbf-4468-4160-8949-02558d16fc96" alt=""><figcaption></figcaption></figure>

The components are as follows:

* The first line's `4`,`7` respectively indicate that this part of the circuit has 4 logic gates and 7 signal lines.
* The first number in the second line represents the bit size of the circuit's input signals, and the second number represents the quantity of input signals. For example, in the case above, it includes a one-bit input, but the input signals comprise three separate inputs `(0)`, `(2)`, and `(3)`.
* The first number in the third line indicates the quantity of the circuit's output signals, and the second number represents the bit size of the outputs. In the case above, it contains one output, which only includes a single digit `(6)`.
* Apart from the above three lines, the rest of the content specifically defines each logic gate and signal line within the circuit, listing the following details for every logic gate:
  * The number of input signal lines
  * The number of output signal lines
  * The identifiers for the input lines
  * The identifiers for the output lines
  * The function of the logic gate

For example, `1 1 0 1 INV` indicates that the logic gate has one input line, one output line, the input line identifier is `(0)`, the output line identifier is `(1)`, and the logic gate operation is `INV`. This effectively describes gate A in the aforementioned example circuit.&#x20;

A more complex case like `2 1 3 5 6 AND` indicates that the logic gate has two input lines, one output line, the input line identifiers are `(3)` and `(5)`, the output line identifier is `(6)`, and the logic gate operation is `AND`. This actually defines `gate D` in the example circuit. We can also represent `gate D` with the mathematical formula $$w\_6 = \text{AND}(w\_3, w\_5)$$.&#x20;

In this document, we only use `INV` and `AND` logic gates. `INV` represents the `NOT` operation, and it operates according to the following rule:

| Input | Output |
| ----- | ------ |
| 0     | 1      |
| 1     | 0      |

The `AND` logic gate represents the AND operation, and it operates according to the following rule:

<table><thead><tr><th>Input 1</th><th width="148">Input 2</th><th>Output</th></tr></thead><tbody><tr><td>0</td><td>0</td><td>0</td></tr><tr><td>0</td><td>1</td><td>0</td></tr><tr><td>1</td><td>0</td><td>0</td></tr><tr><td>1</td><td>1</td><td>1</td></tr></tbody></table>


# Preimage Commitment

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FFCttitF35YsY298WuSUK%2FPreimageCommitment_1.png?alt=media&amp;token=4f773a44-1f54-4e67-b61c-c27a62723577" alt=""><figcaption></figcaption></figure>

The Preimage Commitment is an important cryptographic primitive in constructing SatoshiVM. Cryptographic primitives refer to low-level encryption algorithms that are mature and often used to build computer security systems.

Preimage Commitment is used to conceal the execution trace of a circuit until the Prover reveals the execution trace preimage to the Verifier. The execution trace refers to all the input and output signal values generated during the circuit's execution process. The preimage is related to hash functions, where if hash(a) = b, we call a the preimage and b the hash value. When the Prover discloses the preimage corresponding to a Preimage Commitment, the Verifier needs to check it to confirm whether it truly complies with the circuit's execution rules.

Consider a specific case, focusing on gate C, which has one input (1) and one output (5), and its function is to perform a NOT operation on its input. Suppose that when the circuit execution reaches gate C, its input value is `value`, as follows:

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FpZUPDdta6dOe6ye2uUV1%2FPreimageCommitment_2.png?alt=media&amp;token=338e6d22-05d5-4c5d-a6f8-d9b9401cb752" alt=""><figcaption></figcaption></figure>

The Prover sends the hash value of the input line (4) value `value` and the output line (5) value `output` of gate B to the Verifier. The Verifier then uses these hash values to construct a script for on-chain verification, which we will discuss in detail later. The hash values of `value` and `output` given here are referred to as the Preimage Commitment. As mentioned before, the purpose of the Preimage Commitment is to prevent the Prover from altering the pre-committed execution path for malicious purposes. Once the Verifier has completed constructing this script, the Prover reveals the values of `value` and `output`.The Verifier has a local program that can verify whether the inputs and outputs disclosed by the Prover comply with the rules of gate B. If the Prover's output does not match the gate's rules, a transaction can be spent to prove the Prover's malfeasance. The script corresponding to this transaction is as follows:

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FVMMG6zkD5JmNQths1L5l%2FPreimageCommitment_3.png?alt=media&amp;token=13174719-9966-4f58-9dd9-92af9a5d2620" alt=""><figcaption></figcaption></figure>

When the Prover behaves maliciously, such as providing an input of `1` but also providing an output of `1`, indicating dishonesty, the Verifier can spend the UTXO locked by the above script to prove that the Prover has acted maliciously. The specific construction of this script will also be discussed later in the document.


# SatoshiVM Scripts and Taproot

In the preceding text, we mentioned the following two scripts:

1. The script for verifying the Preimage Commitment published by the Proposer, referred to hereafter as the **bit commitments Taproot**.
2. The script for verifying whether the execution trace publicly disclosed by the Proposer is correct, referred to hereafter as the **verification Taproot**.

Additionally, both of the aforementioned transactions include an important time-locked leaf. Within Bitcoin scripts, there exists the `OP_CHECKLOCKTIMEVERIFY` opcode, which provides support for time locks. The specific function of a time lock is to determine whether a UTXO needs to be unlocked based on the current block time.&#x20;

For the bit commitments Taproot, the time-locked leaf will restrict the time for the Proposer to submit proofs, thereby preventing the Proposer from delaying the release of data. If the Proposer delays the submission of proofs, the time lock will automatically activate, allowing the Verifier to spend the bit commitments Taproot. For third-party validators, observing the Verifier spending the bit commitments Taproot implies that the Proposer did not submit proofs on time.&#x20;

As for the verification Taproot, the time-locked leaf is used to unlock the UTXO upon expiration, ensuring that funds are not permanently locked in the absence of malfeasance by the Proposer.

Unlike proof systems such as bitVM that require interaction between Prover and Verifier, SatoshiVM can determine the trustworthiness of final execution solely based on the spending conditions and spending time of bit commitments Taproot and verification Taproot. The use of time locks is an important tool for introducing time factors into the verify process. When the bit commitments Taproot fail to unlock within the specified time, it implies malicious behavior by the Prover in earlier commitment stages, rendering the final execution result untrustworthy. Conversely, when the verification Taproot unlocks upon expiration, it signifies that the Verifier did not find any execution errors by the Prover, and the final execution result is deemed trustworthy.

## Bit commitments Taproot

Firstly, let's introduce the bit commitments Taproot. The input to this script consists of the values of each wire in the circuit, denoted by variables such as `input_0` in the following script, with each input corresponding to a verification script, such as `script_0`.

```
Inputs:
input_0
input_1
...
input_n
Scripts:
script_0
script_1
...
script_n
<Prover’s Public Key>
OP_CHECKSIG
```

`OP_CHECKSIG` within the above script is used to verify that the signature entered is the signature of the current transaction. Returns 1 if the signature is correct, otherwise returns 0.

The specific code for each input `input_n` corresponding to `script_n` in the above scripts is as follows:

```Assembly
input_n:
<preimage of a value of wire_n>

script_n:
OP_SHA256
<preimage hash of value 0 of wire_n>
OP_EQUAL
OP_SWAP
OP_SHA256
<preimage hash of value 1 of wire_n>
OP_EQUAL
OP_BOOLOR
OP_VERIFY

```

The function of the above script is to perform a hash calculation on the input and then test for equality with the hash value previously provided by the Proposer within the script. This equality test relies primarily on the `OP_EQUALVERIFY` opcode, which returns `1` if the inputs are equal and invalidates the transaction otherwise. The reason for conducting this equality test is to prevent the Proposer from providing an execution flow that contradicts the pre-committed one.

The above bit commitments Taproot are generated and submitted to the BTC network by the Verifier based on the hash values provided by the Proposer. The Proposer needs to provide the original values for all hash values to spend the UTXO.

It is worth noting that, in addition to the leaf for hash equality checks mentioned above, the bit commitments Taproot also include a time-locked leaf, allowing the Verifier to spend the UTXO corresponding to the bit commitments Taproot after a set block interval. If, within the set block interval, the Prover does not provide inputs that meet the unlocking conditions, we consider that the Prover has acted maliciously when previously disclosing the hash values, and the results of its execution are not trustworthy.

## Verification Taproot

Verification Taproot is used to verify the execution process of a Proposer after they disclose the specific execution trace. It is utilized to confirm whether the Proposer's execution is correct. Taking the NOT logic `gate C` as an example provided in the previous text, the Proposer's execution is considered correct only if the disclosed execution process meets the following conditions:

* Input = 1, output = 0
* Input = 0, output = 1

Additionally, if the Proposer provides the following conditions, it indicates incorrect execution:

* Input = 0, Output = 0
* Input = 1, Output = 1

We translate the two cases of incorrect execution, where `Input = 0 and Output = 0`, into corresponding scripts:

```
Inputs
<preimage of a value of wire_4>
<preimage of a value of wire_5>
Scripts
OP_TOALTSTACK
OP_SHA256
<preimage hash of value 0 of wire_4>
OP_EQUALVERIFY
OP_0
OP_NOT
OP_FROMALTSTACK
OP_SHA256
<preimage hash of value 1 of wire_5>
OP_EQUALVERIFY
OP_0
OP_NUMNOTEQUAL
OP_VERIFY
<Verifier’s Public Key>
OP_CHECKSIG
```

The above scripts first utilize `OP_SHA256` and `OP_EQUALVERIFY` to check whether the input original and the hash value publicly implemented by the Prover are the same, then use `OP_NUMNOTEQUAL` to examine whether both input and output are 0.

Of course, there also exists a script to check if both input and output are 1. When the value of `wire_4` provided by the Prover is 0 while the value of `wire_5` is 0, the Verifier can spend the verification Taproot based on the above script. For all logic gates and their inputs and outputs, the above script can be constructed. Since anyone can run a BTC node to trustlessly obtain BTC block data, besides the Verifier and Prover, third-party protocol participants can monitor block data to obtain spending information of the verification Taproot and determine whether the Prover is malicious based on the spending information.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FGRBznW9MlHLdxRImeT4I%2FSatoshiVM%20Scripts%20and%20Taproot.png?alt=media&amp;token=6cc87ac2-1f95-4884-83c7-074a968af7a7" alt=""><figcaption></figcaption></figure>


# Verification

In the preceding section, we discussed how to construct a verification Taproot for validating a single logic gate. In this section, we will delve into extending the script for verifying a single logic gate to the entire circuit. We will employ a simple principle: the output of each logic gate serves as the input to the next logic gate.

In the diagram below, `(4)` receives the output of `gate B` and acts as the input to `gate C`. Assuming that the output of `gate B` does not match the input of `gate C`, it implies that `(4)` has two possible values, which is evidently incorrect. By using the script provided earlier, we can ensure the correctness of both the input and output of `gate B` and also verify the input and output of `gate C`. Next, by leveraging the property that the input equals the output of `(4)`, it suffices to validate that the output of `gate B` equals the input of `gate C` to ensure the overall correctness of the two logic gates formed by `gate B` and `gate C`. By extension, we can ultimately prove the correctness of the entire circuit.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FHloSa4B0cgHsbm30PVbn%2FVerification_1.png?alt=media&amp;token=96ffef33-f093-49ae-ae75-b3dcd441a643" alt=""><figcaption></figcaption></figure>

If the Prover violates this rule, we can easily identify issues within the circuit. As shown in the diagram below, if the Prover assigns different values to `(4)`, the Verifier can readily detect this problem and declare the entire circuit invalid.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F2DZrVGXVlxqqZKDLnXKw%2FVerification_2.png?alt=media&amp;token=94888ad8-afee-4f62-84fb-720dcdc5660f" alt=""><figcaption></figcaption></figure>

In summary, the Verifier constructs all possible scenarios of logic gate malfunctions within the Verification Taproot. The Verifier only needs to detect a single logic gate malfunction off-chain to construct a spending Taproot unlocking script. Clearly, this is a non-interactive approach.


# Framework Visualization

The complete process of SatoshiVM operation is illustrated in the diagram below. Here, there is a mention of third-party verifiers. These verifiers do not directly participate in the validation process but determine whether the Prover is acting maliciously based on the execution on-chain. The majority of regular users belong to the third-party verifiers.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F39DF8g6dvxrolxfNYA6r%2FFramework%20Visualization_1.png?alt=media&amp;token=3cfa7241-e3c8-4b69-a503-2f5baa4c5b1a" alt=""><figcaption></figcaption></figure>

The diagram below outlines the overall process of block validation in SatoshiVM:

Step 1: The Prover obtains the L2 block to be verified from the sequencer and generates a ZK proof for it, which is then validated. Due to the potential collusion between the Prover and the sequencer, even if the Prover successfully validates the ZK proof, other participants will not accept this result. Therefore, the Prover needs to further validate this ZK proof within the public network.

Step 2: During the public ZK proof verification process, the Prover needs to send the hash values of all wires in the circuit of the ZK proof verification to the Verifier.

Step 3: The Verifier constructs bit commitments Taproot and verification Taproot based on the hash values sent by the Prover. The former is used to determine whether the Prover's commitment to ZK proof verification is complete, while the latter is used to determine whether the Prover has executed correctly.

Step 4: The Prover reveals the preimage of the hash values and uses it to spend the bit commitments Taproot, which means the Prover publicly discloses the process of verifying the ZK proof.

Step 5: The Verifier judges whether the execution given by the Prover is correct based on the publicly disclosed execution trace. If incorrect, the verification Taproot is spent.

Step 6: Time lock is unlocked, and the unspent bit commitments Taproot or verification Taproot are unlocked and spent.

Step 7: Third-party verifiers determine whether the Prover is acting maliciously based on the spending status of the bit commitments Taproot and verification Taproot. The rules for third-party verifier judgment will be provided in the next section.

In the preceding text, we mentioned the use of time locks. The diagram below illustrates the sequential execution process of the Prover and Verifier based on time:

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FqLvIHmS6y5qAkxGJmwbK%2FFramework%20Visualization_2.png?alt=media&amp;token=243e2958-0f64-4223-a29c-abce0f80b234" alt=""><figcaption></figcaption></figure>

The entire proof process is divided into two parts. The first part involves the Prover proving that the execution flow they have published is complete and consistent with the Preimage Commitment, primarily relying on bit commitments Taproot. The Prover spends bit commitments Taproot to prove that the execution flow they have published is complete. However, the Prover may intentionally delay the release of raw data, leading to inefficient system execution. To prevent this scenario, we embed time locks within the bit commitments Taproot. If the Prover fails to provide the raw data on time, they are directly considered malicious. Once the time lock expires, the Verifier can spend the bit commitments Taproot.

The second part involves the Verifier verifying that there are no issues with the execution flow published by the Prover. The Verifier can spend verification Taproot to prove that there are issues with the Prover's execution process. However, if the Prover executes correctly, the verification Taproot will not be spent by the Verifier. To prevent verification Taproot from being permanently locked within the BTC network, we also embed time locks within verification Taproot. Once the time lock expires, we assume that the execution flow published by the Prover is correct. At this point, the Prover can spend the verification Taproot.


# Third Party Verification

In the previous text, we have detailed the composition of bit commitments Taproot and verification Taproot, and what their being spent signifies, thereby allowing third-party verifiers to determine directly by observing BTC transactions whether the Prover has acted maliciously.

The specific verification process is as follows:

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FdfdyUDeVITqbWCAXd9ID%2FThirdPartyVerification_1.png?alt=media&amp;token=60131931-c0f2-439c-a3c0-8bccf6f30f4c" alt=""><figcaption></figcaption></figure>

First, observe the spending of the bit commitments Taproot. If the bit commitments Taproot is spent by the Prover, one can proceed to observe the spending of the verification Taproot. If the bit commitments Taproot is spent by the Verifier, it proves that the execution process disclosed by the Prover is inconsistent with the commitment, and it can be directly assumed that the Prover has acted maliciously.

Second, observe the spending of the verification Taproot. If the verification Taproot is spent by the Verifier, it indicates that the execution process provided by the Prover contains errors, and the Prover can be directly considered to have acted maliciously. If the verification Taproot is spent by the Prover, it indicates that there are no errors within the execution process.


# BTC Connect

## Account Abstraction with BTC Connect

Built by [Particle Network](https://particle.network), BTC Connect is the [first account abstraction protocol for the Bitcoin ecosystem](https://blog.particle.network/btc-connect-bitcoin-account-abstraction), unifying the experience between smart accounts on Bitcoin Layer-2s and standard BTC accounts through existing wallet interfaces.

BTC Connect achieves this by allowing users to connect to your application with a native Bitcoin wallet (such as UniSat, OKX, Bitget, TokenPocket, etc.) Upon connecting, a smart account will be generated and assigned to their BTC account using custom ERC-4337 AA infrastructure deployed natively on SatoshiVM. This smart account can then be used and authenticated directly through their native Bitcoin wallet, allowing for a central interface for users across both Bitcoin Layer-1 and Bitcoin Layer-2s.

Using BTC Connect, you'll have the ability to craft a user experience akin to the example video below.

![](https://i.imgur.com/AF8sRyl.gif)


# Guide Overview

Currently, BTC Connect is live on the SatoshiVM Testnet and can be used through its corresponding JS library, `@particle-network/btc-connectkit`. This document will go through the process of implementing BTC Connect within an application built on SatoshiVM.

Integrating BTC Connect can generally be done in under 50 lines of code. This example will break the process into three key steps:

1. Configuring and initializing BTC Connect (`@particle-network/btc-connect`) within a standard `create-react-app` project.
2. Initiating wallet connection (and assigning a smart account on SatoshiVM).
3. Executing both EVM and BTC transactions (through the same wallet interface).


# Integrating BTC Connect

As mentioned, the process of integrating BTC Connect starts with configuration.

Before jumping in, it's important to note that this example will follow a `create-react-app` structure; thus, we'll repeatedly refer to the following files within this guide:

* `index.tsx`, our central location for the configuration of BTC Connect.
* `App.tsx`, the central component containing our core application logic (wallet connection and transaction execution).

To begin, we'll need to install several required and optional dependencies, as will be covered below.

### Setup: Dependencies

BTC Connect can be integrated and utilized solely through one SDK, `@particle-network/btc-connectkit`. This library is responsible for handling all three steps of our example application. For the sake of programmatic simplicity, we'll be using a combination of the following libraries:

* `@particle-network/btc-connectkit`, the aforementioned key library for using BTC Connect.
* `@particle-network/chains`, for connecting to SatoshiVM.
* `@particle-network/aa`, to simplify interaction with the associated smart account.
* `ethers`, used hand-in-hand with `@particle-network/aa` to streamline the means of transaction execution.

To install these libraries, you'll need to run one of the two commands highlighted below at the root of your project:

```shell
yarn add @particle-network/btc-connectkit @particle-network/chains @particle-network/aa ethers


# OR


npm install @particle-network/btc-connectkit @particle-network/chains @particle-network/aa ethers


# Any other standard package manager works as well.
```

### Part 1: Configuration and Initialization

Now that you've installed various dependencies and understand the basic structure of this example, you're ready to proceed to the first part of implementing BTC Connect: the process of configuration.

Configuring BTC Connect entails usage of the `ConnectProvider` component imported from `@particle-network/btc-connectkit`.

`ConnectProvider` acts as the central component for configuration, taking a variety of parameters responsible for instance authentication (API keys), wallet modal customization (we'll cover this more momentarily), and supported wallet customization (deciding the range of supported wallets within your application, such as UniSat, OKX, and so on).

Additionally, `ConnectProvider` should wrap the component where you intend to use BTC Connect. This is where our previously defined usage of `App.tsx` and `index.tsx` resurface.

Configuration in this example will happen within `index.tsx`. This file will import the `App` component from `App.tsx`, allowing `ConnectProvider` to wrap it and enabling the usage of BTC Connect within our application (defined within `App.tsx`).

***

With this established, you'll need to render `ConnectProvider` with the following parameters defined (through the `options` and `connectors` parameters):

* `projectId`, `clientKey`, and `appId`. These are required values authenticating your instance of BTC Connect; they fundamentally tie your project to the [Particle dashboard](https://dashboard.particle.network).
  * To retrieve these keys, open the [dashboard](https://dashboard.particle.network) and create a new project alongside a new application; the corresponding **Project ID**, **Client Key**, and **App ID** will need to be defined within their respective parameters, detailed above.
* `aaOptions`, which contains `accountContracts`, taking:
  * `BTC`, an array of objects outlining chain-related configurations for the smart account. These parameters include:
    * `chainIds`, an array of chain IDs referring to the chains you intend to use within your application. Here, we'll be using `SatoshiVMTestnet.id` from `@particle-network/chains`.
    * `version`, the version of the smart account you'd like to use. For now, only `1.0.0` is supported.
* `walletOptions`, settings impacting the optional embedded wallet modal responsible for facilitating interaction with the smart account derived from a user's native Bitcoin wallet.
  * This takes one parameter, `visible`. If set to `true`, the embedded wallet modal will be available through the bottom right corner of your application after the wallet connection. Otherwise, if `false`, the modal will be omitted, leaving the handling of the smart account solely to your application.

Outside of `options`, within `connectors`:

* An array of wallet connectors you'd like to support within your application (such as UniSat, Bitget, or OKX). These connections can be imported from `@particle-network/btc-connectkit`, through:
  * `OKXConnector`.
  * `UnisatConnector`.
  * `BitgetConnector`.

With these parameters filled in, your `index.tsx` file (or its equivalent within your application) should look similar to the example below:

```javascript
import React from "react"
import ReactDOM from "react-dom/client"
import {
    ConnectProvider, // Central component used for configuration
    OKXConnector, // OKX Wallet
    UnisatConnector, // Unisat Wallet
    BitgetConnector, // Bitget Wallet
} from "@particle-network/btc-connectkit"
import { SatoshiVMTestnet } from "@particle-network/chains" // Optional
import App from "./App" // The component you intend to use BTC Connect within

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
    <React.StrictMode>
        <ConnectProvider
            options={{
                projectId: process.env.REACT_APP_PROJECT_ID, // ---
                clientKey: process.env.REACT_APP_CLIENT_KEY, // Retrieved from https://dashboard.particle.network
                appId: process.env.REACT_APP_APP_ID, // ---
                aaOptions: {
                    accountContracts: {
                        BTC: [
                            {
                                chainIds: [SatoshiVMTestnet.id],
                                version: "1.0.0", // Keep as 1.0.0 for now.
                            },
                        ],
                    },
                },
                walletOptions: {
                    // Dictates whether or not the optional embedded wallet modal is shown.
                    visible: true,
                },
            }}
            // Instances of the previously imported connectors
            connectors={[new UnisatConnector(), new OKXConnector(), new BitgetConnector()]}
        >
            <App /> // The component imported above
        </ConnectProvider>
    </React.StrictMode>
)
```

### Part 2: Initiating Wallet Connection

With BTC Connect configured and initialized, you're ready to begin building your application (or integrating BTC Connect within an existing one).

We'll be doing this within the previously mentioned `App.tsx` file (using the `App` component we wrapped within `ConnectProvider`).

Opening and taking a user through the wallet connection menu is quite simple and generally only takes one line of code, although it requires a preliminary setup.

First, it's important to understand how BTC Connect is used programmatically.

BTC Connect has four primary hooks that provide functions to control all core functionality. These are:

* `useETHProvider`, for managing the associated smart account on SatoshiVM.
* `useBTCProvider`, to receive the user's Bitcoin address and execute native BTC transactions.
* `useConnectModal`, for initiating a wallet connection.
* `useAccounts`, for retrieving the user's addresses.

We'll walk through the process of leveraging `useETHProvider` (alongside `@particle-network/aa` and `ethers`) and `useBTCProvider` in part 3. For now, let's focus on `useConnectModal`.

After importing `useConnectModal` from `@particle-network/btc-connectkit`, we'll need to define the `openConnectModal` function (and optionally, the `disconnect` function). An example of this has been included below:

```javascript
import { useETHProvider, useBTCProvider, useConnectModal } from '@particle-network/btc-connectkit';


const App = () => {
  ...

  const { openConnectModal, disconnect } = useConnectModal();
  const { accounts } = useBTCProvider(); // We'll be using this in a moment.

  ...
}
```

`openConnectModal` is the sole function responsible for both initiating and handling end-to-end wallet connections. In this example, we'll wrap `openConnectModal` within a function, `handleLogin`to ensure its execution only happens conditionally.

`handleLogin` will only execute `openConnectModal` *if* the user has yet to connect their wallet. This is indicated by the length of the `accounts` array from `useBTCProvider`, which is populated upon wallet connection.

Upon calling `handleLogin`, if the user has yet to connect, a generalized connection interface will be displayed, allowing a user to choose between the wallets previously defined within the `connectors` parameter through `ConnectProvider`. After choosing and connecting a specific wallet, they'll be ready to use your application either through their native Bitcoin account or the newly assigned smart account (on SatoshiVM).

`handleLogin`, or an equivalent function within your application, may look like the below example.

```javascript
const handleLogin = () => {
    if (!accounts.length) {
        openConnectModal() // Opens a generalized connection interface
    }
}
```

### Part 3: Transaction Execution

Taking a few steps back, let's revisit the hooks discussed in part 2.

As mentioned, the `useETHProvider` and `useBTCProvider` hooks are used to control their associated accounts (smart account and native Bitcoin account).

We'll begin by focusing on `useETHProvider`, using it to send a gasless burn transaction of 0.0001 BTC.

**EVM Transaction**

`useETHProvider` exposes a few objects, but the most important one among them is `smartAccount`. This is the sole object for controlling the smart account generated after the wallet connection.

`smartAccount` can either be used independently, through methods like `smartAccount.sendTransaction`, or it can be used alongside `@particle-network/aa` to define an associated EIP-1193 provider to be used within an instance of Ethers.

The latter is what we’ll use in this example.

Specifically, you'll need to import the following from `@particle-network/aa`:

* `AAWrapProvider`, for constructing the custom EIP-1193 provider.
* `SendTransactionMode`, to designate the fee payment method for transactions sent through the Ethers instance.

This, in tandem with `smartAccount`, a custom Ethers object, can be constructed through a flow similar to the following:

```javascript
import React, { useState, useEffect } from 'react';
import { useETHProvider, useBTCProvider, useConnectModal, useConnector } from '@particle-network/btc-connectkit';
import { AAWrapProvider, SendTransactionMode } from '@particle-network/aa';
import { ethers } from 'ethers';


const App = () => {
  const { smartAccount } = useETHProvider();

  ...

  const customProvider = new ethers.providers.Web3Provider(new AAWrapProvider(smartAccount, SendTransactionMode.Gasless), "any");

  ...
}
```

Therefore, this object, `customProvider`, will allow for the construction and execution of transactions through standard Ethers syntax and structure while directly routing signatures through BTC Connect.

By including `SendTransactionMode.Gasless` within the construction of `AAWrapProvider`, we'll be requesting gas sponsorship on every transaction sent through `customProvider`. Since we’re using the SatoshiVM Testnet, all transactions will be automatically sponsored (gasless). However, if this were on Mainnet, you'd need to deposit USDT to the Paymaster within the [Particle dashboard](https://dashboard.particle.network).

:::info

This method of building a custom EIP-1193 provider with `smartAccount` to use BTC Connect through a standard Web3 library is **not** exclusive to Ethers. `AAWrapProvider` can be used within Web3.js, viem, or any other library with EIP-1193 compatibility.

:::

Using `customProvider` to send a transaction is straightforward, following a typical Ethers flow. As such, developers familiar with Ethers might be used to this.

In this example, we'll be executing a burn transaction of 0.0001 BTC within `executeTxEvm`. This function will construct a simple `tx` object containing fields such as `to` and `value`.

Using a signer object retrieved through `customProvider.getSigner()`, this raw `tx` object can be used to execute a complete transaction ([UserOperation](https://www.erc4337.io/docs/understanding-ERC-4337/user-operation)).

To do this, we'll call `signer.sendTransaction(tx)`, which will prompt the user for confirmation (signature) through the Bitcoin wallet they connected previously. Upon confirmation, the transaction will be executed on SatoshiVM.

Below, you'll find an example for what a function of this nature may look like.

```javascript
const executeTxEvm = async () => {
    const signer = customProvider.getSigner()

    const tx = {
        to: "0x000000000000000000000000000000000000dEaD",
        value: ethers.utils.parseEther("0.01"),
        data: "0x",
    }

    const txResponse = await signer.sendTransaction(tx)
    const txReceipt = await txResponse.wait()

    return txReceipt.transactionHash
}
```

**BTC Transaction**

Alternatively, the same wallet interface can be used to send a native (L1) Bitcoin transaction, using the account attached to the previously connected wallet.

We'll do this through the `sendBitcoin` function from the `useBTCProvider` hook (akin to `smartAccount` from `useETHProvider`, but solely for executing a Bitcoin transaction).

`sendBitcoin` can be defined through `useBTCProvider` using syntax adjacent to the example below.

```javascript
import { useETHProvider, useBTCProvider, useConnectModal } from '@particle-network/btc-connectkit';


const App = () => {
  ...

  const { sendBitcoin, accounts } = useBTCProvider();

  ...
}
```

Executing this function will be as simple as passing in two parameters (this is all that's needed for a P2P transaction on Bitcoin). These parameters are:

* `toAddress`, the recipient of the transaction. In this example, we'll define the recipient as accounts\[0], which will send the BTC back to ourselves, just for the sake of demonstration.
* `satoshis`, the value of the transaction denominated in satoshis.
* Optionally, the `options` parameter can be used to define:
  * `feeRate`, for making manual adjustments to the transaction's gas fee.

We'll execute `sendBitcoin` through `executeTxBtc`, which should look similar to the following snippet:

```javascript
const executeTxBtc = async () => {
    return await sendBitcoin(accounts[0], 1)
}
```

Upon calling `executeTxBtc`, alike `executeTxEvm`, the user will be prompted to confirm and sign the transaction. After this, it'll be sent to Bitcoin for execution.


# Quick Summary

At this point, you've gone through the process of installing, configuring, and leveraging BTC Connect to facilitate a native Bitcoin wallet connection, send a gasless transaction on SatoshiVM, and send a sample transaction on Bitcoin.

To learn more about BTC Connect, take a look at the following resources:

* [BTC Connect Documentation](https://developers.particle.network/reference/introduction-to-btc-connect).
* [Introductory Blog Post](https://blog.particle.network/btc-connect-bitcoin-account-abstraction), covering BTC Connect.
* [BTC Connect Landing Page](https://particle.network/btc-connect.html).


# Contract Address


# Alpha Mainnet

## BTC Bridge

### Bitcoin

* BTCBridge: [bc1q5km8mejthm05xmwfj2csm5j8fpyy9gmnta6a33](https://mempool.space/address/bc1q5km8mejthm05xmwfj2csm5j8fpyy9gmnta6a33)

### SatoshiVM Alpha

* BTCBridge: [0xF70Af817B07118CBF7ACCC38767899598e045408](https://svmscan.io/address/0xF70Af817B07118CBF7ACCC38767899598e045408)

## $SAVM Bridge

### Ethereum

* SAVMBridge: [0xF70Af817B07118CBF7ACCC38767899598e045408](https://etherscan.io/address/0xF70Af817B07118CBF7ACCC38767899598e045408)

### SatoshiVM Alpha

* SAVMBridge: [0x1109F6221F684BCb9B2529b8803a7b8c3411d45f](https://svmscan.io/address/0x1109F6221F684BCb9B2529b8803a7b8c3411d45f)


# Testnet

## BTC Bridge

### Bitcoin Testnet

* BTCBridge: [tb1q7y4e54ujq3xqlvmghwmaade48qdam8xwf47kr9](https://mempool.space/testnet/address/tb1q7y4e54ujq3xqlvmghwmaade48qdam8xwf47kr9)

### SatoshiVM Testnet

* BTCBridge: [0x2061d3E567B92C025e75c57FE40a26f080487e42](https://testnet.svmscan.io/address/0x2061d3E567B92C025e75c57FE40a26f080487e42)

## $SAVM Bridge

### Ethereum Sepolia

* SAVMBridge: [0xB9A60416f2dea96C07A9Ab53e35350888D2D67e0](https://sepolia.etherscan.io/address/0xB9A60416f2dea96C07A9Ab53e35350888D2D67e0)

### SatoshiVM Testnet

* SAVMBridge: [0x23C96A36bC1AEedef64a2D924911128911C9A2db](https://testnet.svmscan.io/address/0x23C96A36bC1AEedef64a2D924911128911C9A2db)


# Alpha Mainnet


# Getting Started

## Getting Started with SatoshiVM Alpha Mainnet

Welcome to SatoshiVM! This guide will help you kickstart your journey on this EVM-compatible network that operates as a Bitcoin Layer 2 solution, utilizing BTC as its native token. Below are the key steps to familiarize yourself with SatoshiVM:

1. [**Network Information**](/user-guide/alpha-mainnet/network-information)**:** Understand the basics of SatoshiVM - its compatibility, native token, and the parameters of the Testnet for interaction.
2. [**Wallet Setup via MetaMask**](/user-guide/alpha-mainnet/wallet-setup)**:** Set up your MetaMask wallet to handle BTC on the SatoshiVM network.
3. [**Bridging BTC to SatoshiVM**](/user-guide/alpha-mainnet/btc-bridge-alpha-mainnet)**:** Use the official BTC bridge to transfer BTC from Bitcoin to SatoshiVM.
4. [**Bridging SAVM to SatoshiVM**](/user-guide/alpha-mainnet/savm-bridge-alpha-mainnet): Use the official SAVM bridge to transfer SAVM from Ethereum to SatoshiVM.
5. [**Savmswap**](/user-guide/alpha-mainnet/ecosystem-dapps/savmswap):  The first DEX on SatoshiVM.


# Network Information

## Key Features

### Compatibility

SatoshiVM is built to be EVM-compatible, providing users with a familiar EVM interaction environment and enabling developers to leverage existing Ethereum tools.

### Native Token

BTC serves as the native token on SatoshiVM. All BTC on this network is bridged from Bitcoin Core, allowing seamless interaction with the Bitcoin ecosystem while benefiting from the capabilities of an EVM-compatible environment.

## Network Configuration

### SatoshiVM Alpha Mainnet

SatoshiVM Alpha Mainnet is live, configuration information is as follows:

<table data-full-width="false"><thead><tr><th width="205">Parameter</th><th>Value</th></tr></thead><tbody><tr><td>Network Name</td><td>SatoshiVM Alpha</td></tr><tr><td>Network Type</td><td>Alpha Mainnet</td></tr><tr><td>Chain ID</td><td><code>3109</code></td></tr><tr><td>Currency Symbol</td><td>BTC</td></tr><tr><td>Currency Decimal</td><td>18</td></tr><tr><td>RPC URL</td><td><a href="https://alpha-rpc-node-http.svmscan.io/
">https://alpha-rpc-node-http.satoshivm.io/</a></td></tr><tr><td>Official Explorer</td><td><a href="https://explorer.satoshivm.io/">https://explorer.satoshivm.io/</a></td></tr></tbody></table>


# Wallet Setup

## Wallet Setup via MetaMask

To interact with SatoshiVM and manage BTC on this network, setting up a MetaMask wallet is essential. Follow these steps to configure MetaMask for SatoshiVM:

### Installing MetaMask

Install the [MetaMask](https://metamask.io/) browser extension or mobile app if you haven't already.

### Wallet Import or Creation

Import existing Ethereum wallets into MetaMask or create new wallets specifically for managing BTC on SatoshiVM.

### Network Configuration

Configure MetaMask to interact with the SatoshiVM network. Add the network [details](/user-guide/alpha-mainnet/network-information), including the RPC endpoints and chain ID, to enable seamless communication.


# BTC Bridge (Alpha Mainnet)

## Prerequisites

Before starting the bridging process between Bitcoin and SatoshiVM Alpha Mainnet, ensure the following:

1. [**MetaMask Wallet**](/user-guide/testnet/wallet-setup)**:** Have MetaMask installed and configured to interact with the SatoshiVM.
2. [**UniSat Wallet**](/user-guide/testnet/faucet/bridge-from-bitcoin#wallet-setup-via-unisat)**:** Ensure your UniSat wallet is ready for the transaction process.

## Deposit: Bridge BTC to SatoshiVM

### 1. Navigate to the official BTC Bridge

Access the official [BTC Bridge page](https://bridge.satoshivm.io/). This is where you'll be initiating the process of transferring BTC from Bitcoin to SatoshiVM Alpha Mainnet.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FDycsFDfrLh3D6YOUq897%2FBTC%20Bridge%201.png?alt=media&amp;token=f7ea6ab6-994d-4874-a171-02f195c4cbab" alt=""><figcaption></figcaption></figure>

### 2. Connect Both Wallets

On the Bridge interface, connect both your MetaMask and UniSat wallets. Follow the prompts and confirm the wallet connections.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F5WNc4CDNWxnYaW8O3By5%2FBTC%20Bridge%202.png?alt=media&amp;token=8d5ed487-c543-4aa5-9539-b0001aee0457" alt=""><figcaption></figcaption></figure>

### 3. Deposit on Bitcoin

Initiate the deposit process by specifying the amount of test BTC you want to bridge from the Bitcoin to the SatoshiVM Alpha Mainnet. Review and confirm the transaction details.

{% hint style="warning" %}
Please note that the current deposit feature **does NOT support Legacy-type** Bitcoin wallet addresses. Additional attention should be given to ensure that only compatible wallet addresses are used when initiating deposits.
{% endhint %}

#### 3.1 Specify the amount of BTC to deposit

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2Fn8rQjHgtBfWpFHlLvhat%2FBTC%20Bridge%203.1.png?alt=media&amp;token=0cdadea1-b089-4995-b7f5-2a6d38962f8f" alt=""><figcaption></figcaption></figure>

#### 3.2 Confirm the deposit transaction in UniSat

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FCIaNWnlag1hFFaxGmab6%2FBTC%20Bridge%203.2.png?alt=media&amp;token=27453ac5-54e2-4bce-9264-9919ace7f62c" alt=""><figcaption></figcaption></figure>

### 4. Monitor progress on the History page

Once the deposit is initiated, monitor the progress of your transaction on the History page of the SatoshiVM Bridge. This section provides real-time updates on the status of your deposit.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FCbhwKOlNYBSTNGmCqYIh%2FBTC%20Bridge%204.png?alt=media&amp;token=f6327ca2-1b6d-4e73-a25c-240e89b50e0f" alt=""><figcaption></figcaption></figure>

### 6. Check destination address balance via SatoshiVM Explorer

After the deposit is completed, check the destination address balance using the [SatoshiVM Explorer](https://svmscan.io/). Confirm that the bridged BTC is reflected in your SatoshiVM address.


# SAVM Bridge (Alpha Mainnet)

## Prerequisites

### MetaMask Wallet

Have MetaMask installed and configured to interact with the SatoshiVM Alpha Mainnet.

{% hint style="info" %}
MetaMask has automatically added the configuration for the Ethereum.
{% endhint %}

## Deposit: Bridge SAVM from Ethereum to SatoshiVM

### 1. Navigate to the official SAVM Bridge

Access the official [SAVM Bridge page](https://bridge.satoshivm.io/savm). This is where you'll be initiating the process of transferring SAVM from Ethereum to SatoshiVM Alpha Mainnet.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FuyoaFqbzuzXS5II4ufdt%2FSAVM%20Bridge%201.png?alt=media&amp;token=b018a8f9-daa6-4158-8e16-59632e42aec1" alt=""><figcaption></figcaption></figure>

### 2. Connect MetaMask

On the Bridge interface, connect your MetaMask wallet. Follow the prompt and confirm the wallet connection.

{% hint style="info" %}
Connecting the UniSat wallet is **NOT** required here.
{% endhint %}

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FkTWgxBvviwiFUhxBPuE9%2FSAVM%20Bridge%202.png?alt=media&amp;token=0e1684a6-d944-40a5-ab9f-afefb8eb7f94" alt=""><figcaption></figcaption></figure>

### 3. Deposit on Ethereum

#### 3.1 Enter the amount of an Ethereum asset to deposit

{% hint style="info" %}
Aggregator Functionality:

The default asset is **$SAVM**, and users can also choose other Ethereum assets (such as ETH, USDT, USDC, etc.).

Then SAVM Bridge will automatically swap other assets for **$SAVM** and cross-chain them to SatoshiVM.
{% endhint %}

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FJJdNefEVgoL5QaVuTHiH%2FSAVM%20Bridge%203.1.png?alt=media&amp;token=95998be7-27ed-4fec-a4c3-d2ec35b98c73" alt=""><figcaption></figcaption></figure>

#### 3.2 Input the desired gas exchange amount (optional)

{% hint style="warning" %}
SatoshiVM Alpha Mainnet operates with **BTC for gas fees**. After transferring SAVM from Ethereum to SatoshiVM Alpha Mainnet, users may **lack gas**. They can exchange SAVM for BTC on this interface to facilitate operations.

Alternatively, cross-chain BTC to SatoshiVM Alpha Mainnet via the [BTC Bridge](/user-guide/alpha-mainnet/btc-bridge-alpha-mainnet) if not exchanging BTC for gas fees here.
{% endhint %}

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FllLOjsodSrTxhy4p2TD1%2FSAVM%20Bridge%203.1%20%26%203.2.png?alt=media&amp;token=72ca7716-7b03-4872-812f-935b69302145" alt=""><figcaption></figcaption></figure>

#### 3.3 Approve to spend SAVM

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FTOL8dW82EFDK4rIPs0HP%2FSAVM%20Bridge%203.3.1.png?alt=media&amp;token=02f9ae53-bc7f-4918-8f93-268945f035ee" alt=""><figcaption></figcaption></figure>

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FFx5NT8ismoAiz5edQ2fP%2FSAVM%20Bridge%203.3.2.png?alt=media&amp;token=c5fcbe68-a1db-4c8b-9496-70c46f6ac430" alt=""><figcaption></figcaption></figure>

#### 3.4 Confirm the deposit transaction in MetaMask

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FPbaYSlrggF9uDwmNIZYc%2FSAVM%20Bridge%203.4.png?alt=media&amp;token=d966979a-9b31-451a-8ebc-31ea132be614" alt=""><figcaption></figcaption></figure>

### 4. Monitor progress on the History page

Once the deposit is initiated, monitor your transaction's progress on the SatoshiVM Bridge History page. This section provides real-time updates on the status of your deposit.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FlAQwWn1AH92YdMJYTJdk%2FSAVM%20Bridge%204.png?alt=media&amp;token=df5e9f06-d159-4af6-afa1-18499ade1a30" alt=""><figcaption></figcaption></figure>

### 5. Check SAVM balance via Explorer

After completing the deposit, check the token balances of the recipient address using the [SatoshiVM Explorer](https://svmscan.io/).&#x20;

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FmorFqhcRPeeHVeKMpI6Y%2F2024-03-15%209.46.02%20AM.jpg?alt=media&amp;token=6ab3c9b3-99f4-436d-9726-34ead6614aac" alt=""><figcaption></figcaption></figure>

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FHvxYUTJSNFKnUKhSJ5KV%2Fimage.png?alt=media&amp;token=71c36839-10d9-4888-9eca-17df3619e3cb" alt=""><figcaption></figcaption></figure>


# Ecosystem DApps


# Savmswap

Explore Savmswap, the first DEX on SatoshiVM Testnet:

* Website: [savmswap.io](https://www.savmswap.io/)
* Documentation: [savmswap.gitbook.io](https://savmswap.gitbook.io/)

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FyJifihZHNXtLHCkijjny%2Fimage.png?alt=media&amp;token=d60f0bde-e0cd-4124-b669-2393be995ca9" alt=""><figcaption></figcaption></figure>


# Testnet


# Getting Started

## Getting Started with SatoshiVM Testnet

Welcome to SatoshiVM! This guide will help you kickstart your journey on this EVM-compatible network that operates as a Bitcoin Layer 2 solution, utilizing BTC as its native token. Below are the key steps to familiarize yourself with SatoshiVM:

1. [**Network Information**](/user-guide/testnet/network-information)**:** Understand the basics of SatoshiVM - its compatibility, native token, and the parameters of the Testnet for interaction.
2. [**Wallet Setup via MetaMask**](/user-guide/testnet/wallet-setup)**:** Set up your MetaMask wallet to handle BTC on the SatoshiVM network.
3. [**Accessing test BTC via Faucet**](/user-guide/testnet/faucet/bridge-from-bitcoin)**:** Obtain test BTC from public faucets on the Bitcoin Testnet to conduct transactions on the SatoshiVM Testnet.
4. [**Bridging BTC to SatoshiVM**](/user-guide/alpha-mainnet/btc-bridge-alpha-mainnet)**:** Use the official BTC bridge to transfer BTC from Bitcoin to SatoshiVM.
5. [**Bridging SAVM to SatoshiVM**](/user-guide/testnet/savm-bridge-testnet): Use the official SAVM bridge to transfer SAVM from Ethereum to SatoshiVM.
6. [**Bridging brc-20 assets to SatoshiVM**](/user-guide/testnet/brc20-bridge-testnet)**:** Use the official BRC-20 Bridge to transfer brc-20 assets between Bitcoin and SatoshiVM.
7. [**Savmswap**](/user-guide/testnet/ecosystem-dapps/savmswap#savmswap):  The first DEX on SatoshiVM.
8. [**SARC-20**](/user-guide/testnet/ecosystem-dapps/sarc-20): The first token inscription protocol on SatoshiVM.


# Network Information

## Key Features

### Compatibility

SatoshiVM is built to be EVM-compatible, providing users with a familiar EVM interaction environment and enabling developers to leverage existing Ethereum tools.

### Native Token

BTC serves as the native token on SatoshiVM. All BTC on this network is bridged from Bitcoin Core, allowing seamless interaction with the Bitcoin ecosystem while benefiting from the capabilities of an EVM-compatible environment.

## Network Configuration

### SatoshiVM Testnet

SatoshiVM Testnet is live, offering users the opportunity to experiment, develop, and test applications without risking real assets. Accessing the Testnet is a great way to familiarize yourself with the network's functionalities. Configuration information is as follows:

<table data-full-width="false"><thead><tr><th width="205">Parameter</th><th>Value</th></tr></thead><tbody><tr><td>Network Name</td><td>SatoshiVM Testnet</td></tr><tr><td>Network Type</td><td>Testnet</td></tr><tr><td>Chain ID</td><td><code>3110</code></td></tr><tr><td>Currency Symbol</td><td>BTC</td></tr><tr><td>Currency Decimal</td><td>18</td></tr><tr><td>RPC URL</td><td><a href="https://test-rpc-node-http.svmscan.io">https://test-rpc-node-http.svmscan.io</a></td></tr><tr><td>Official Explorer</td><td><a href="https://testnet.svmscan.io/">https://testnet.svmscan.io/</a></td></tr></tbody></table>

### SatoshiVM Alpha Mainnet

<table data-full-width="false"><thead><tr><th width="205">Parameter</th><th>Value</th></tr></thead><tbody><tr><td>Network Name</td><td>SatoshiVM Alpha Mainnet</td></tr><tr><td>Network Type</td><td>Mainnet</td></tr><tr><td>Chain ID</td><td><code>3109</code></td></tr><tr><td>Currency Symbol</td><td>BTC</td></tr><tr><td>Currency Decimal</td><td>18</td></tr><tr><td>RPC URL</td><td><a href="https://alpha-rpc-node-http.svmscan.io">https://alpha-rpc-node-http.svmscan.io</a></td></tr><tr><td>Official Explorer</td><td><a href="https://svmscan.io/">https://svmscan.io/</a></td></tr></tbody></table>

### SatoshiVM Mainnet

{% hint style="info" %}
Details regarding the Mainnet network will be disclosed after its launch.
{% endhint %}


# Wallet Setup

## Wallet Setup via MetaMask

To interact with SatoshiVM and manage BTC on this network, setting up a MetaMask wallet is essential. Follow these steps to configure MetaMask for SatoshiVM:

### Installing MetaMask

Install the [MetaMask](https://metamask.io/) browser extension or mobile app if you haven't already.

### Wallet Import or Creation

Import existing Ethereum wallets into MetaMask or create new wallets specifically for managing BTC on SatoshiVM.

### Network Configuration

Configure MetaMask to interact with the SatoshiVM network. Add the network [details](/user-guide/testnet/network-information#network-configuration), including the RPC endpoints and chain ID, to enable seamless communication.


# Faucet

Faucet is a developer tool designed to acquire free test tokens for development on different testnets. As a Bitcoin Layer 2 and an EVM-compatible one, SatoshiVM uses BTC as the native gas token that needs to be acquired on the Bitcoin chain and then transferred to Layer 2 for use via cross-chain methods.


# Bridge from Bitcoin

## Bridge test BTC from Bitcoin to SatoshiVM

SatoshiVM uses BTC as its gas token, and all BTC originates from Bitcoin Core. To experience the SatoshiVM Testnet, users should first acquire test BTC on the Bitcoin Testnet using a Bitcoin wallet and then obtain BTC on SatoshiVM through cross-chain bridges.

### Wallet Setup via UniSat

Presently, on the Bitcoin Testnet, we recommend utilizing the [UniSat](https://unisat.io/) wallet for acquiring test BTC and subsequent cross-chain functional interactions.&#x20;

#### Install UniSat

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FYgXDN26WPhbvfYAimm9h%2FUniSat-setup.png?alt=media&amp;token=bf709551-ffe4-41b3-94b8-22be8f6db0ee" alt=""><figcaption></figcaption></figure>

#### Configure Network and Address Type

Within UniSat's Settings, set the Network to **TESTNET** and select the Address Type as **Native Segwit** for your wallet address.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2Fs4tMmEnP7V9kEh82LMcm%2FUniSat-configuration.png?alt=media&amp;token=f3ddea54-5f9f-4f18-940f-a9a76a527681" alt="" width="326"><figcaption></figcaption></figure>

### Acquire test BTC

Currently, users can obtain test BTC on the Bitcoin Testnet using the following third-party faucets.

* Coinfaucet: <https://coinfaucet.eu/en/btc-testnet/>
* Bitcoinfaucet: <https://bitcoinfaucet.uo1.net/send.php>

{% hint style="warning" %}
It is important to note that the recommended address type for the receiving destination is **Native Segwit**. Using any other address type may result in the inability to receive the test BTC.
{% endhint %}

### Deposit test BTC and receive it on SatoshiVM Testnet

For further details, please refer to the [Bridge](/user-guide/alpha-mainnet/btc-bridge-alpha-mainnet) section.


# Acquire on SatoshiVM

## Acquire test BTC on SatoshiVM

Coming soon.


# BTC Bridge (Testnet)

## Prerequisites

Before starting the bridging process between Bitcoin and SatoshiVM, ensure the following:

1. [**MetaMask Wallet**](/user-guide/testnet/wallet-setup)**:** Have MetaMask installed and configured to interact with the SatoshiVM Testnet.
2. [**UniSat Wallet**](/user-guide/testnet/faucet/bridge-from-bitcoin#wallet-setup-via-unisat)**:** Ensure your UniSat wallet is ready for the transaction process.

## Deposit: Bridge test BTC to SatoshiVM

### 1. Acquire test BTC on Bitcoin Testnet

[Obtain test BTC](/user-guide/testnet/faucet/bridge-from-bitcoin#acquire-test-btc) from public faucets on the Bitcoin Testnet. This is essential for initiating the bridging process on SatoshiVM.

### 2. Navigate to the official BTC Bridge

Access the official [BTC Bridge page (Testnet)](https://testnet-bridge.satoshivm.io/). This is where you'll be initiating the process of transferring BTC from Bitcoin Testnet to SatoshiVM Testnet.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FR6kIj4GHDMqMLjSqReAi%2FBridge-mainpage.png?alt=media&amp;token=b5531ac0-895c-4f12-8ce3-0cc3bab894ca" alt=""><figcaption></figcaption></figure>

### 3. Connect Both Wallets

On the Bridge interface, connect both your MetaMask and UniSat wallets. Follow the prompts and confirm the wallet connections.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F3HjfswgiNf8sHYuMVcBT%2FBridge-WalletConnection.png?alt=media&amp;token=6cc63ca3-28c7-46f2-8a5b-1f98bd4f8cf2" alt=""><figcaption></figcaption></figure>

### 4. Deposit on Bitcoin Testnet

Initiate the deposit process by specifying the amount of test BTC you want to bridge from the Bitcoin Testnet to the SatoshiVM Testnet. Review and confirm the transaction details.

{% hint style="warning" %}
Please note that the current deposit feature **does NOT support Legacy-type** Bitcoin wallet addresses. Additional attention should be given to ensure that only compatible wallet addresses are used when initiating deposits.
{% endhint %}

#### 4.1 Specify the amount of test BTC to deposit

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FTNdYQgQAElHBHpjXfA12%2FBridge-deposit.png?alt=media&amp;token=2cc4e490-22bd-4c0c-877e-05beaa99952a" alt=""><figcaption></figcaption></figure>

#### 4.2 Confirm the deposit transaction in UniSat

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F8U3oHBKPzZ9Dhdcjpe3I%2FBridge-deposit-confirm.png?alt=media&amp;token=b57f33bd-da5e-498c-913c-a9f0f3f4dbdc" alt=""><figcaption></figcaption></figure>

### 5. Monitor progress on the History page

Once the deposit is initiated, monitor the progress of your transaction on the History page of the SatoshiVM Bridge. This section provides real-time updates on the status of your deposit.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FcyfyZxxcY4DSHmMvTqqI%2FBridge-history.png?alt=media&amp;token=6b88113e-6e04-4b63-ab29-f4e40f11b369" alt=""><figcaption></figcaption></figure>

### 6. Check destination address balance via SatoshiVM Explorer

After the deposit is completed, check the destination address balance using the [SatoshiVM Explorer](https://testnet.svmscan.io/). Confirm that the bridged BTC is reflected in your SatoshiVM address.


# SAVM Bridge (Testnet)

## Prerequisites

### 1. MetaMask Wallet

Have MetaMask installed and configured to interact with the SatoshiVM Testnet.

{% hint style="info" %}
MetaMask has automatically added the configuration for the Ethereum Sepolia network.
{% endhint %}

### 2. Acquire test ETH on Ethereum Sepolia

Please note that users need to obtain ETH through the following third-party Faucet for interactions on Ethereum Sepolia.

* [Alchemy](https://sepoliafaucet.com/)
* [Infura](https://www.infura.io/faucet/sepolia)

## Deposit: Bridge test SAVM from Ethereum to SatoshiVM

### 1. Navigate to the official SAVM Bridge

Access the official [SAVM Bridge page (Testnet)](https://testnet-bridge.satoshivm.io/savm). This is where you'll be initiating the process of transferring SAVM from Ethereum Sepolia to SatoshiVM Testnet.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FggAbPgaCoBEgEDnLSNQD%2Fimage.png?alt=media&amp;token=8460b017-83fa-435f-8461-7bc57c906fac" alt=""><figcaption></figcaption></figure>

### 2. Connect MetaMask

On the Bridge interface, connect your MetaMask wallet. Follow the prompt and confirm the wallet connection.

{% hint style="info" %}
Connecting the UniSat wallet is **NOT** required here.
{% endhint %}

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FqF1Pq9WyJvXWbVO1kKoO%2Fimage.png?alt=media&amp;token=f85e5bfd-939b-4ef7-9ff7-72e2b56bd7ca" alt=""><figcaption></figcaption></figure>

### 3. Request test SAVM

{% hint style="warning" %}
**Test SAVM has NO transactional value**, and each user is limited in the amount they can request.
{% endhint %}

#### 3.1 Click on the 'tSAVM Faucet' at the bottom of the page

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FomRExsk1FONFPtOBPMfI%2Fimage.png?alt=media&amp;token=3f937b03-a588-4af8-a8f8-e998746bbdff" alt=""><figcaption></figcaption></figure>

#### 3.2 Request test SAVM by signing with your wallet

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FbPqXn45hk9SVsqw7UJbz%2Fimage.png?alt=media&amp;token=9fc7d019-dd90-4cb5-9cc1-4e73db85721f" alt=""><figcaption></figcaption></figure>

#### 3.3 Add test SAVM to your wallet

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FyppdKbALTNp0Kp23CYTf%2Fimage.png?alt=media&amp;token=20f0e719-bcbf-47e8-a050-a6624173013a" alt=""><figcaption></figcaption></figure>

#### 3.4 Limited request amount per user day

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2Fk2LmTZBI1ybcTqUjGMs3%2Fimage.png?alt=media&amp;token=5a65fc6c-2b6b-4961-a8a6-33705a2b3e5b" alt=""><figcaption></figcaption></figure>

### 4. Deposit on Ethereum Sepolia

#### 4.1 Enter the amount of test SAVM to deposit

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F4EPSOLJtOp8s73aY4zL0%2Fimage.png?alt=media&amp;token=ff72cd41-3e89-4216-8d29-bd5f32a13148" alt=""><figcaption></figcaption></figure>

#### 4.2 Approve to spend test SAVM

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F03ikKXsQ79pJUOJSv0T4%2Fimage.png?alt=media&amp;token=0672e9b0-a4fa-4d8b-b74c-b7db77bf0386" alt=""><figcaption></figcaption></figure>

#### 4.3 Confirm the deposit transaction in MetaMask

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FLG5eNFZsqX4RNWYQj8fY%2Fimage.png?alt=media&amp;token=990b59c9-071a-4f7a-aacb-be6b491cb7a0" alt=""><figcaption></figcaption></figure>

### 5. Monitor progress on the History page

Once the deposit is initiated, monitor your transaction's progress on the SatoshiVM Bridge History page. This section provides real-time updates on the status of your deposit.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FwdeWYhRBPhZSwzD6AWYs%2Fimage.png?alt=media&amp;token=c0760742-848e-44ef-a584-7dcac95f7701" alt=""><figcaption></figcaption></figure>

### 6. Check SAVM balance via Explorer

After completing the deposit, check the token balances of the recipient address using the [SatoshiVM Explorer](https://testnet.svmscan.io/).&#x20;

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FRKfsWQmBat7TjZea5CRG%2Fimage.png?alt=media&amp;token=e36a29f5-681b-4105-8e3a-9a479f10b1a5" alt=""><figcaption></figcaption></figure>

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FHvxYUTJSNFKnUKhSJ5KV%2Fimage.png?alt=media&amp;token=71c36839-10d9-4888-9eca-17df3619e3cb" alt=""><figcaption></figcaption></figure>


# BRC20 Bridge (Testnet)

## Prerequisites

Before starting the bridging process between Bitcoin and SatoshiVM, ensure the following:

1. [**MetaMask Wallet**](/user-guide/testnet/wallet-setup)**:** Have MetaMask installed and configured to interact with the SatoshiVM Testnet.
2. [**UniSat Wallet**](/user-guide/testnet/faucet/bridge-from-bitcoin#wallet-setup-via-unisat)**:** Ensure your UniSat wallet is ready for the transaction process.
3. Understand [**brc-20 protocol**](https://domo-2.gitbook.io/brc-20-experiment/).

## Mint $sats for testing

### 1. Navigate to UniSat Testnet

Access [UniSat Testnet](https://testnet.unisat.io/brc20/sats) to mint $sats, a brc-20 token deployed on Bitcoin Testnet.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FbaTBYqD4dxKTy4AmGUlV%2Fimage.png?alt=media&amp;token=8a04ba53-2b03-4450-a289-bca456e90e09" alt=""><figcaption></figcaption></figure>

### 2. Mint $sats directly

Connect your Bitcoin wallet and mint $sats directly:

#### 2.1 Generate the text for minting

Click "Mint Directly" and follow the prompt to generate the text for minting.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FDXPhDsiEfXn77aqEYPLw%2Fimage.png?alt=media&amp;token=4f4d980c-7aed-4871-bb07-8e33390c6041" alt=""><figcaption></figcaption></figure>

#### 2.2 Confirm the inscription details

Review the generated text and click "Next" to continue.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FIxYB8QW5j2l2at2GDBUu%2Fimage.png?alt=media&amp;token=f2024889-98b7-46b4-a9d9-08ad5fb0b383" alt=""><figcaption></figcaption></figure>

#### 2.3 Fill in the recipient's address

Fill in your Bitcoin Testnet address to receive $sats.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FdQE6aD7f7MxHklBMJLrX%2Fimage.png?alt=media&amp;token=055b781f-f6d3-4add-aa00-a540f6e5e007" alt=""><figcaption></figcaption></figure>

#### 2.4 Submit and pay the minting invoice

Submit and pay the prompted invoice to process the minting transaction.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FKNO2XuovmyeILh1f2TL5%2Fimage.png?alt=media&amp;token=851b4256-1bac-41b9-b2a8-5010c0f8d099" alt=""><figcaption></figcaption></figure>

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FdSQy2kwwJWeMsG0j0C0t%2Fimage.png?alt=media&amp;token=0ddb1de4-687d-429e-b6b4-140c72af0138" alt=""><figcaption></figcaption></figure>

### 3. Check your $sats balance in UniSat

{% hint style="warning" %}
Note that it generally takes a few minutes to get your BRC-20 balances updated in UniSat.
{% endhint %}

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FhNDJvC0yIcJdyui6fExh%2Fimage.png?alt=media&amp;token=738c6afb-8fca-4afa-be04-295ca24881d1" alt=""><figcaption></figcaption></figure>

## Deposit: Bridge $sats to SatoshiVM

### 1. Navigate to the official BTC bridge

Access the official [BTC Bridge page (Testnet)](https://testnet-bridge.satoshivm.io/) and select $sats for depositing.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2F6KKoLiLu7kyHhKdEHffU%2Fimage.png?alt=media&amp;token=1525abb1-ee13-4163-b43b-2b07996562d6" alt=""><figcaption></figcaption></figure>

### 2. Inscribe TRANSFER for depositing

According to brc-20 protocol, one has to inscribe the transfer function for a given amount before sending it to a desired recipient. Uninscribed brc-20 tokens are non-transferable.

{% hint style="warning" %}
Note that it generally takes a few minutes to get your transferable BRC-20 balances updated.
{% endhint %}

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FHppFNycNWhKc2153qyOe%2Fimage.png?alt=media&amp;token=aee6704f-170e-4ef6-9de0-611072199114" alt=""><figcaption></figcaption></figure>

### 3. Deposit transferable BRC-20 on Bitcoin Testnet

#### 3.1 Select a transferable BRC-20 balance for depositing

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FMCEaby57MgA9CUcWutPm%2Fimage.png?alt=media&amp;token=6bb40830-ebc4-4e65-b773-adb7fb5473d0" alt=""><figcaption></figcaption></figure>

#### 3.2 Confirm the deposit transaction in UniSat

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2Fctx3yRbcYuT5JSC1unwc%2Fimage.png?alt=media&amp;token=5fae609d-f556-47b4-a42f-ceb9b08308f3" alt=""><figcaption></figcaption></figure>

### 4. Monitor progress on the History page

Once the deposit is initiated, monitor your transaction's progress on the SatoshiVM Bridge History page. This section provides real-time updates on the status of your deposit.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FCj4CqIHH7ZJlIkqELsth%2Fimage.png?alt=media&amp;token=5b5450ae-a2b3-4c07-ba9c-fd36840ed123" alt=""><figcaption></figcaption></figure>

### 5. Check destination address balance via SatoshiVM Explorer

After completing the deposit, check the destination address balance using the [SatoshiVM Explorer](https://testnet.svmscan.io/). Confirm that the equivalent amount of $sats has been transferred to your SatoshiVM address.


# Runes Bridge (Testnet)

Prerequisites

Before starting the bridging process between Bitcoin and SatoshiVM, ensure the following:

1. [**MetaMask Wallet**](/user-guide/testnet/wallet-setup)**:** Have MetaMask installed and configured to interact with the SatoshiVM Testnet.
2. [**UniSat Wallet**](/user-guide/testnet/faucet/bridge-from-bitcoin#wallet-setup-via-unisat)**:** Ensure your UniSat wallet is ready for the transaction process.
3. Understand [**Runes protocol**](https://docs.ordinals.com/runes.html).

## Mint SATOSHIVM•RUNES for testing

### 1. Navigate to UniSat Testnet

Access [UniSat Testnet](https://testnet.unisat.io/runes/inscribe) to mint SATOSHIVM•RUNES, a Runes token deployed on Bitcoin Testnet.

### 2. Mint SATOSHIVM•RUNES directly

Connect your Bitcoin wallet and mint SATOSHIVM•RUNES directly:

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FtlO14zp7ussOyC5cD292%2Fimage.png?alt=media&amp;token=ecc6d2e7-e222-49ab-8a3e-2d48765a684a" alt=""><figcaption></figcaption></figure>

#### 2.1 Generate the transaction for minting

Click "Next" and follow the prompt to generate the transaction for minting.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FfGCbsCc4KSijSZ38Ce1w%2Fimage.png?alt=media&amp;token=8987ea88-08f1-4af3-be84-19eb5f1e9c86" alt=""><figcaption></figcaption></figure>

#### 2.2 Fill in the recipient's address

Fill in your Bitcoin Testnet address to receive SATOSHIVM•RUNES.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FpwF8BhQr3LuQNolyjSFH%2Fimage.png?alt=media&amp;token=bfc3a3c6-0ce9-4f8f-b10c-e64c8a5faa32" alt=""><figcaption></figcaption></figure>

#### 2.3 Submit and pay the minting invoice

Submit and pay the prompted invoice to process the minting transaction.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FXwL5UoflmY2v15TBB1B2%2Fimage.png?alt=media&amp;token=dc05276e-8e92-4abc-846e-df35354543bf" alt=""><figcaption></figcaption></figure>

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FmhxbzzJW7lIjwzwpzqPu%2Fimage.png?alt=media&amp;token=e4000694-df25-45d0-967d-c0cf8e629a46" alt=""><figcaption></figcaption></figure>

### 3. Check your SATOSHIVM•RUNES balance in UniSat

{% hint style="warning" %}
Note that it generally takes a few minutes to get your Runes balances updated in UniSat.
{% endhint %}

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FIzUsD6UaME1JaGmQ1yf0%2Fimage.png?alt=media&amp;token=d6034138-4564-4c09-9882-26a01df8b232" alt=""><figcaption></figcaption></figure>

## Deposit: Bridge SATOSHIVM•RUNES to SatoshiVM

### 1. Navigate to the official BTC bridge

Access the official [BTC Bridge page (Testnet)](https://testnet-bridge.satoshivm.io/) and select SATOSHIVM•RUNES for depositing.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FcBVdXnth79zfHE5HgKMr%2Fimage.png?alt=media&amp;token=173cb78c-efa9-475d-bfc2-5072d2eee016" alt=""><figcaption></figcaption></figure>

### 2. Deposit RUNES on Bitcoin Testnet

#### 2.1 Choose the amount of SATOSHIVM•RUNES for depositing

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FMGgHcLoOSxELwmQjrwJD%2Fimage.png?alt=media&amp;token=259da47c-2253-4d04-93d3-d80ae8d29b5c" alt=""><figcaption></figcaption></figure>

#### 2.2 Confirm the deposit transaction in UniSat

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FQm3UK5nuiT6PLIzYBhMw%2Fimage.png?alt=media&amp;token=c3f58983-69fd-4a67-bc0b-d43c55c8d852" alt=""><figcaption></figcaption></figure>

### 3. Monitor progress on the History page

Once the deposit is initiated, monitor your transaction's progress on the SatoshiVM Bridge History page. This section provides real-time updates on the status of your deposit.

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2Fdrmk3gsLjwHhxY3MQsn8%2Fimage.png?alt=media&amp;token=512d5b63-54be-45d4-b722-fe74616fa7cc" alt=""><figcaption></figcaption></figure>

### 4. Check destination address balance via SatoshiVM Explorer

After completing the deposit, check the destination address balance using the [SatoshiVM Explorer](https://testnet.svmscan.io/). Confirm that the equivalent amount of SATOSHIVM•RUNES has been transferred to your SatoshiVM address.


# Ecosystem DApps


# Savmswap

Explore Savmswap, the first DEX on SatoshiVM Testnet:

* Website: [savmswap.io](https://www.savmswap.io/)
* Documentation: [savmswap.gitbook.io](https://savmswap.gitbook.io/)

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FyJifihZHNXtLHCkijjny%2Fimage.png?alt=media&amp;token=d60f0bde-e0cd-4124-b669-2393be995ca9" alt=""><figcaption></figcaption></figure>


# SARC-20

Explore SARC-20, the first token inscription protocol on SatoshiVM Testnet:

* Website: [sarc20ipt.com](https://www.sarc20ipt.com/)
* Documentation: [docs.sarc20ipt.com](https://docs.sarc20ipt.com/)

<figure><img src="https://67081447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FLhegu0iVyRUg425RQWaa%2Fuploads%2FrzqqgHsEixBEC1dqBndS%2Fimage.png?alt=media&amp;token=d1b31c46-2b24-4959-aec2-d87fa3578d79" alt=""><figcaption></figcaption></figure>


# Token Information

### Basic information

The fundamental information of $SAVM is as follows:

* Token  Name: SatoshiVM
* Token Symbol: SAVM
* Token Decimals: 18
* Total supply: 21,000,000
* [Token contract address](/usdsavm/contract-address)

### Useful links

#### Trading platforms

TBA

#### Data analysis platforms

TBA


# Token Distribution

### Overview

The distribution of SatoshiVM ($SAVM) is as follows:

* Ecosystem: 36.5%
* Liquidity: 30%
* Contributors: 15%
* Bootstrapping and Advisors: 15%
* Bounce Finance IDO: 2%
* APE Terminal IDO: 1%
* $MUBI Farming Pool: 0.4%
* $BSSB Farming Pool: 0.1%

### Unlocking mechanism and vesting schedule

#### 1. Ecosystem

Vested linearly, unlocking 5% of the total each month.

#### 2. Liquidity

20% unlocked on TGE, allocated to Uniswap liquidity. Rest TBC.

#### 3. Contributors

6 months cliff followed by a 2 year vesting schedule.

#### 4. Bootstrapping and Advisors

Bootstrapping partners: 50% initially, 3-month cliff, then 4% per month for a year for a total of 15 month vesting.

Advisors: 3 months cliff followed by a 2 year vesting schedule.

#### 5. Bounce Finance IDO

100% at TGE.

#### 6. APE Terminal IDO

100% at TGE.

#### 7. $MUBI Farming Protocol

TBC

#### 8. $BSSB Farming Protocol

TBC


# Token Utility

SatoshiVM is a community-driven project where $SAVM, its native token, plays a crucial role in advancing community development. $SAVM's motivates community participants and fosters collaboration. In the Tokenomics section, a significant portion of $SAVM is allocated to the Ecosystem, emphasizing its role in incentivizing community engagement and project co-creation.

## Common utilities

### Governance and Voting

$SAVM holders influence the future direction of SatoshiVM. Actively participating in governance proposals and voting empowers $SAVM holders to shape important decisions, ensuring alignment with the community's aspirations.

### Staking Rewards

Staking $SAVM tokens provides an additional way for holders to earn rewards within the SatoshiVM ecosystem. By participating in the staking program, users contribute to ecosystem stability while enjoying attractive rewards.

## Premium utilities

### Early Participant Incentives

In appreciation of contributors during the Testnet and Alpha Mainnet stages, $SAVM serves as a token of gratitude, offering phased incentive programs to encourage ongoing community involvement.

### Ecosystem Priority

&#x20;$SAVM serves as a mechanism to reward and incentivize active participation and contributions within the SatoshiVM community. As part of our commitment to community growth, we would collaborate with programs prioritizing $SAVM holders, ensuring they receive rewards for actively engaging in community-driven initiatives.

### Liquidity Provider Rewards

As SatoshiVM operates as a Bitcoin Layer 2 with native BTC as gas, $SAVM incentivizes BTC liquidity providers. Recognizing their contributions to SatoshiVM's value and usability aligns their interests with the ecosystem's continual growth.

### Security Model Rewards

Participants in the Prover and Verifier modules, guardians of security, play a vital role in maintaining SatoshiVM's safety. Their commitment to overall integrity is rewarded with $SAVM.


# Contract Address

{% hint style="warning" %}
Please consider the SAVM contract address provided on this documentation **as the sole trusted data source**. Be vigilant in identifying potential fraudulent activities.
{% endhint %}


# Mainnet

### Ethereum Mainnet

* Chain ID: `1`
* Address: [`0x15e6E0D4ebeAC120F9a97e71FaA6a0235b85ED12`](https://etherscan.io/token/0x15e6E0D4ebeAC120F9a97e71FaA6a0235b85ED12)

### SatoshiVM Alpha Mainnet

* Chain ID: `3109`
* Address: [`0x0E02765992f946397E6d2e65642eABb9cc674928`](https://explorer.satoshivm.io/address/0x0E02765992f946397E6d2e65642eABb9cc674928)


# Testnet

### SatoshiVM Testnet

* Chain ID: `3110`
* Address: [`0x77726BFbE61B6ad7463466fD521A3A4B89B0EFd8`](https://testnet.svmscan.io/token/0x77726BFbE61B6ad7463466fD521A3A4B89B0EFd8)

### Ethereum Sepolia

* Chain ID: `11155111`
* Address: [`0x77726bfbe61b6ad7463466fd521a3a4b89b0efd8`](https://sepolia.etherscan.io/token/0x77726bfbe61b6ad7463466fd521a3a4b89b0efd8)


# Roadmap

## 2024 Q1

### Testnet Phase

* [x] Release SatoshiVM Testnet and the blockchain explorer.
* [x] Launch the Bitcoin Testnet-SatoshiVM Testnet BTC bridge.
* [x] Launch the SAVM Faucet and the Ethereum Sepolia-SatoshiVM Testnet SAVM Bridge.
* [x] Release SatoshiVM technical paper.
* [x] Open-source SVMZK toolkit.
* [x] Distribute the first batch of NFTs to early participants.

### Alpha Mainnet Phase

* [x] Release SatoshiVM Lite and the blockchain explorer.
* [x] Launch the Bitcoin-SatoshiVM BTC bridge based on the classic architecture of Bool Network.
* [x] Launch EVMs-SatoshiVM SAVM Bridge.
* [x] Token distribution for early NFT holders (Phase 1).
* [x] **Start to deploy partner DApps and protocols on top of SatoshiVM.**

## 2024 Q2

* [x] Ecosystem growth: Onboarding more protocols and DApps on top of SatoshiVM.
* [x] Initiate comprehensive security audits and protocol evaluations.
* [x] Implement the Data Availability module to publish SatoshiVM data and states.
* [x] Introduce Forced Exit functionality, enabling users to withdraw assets on Bitcoin in extreme situations.
* [x] Collaborate with Bool Network and other cross-chain protocols to establish connections between SatoshiVM and other EVM and non-EVM ecosystems.
* [x] Develop the Prover module to generate proofs for SatoshiVM transactions.
* [x] Advance the development of the SatoshiVM Prover System (Phase 1).
* [x] Distribute future batches of tokenized NFTs to the community.

## 2024 Q3

* [x] Develop the Rollup module for publishing SatoshiVM's states to the Data Availability layer.
* [x] Implement Rollup contracts for conducting the legitimacy verification of transaction proofs and states.
* [x] Advance SatoshiVM Prover System (Phase 2).
* [x] Initiate circuit conversion for the verification module (Phase 1).
* [x] Release non-interactive verification for prover and verifier on Bitcoin, excluding circuit conversions.
* [x] Introduce the Anti-Transaction Reordering module based on SVMZK.

## 2024 Q4

* [x] Commence integration of ZK Rollup modules for SatoshiVM.
* [x] Initiate the development of circuit conversion for the verification module (Phase 2).

## 2025 Q1 and after

* [ ] Conduct the system integration testing.
* [ ] Empirical verification of the security model.
* [ ] Optimize the system performance.