> For the complete documentation index, see [llms.txt](https://docs.builtbydao.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.builtbydao.com/developers/contracts.md). # Smart Contract Catalog {% hint style="info" %} ## Current contract suite The hosted app selects this suite on Base Sepolia in prelaunch. A listed contract does not mean a public program is open. See [Developer Overview](/developers/developers.md) for release names and current availability. {% endhint %} This catalog describes the contracts and their responsibilities. The app and its release evidence determine what is available to each member. The reviewed source revision is `09197fe58978f55f0908d94baad48f942ea0414b`. Exact interfaces, policy, dependencies, and authority remain in the private implementation repository. The release program names **27 product labels**. That is not a total deployed-address count: stable-account and payment infrastructure, recovery adapters, implementations, and environment dependencies are additional components. FounderFund is a second OperatingBudgetVault instance. ## Control and policy ### AccessControlContract * **Purpose:** Defines the control key, founder authority, delegated roles, expiries, denials, and marked contract classifications. * **Behavior and safeguards:** DEPLOYER has the authority bypass; FOUNDER holds explicit operating grants. SUPER\_ADMIN is a delegated tier with the applicable grants. ### ParameterRegistry * **Purpose:** Stores configurable policy and bounds. * **Behavior and safeguards:** Consumers read their applicable policy and fail when required inputs are absent or invalid. Policy administration and authority to change bounds are separate powers. ### BusinessRegistry * **Purpose:** Records registered businesses and current acceptance policy. * **Behavior and safeguards:** Active registration alone does not grant an external partner a conversion agreement. ## Identity, membership, and voting inputs ### MemberAccountRegistry * **Purpose:** Binds a stable account to its current wallet and revision. * **Behavior and safeguards:** Coordinates recipient acceptance and recovery across required domains before the new wallet becomes active. Identity survives recovery; retired authorizations must not be replayed. ### DAOMembershipNFT * **Purpose:** One soul-bound membership credential records rank, standing, and designations. * **Behavior and safeguards:** Rank progression updates the existing credential. Authorized recovery is coordinated through the recovery adapter; ordinary transfers remain disabled. ### GuildMeritNFT * **Purpose:** Records guild merit and supplies policy-controlled earning inputs. * **Behavior and safeguards:** Recovery preserves the credential and its relevant history. ### InvestorTierNFT * **Purpose:** Projects investor accounts from InvestorAllocator. * **Behavior and safeguards:** The allocator is the sole structural writer for managed records. This credential is neither a private security nor a substitute for allocation accounting. ### RankVotingWeightRegistry * **Purpose:** Maintains the ordered rank-weight ladder within 1.00–1.25×. * **Behavior and safeguards:** The 14 rank positions, their rank values, and unique membership token IDs are distinct identifiers. ## Tokens and grants ### BLTBYToken * **Purpose:** Transferable utility token with schedule-controlled issuance, a 7-billion lifetime issuance ceiling, and pause controls. * **Behavior and safeguards:** Token implementation does not announce a public sale or a market. ### EQTBLTTokenV3 * **Purpose:** Keeps member account balances separate from contract custody, with whole-credit WORK and RENT buckets. * **Behavior and safeguards:** Per-bucket roles gate minting to accounts and vault custody; the reviewed release assigns WORK minting to FlowTreasurer and RENT minting to RentalAndRebate. Approved spending preserves provenance. Separately authorized reserve capitalization creates DAO-held credit; authorized custody burning retires only the caller’s own held credits, never a member’s account balance. ### TokenVesting * **Purpose:** Holds generic funded token grants with their claim, revocation, and recovery rules. * **Behavior and safeguards:** A grant is separate from purchased or bonus entitlements held in InvestorAllocator. ## Work budgets and payment execution ### FlowTreasurer * **Purpose:** Creates and manages the work-budget vault hierarchy and authorization needed to fund approved work. * **Behavior and safeguards:** A budget authorization is distinct from a particular payment. ### ProjectFlowVaultImplementation * **Purpose:** Implements project-vault custody and releaseWork. * **Behavior and safeguards:** A release binds the stable account and revision, work and policy inputs, exact amount, and unique payment identity. It records work and executes settlement together. ### WorkActivityTracker * **Purpose:** Quotes policy-qualified work and records authorized vault releases. * **Behavior and safeguards:** It supplies activity checkpoints and governance inputs; a funded project vault executes WORK payment. ### TaskPaymentRegistry * **Purpose:** Immutable, asset-free ledger that consumes a payment ID once across authorized executors. * **Behavior and safeguards:** Separate installments may use distinct payment IDs; a task ID or repeated note is not itself the payment identity. ### BLTBYTaskPayoutVault * **Purpose:** Executes funded BLTBY task payments through the same account and payment-identity boundary. * **Behavior and safeguards:** A BLTBY payout is not WORK EQTBLT and must be displayed as its actual asset. ## Treasury and operations ### Treasury * **Purpose:** Books balance-backed revenue by immutable source identity. * **Behavior and safeguards:** Reversals and disposal are bounded to the source record. Ordinary outflows use policy rails and the observed-peak reserve floor; founder emergency withdrawal and peak-reset powers remain explicit exceptions. ### OperatingBudgetVault * **Purpose:** Isolated operating custody with its own manager, funding, spending, recall, pause, and close behavior. ### FounderFund * **Purpose:** A separate OperatingBudgetVault instance for founder operations. * **Behavior and safeguards:** It does not automatically receive a percentage of revenue. ### BLTBYBank * **Purpose:** Quotes and executes authorized purchases from funded Treasury inventory using the selected price and applicable limits. * **Behavior and safeguards:** Bank availability, allowed assets, and campaign settings come from the release and current policy. ### DAOBusiness * **Purpose:** Keeps DAO-unit receipts, accepted services, liabilities, refunds, spend requests, and Treasury revenue isolated. * **Behavior and safeguards:** Request approval and actual settlement are different states. ## Housing, bookings, and services ### RentalAndRebate * **Purpose:** Records qualifying lease periods and issues RENT at the lease-stamped rate with duplicate-period protection. * **Behavior and safeguards:** It does not itself collect rent, transfer property title, or create contributor voting power. ### Bookings * **Purpose:** Tracks reservation and deposit custody through accepted terms, capture, cancellation, refund, forfeiture, and recovery. * **Behavior and safeguards:** A later configuration change does not erase an existing liability. ### AmenityAccess * **Purpose:** Manages paid amenity plans, accepted quotes, recurring or prepaid terms, settlement, grace, refunds, and recovery. * **Behavior and safeguards:** Paid service access is separate from the soul-bound DAO membership credential. ### SpendRouter * **Purpose:** Moves approved member WORK or RENT credits through enabled lanes into appropriate custody. * **Behavior and safeguards:** Checks the account, policy, destination, and relevant service conditions. Ordinary spending is a transfer, not a member credit burn. ## Investor allocations, unit credit, and partners ### InvestorAllocator * **Purpose:** Immutable canonical investor entitlement ledger. * **Behavior and safeguards:** Supports authorized stablecoin, ETH, and manual-attestation paths, allocation claims, bonus adjustments, credential projection, and recovery. Purchased entitlement and already vested value have their own protections. A private fund interest remains a separate off-chain agreement. ### UnitCreditFacility * **Purpose:** Lends WORK credit to active DAO-operated units for approved work. issueLoan establishes the commitment; drawAndRelease funds and pays a recorded work release atomically. * **Behavior and safeguards:** Repayment returns credits for reuse; the facility has no member or unit cash-conversion door. Delegated write-off uses two participants, with an explicit FOUNDER exception. ### PartnerConversion * **Purpose:** Separate external-partner settlement. * **Behavior and safeguards:** Active registration and an active agreement are required for new payments. A member or token holder pays for the partner’s service; USDC is owed to the partner, not the payer. Owed limits cap exposure, payouts require available pool funding, and closing an agreement does not erase existing debt. ## Governance ### Governance * **Purpose:** Contributor, Investor, and Council houses use category-specific proposal rules. * **Behavior and safeguards:** The contracts verify frozen snapshot facts and stable account identity, preserving one vote per account through recovery. Contributor power uses WORK activity, square-root weighting, and bounded rank/tenure; RENT does not add contributor power. Execution rechecks the applicable target classification. ### GuildGovernance * **Purpose:** Scoped guild proposals and votes use the guild’s membership, merit, timing, and snapshot rules. * **Behavior and safeguards:** Stable account identity prevents a recovered wallet from voting again as a different person. ## Recovery and release evidence Recovery spans the configured domain adapters rather than independently moving one token while leaving other rights behind. The full release program records fourteen recovery domains. Completion requires the configured domains and account revision to reconcile; a local adapter test is not proof of a complete production recovery. Recovery adapters and the release program are part of the reviewed internal source snapshot. The app must import the matching manifest and interfaces, verify the actual release, and exercise its member and operator journeys. Use the selected release for addresses, balances, allowances, and receipts. ## Dashboard integration rules * Contract addresses and ABIs come from one validated deployment manifest, never hand-copied constants. * During an outage, contract-backed pages show unavailable or pending states. * Privileged controls require both dashboard resource authorization and the exact contract role. * Transactions expose preparation, wallet confirmation, broadcast, confirmation, replacement, and failure states. * Event indexing is idempotent and reorg-aware and preserves stable account, token identity, EQTBLT bucket, payer, unit, and authorization path. * `WORK` and `RENT` remain neutral provenance. Legal, accounting, labor, housing, securities, and tax conclusions stay in professional off-chain workflows. {% content-ref url="/pages/hftDRIhC6qRmHIxsCTJn" %} [Overview](/developers/developers.md) {% endcontent-ref %} {% content-ref url="/pages/3tD3Lg3QAxpvmADNnNqn" %} [Dashboard Integration](/developers/platform.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.builtbydao.com/developers/contracts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.