Bond Protocol is a fixed-income infrastructure platform enabling decentralized protocols and crypto industry companies to issue revenue-backed bonds to KYC-verified Qualified Purchaser funds. The platform facilitates the complete bond lifecycle: request intake, sealed-bid price discovery, clearing, allocation, escrow, tokenization, repayment streaming, default surveillance, and secondary market trading.

Borrower Types

• On-chain: Lending platforms, DEXes, liquid staking providers, wallet providers, data providers, oracles, and any entity generating protocol-native revenue
• Off-chain: Data centers, energy farms, specialty finance companies, and any business with predictable cash flows routable through on-chain settlement

Lender Types

• On-chain: DeFi protocols, DAO treasuries, credit pools, and yield-seeking stablecoin holders
• Off-chain: Credit funds, family offices, institutional underwriters — onboarded via third-party custodians (Anchorage, BitGo, Fidelity Digital Assets)

Why On-Chain Lending Infrastructure

Reduced Duration Risk — Top-of-line revenue integration routes repayments automatically from the top of the revenue waterfall. Per-second streaming compresses duration and reduces lender exposure. The question shifts from "will this company survive long enough to repay?" to "how quickly will cash flows arrive?" — converting counterparty risk into manageable duration risk.

Reduced Operational Overhead — Smart contract-based escrow, repayment logic, distribution, and surveillance eliminate manual back-office processes. Bond token minting, repayment routing, pro-rata distribution, and default detection all execute programmatically — reducing cost, human error, and the administrative friction that makes small-to-mid-size credit deals uneconomical in traditional markets.

Reduced Fraud Risk — All fund movements — escrow funding, disbursement, repayment, and secondary trading — settle on-chain with full transparency and immutable audit trails. Zero opacity in the flow of funds between lender, escrow, and borrower.

Reduced Counterparty Risk — Smart contract-level spending approvals route a pre-agreed percentage of revenue directly to escrow. The borrower authorizes the revenue diversion at deal inception; from that point, repayment is automatic and non-discretionary.

Dynamic Repayment Caps — If the repayment schedule drags — revenue coming in slower than projected — the repayment cap can be dynamically raised to increase the revenue percentage flowing to escrow. This creates a self-correcting mechanism: underperforming deals automatically adjust to protect lender IRR rather than requiring manual renegotiation.

Product Spectrum

Bond Protocol's architecture allows every deal to be structured at any point along two independent axes — deal structure and repayment cadence — creating a configurable product space that no single existing protocol covers.

Axis 1: Deal Structure — Ranges from FIXED-RATE DEBT (traditional coupon) through RBF with cap, revenue royalty, to TOTAL RETURN SWAP (full participation).

Axis 2: Repayment Cadence — Ranges from STREAMING (real-time, per-second) through daily, weekly, monthly, quarterly, to BIANNUAL.

Borrowers (Protocols / Crypto Companies)

Requirements / Role:

• Revenue-generating protocols or crypto companies seeking capital through bond issuance
• Active revenue generation (tokenized or traditional streams)
• Revenue pipeline integration capability for automated repayment diversion
• A defined percentage of revenue dedicated to bond repayment
• Legal guarantor identification (required especially for DAOs or non-entity structures)
• KYC completion and entity/protocol documentation

Capabilities / Outputs:

• Issuer details and use of proceeds statement
• Revenue pipeline integration and verification
• Repayment diversion mechanism verification
• Minimum revenue threshold (default trigger floor)
• Existing revenue obligations to other bonds

Lenders (Institutional Qualified Purchaser Funds)

Requirements / Role:

• KYC-verified institutional Qualified Purchasers
• Wallet verification via ZK proofs for allocation and trading wallets
• Proof of capital for bid submission

Capabilities / Outputs:

• Allocate funds to deals and submit bids during bid windows
• Hold bond tokens and receive pro-rata repayment distributions
• Trade bond tokens on the platform exchange
• Set notification preferences for protocol types and deal characteristics

Platform (Bond Protocol — Central Infrastructure Operator)

Requirements / Role:

• Owns and operates the issuance portal and secondary exchange
• Handles KYC verification, deal vetting, bid matching, and clearing
• Manages smart contracts for escrow, repayment, and token operations
• Enforces compliance and operational rules across the lifecycle

Capabilities / Outputs:

• Gatekeeping: KYC, compliance, verification
• Operations: issuance, matching, clearing, escrow management
• Market-making: liquidity provision, transfer enforcement
• Surveillance: default monitoring and enforcement triggers

Protocol Developer / LabCo (Development Entity / Legal Guarantor)

Requirements / Role:

• The development entity or lab company associated with a protocol
• Provides legal guarantees and receives upstream funds
• Bridges decentralized protocol operations and traditional legal frameworks

Capabilities / Outputs:

• Legal backing for bond obligations
• Upstream fund management to protocol treasury
• Critical role for DAO borrowers where no traditional legal entity exists

Phase 1: Pre-Issuance & Onboarding

Borrower Onboarding:

• Entity/protocol documentation
• Use of proceeds statement
• Revenue pipeline integration & verification
• Repayment diversion mechanism verification
• Legal guarantor identification (required for DAOs)
• KYC completion

Lender Onboarding:

• Qualified Purchaser verification (KYC)
• Wallet verification via ZK proofs (allocation + trading wallets)
• Notification preference setup (protocol types, deal characteristics)

Phase 2: Bond Request & Price Discovery

Bond Request Creation — The borrower submits a bond request order that transitions through: DRAFT → platform validation → ACTIVE.

Required Parameters:

• Issuer name / legal entity
• Notional amount (total face value)
• Currency denomination
• Eligible repayment stablecoins (USDC, USDT, etc.)
• Use of proceeds
• % of revenue allocated to this bond
• % revenue currently obligated to other bonds
• Minimum revenue threshold (default trigger floor)
• Legal guarantor identity

Sealed-Bid Price Discovery — Pricing uses Original Issue Discount (OID) — lenders bid a price below par they're willing to pay for face-value bonds. All bids are hidden during the bid window and revealed simultaneously at close.

1. Initial Bid Window (48 hours): All bids hidden. Each bid includes: notional amount (≤ bond request), OID percentage, proof of funds, and timestamp.
2. Bid Reveal & Clearing: All bids revealed simultaneously. Clearing OID determined by sorting bids highest-to-lowest OID and finding the marginal OID where cumulative notional meets or exceeds bond size.
3. Final Bid Window (24 hours): Clearing OID locked. Lenders can submit notional-only bids at the locked price.
4. Borrower Decision: Accept the deal at clearing OID and proceed to allocation, or decline and enter Auto-Intermission — view anonymized bid stack, optionally resize parameters, and restart a new bid cycle.

Phase 3: Commitment, Escrow & Tokenization

Allocation Priority — Weighted priority system: OID level (primary — higher bids receive priority), timestamp (secondary — earlier bids at same OID), and loyalty score (tertiary — historical deal volume and trading activity).

Escrow & Minting — Lenders receive allocation amounts and have a 72-hour funding window to transfer capital. Each bond has a unique escrow address (never reused). Once full escrow is received, the platform rechecks revenue pipeline connectivity, then executes an atomic operation: bond tokens are minted to lender wallets, and the borrower receives funds equal to (Notional × OID) minus platform fees.

Fund Flow Summary:

Phase 4: Repayment

The borrower streams their designated percentage of revenue to a treasury/revenue collecting account. The repayment logic smart contract routes funds on the configured schedule (daily, weekly, monthly) to the amortizing bond repayment account. The platform's bond admin confirms receipt and performs surveillance. Pro-rata distributions flow to all verified bond token holders' proceeds accounts.

The bond is fully satisfied when cumulative repayments equal the notional amount; excess funds return to the borrower treasury.

Phase 5: Secondary Trading

Bond tokens are automatically listed on the platform's vertically integrated exchange post-issuance. Trading is restricted to KYC-verified lenders only. All trades settle onchain. Sellers transfer bond tokens to the exchange hub, buyers transfer payment, and the exchange routes tokens to the buyer and proceeds to the seller. New lenders can enter the market by purchasing existing bond positions.

The platform may restrict trading of defaulted or disputed bonds. An optional liquidity pool or RFQ system is available for thin order books.

Each bond deal produces a unique set of fungible tokens. Tokens are fungible within a single bond deal only (not across deals) and are transferable only to KYC-verified lender wallets.

Token Properties

Token Layer — Hybrid Standard

Primary Issuance Layer ERC-1400 or ERC-7518 — Compliance-controlled, tranche-partitioned bond issuance with KYC/AML hooks, transfer restrictions, and operator roles. Provides the regulatory controls needed for securities-classified instruments.

Secondary Trading Layer ERC-20 wrapped — Wrapped versions for DeFi composability and liquidity on the platform exchange. Enables standard wallet compatibility and integration with existing DeFi infrastructure.

Streaming Layer Super Token wrappers (Superfluid-compatible) — For continuous repayment flows when configured for streaming cadence. Enables per-second revenue diversion directly into repayment contracts.

Repayment is the core mechanism that differentiates Bond Protocol from traditional credit platforms. Rather than relying on borrower discipline to service debt, the platform uses smart contract-level spending approvals to route a pre-agreed percentage of revenue directly to escrow.

Repayment Flow

1. Revenue Streaming: The borrower streams their designated percentage of revenue to a treasury/revenue collecting account. The borrower authorizes this revenue diversion at deal inception — from that point, repayment is automatic and non-discretionary.
2. Smart Contract Routing: The repayment logic smart contract routes funds on the configured schedule (daily, weekly, monthly) to the amortizing bond repayment account. Schedule cadence is independently configurable from real-time streaming (per-second, Superfluid-style) through biannual.
3. Surveillance & Confirmation: The platform's bond admin confirms receipt and performs surveillance. Monitors for payment defaults and revenue threshold breaches.
4. Pro-rata Distribution: Pro-rata distributions flow to all verified bond token holders' proceeds accounts. Distribution is proportional to token holdings at the time of each payment.
5. Bond Satisfaction: The bond is fully satisfied when cumulative repayments equal the notional amount. Excess funds return to the borrower treasury. Protocol obligation ends.

Dynamic Repayment Caps

If revenue underperforms and the repayment schedule drags beyond the projected timeline, the revenue commitment percentage can be dynamically raised. This shifts the deal structure toward the total return swap end of the spectrum, increasing the revenue percentage flowing to escrow and improving the lender's IRR.

Revenue Pipeline Integration

ON-CHAIN — Smart contract claims against protocol revenue streams, DAO treasuries, or on-chain accounts receivable. Revenue is verifiable directly on-chain without oracle intermediaries.

OFF-CHAIN — Webhooks/API integrations with Stripe, Square, and other POS/payments infrastructure → stablecoin conversion (Circle/USDC, Paxos/USDP, Tempo) → escrow smart contract. Requires oracle infrastructure to bridge off-chain revenue figures on-chain (architecture TBD).

Disbursement Mechanics

The current design supports manual claim with optional automation. During idle time between revenue receipt and disbursement, escrow balances can earn yield via tokenized Treasuries (4-5% baseline), money market protocols, or stablecoin yield strategies. The escrow yield share — a portion of yield generated on idle escrow balances — represents an additional revenue stream for the platform.

An Event of Default occurs when either of the following conditions is met:

Payment Default — Revenue exists but no funds are received in the disbursement escrow for 2 consecutive payment periods.

Revenue Default — Revenue falls below the agreed minimum monthly threshold for 2 consecutive months.

Enforcement Cascade

Upon default, the following enforcement sequence is triggered:

1. Notification: Borrower is notified of the Event of Default. The trustee (or paying agent and collateral agent, if no trustee) is also notified.
2. Remediation Window: Borrower is given opportunity to take remedial action and cure the default.
3. Default Flagging: If no remedial action is taken and the Event of Default persists, bond tokens are flagged as "in default."
4. Guarantor Enforcement: Guarantor enforcement triggers activate — contractual and legal remedies are pursued through the legal guarantor/LabCo entity.
5. Trading Restriction: Secondary market trading of the defaulted bond tokens may be paused by the platform.

Escrow Architecture

Every bond has a unique escrow contract address (never reused). The escrow handles three phases: (1) collecting lender capital during the 72-hour funding window, (2) disbursing funds to the borrower minus fees upon full funding, and (3) collecting revenue repayments and distributing pro-rata to bondholders.

Order Book Architecture

Position Exchange — Platform-operated marketplace for bond token trading. All tokens automatically listed post-issuance. Only KYC-verified lenders may trade. All trades settle onchain. Optional liquidity pool or RFQ system for thin order books.

Option Order Book — Parallel market for trading duration exposure, allowing lenders to hedge or speculate on cash flow timing. May trigger CFTC jurisdiction — see Regulatory section.

Offchain / Onchain Split

A deliberate architectural decision separates negotiation from settlement. This keeps sensitive negotiation data off-chain while providing full transparency and immutability for settlement.

Offchain: OID finalization, Notional amount negotiation, Notional confirmation, Borrower signoff, Legal signatures

Onchain: Cleared allocation records, Bond token minting, Escrow funding, Repayment flows, Pro-rata distributions, Secondary market trades

Settlement Infrastructure

The platform supports settlement across multiple EVM-compatible chains and stablecoin rails:

• Chains: Ethereum mainnet, Solana, Arbitrum, Base, or any EVM-compatible L1/L2
• Stablecoin Rails: Stripe/Tempo, PayPal/PayPal USD, Tether, Arc/USDC
• Off-chain Integration: Plaid, Zelle, consumer finance apps (Venmo), clearinghouses (DTCC)
• Stablecoin Compliance: All integrations must use GENIUS Act-compliant issuers: 1:1 reserve backing required, interest payments on payment stablecoins prohibited

Streaming Infrastructure Partners

Superfluid (~$30M TVL) — Core infrastructure candidate for the streaming repayment layer. CFA (Constant Flow Agreement) primitives directly applicable to per-second revenue diversion.

Sablier (~$6M TVL) — Stream-as-NFT model and custom streaming curves (linear, exponential, cliff) relevant to flexible repayment schedule design.

Revenue Model

Market Sizing

Pricing Mechanism: OID Bidding

Bonds are priced via Original Issue Discount — lenders bid the price they'll pay per unit of face value. A bond issued at 85 OID means the lender pays $0.85 for every $1.00 of notional. The lender's return comes from the spread between purchase price and full notional repayment, plus timing (faster repayment = higher IRR).

IRR Sensitivity Table

Lender IRR based on bond size (as % of annual revenue) and revenue commitment percentage. Assumes 0% coupon, 85 OID.

Bond Sizing Example

A protocol with $60M/year revenue and a 5% revenue commitment generates $3M/year in repayment capacity. Maximum LTV = 30% of $240M (4× revenue) = $72M total bond capacity. This can be structured as $6M series bonds, each with approximately 2-year payback.

Tax Treatment

The IRS typically treats revenue-based financing as "contingent payment debt instruments" under the Non-Contingent Bond Method (NCBM). Borrower payments are generally deductible as interest if classified as debt; non-deductible dividends if reclassified as equity. Lenders face potential "phantom income" — tax liability in early years exceeding actual cash received.

Addressable Borrower Universe

On-chain protocols with stable recurring revenues represent the primary market: Aave ($809M in 2025), Uniswap ($1.5B fees), Jito ($813M), Hyperliquid ($1B+), Jupiter ($1.1B). More volatile protocols (Meteora $1.25B, Pump.fun $937M) suit the revenue-swap end of the spectrum. The off-chain addressable market (global private credit) is approximately $2T in AUM.

Securities Classification

Bond Protocol's receipt tokens almost certainly constitute investment contracts under Howey. The platform must operate within recognized exemptions.

Money Transmitter Risk

Escrow balances may trigger Money Services Business (MSB) classification under the Bank Secrecy Act. Three potential mitigation paths:

1. Custodial pass-through: Route all escrow through Anchorage Digital (OCC-chartered federal bank). Their banking charter covers money transmission.
2. Non-custodial smart contract escrow: If the platform never has control over funds (smart contract-only custody), MSB classification may not apply. Requires careful contract design.
3. Full MSB registration: Register with FinCEN and obtain 47+ state money transmitter licenses. Expensive and time-consuming but provides maximum regulatory clarity.

Derivatives & Broker-Dealer

The option order book may trigger CFTC jurisdiction. Revenue swaps may be classified as "swaps" under Dodd-Frank Title VII. If facilitating securities trading, broker-dealer and/or ATS registration may be required.

Capital Stack & Custodial Partners

Anchorage Digital — OCC-chartered federal bank (Jan 2021). Only crypto-native federal bank. $4.2B valuation. Atlas collateral management network (~600 participants). Custody for BlackRock ETFs ($50B+ AUM). Stablecoin issuance platform launched July 2025. Priority custodial partner — ideal for institutional escrow and collateral management.

BitGo — OCC conditional approval (Dec 2025). $90B+ AUC. NYSE IPO filed Jan 2026. MiCA-compliant EU licenses. Secondary custodial partner.

Fidelity Digital Assets — OCC national trust charter (2025). Backed by $4T+ AUM parent. Institutional credibility.

Stablecoin & On-Ramp Compliance

Settlement and escrow rails use Circle (USDC), Paxos (USDP/PYUSD), and Tempo. All integrations must use GENIUS Act-compliant issuers (enacted July 18, 2025): 1:1 reserve backing required, interest payments on payment stablecoins prohibited, and stablecoin holders have priority in insolvency.

The platform follows a phased rollout strategy designed to maximize defensiveness in early stages, adding complexity and broader access as regulatory clarity and market validation are established.

Phase I — Maximum Defensiveness, No Securities Features

Launch configuration — minimize regulatory surface area.

Lenders:

• Only Qualified Institutional Buyers (QIBs)
• No natural persons (regardless of financial status)

Borrowers:

• Blue-chip protocols with significant revenue
• Protocols where the founders are known to the team historically

Structure:

• 0% interest amortizing bond, with amortization paid at par
• Issued at a discount negotiated between lender and borrower (OID)
• Minimum amortization payment each period + "cash flow sweep" based on excess cash flow (revenue minus fees owed contractually to other stakeholders)
• Maturity of 10 years

Transferability:

• Only transferrable to other vetted QIBs
• Assignment fee of $250 per transfer

Marketing:

• No public marketing — only hand-picked lenders
• Borrowers approach platform directly, or are selectively recruited

Protocol Revenues:

• Assignment fees ($250 per transfer)
• Platform fee proportionate to deal size (pending finalization)

MVP Milestone Tracker

• ✓KYC + Wallet Verification
• ✓Bond Request Order Model
• ✓Bid Engine + Clearing Logic
• ✓Escrow + Tokenization Smart Contracts
• ○Onchain Repayment Streaming
• ○Secondary Trading Venue
• ○Trustee Enforcement Framework
• ○Default/Dispute Protocols

Interactive flow diagrams showing the three core protocol flows with color-coded actors.

The following questions represent unresolved design decisions that will shape the protocol's final form. They are organized by domain and annotated with context to aid decision-making.

Architecture

• Oracle design for off-chain revenue — The critical trust assumption. Chainlink, custom oracle, or hybrid?
• Cross-chain settlement for mirrored ERC-20s — Needed for option order book across multiple L2s
• Payment processor ToS compliance — Do Stripe/Square permit revenue-splitting to crypto escrow?

Credit & Underwriting

• Underwriting model — Algorithmic, human (credit committee), or hybrid? Maple uses pool delegates; Goldfinch uses auditors + backers
• Internal credit ratings/scoring for protocols — Do we build this in-house or partner with an existing provider?
• Recovery mechanisms for off-chain borrowers who disconnect — Limited technical recourse when off-chain payment pipeline is severed

Legal Structure

• Entity wrapper for receipt tokens — SPV per deal, master trust, or series LLC?
• Trustee structure, authority, and technical capabilities — Who serves as trustee? What powers do they have?
• Broker-dealer and/or ATS registration requirements — Triggered by secondary trading and option order book
• Legal guarantees — Who provides them? Under what jurisdictions? What enforcement mechanisms?

Product Design

• Callable debt — Should borrowers have early repayment options? How does this affect IRR?
• Debt buyback — Can protocols repurchase bonds from secondary markets?
• Auto-buyback — Should revenue be used to auto-buy tokens below par?
• Perpetual bonds — Non-repayment-based yield tokens — is there a market?
• Bond pooling — Should bonds be pooled like MBS structures? Risk layering implications?
• Collateralization — Can borrowers lock tokens as backup? How is it forfeited?
• Disbursement mechanics — Manual claim vs. automatic distribution — gas cost and UX tradeoffs

Economic Design

• Escrow yield strategy and associated risk management — How aggressively to deploy idle escrow capital?
• Pricing oracle for secondary market — TWAP? Offchain? What feeds are needed?
• Liquidation mechanics and circuit breakers for the option order book — Prevent cascade failures
• Token recovery if bond tokens are lost — Key management failure recovery path?