Read/Write Phase Model

Two Transaction Domains

BINST operations happen in two independent domains:

  1. Bitcoin transactions — deliberate, user-initiated actions that create or transfer identity (inscriptions, runes)
  2. L2 transactions — EVM transactions on the processing delegate for institutional logic

These domains are decoupled. A Bitcoin inscription and an L2 contract deployment are separate operations that can happen in any order. The batch proof that anchors L2 state to Bitcoin happens automatically — the user doesn't trigger it.

USER ACTION           L2 (Citrea)                    Bitcoin
─────────────────────────────────────────────────────────────
Create Institution    → deploy contract               (nothing yet)
                      → state change on L2

                      ... L2 batches state ...     
                      
                      → batch proof inscribed          ← Bitcoin DA write
                                                         (automatic, not 
                                                          user-initiated)

Inscribe Identity     (nothing on L2)                 ← ordinal inscription
                                                         (user-initiated,
                                                          separate Bitcoin tx)

Bind Inscription      → setInscriptionId()            (nothing)
to Contract           → now L2 knows its Bitcoin anchor

Write Phases (User-Initiated Transactions)

ActionWhereWho pays / signs
Inscribe identityBitcoin (ordinal)User, BTC wallet
Etch membership RuneBitcoin (rune)User, BTC wallet
Deploy Institution contractCitrea (EVM)User, EVM wallet
Bind inscription to contractCitrea (EVM)User, EVM wallet
Add memberCitrea (EVM)Admin, EVM wallet
Send Rune to memberBitcoin (rune)Admin, BTC wallet
Create process templateCitrea (EVM)Admin, EVM wallet
Create process instanceCitrea (EVM)Admin, EVM wallet
Execute stepCitrea (EVM)Member, EVM wallet

Automatic (No User Action)

ActionWhereWho pays
ZK batch proofBitcoin DACitrea sequencer (periodic, async)

The user does not create a Bitcoin transaction when they interact with Citrea. The batch proof is automatic — the sequencer batches L2 state changes and inscribes the ZK proof on Bitcoin periodically. The user doesn't trigger it or pay for it.

Read Phases (Free)

ActionWhereCost
Verify membershipCitrea (EVM view call)Free
Check process stateCitrea (EVM view call)Free
Verify inscription existsBitcoin (indexer query)Free
Verify batch proofBitcoin DA (decode)Free
Cross-chain identity queryLayerZero / Bitcoin DARelay fee or free

Wallet UX

Current: Two Wallets

  • Bitcoin wallet (Xverse, Unisat) — for inscriptions and runes
  • EVM wallet (MetaMask) — for L2 transactions

The Schnorr precompile on Citrea (0x5a) means contracts can verify Bitcoin Schnorr signatures, but the current flow requires both wallets.

Future: Single Bitcoin Wallet

Account abstraction or Schnorr-verified sessions will allow the user to sign once with their Bitcoin key, and an AA layer submits to the L2. One wallet, one identity.