> 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).

# V2 Smart Contract Catalog

{% hint style="warning" %}

## Pre-deployment candidate

The v2 suite is complete locally but is not live and does not currently synchronize with the production dashboard. One fresh Base Sepolia rehearsal is planned before any separately approved production deployment. No address, balance, or transaction shown elsewhere should be treated as current v2 chain state.
{% endhint %}

This is the public functional specification for every address in the v2 deployment manifest. It explains responsibilities, authority, lifecycle, safety boundaries, events, and expected dashboard behavior. It deliberately does not duplicate ABI signatures, storage layouts, or deployment assertions. Those source-derived details live in [`BLTBYcontracts/docs/contracts`](https://github.com/marquisdavis/BLTBYcontracts/tree/main/docs/contracts), next to the Solidity they describe.

## Foundation and policy

### AccessControlContract

* **Purpose:** Shared authority for the entire suite. Upgradeable contracts ask this keychain whether an address may use a protected lane.
* **Authority:** A live role grant authorizes an action; a strict role grant classifies an address as a vault, custodian, business, minter, or service. The `SUPER_ADMIN` bypass applies to ordinary authority checks but never to strict classification.
* **Actions:** Role administrators grant, revoke, or temporarily grant roles; record or lift explicit denials; delegate role administration; and atomically transfer super-admin authority. Holders may renounce their own roles.
* **Lifecycle and policy:** Temporary grants expire automatically. A denial blocks new grants until lifted. Super-admin rotation adds the replacement and removes the prior holder in one transaction, while a last-admin guard prevents orphaning the system.
* **Safety:** Zero/default-admin shortcuts are disabled, temporary super-admin grants are forbidden, denials take precedence over grants, and upgrades require `UPGRADER` authority.
* **Events and dashboard:** Index `RoleGranted`, `RoleRevoked`, `RoleTemporarilyGranted`, `RoleDenied`, `RoleDenialLifted`, and `SuperAdminTransferred`. The dashboard must combine live chain roles with its narrower resource authorization; neither may broaden the other.
* **Technical reference:** [AccessControlContract](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/AccessControlContract.md)

### ParameterRegistry

* **Purpose:** Evented policy board for adjustable economic and operating values, keeping tunable numbers out of individual contracts.
* **Authority:** `PARAMETER_ADMIN` writes values singly or in batches. Only `SUPER_ADMIN` sets the inclusive minimum and maximum rails that even administrators must obey.
* **Actions:** Set one or many values, define bounds, perform fail-closed typed reads, or use soft reads when an unavailable value is an expected UI state.
* **Lifecycle and policy:** A key starts unset. Bounds may be established before or after its value, but may never exclude the current value. Every later change is prospective unless the consuming contract explicitly freezes accepted terms.
* **Safety:** Required reads revert when unset, out-of-range writes revert, batch lengths must match, and deployment seeds and reads back the complete required key set.
* **Events and dashboard:** `PolicyChanged` and `PolicyBoundsChanged` form the policy history. Dashboard estimates must use the same current keys and clearly show unavailable—not guessed—values when policy is missing.
* **Technical reference:** [ParameterRegistry](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/ParameterRegistry.md)

### BusinessRegistry

* **Purpose:** Canonical list of businesses that may receive value inside the closed-loop economy.
* **Authority:** `BUSINESS_MANAGER` registers, suspends, reactivates, and configures businesses. Consumers read registry state; they cannot create an alternate allowlist.
* **Actions:** Register a business once, set its total EQTBLT acceptance cap, configure per-purchase token-share and amount limits, suspend it, or reactivate it.
* **Lifecycle and policy:** Records move from unregistered to active, may alternate between active and suspended, and retain their configuration while suspended. Registration is not silently replaceable.
* **Safety:** Execution-time consumers re-check active status and caps, preventing an approval made before suspension from bypassing the later restriction. Token-share policy cannot exceed 100%.
* **Events and dashboard:** Index registration, suspension/reactivation, cap changes, and checkout-policy changes. A public profile may display this state, but off-chain approval never substitutes for the contract gate.
* **Technical reference:** [BusinessRegistry](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/BusinessRegistry.md)

## Tokens, vesting, and credentials

### BLTBYToken

* **Purpose:** Transferable ERC-20 utility-token workstream, distinct from EQTBLT and from the private securities offering.
* **Authority:** `BLTBY_MINTER` mints only to Treasury under the schedule; `BLTBY_CAP_ADMIN` may adjust the annual allowance within its hard ceiling; `PAUSER` controls the emergency brake; `SUPER_ADMIN` may repoint Treasury.
* **Actions:** Standard transfers, approvals, permit approvals, and holder-consented burns are available when unpaused. Authorized schedule minting creates Treasury inventory.
* **Lifecycle and policy:** The cumulative schedule begins from genesis, advances in 365-day years, and exposes `mintableNow`. Completed years are banked before an allowance change.
* **Safety:** Maximum lifetime issuance is 7 billion BLTBY. Annual allowance cannot exceed 350 million. Capacity is measured by cumulative minted amount, so burning never reopens mint room.
* **Events and dashboard:** Use normal ERC-20 events plus `ScheduleMinted`, `AnnualMintAllowanceChanged`, and `TreasuryChanged`. Before an approved launch, the dashboard must not imply that public sale, market access, or liquidity is live.
* **Technical reference:** [BLTBYToken](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/BLTBYToken.md)

### EQTBLTToken

* **Purpose:** Zero-decimal, non-tradable credit ledger with neutral `WORK` and `RENT` provenance.
* **Authority:** Each bucket has a derived strict minter role. Strict vault, custodian, business, and backend classifications control movement. `SUPER_ADMIN` activates buckets and wires dependencies; `PAUSER` stops mints and transfers.
* **Actions:** Authorized issuers mint into an active bucket. Holders approve, transfer, or let a router pull a specific bucket through the closed-loop valve. Aggregate and per-bucket balances remain readable.
* **Lifecycle and policy:** Buckets are activated once with a durable policy hash and cannot be deactivated; at most 32 may exist. Credits retain their bucket through every movement.
* **Safety:** Ordinary ERC-20 transfer and approval writes revert. Mints require policy bounds and eligible recipients; movements require an approved in-loop destination and enforce business acceptance caps. Spending transfers credits into custody rather than burning them.
* **Events and dashboard:** `BucketMinted`, `BucketTransfer`, `BucketApproval`, and `BucketActivated` are the provenance feed; ERC-20 `Transfer` supports explorers. UI balances and history must reconcile by bucket and confirmed chain state.
* **Technical reference:** [EQTBLTToken](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/EQTBLTToken.md)

### TokenVesting

* **Purpose:** Fully collateralized BLTBY vesting custody for approved allocations such as investor bonuses.
* **Authority:** `VESTING_CREATOR` creates schedules, `VESTING_ADMIN` revokes or performs recovery actions, and `TREASURY_OPS` may recover only unallocated inventory. Anyone may trigger a claim, but payment always goes to the beneficiary.
* **Actions:** Create a schedule with beneficiary, start, cliff, duration, and revocability; claim one or many schedules; revoke; cancel before start; reassign a beneficiary; or recover free inventory.
* **Lifecycle and policy:** A funded schedule vests linearly after its cliff and completes at duration. Revocation freezes vested value and releases only the unvested remainder. A pre-start cancellation releases the whole allocation.
* **Safety:** Creation fails without available collateral. Claimed or vested value cannot be redirected, beneficiary recovery is explicit and evented, and reserved inventory cannot be recovered.
* **Events and dashboard:** Index schedule creation, claims, revocation, cancellation, reassignment, and unallocated recovery. Display current claimable value and actual state rather than inventing future entitlement.
* **Technical reference:** [TokenVesting](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/TokenVesting.md)

### DAOMembershipNFT

* **Purpose:** One soul-bound membership credential per member, carrying current rank, standing, and leadership designations.
* **Authority:** `MEMBERSHIP_OPS` handles ordinary minting, progression, suspension, and reactivation. `MEMBERSHIP_EXECUTIVE` controls high-rank actions, demotion, burn, recovery, and designations. `SUPER_ADMIN` sets the single founder designation.
* **Actions:** Mint or burn membership, promote or demote rank, suspend/reactivate, award or revoke Framer and Council flags, and recover a credential to a replacement wallet.
* **Lifecycle and policy:** Membership begins active at Seeker. The same token remains through rank changes; promotion does not burn and remint. Suspension preserves identity while removing good standing. Recovery is the only wallet-movement path.
* **Safety:** Transfers and approvals are disabled, one credential per address is enforced, high-rank changes use the executive lane, and designation prerequisites check rank and standing.
* **Events and dashboard:** Index membership, rank, standing, designation, burn, and recovery events. Member-gated pages use `isMemberInGoodStanding`; a profile label cannot create or reactivate membership.
* **Technical reference:** [DAOMembershipNFT](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/DAOMembershipNFT.md)

### GuildMeritNFT

* **Purpose:** Soul-bound proof of a member's merit level inside a registered guild.
* **Authority:** `GUILD_MANAGER` creates guilds, changes activity, and adjusts the bounded level ladder. `MERIT_ISSUER` awards, changes, or revokes credentials.
* **Actions:** Create a guild, activate/deactivate it, award one credential per member and guild, change levels one through five, revoke, or recover by revoke-and-reissue.
* **Lifecycle and policy:** Deactivation blocks new awards but permits corrections, level changes, and revocation. Level modifiers are adjustable only within policy ceilings and monotonic ordering.
* **Safety:** Credentials cannot transfer, awards require DAO membership, duplicates revert, and merit is a bounded earning modifier rather than a tradable asset.
* **Events and dashboard:** Index guild status, awards, level changes, revocations, and modifier changes. Guild pages distinguish off-chain participation from a confirmed credential.
* **Technical reference:** [GuildMeritNFT](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/GuildMeritNFT.md)

### InvestorTierNFT

* **Purpose:** One merged, soul-bound eligibility credential for verified Angel, VentureOne, and Trust investors; it is not the subscribed security.
* **Authority:** `INVESTOR_OPS` attests principal, updates follow-on principal, revokes, and recovers. `SUPER_ADMIN` manages metadata.
* **Actions:** Attest with tier, derived subtier, principal, and document fingerprint; increase principal; revoke; recover; and read the policy-bounded governance multiplier.
* **Lifecycle and policy:** One live credential exists per investor address. Subtier is derived from registry thresholds and may rise after follow-on investment. Recovery moves it without creating a transfer market.
* **Safety:** Transfers and approvals are disabled, a nonzero evidence hash is required, tier thresholds fail closed, and influence is clamped to the anti-capture ceiling. Private verification material stays off-chain.
* **Events and dashboard:** Index attestation, principal increase, revocation, and recovery. Show verification and permitted effects without presenting this NFT as the investment, a BLTBY purchase, or public private-document proof.
* **Technical reference:** [InvestorTierNFT](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/InvestorTierNFT.md)

### RankVotingWeightRegistry

* **Purpose:** Canonical adjustable voting-weight ladder for the 14 membership ranks.
* **Authority:** `GOV_EXECUTOR` changes one rung or an atomic batch. Governance reads the result directly.
* **Actions:** Read one or all weights, or update the ladder through governance execution.
* **Lifecycle and policy:** Initialization seeds the approved 1.00–1.25× progression. Later changes are prospective and evented.
* **Safety:** Exactly 14 entries stay within 10,000–12,500 basis points and may never decrease as rank rises. Framer, council, and founder flags do not stack above the ceiling.
* **Events and dashboard:** `RankWeightUpdated` records each changed rung. Vote previews read this registry rather than a copied table.
* **Technical reference:** [RankVotingWeightRegistry](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/RankVotingWeightRegistry.md)

## Earning and project custody

### EQTBLTActivityTracker

* **Purpose:** Authorized `WORK` issuer and durable activity ledger for governance recency and tenure.
* **Authority:** `WORK_RECORDER` validates and mints ordinary work. `VAULT_RELEASER` records ProjectFlow settlement without minting twice.
* **Actions:** Record approved work with class, guild, minutes, and rate; record a vault release; and read 30/90/180-day, lifetime, yearly, and effective activity.
* **Lifecycle and policy:** Records enter rolling 30-day buckets. Class rate bands and tenure thresholds come from ParameterRegistry; guild merit may apply a bounded modifier.
* **Safety:** Good standing, positive time/amount, rate bands, role authority, and settlement path are atomic. The ProjectFlow-only community class cannot direct-mint.
* **Events and dashboard:** `WorkRecorded` contains full earning provenance. Task approval only prepares a transaction; UI marks credits earned after confirmation.
* **Technical reference:** [EQTBLTActivityTracker](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/EQTBLTActivityTracker.md)

### RentalAndRebate

* **Purpose:** `RENT` issuer for Housing Loyalty, based on a qualifying lease and recorded rent payments.
* **Authority:** `RENTAL_OPS` registers/closes leases and records qualifying payments.
* **Actions:** Register a lease with unit, monthly rent, and property rate; close it; record one payment for a unique period; and read trailing 180-day RENT history.
* **Lifecycle and policy:** A lease stamps its rate until renewal. The normal range is 5–15% with 10% default: high-demand/high-cost properties tend lower; rural, lower-demand, or lease-up properties may use more.
* **Safety:** Good standing is required, unrelated charges are excluded by workflow, a record cannot exceed monthly rent, periods cannot repeat, and rate bounds fail closed.
* **Events and dashboard:** Index `LeaseRegistered`, `LeaseClosed`, and `RentPaymentRecorded`. Show the stamped rate and qualifying payment—not a universal rebate, cash redemption, property interest, or governance right.
* **Technical reference:** [RentalAndRebate](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/RentalAndRebate.md)

### FlowTreasurer

* **Purpose:** Factory, registry, and authorization root for the cohort → epoch → project `WORK` custody tree.
* **Authority:** `FLOW_VAULT_CREATOR` creates vault proxies, `TREASURY_OPS` authorizes cohort budgets, and `UPGRADER` changes the template or treasurer implementation.
* **Actions:** Create a vault at its correct level/parent, authorize a cohort budget, register child allocations, enumerate vaults/authorizations, and verify the path an authorization reached.
* **Lifecycle and policy:** Budget begins at an active cohort vault and moves only one direct tree edge at a time. Each authorization preserves origin and reached-vault set.
* **Safety:** Only registered vaults enter the fixed-depth tree, scope references are unique, and creation grants strict vault/release classifications.
* **Events and dashboard:** Join `VaultCreated`, `BudgetAuthorized`, and `BudgetAllocated` by authorization and scope. Distinguish authorization, custody, task encumbrance, and release.
* **Technical reference:** [ProjectFlow](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/ProjectFlow.md)

### ProjectFlowVault

* **Purpose:** Isolated `WORK` custody for one cohort, epoch, or project; each vault is its own proxy and accounting boundary.
* **Authority:** Its derived manager and ancestor managers may fund, pause, recall, recover, and close; `TREASURY_OPS` has recovery authority; only `FLOW_RELEASER` settles project work.
* **Actions:** Fund a child, release work, recall, pause/unpause, recover an unexpected bucket, close/sweep, and inspect balance/ancestry.
* **Lifecycle and policy:** Active vaults fund/release, paused vaults block new movement but remain recoverable, and closed vaults are terminal. Releases share ActivityTracker policy.
* **Safety:** Release checks level, authorization path, standing, formula, custody, and cap. Closing sweeps the complete bounded bucket set to the parent.
* **Events and dashboard:** Join `WorkReleased`, `BudgetRecalled`, and `VaultStatusChanged` with token transfer and tracker events in the same transaction.
* **Technical reference:** [ProjectFlow](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/ProjectFlow.md)

## Treasury, revenue, and operating funds

### Treasury

* **Purpose:** Main asset vault, gross/net revenue ledger, EQTBLT custody ledger, and controlled source of operating funds.
* **Authority:** Strict `REVENUE_SOURCE` contracts deposit; `TREASURY_OPS` handles operations/reversals/custody; `GOV_EXECUTOR` executes proposals; `PAUSER` brakes ordinary outflows; `SUPER_ADMIN` owns an evented emergency lane and vault registry.
* **Actions:** Deposit cash, ERC-20, ETH, or bucketed credit revenue; reverse eligible revenue; execute rail-checked withdrawals; fund registered vaults; route credits; and maintain the vault registry.
* **Lifecycle and policy:** Gross receipts never rewrite; reversals accumulate separately. Daily, monthly, proposal, and reserve-floor rails come from policy and live balances.
* **Safety:** Deposits pull value atomically, source references/buckets persist, ordinary outflows stop while paused, and emergency withdrawal is separately authorized and reason-evented.
* **Events and dashboard:** Reconcile revenue, reversal, credit, withdrawal, vault-funding, and disposal events. Separate booked/net revenue, balance, proposal state, and rail capacity.
* **Technical reference:** [Treasury](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/Treasury.md)

### OperatingBudgetVault

* **Purpose:** Reusable operating account with an isolated manager lane and Treasury recovery controls.
* **Authority:** The address-derived manager spends while active. `TREASURY_OPS` pauses, configures, recalls, and closes. `UPGRADER` upgrades the proxy.
* **Actions:** Accept ERC-20/ETH, spend with a memo, configure cap/allowlist, recall funds, or close and sweep to Treasury.
* **Lifecycle and policy:** It starts active, may alternate active/paused, and becomes permanently closed after listed tokens and ETH are swept.
* **Safety:** Spending requires active state, allowed token, positive amount, and cap compliance. Recovery remains available in every state.
* **Events and dashboard:** Index spending, recall, state, closure, cap, and allowlist changes. Show this vault's manager, identity, balances, and limits separately.
* **Technical reference:** [OperatingBudgetVault](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/OperatingBudgetVault.md)

### FounderFund

* **Purpose:** Named OperatingBudgetVault instance for approved founder operations—not a separate implementation, personal wallet, or automatic revenue entitlement.
* **Authority:** Its own manager spends; Treasury retains the same pause, recall, configuration, close, and recovery authority as every operating vault.
* **Actions:** Receive explicit Treasury allocations and make memoed, capped, optionally allowlisted operating payments.
* **Lifecycle and policy:** It follows active → paused → terminally closed. Funding enters only through explicit approved transfers.
* **Safety:** No contract skims a founder percentage from revenue. Funding and spending remain governed by Treasury and vault rails.
* **Events and dashboard:** Use shared vault events but label the manifest proxy FounderFund. Present allocations and expenses, never a personal claim on receipts.
* **Technical reference:** [FounderFund](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/FounderFund.md)

### BLTBYBank

* **Purpose:** Inventory-backed BLTBY sale mechanism reserved for a future separately approved public-token launch.
* **Authority:** Buyers call purchase paths; `SUPER_ADMIN` lists stablecoins and maintains feeds; `TREASURY_OPS` returns inventory; `PAUSER` stops purchases.
* **Actions:** Quote/buy with approved stablecoin or ETH, maintain coins/feeds, withdraw inventory, and read purchased USD totals.
* **Lifecycle and policy:** Treasury supplies inventory first. Registry policy supplies bounded price, per-address cap, oracle age, and sequencer grace.
* **Safety:** Coins must be listed, ETH requires fresh oracle and healthy sequencer, minimum output protects slippage, caps are cumulative, and proceeds book to Treasury atomically.
* **Events and dashboard:** Index purchases and configuration/inventory changes. Source or address alone never makes a sale live; launch approval and inventory must be confirmed.
* **Technical reference:** [BLTBYBank](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/BLTBYBank.md)

### Bookings

* **Purpose:** Two-leg reservation custody for fee and optional deposit, with payer-bound refunds and explicit disputes.
* **Authority:** `BOOKING_MANAGER` configures unit-backed assets/policies; payers reserve; `BOOKING_OPS` settles normal states; the asset operator marks exceptions/claims; `TREASURY_OPS` executes exceptional refunds.
* **Actions:** Configure assets, reserve, capture, cancel/refund, mark/execute forfeiture, request/execute exceptional refund, release deposits, or file/execute claims.
* **Lifecycle and policy:** Reservation freezes payer, terms, value, token, bucket, and provenance. Fee and deposit then follow separate settlement states; claims wait 72 hours.
* **Safety:** Both legs pull atomically, refunds return only to payer, policy/unit status recheck, exceptional approval is split from movement, and replayed transitions revert.
* **Events and dashboard:** Index configuration, custody, fee resolution, deposit resolution, evidence, and window timestamps; mirror each leg independently.
* **Technical reference:** [Bookings](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/Bookings.md)

### PaidMembership

* **Purpose:** Auditable recurring or prepaid amenity membership custody, with revenue earned by period.
* **Authority:** `BUSINESS_MANAGER` creates plans and signs bounded member quotes; the member accepts and cancels; `MEMBERSHIP_OPS` performs scheduled pulls.
* **Actions:** Create/activate plans, sign up monthly or 3/12 months, cancel, reactivate with a fresh quote, and pull one or batch of due periods.
* **Lifecycle and policy:** Monthly service stays active through paid-through cancellation. Failure enters exactly seven days of Grace, may recover, then lapses. Prepaid discounts are 7%/17%; unused whole months refund to the member.
* **Safety:** Quotes bind member, plan, asset, bucket, policy key, rate, term, expiry, nonce, chain, and contract and are replay-protected without exposing standing tier. Closed units atomically refund remaining prepaid custody.
* **Events and dashboard:** Index opaque quote use, start, pull, failure, Grace, lapse, cancellation, and reactivation. Show paid-through, due date, held remainder, and actual state.
* **Technical reference:** [PaidMembership](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/PaidMembership.md)

## Business and spending loop

### DAOBusiness

* **Purpose:** Isolated books and custody for DAO-operated units, including receipts, refunds, revenue, balances, and spend requests.
* **Authority:** `BUSINESS_MANAGER` manages units; customers pay; unit managers request/cancel spends; strict booking/membership sources credit their lanes; `TREASURY_OPS` executes, refunds, refills, transfers, and sweeps.
* **Actions:** Accept listed stablecoin, bounded-price BLTBY, or bucketed EQTBLT; credit deposits/membership periods; refund; request/execute spends; transfer between units; and sweep to Treasury.
* **Lifecycle and policy:** Units start active, may suspend/reactivate, and close permanently. Receipts retain value/provenance; spends progress pending → executed/cancelled.
* **Safety:** Ledgers are unit-isolated, managers cannot execute requests, active state rechecks, closed units reject credits, and EQTBLT preserves bucket/cap rules.
* **Events and dashboard:** Reconcile unit, payment, refund, revenue-credit, refill, transfer, spend, and sweep events per unit, including refund reserves and terminal state.
* **Technical reference:** [DAOBusiness](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/DAOBusiness.md)

### SpendRouter

* **Purpose:** Member-facing EQTBLT valve for Home Rebate, Rent, Commercial Space, DaoAccess, and Services/Store.
* **Authority:** Members spend after bucket approval. `TREASURY_OPS` routes collected custody to Treasury or an active registered business.
* **Actions:** Spend through an enabled lane with a reference, inspect seasoning/discount, and route custody onward without changing bucket.
* **Lifecycle and policy:** Lanes fail closed until enabled. Housing uses require 180-day seasoning. Store discounts use bounded rank policy.
* **Safety:** No cash-out lane exists. Amount, lane, allowance, balance, seasoning, destination, and business cap all recheck. Spending transfers rather than burns.
* **Events and dashboard:** `Spent` records member/lane/bucket/reference; `CustodyRouted` records later settlement. Display these as distinct steps.
* **Technical reference:** [SpendRouter](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/SpendRouter.md)

### BusinessCreditFacility

* **Purpose:** Bounded liquidity for registered businesses, not member cash redemption.
* **Authority:** `CREDIT_MANAGER` sets terms/issues loans; businesses convert; borrowers repay; `TREASURY_OPS` manages reserves.
* **Actions:** Set conversion/loan terms, convert credits for USDC, issue/repay `WORK` loans, inspect debt/overdue state, and move reserves.
* **Lifecycle and policy:** Rolling business/DAO budgets constrain conversion and exposure. Loans store principal, full owed amount, due date, and open/closed state.
* **Safety:** Conversion ≤95%, interest ≤15%, both lanes require reserves, repayment uses `WORK`, and remaining principal or interest blocks cash conversion.
* **Events and dashboard:** Index terms, conversion, loan, repayment, and reserves. Business views show full debt/due status; member pages never advertise this facility as cash-out.
* **Technical reference:** [BusinessCreditFacility](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/BusinessCreditFacility.md)

## Governance and investor allocation

### Governance

* **Purpose:** Tricameral proposal, snapshot, voting, finalization, cooling-off, and execution for Contributor, Council, and Investor houses.
* **Authority:** Qualified members sponsor; `SNAPSHOT` commits eligibility; snapshotted voters/council vote; anyone finalizes/executes on time; `SUPER_ADMIN` has reasoned cancellation; `UPGRADER` upgrades.
* **Actions:** Propose/withdraw, commit snapshot, cast house/council votes, finalize, execute after cooling-off, or founder-cancel.
* **Lifecycle and policy:** Active proposals enter snapshotted voting, finish passed/rejected, and passed proposals wait category cooling-off. Categories define houses, sponsor rank, stake, thresholds, quorum, target, and value permission.
* **Safety:** Every required house independently consents. Contributor power uses square-root EQTBLT with bounded rank/tenure, small-N one-member-one-vote, overlap cap, committed denominators, and category-bound execution.
* **Events and dashboard:** Index every lifecycle event and reason. Previews reproduce exact curve/snapshot and buttons respect eligibility, prior vote, deadlines, and cooling-off.
* **Technical reference:** [Governance](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/Governance.md)

### GuildGovernance

* **Purpose:** One-member-one-vote decisions for one guild, separate from system Treasury/constitutional execution.
* **Authority:** Good-standing guild credential holders propose, vote, or escalate. Anyone finalizes after the window. `UPGRADER` alone administers implementation.
* **Actions:** Create, vote for/against, finalize, or escalate with a reason for main Governance follow-up.
* **Lifecycle and policy:** Active proposals use a registry window and end passed when for > against, rejected on tie/loss, or escalated while active.
* **Safety:** Live roster/standing recheck, one vote each, deadlines enforced, no stake, no target call, and no founder cancellation lane.
* **Events and dashboard:** Index creation, votes, finalization, escalation. Escalation is a request for a separate system proposal, not execution.
* **Technical reference:** [GuildGovernance](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/GuildGovernance.md)

### InvestorBonusAllocator

* **Purpose:** Atomic bridge from verified investor eligibility to collateralized BLTBY vesting bonus, separate from the subscription security.
* **Authority:** `INVESTOR_OPS` performs initial/follow-on attestations; `UPGRADER` upgrades; credential and vesting contracts enforce their strict lanes.
* **Actions:** Attest, increase attestation, calculate expected cumulative bonus, and verify granted amount equals formula.
* **Lifecycle and policy:** First attestation creates credential, locks reference price, calculates bonus, and creates a 12-month cliff plus 12-month revocable vest. Follow-ons true up only positive delta at locked price.
* **Safety:** One initial attestation, required evidence hash, bounded bonus rate, locked price, collateralized schedule, and `bonusConsistent` prevent duplicate/retroactive/underfunded grants.
* **Events and dashboard:** Join allocator, credential, and vesting events. Separate subscribed instrument, verification, bonus calculation, and claim state.
* **Technical reference:** [InvestorBonusAllocator](https://github.com/marquisdavis/BLTBYcontracts/blob/main/docs/contracts/InvestorBonusAllocator.md)

## Dashboard integration rules

* Contract addresses and ABIs come from one validated deployment manifest, never hand-copied constants.
* Before deployment or 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 references, 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.builtbydao.com/developers/contracts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.