> For the complete documentation index, see [llms.txt](https://ciphera.gitbook.io/zerosats-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ciphera.gitbook.io/zerosats-docs/welcome-to-zerosats/trust-assumptions.md).

# Trust assumptions

This page outlines various risks associated with using the Zerosats system. Zerosats is not publicly available to use, but we still feel obligated to share the trust assumptions on the system so users can understand the various tradeoffs. This page outlines an L2Beat-style review of the Zerosats system, where potential trust assumptions lie, and more. Please note that this is not a security assessment and that there is not always a direct correlation between trust and security. **Please also note that we have modified the core UTXO circuit in our fork and that these changes are unaudited**.

## Risk summary

#### Funds can be stolen if...

{% hint style="danger" %}

1. The proof systems securing the Citrea smart contracts & Clementine smart contracts are implemented incorrectly,
2. the operators of the Clementine BitVM bridge, a 10-of-10 multisig, collude and steal bitcoin in the bridge backing cBTC which backs Zerosats notes,
3. the security council in the Clementine BitVM bridge, a 3-of-5 multisig, turns malicious and steals the bitcoin in the bridge backing cBTC which backs Zerosats notes (CRITICAL). 
   {% endhint %}

#### Funds can be lost if...

{% hint style="warning" icon="triangle-exclamation" %}

1. the external data becomes unavailable (CRITICAL).
   {% endhint %}

#### Users can experience liveness failures if...

{% hint style="warning" icon="circle-pause" %}

1. the operator goes offline and is unable to process transactions.
   {% endhint %}

## Trust analysis

*This analysis covers our future mainnet state. Our contracts are currently immediately upgradable by a privileged admin. We are upgrading them to be immutable in the coming weeks.*

#### Native Bitcoin Custody

<mark style="color:$danger;">**VERY HIGH TRUST**</mark>**:** Clementine bridge

Clementine BitVM bridge: Clementine is primarily secured by 10 signers participating in a N-of-N multisig. If one of these signers goes offline, the bridge can fall back to operated funded withdrawals, which are bound to the rules of a specific BitVM-style program. There are currently two operators in Clementine's bridge set up. The bridge additionally includes a spend path where a 3-of-5 multisig, known as a security council, can spend funds out of the bridge unilaterally.

*Note that the Zerosats team is not involved in running any operations for the Clementine bridge protocol.*

#### Sequencer failure

<mark style="color:$danger;">**VERY HIGH TRUST**</mark>: No self-sequence

Users cannot sequence their own transaction and running a sequencer is not permissionless. However, due to the privacy properties of the system, the sequencer cannot individually censor a specific user. In other words, if the sequencer wants to censor users, they have to halt the entire system.

#### State validation

<mark style="color:$success;">**LOW TRUST**</mark>: Validity proofs (SN)

SNARKs are validity proofs that ensure state correctness. SNARKs require a [trusted setup](https://l2beat.com/glossary#trusted-setup).

#### Data availability

<mark style="color:$danger;">**VERY HIGH TRUST**</mark>: External

Proof construction and state derivation rely fully on data that is NOT published to bitcoin. The validator is responsible for making state data available to pears.

*Users can run their own archive node after fetching state from the validator.*

#### Exit window

<mark style="color:$success;">**LOW TRUST**</mark>: Immutable contracts\*

Citrea smart contracts are immutable. Users can run their own prover and exit the system if the sequencer goes offline.

{% hint style="info" %}
This analysis covers our future mainnet state. Our contracts are currently immediately upgradable by a privileged admin. We are upgrading them to be immutable in the coming weeks.
{% endhint %}

#### Proposer failure

<mark style="color:$success;">**LOW TRUST**</mark>: Users can run their own proposer after 7 days pass

If the prover goes offline, users can run their own prover and prove their withdrawal requests to the Citrea bridge contract. If they have the authority to spend a specific note, the bridge contract verifies their zero-knowledge proof and releases the funds to the user on Citrea.

## Data availability

#### Data is not stored on bitcoin <a href="#data-availability" id="data-availability"></a>

The transaction data is not recorded on the bitcoin main chain. Transaction data is stored off-chain and made available by the Zerosats validator. Anyone can run an archive node and maintain a historical record of Zerosats state.

{% hint style="danger" %}
Funds can be lost if the Zerosats state data is lost and/or becomes unavailable **(CRITICAL)**.
{% endhint %}

## State validation

#### Validity proofs

Each update to the system state must be accompanied by a validity proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Citrea by a smart contract.

## Operator

#### The system has a centralized operator <a href="#operator" id="operator"></a>

The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.

{% hint style="info" icon="handshake" %}
The operator cannot maliciously update the state of the Zerosats bridge contract and steal funds. It is only capable of sequencing and validating transactions.
{% endhint %}

## Withdrawals

#### Zerosats to Citrea <a href="#exit-mechanisms-1" id="exit-mechanisms-1"></a>

The user initiates Zerosats<>Citrea messages by submitting a regular burn transaction to the Zerosats validator. The validator verifies that it is a valid transaction with a valid zk-proof and the transaction is added to the withdrawal queue. The validator then signs off on an epoch of blocks and passes this epoch to the prover who proves all blocks and accompanying transactions are valid. The prover verifies the validator's signature and proofs for all individual transactions within the epoch. It generates an aggregate UTXO proof that it submits to the Zerosats verifier contract on Citrea. Upon verifying the proof, the contract releases funds to users.

{% hint style="info" %}
Because the prover must verify all individual burn proofs, with their accompanying witnesses, the validator cannot forge burn proofs for users' whose private keys it does not know. In other words, the validator cannot steal.
{% endhint %}

#### Forced withdrawals to Citrea <a href="#exit-mechanisms-2" id="exit-mechanisms-2"></a>

If the Zerosats prover goes offline for more than 7 days, users can run their own prover to generate an aggregate UTXO proof and leave the system to Citrea (so long as they have access to Zerosats' most recent state).

#### Zerosats to Lightning <a href="#exit-mechanisms-1" id="exit-mechanisms-1"></a>

Users can swap Zerosats notes to a bitcoin Lightning wallet. While swaps are atomic, they rely on permissioned roles to facilitate the swaps.

### Permissioned Roles

*We will publish these once we've upgraded our contracts to be immutable.*

&#x20;

&#x20;

<br>