Smart Contracts
Genesis Transparency provides verifiable, real-time visibility into every deployed contract family as Stage 3 advances on main-net (pre-audit). Each group includes verified addresses, explicit ownership structures, and architectural context, enforcing the protocol's foundational separation: Vault assets (backing GUILD) remain permanently isolated from Treasury volatility. All data is on-chain verifiable; audit status is tracked separately in Security & Audits.
Last updated: Mar.2026
System Tokens
Monetary primitives and governance instruments enabling capital formation and sovereign currency circulation.
GUILD (currency), 3Fi (governance equity), and Startup Tokens (SEED3/PRIME3/ALPHA) form the protocol's foundational token layer; enabling permission-less capital formation and 'seeding' the unencumbered medium of exchange for autonomous economies.
Receipt Tokens
Composable claims on Treasury-managed yield positions.
3Receipts provide programmable exposure to protocol-held assets within The Grove. Their architecture enforces strict volatility isolation, ensuring Treasury fluctuations never propagate to GUILD's stability layer.
NFTs
Structured commitment instruments and programmable yield containers.
PACTs (Protocol Aligned Commitment Tokens), formalise staged capital commitments aligned with protocol sovereignty; 3.NFTs compose locked yield positions with immutable governance signals. Both enforce strict separation between commitment mechanics and GUILD's stability layer.
* Notes:
Aged PACT contract is named '3Bond (3BOND)'
Adolescent PACT contract is named 'Rebate Receipt NFT (RR NFT)'
CDPs
Revenue-generating infrastructure with enforced volatility isolation.
Compound Deposit Pools (CDPs) and Liquid Deposit Pools (LDPs) generate protocol revenue while architecturally confining all yield volatility to Treasury, ensuring zero propagation risk to GUILD's stability layer.
Stability & Settlement Layer
Enforcing the mathematically-determined path from bootstrap pledge to Vault-backed sovereignty.
Settlement contracts provide transitory convertibility assurance during bootstrap while executing Reserve Requirement Curves—systematically transitioning GUILD's stability foundation from pledge dependence to unencumbered Vault equity.
* Notes:
SettlementV1 is obsolete and no longer in use by 3 protocol.
Remaining crvUSD balance reflects unclaimed settlement.
Contract state is fully settled.
Revenue Generation Layer
Strategic asset acquisition and protocol revenue generation.
The Arbitrage Master Node and specialised engines acquire Protocol-Held Assets while generating fee revenue—both streams fuelling Vault fortification and the liability-retiring mechanics essential to GUILD's path toward sovereignty.
Governance & Treasury Layer
Layered sovereignty with enforced Vault/Treasury segregation.
These contracts implement user-sentiment-driven governance while architecturally confining all asset volatility to Treasury; ensuring GUILD's stability remains mathematically determined by Vault equity, not politically exposed.
Credit Infrastructure Layer
Foundations for liability-retiring credit markets.
These contracts enable staged capital commitments and future credit claims; advancing the protocol toward Stage 4's single-sided lending pool while preserving stability during bootstrap.
Core Utility Layer
Composable primitives enabling cross-protocol interoperability and capital efficiency.
Swaps, GuildSwaps, and Holdings provide purpose-built infrastructure for asset routing, PHA acquisition, and Treasury segregation; maximising composability within strict architectural boundaries that preserve GUILD stability.
PODs (Purpose-Oriented Distributors)
Governance-weighted distribution of protocol revenue to ecosystem growth vectors.
Purpose-Oriented Distributors channel Vault-derived ETH into development, creativity, and liquidity incentives; closing the sustainability flywheel by converting revenue into compounding backing density and autonomous ecosystem growth.
Query Contracts
OCP = On Chain Proof, if an 'asterisk', '*', is shown, this indicates a further step is required to decode the hash and validate the transaction type. To do so, follow these steps:
Navigate to the OCP transaction,
Copy the 'Input data' field,
Navigate to Swiss Knife - https://swiss-knife.xyz/
Select the 'Calldata' option,
With 'Decode' selected, paste the 'input data' filed value copied in step 2,
Actioning step 5 will auto-populate the decoded data, revealing the function being performed and the address to which the function relates. In the case of OCP's, all are expected to be:
Function = 'setNewOwner'
Address of owner = 0xbE19C48B0025B28CA91C916467B0637260652E61
Last updated