Creating an Institution

The full lifecycle from key generation to a fully anchored Bitcoin-sovereign institution.

Step-by-Step Flow

1. Admin generates a Bitcoin key pair (x-only Taproot pubkey)
   → this key IS the institution's identity root
   → everything else derives from this key

2. Admin inscribes institution on Bitcoin (Ordinal)
   → metaprotocol: "binst", body: institution metadata
   → gets inscription ID: abc123...i0
   → inscription lives in a Taproot vault UTXO → admin owns it
   → the inscription is the institution's birth certificate

3. Admin etches membership Rune on Bitcoin
   → INSTITUTION•MEMBER, premine: 1
   → admin holds the initial unit

4. Admin deploys Institution.sol on an L2 (currently Citrea)
   → constructor gets: name, admin address
   → admin calls setInscriptionId() and setRuneId() to bind the contract
   → the L2 contract is now a DELEGATE of the Bitcoin key holder

5. L2 state reaches Bitcoin via batch proof
   → institution is now represented THREE ways on Bitcoin:
      a) Ordinal inscription (identity — AUTHORITATIVE)
      b) Rune (membership token)
      c) State diff in batch proof (computational state)

Note: Step 4 can be repeated on any L2. The inscription ID and Rune ID stay the same. Only the L2 contract address changes.

Note: Steps 2–3 (Bitcoin) and step 4 (L2) are independent — they can happen in any order. If step 4 happens first without steps 2–3, the institution is UNANCHORED (see Institution Anchoring Lifecycle).

Transaction Summary

StepChainTransaction typeCost
Generate keyOfflineNoneFree
Inscribe identityBitcoinOrdinal inscription (~500B)~$2–5
Etch RuneBitcoinRunestone in OP_RETURN~$1–3
Deploy contractCitreaEVM contract creation~cBTC gas
Bind inscriptionCitreaEVM function call~cBTC gas
Bind RuneCitreaEVM function call~cBTC gas
Batch proofBitcoinAutomatic (sequencer)User doesn't pay

The Inscription Envelope

Every BINST inscription uses the Ordinals envelope format:

OP_FALSE OP_IF
  OP_PUSH "ord"
  OP_PUSH 1                              ← content type tag
  OP_PUSH "application/json"             ← MIME type
  OP_PUSH 7                              ← metaprotocol tag
  OP_PUSH "binst"                        ← protocol identifier
  OP_PUSH 5                              ← metadata tag
  OP_PUSH <CBOR-encoded metadata>        ← structured metadata
  OP_PUSH 3                              ← parent tag
  OP_PUSH <binst-root-inscription-id>    ← provenance chain
  OP_PUSH 0                              ← body separator
  OP_PUSH '{
    "type": "institution",
    "name": "Acme Financial",
    "admin_btc_pubkey": "a3f4...x-only-32-bytes",
    "citrea_contract": "0x1234...5678",
    "created_btc_height": 127600,
    "members": ["pubkey1...", "pubkey2..."]
  }'
OP_ENDIF

See Inscription Schema for the full JSON schema specification.