Protocol

Access Control (BIDGES)

BIDGES — Badge Identity & Delegation for Gated Execution System — is the access-control layer of the protocol. It separates who you are from what you can do using two token types, unified behind the TAGITAccess facade (one of the six core modules of the contract suite):

• Identity badges (ERC-5192, soulbound) — verify WHO an actor is. Non-transferable, one per address, issued after KYC or institutional verification.
• Capability badges (ERC-1155) — grant WHAT an actor may do. Grantable, revocable, and delegable; authorization is balance-based (balanceOf(addr, id) > 0).

┌─────────────────────────────────────────────────────────────┐
│                    TAGITAccess (facade)                     │
├─────────────────────────────┬───────────────────────────────┤
│   IdentityBadge (WHO)       │   CapabilityBadge (WHAT)      │
│   ERC-5192 soulbound        │   ERC-1155                    │
│   • non-transferable        │   • grantable / revocable     │
│   • 1 per address           │   • multiple per address      │
└─────────────────────────────┴───────────────────────────────┘

Contract architecture

Identity badges (WHO)

Soulbound tokens issued after verification. Each address holds at most one; badges can be upgraded (KYC_L1 → KYC_L2) by authorized issuers and revoked for compliance violations.

Capability badges (WHAT)

ERC-1155 tokens that gate specific protocol actions. They can be delegated to sub-contractors, revoked by admins at any time, stacked per address, and every grant or revoke is logged on-chain.

How capabilities gate the lifecycle

Every state-changing function in TAGITCore checks BIDGES before executing. The mapping onto the 7-state asset lifecycle:

claim(), transferAsset(), and recycle() are gated by identity plus ownership context (buyer, current owner, authorized recycler) rather than a standalone capability badge — see the transition table for the authorized caller of every transition.

Access check flow

Authorization is a two-step check: an identity badge must exist, then the capability balance must be non-zero.

msg.sender calls mint()
       │
       ▼
TAGITCore.requiresCapability(CAP_MINT)
       │
       ▼
TAGITAccess.requireCapability(sender, CAP_MINT)
       │
       ├─▶ IdentityBadge.hasIdentity(sender)?          ✗ revert NO_IDENTITY
       │
       └─▶ CapabilityBadge.balanceOf(sender, 100) > 0? ✗ revert NO_CAPABILITY
       │
       ▼
     ✓ execute

// Check identity only — identityId is a BIDGES badge id (e.g. KYC_L1 = 1)
bool hasId = tagitAccess.hasIdentity(user, KYC_L1);

// Check a specific capability — non-reverting
bool canMint = tagitAccess.hasCapability(user, CAP_MINT);

// Enforce instead of checking: reverts with MissingCapability if not held.
// This is what the requiresCapability modifier calls internally.
tagitAccess.requireCapability(user, CAP_MINT);

Access checks are gas-optimized: requireCapability() costs ~9.2k gas and pure view checks ~8.3k, keeping the authorization overhead of every lifecycle call under 10k gas.

Security features

Circuit breaker

An emergency pause for incident response, gated by CAP_FREEZE. While triggered, all capability checks fail; it auto-resets after 24 hours or can be reset earlier by DAO action.

Rate limiting

Per-address rate limits prevent bulk abuse of granted capabilities:

uint256 constant MINT_RATE_LIMIT  = 100; // per hour
uint256 constant BIND_RATE_LIMIT  = 100; // per hour
uint256 constant CLAIM_RATE_LIMIT = 50;  // per hour

NIST CSF 2.0 alignment

Deployed contracts (Base Sepolia)

Mainnet deployment is audit-gated, targeted H1 2027. See Contract Addresses for the full registry.

Next steps

• Asset Lifecycle — the transitions these badges gate
• Smart Contracts — the full 25-contract suite and its libraries
• Security — audit posture and disclosure policy