Membership & Runes

How Membership Works

Each institution etches a Rune on Bitcoin that represents membership. The Rune is a fungible token — holding ≥1 unit means "you are a member."

Rune: ACME•MEMBER
  Divisibility: 0  (whole units only — member or not)
  Symbol: 🏛
  Premine: 1  (admin gets the first unit)
  Terms: cap=1000, amount=1 (admin mints and distributes)

Operations

  • Check membership: "Does Alice hold ≥1 ACME•MEMBER?" — standard Rune indexer query. No L2 needed.
  • Add member: Admin sends 1 unit to new member's Bitcoin address.
  • Remove member: Admin burns the token via edict, or member sends it back.
  • Visible: Members see membership in any Rune-aware wallet (Xverse, Unisat).

Adding a Member (Full Flow)

1. Admin sends 1 INSTITUTION•MEMBER rune to new member's address
   → member now holds membership token in their Bitcoin wallet
   → visible in any Rune-aware wallet or indexer

2. Admin calls addMember(memberAddress) on the L2 contract
   → L2 contract updates member list
   → (optional: contract verifies Rune balance via bridge)

3. L2 state diff reaches Bitcoin via batch proof
   → member addition is now ZK-proven on Bitcoin

L1 + L2 Mirroring

Membership exists in two places simultaneously:

LayerHow membership is representedHow to check
Bitcoin L1Rune balance (ACME•MEMBER ≥ 1)Any Rune indexer
L2 (Citrea)isMember[address] mapping in Institution.solEVM view call

Both representations should be kept in sync. The Bitcoin Rune is the authoritative source — if there's a discrepancy, the Rune balance wins.

Future: Governance Tokens

A separate Rune (e.g., ACME•VOTE) with divisibility could represent weighted voting power. Governance becomes a token distribution problem — not a staking competition.