AB5DPublic RecordPoliciesDecisionsProgramsAccessionsRevisions
AB5D-GOV-2026-007

Token-bound membership architecture recorded

No adopted effect
JSONMarkdownPropose a correction
Status
No adopted effect
Date
2026-08-10
Decision type
Architecture proposal
Authority
Proposal only
Source commit
8fc9554267b1e1dc82abc4f422151e3ebbc90723
Adopted effect
Records a proposed membership architecture in which a membership NFT may act as a portable institutional identity and may control an optional ERC-6551 token-bound account for personal credentials and member-held artifacts. The AB5D Safe remains the sole institutional treasury and custodian of collectively acquired works. This record creates no membership issue, sale, equity, profit participation, collection share, governance right, or claim on institutional assets.
Rationale
A token-bound account can make a membership credential composable without confusing personal member assets with the institution's treasury or collection.

Proposed architecture

  1. The membership NFT is the portable institutional credential and, if later adopted, the canonical key to member identity.
  2. An optional ERC-6551 token-bound account may hold contribution receipts, badges, exhibition records, delegated permissions, and assets that a member intentionally attaches to the credential.
  3. The AB5D Safe remains operationally and legally separate. Membership contributions and institutional revenue flow to the Safe, and collectively acquired works remain in institutional custody.
  4. The token-bound account does not represent equity, profit participation, fractional ownership, a share of future acquisitions, or a claim on AB5D assets.
  5. Secondary-sale creator earnings are optional supplementary revenue only and are not treated as a dependable treasury mechanism.
  6. The Public Record remains the canonical statement of membership terms, governance rights, treasury restrictions, and adopted status.

Conditions before adoption

  1. Resolve whether membership is transferable, transfer-restricted, revocable, or account-bound.
  2. Define loss, recovery, succession, revocation, and compromised-key procedures.
  3. Select and audit the canonical ERC-6551 account implementation, salt, execution interface, signer policy, and deployment chain.
  4. Define how a transferred membership affects the contents and history of its token-bound account.
  5. Prevent ownership cycles, misleading bundled-asset sales, and withdrawal races around marketplace transfers.
  6. Reconcile the architecture with $AB5D, the proposed 500-seat membership, voting weight, and Safe execution authority.
  7. Publish final rights, restrictions, user disclosures, security review, and an adopted decision before deployment or sale.

References