Bond Protocol Spec

ℹ

CONFIDENTIAL — Internal Protocol Specification | v3.2

ℹ

v3.2 integrates four working-session discussions (Apr 2–10, 2026). See spec_v2/discussion-notes-synthesis.md for the delta log.

Protocol Overview

Hexproof's Bond Protocol is a private credit platform enabling unsecured loans (with recourse) to DeFi protocols, crypto-native companies, and off-chain businesses.

For lenders (primarily institutions): familiar credit workflows, attractive IRR/MOIC. For borrowers: programmatic, lower-cost alternative to traditional private credit. Each deal is calibrated to the appropriate risk-return point for the specific borrower-lender pair — the platform's configurable product spectrum (see below) covers repayment structures and frequencies that traditional infrastructure cannot support.

★

Economic terms finalized off-chain. On-chain rails handle escrow, settlement, and payment. Custodians facilitate off-chain lender onboarding.

Traditional Capital Stack

Default/liquidation waterfall priority:

Senior secured debt — first claim; negative pledge clause restricts additional debt
Senior unsecured debt — second priority; contractual seniority
Subordinated / junior debt — lower priority; higher yield
Other liabilities — trade payables, accrued obligations
Preferred equity — senior equity tranche
Common equity — residual claims; last in line

Bond Protocol introduces top-of-line repayments above this entire waterfall. Revenue is diverted programmatically — via smart contract spending approvals or payment integrations — before the borrower's capital stack is relevant. Lenders have been partially or fully repaid through continuous automated diversion before any default waterfall applies.

Why On-Chain Infrastructure

Reduced Duration Risk — Top-of-waterfall diversion, programmatic routing, and high-frequency repayment schedules compress lender exposure vs. standard annual/biannual cycles
Reduced Operational Overhead — Automated integrations handle cash flow computation and reporting, minimizing manual back-office processes. Sub-$75M deals become economical
Reduced Fraud Risk — Detection window collapses from quarters/years to days/hours. All fund movements flow through monitored channels; diversion is immediately visible. (Wirecard concealed €1.9B for years — impossible here.)
Reduced Counterparty Risk — Automated integrations route cash flows per pre-agreed terms directly to escrow. Post-inception, repayment requires no borrower action

Product Spectrum

Every deal sits on two independent spectrums:

Spectrum 1: Exposure — increasing lender exposure to borrower performance →

Fixed-term / floating rate	Loans with fixed caps	Dynamic caps / RBF	Residuals / royalties	Total return swaps

Spectrum 2: Repayment Frequency — decreasing frequency →

Streaming / top-of-waterfall	Daily / weekly	Monthly	Quarterly (best-in-class)	Biannual / annual (standard)

The value proposition: opening the left side of both spectrums — structures requiring smart contracts and continuous monitoring that traditional infrastructure cannot support.

⚠

Product spectrum complicates tax treatment. Fixed-rate = clean "debt." Total return swaps may be reclassified as equity. Phase I restricts to 0% interest amortizing bonds. Each product type requires independent tax counsel.

Transaction Types

Type	Description	Example Borrowers
On-chain revenue loans	Against natively verifiable protocol revenue	Perp DEXes (Hyperliquid, Jupiter), established DeFi protocols
Equipment / infra loans	New equipment or capacity expansion	Data centers (H100 GPUs), frontier AI companies
Residuals	Recurring, predictable cash flows	Data centers w/ long-term contracts, staking providers (Lido)
Revenue swaps	Revenue participation — equity-like upside, no dilution	Energy farms, data centers. Unique product: no one else offers this.
AR / Invoice factoring	Against outstanding receivables	B2B crypto service providers
M&A financing	Protocol or company acquisitions	Consolidating protocols, AI consolidation survivors

Debt vs. Preferred Equity

Covenant protection: Leverage tests, debt incurrence tests, FCF tests prevent debt layering
Anti-layering: Preferred stockholders cannot prevent senior debt above them. Debt holders can.
Programmatic claims: Direct automated claim on cash flows — enforcement, not just a promise

Lender Types

On-chain: Credit facilities, liquid funds, stablecoin vaults — any source seeking novel yield
Off-chain: Credit funds, family offices, institutional underwriters — via third-party custodians

Capital Flow

               LENDER SIDE                              BORROWER SIDE
        ┌─────────────────────┐                  ┌─────────────────────┐
        │  Off-chain Lender   │                  │  On-chain Borrower  │
        └────────┬────────────┘                  └──────────┬──────────┘
            via custodian                                   ▲
                 ▼                                          │
        ┌─────────────────────┐  loan proceeds   ┌─────────┴─────────┐
        │  On-chain Lender    │ ───────────────> │   ON-CHAIN ESCROW │
        │                     │ <─────────────── │                   │
        └─────────────────────┘  repayment flow  └─────────┬─────────┘
                                                     loan proceeds
                                                     (optional offramp)
                                                           ▼
                                                  ┌─────────────────────┐
                                                  │  Off-chain Borrower │
                                                  └────────┬────────────┘
                                                  cash flow routes back
                                                  via payment integrations
                                                  (Stripe, Visa, Plaid, Paxos)
                                                           ▼
                                                     back to escrow
                                                   → lender proceeds

System Actors

Borrowers

Revenue-generating protocol, company, off-chain business, or a named revenue stream within one. Each deal declares a scope parameter:

single_stream — attached to one identified revenue source (Stripe account, protocol fee switch, data center PPA). Factoring-shaped.
global_percentage — attached to a % of the entity's total cash flow. Corporate-bond-shaped; where the top-of-waterfall diversion thesis lives.

An entity with N streams may run up to N single_stream deals, one global_percentage deal, or a hybrid (cross-default handling in §06).

Requirements: revenue integration (on-chain transferFrom approval OR Router-paired PSP integration, §05), repayment commitment, SPV (§07), KYC.

Lenders

Phase I: KYC-verified QIBs only — no natural persons. On-chain credit facilities, liquid funds, stablecoin vaults also eligible. Requirements: wallet verification, proof of capital.

Outputs: fund allocation, bid submission, receipt token holding, pro-rata distributions, secondary trading.

Platform

Central infrastructure operator. Issuance portal, secondary exchange, KYC/compliance, deal vetting, smart contract deployment, custodial partner coordination, real-time monitoring.

SPV / LabCo

Per-deal SPV issues receipt tokens and holds the signed loan agreement as its sole asset. LabCo is reserved for the DAO-bridging development entity that sits between a DAO borrower and the SPV. On default, the SPV — not the token holders — is the creditor of record; token holders direct the SPV to exercise enforcement rights.

⇄

KYC for all participants limits to institutional actors but satisfies Reg D 506(b)/(c). Compliance-first by design.

        Protocol Flow
        v3.2 · 1 diagram
      
      Deal parameter space · design knobs
      v3.2 · SVG
    Core tuple (P,R,B,S,scope) · R union type · exposure & frequency spectrums

  DEAL TUPLE · (P, R, B, S, scope) + optional modifiers

  CORE TUPLE

    P principal  
    R rate · union  
    B borrower  
    S revenue stream  
    scope { single_stream | global_percentage }
  
  R · REPAYMENT STRUCTURE (UNION TYPE)

  fixed %
  phase-1 default

  floating rate
  hybrid instruments

  fixed % of revenue
  single_stream friendly

  PID-target IRR
  continuous, self-correcting

  SCOPE · WHAT THE DEAL ATTACHES TO

  single_stream
  One named revenue stream · factoring-shaped
  cleaner default math · smaller deal sizes
  N streams per entity → up to N parallel deals

  global_percentage
  % of entity’s total cash flow · corporate-bond-shaped
  top-of-waterfall programmatic diversion
  where the “different product” thesis lives

  EXPOSURE SPECTRUM · ← traditional · novel →

  fixed-term / floating

  fixed caps

  dynamic caps / RBF

  residuals / royalties

  total return swaps

  REPAYMENT FREQUENCY · ← novel · traditional →

  streaming / top-of-waterfall

  daily / weekly

  monthly

  quarterly (best-in-class)

  biannual / annual (standard)

Core deal tuple
Every deal is defined by (P, R, B, S, scope): principal, rate/commitment, borrower entity, revenue stream, and scope parameter.
P is the notional. B is the legal entity; S is the specific revenue stream inside that entity.
scope determines whether the deal attaches to one stream (factoring-shaped) or to a % of the entity’s total cash flow (corporate-bond-shaped).
R is a union type
fixed % — simplest; Phase-1 default for revenue-linked deals.
floating rate — traditional coupon indexed to a reference.
fixed % of revenue — stream-scoped revenue commitment.
PID-target IRR — v3.2 continuous controller driving toward a lender IRR target. Replaces v3.1’s discrete step-function dynamic cap.
Spectrum position
Exposure: where the deal sits on the risk-transfer spectrum from fixed-term loans (left, traditional) to total return swaps (right, novel).
Repayment frequency: from streaming top-of-waterfall (left, novel) to annual (right, traditional). The whole value proposition lives in opening the left side of both spectrums.
Phase-1 deals cluster near the traditional end; Phase-2+ moves rightward (exposure) and leftward (frequency) as the rails are proven.

        Implementation
        POC · 2 excerpts
      

BondToken — ERC-1155 receipt POC/src/BondToken.sol

The actor model collapses to three on-chain roles: borrower, lender, and the BondToken that records lender claims.

contract BondToken is ERC1155, Ownable {
    string public name;
    string public symbol;
    
    mapping(address => bool) public authorized;
    
    event AuthorizationUpdated(address indexed account, bool status);
    
    modifier onlyAuthorized() {
        require(authorized[msg.sender] || msg.sender == owner(), "BondToken: Not authorized");
        _;
    }
    
    constructor(
        string memory _name,
        string memory _symbol,
        string memory _uri
    ) ERC1155(_uri) Ownable(msg.sender) {
        name = _name;
        symbol = _symbol;
    }

Loan struct — what the platform tracks POC/src/interfaces/ILoanController.sol

Every actor in §02 maps to a field on this struct.

    struct Loan {
        uint256 loanId;
        address asset;
        address borrower;
        uint256 amount;
        uint256 expiration;
        uint16 feeBps;
        LoanState state;
        uint256 totalFunded;
        uint256 repaid;
    }

Lifecycle

Canonical 10-Step Sequence

Borrower initiates — RFQ. Deal tuple: (P, R, B, S, scope).
Lender submits a quote — P', R' for (B, S). Default path is out-of-band; in-protocol quoting is an add-on.
Optional negotiation loop.
Borrower creates loan offer whitelisted to a specific lender address.
Proof of legal agreement — verified by Hexproof. Hard gate; toggleable per-loan, default on.
Lender (or custodian) funds escrow — capital sits unspent.
Borrower counter-signs the funded transaction on-chain.
Circuit-breaker delay window opens — configurable (e.g. 24h); either party or Hexproof may cancel (policy under legal review, §11 OQ1).
Atomic issuance — receipt tokens minted → lender; principal released from escrow → borrower (pull). Triggered by the lender address.
Repayments & recycling — cash flows route via the Router (§05) → escrow → lender pro-rata claim by burning receipt tokens.

★

The atomic issuance trigger must come from the lender address. This makes the protocol custody-agnostic: if the "lender" is a QIB, the QIB triggers; if it is a custodian acting for clients, the custodian triggers; if it is Hexproof managing funds on behalf of others, Hexproof triggers. One protocol rule, three valid deployments.

Discovery — Out-of-Band First

Default Phase-I path is out-of-band handshake: counterparties agree terms off-platform, the borrower creates a deal and whitelists the lender's address (mutable until funding). In-protocol RFQ / sealed-bid / open-market clearing remain supported and trigger the full origination fee (§08).

Privacy: deal terms may be opaque; borrower identity is never opaque at the protocol layer (required for KYC, recourse, monitoring).

Negotiation — SPV Models

Terms agreed off-chain via modular contract framework (see §08 Cost Compression). Key terms: revenue commitment R (which may be a union type — see §05), interest/OID, cap structure, scope (single_stream | global_percentage), exposure spectrum position, repayment cadence, notional, maturity, default triggers, SPV model.

SPV Models:

Model	Description	Use Case
Contingent note	SPV issues borrower-dependent note; asset = the loan	Standard single-borrower
Syndicated loan	SPV originates, syndicates to multiple lenders	Larger multi-lender deals
Managed pools	Pooled vehicles with security issuance	Phase II+ — diversified exposure

OID Pricing (Phase I primary): Loan at $0.90/$1.00, no coupon — return baked into discount. Lender: higher IRR from faster recycling. Borrower: no rate-driven defaults.

Disbursement — Pull for Borrower, Push for Lender

Initial proceeds are pulled by the borrower (claim() from escrow) — tax-driven affirmative-act requirement. Ongoing repayments are pushed to lenders automatically (manual claim fallback only).

Flow	Step	Pattern	Amount
Lenders → Escrow	6	direct	Notional × OID
Escrow → Borrower	9	pull	Proceeds minus fees
Escrow → Platform	9	direct	Tiered issuance fee (§08)
Router → Escrow	10	push	r% of revenue stream
Escrow → Lender	10	push	Pro-rata share

Repayment Loop & Principal Recycling

Cash flows routed through the Router (§05) per agreed terms. Real-time monitoring, algorithmic default detection. Pro-rata distribution to receipt token holders. Loan satisfied when cumulative repayments = notional; tokens burned. Lenders withdraw proceeds or roll into next deal; idle escrow earns yield (tokenized Treasuries, 4-5%).

Secondary Trading

Receipt tokens tradeable among KYC-verified participants, settled on-chain. Thin order books use a Pendle-style time-decay AMM. Defaulted tokens are composability-restricted, not just trading-restricted — see §06.

        Protocol Flow
        v3.2 · 1 diagram
      
      Issuance flow · 10-step canonical lifecycle
      v3.2 · SVG
    Discovery → Funding → Circuit Breaker → Atomic Issuance · factory deploys 5 linked contracts

  PHASE A · DISCOVERY & AGREEMENT

    Borrower
    Initiates RFQ
    off-chain / on-chain
  
    Lender
    Submits quote
    P', R' for (B, S)
  
    Borrower
    Creates loan offer
    whitelists lender addr
  
    Hexproof
    Verifies legal
    proof-of-agreement gate
  
  RFQ
  
  quote
  
  submit

    1
  
    2
  
    4
  
    5
  
  3 · optional negotiation loop

  OUT-OF-BAND DEFAULT
  Signal · email · Privy directory

  PHASE B · FUNDING & CIRCUIT BREAKER

    Lender / Custodian
    Funds escrow
    capital sits unspent
  
    Escrow Controller
    per-deal contract
    ERC-4626 vault
  
    Borrower
    Counter-signs
    double-confirm
  
    Circuit breaker
    24h delay window
    either party / Hexproof can cancel
  
  deposit
  
  sign
  
  open

    6
  
    7
  
    8
  
  PHASE C · ATOMIC ISSUANCE (LENDER-TRIGGERED)

    Lender
    Triggers issuance
    protocol-agnostic
  
    Escrow
    Atomic operation
    mint + disburse
  
    Receipt Tokens
    ERC-1400 minted
    to lender address
  
    Borrower
    claim() USDC
    pull pattern · tax-driven
  
  fire
  
  mint
  
  pull

    9
  
  10 · repayment loop via Router (see §05)

  PER-DEAL FACTORY · 5 LINKED CONTRACTS

  Bond Token
  ERC-1400

  Escrow Controller
  ERC-4626

  Agreed-Terms Deal
  (P,R,B,S,scope)

  Revenue Router
  r% / (1-r)% split

  Repayment Engine
  R union type

  R ∈ { fixed %, floating rate, fixed % revenue, PID-target IRR }
  scope ∈ { single_stream, global_percentage }

Steps 1–5 · Discovery & Agreement
Borrower posts RFQ (off-chain or on-chain). Out-of-band handshake is the default path — parties agree terms elsewhere and the borrower whitelists the lender address.
Optional in-protocol negotiation loop (step 3) for deals where Hexproof originates.
Borrower creates the loan offer with tuple (P, R, B, S, scope).
Hexproof verifies proof-of-legal-agreement — hard gate, toggleable, default on.
Steps 6–8 · Funding & Circuit Breaker
Lender (or their custodian) funds the per-deal escrow controller; capital sits unspent.
Borrower counter-signs on-chain now that real money is in escrow — double-confirmation.
Circuit-breaker delay window opens (default 24h). During this window either party or Hexproof may cancel. Anti-griefing rules prevent straw-bid-and-yank attacks.
Steps 9–10 · Atomic Issuance & Repayment
Delay elapses → atomic operation: receipt tokens minted to lender address, principal released from escrow. The atomic issuance is triggered by the lender so the protocol is agnostic to custody topology.
Borrower claims USDC from escrow via pull (tax-driven affirmative act), not push.
Repayment loop begins — Router forwards r% of revenue to escrow; lender receives pro-rata via push.

        Implementation
        POC · 3 excerpts
      

LoanState — the on-chain lifecycle POC/src/interfaces/ILoanController.sol

The eight prose phases compress to six terminal-or-transient states. Discovery and Negotiation happen off-chain; the contract enters at createLoan().

    enum LoanState {
        Funding,
        Active,
        Settled,
        Defaulted,
        Canceled,
        Closed
    }

createLoan — Initialization POC/src/LoanController.sol

Borrower-driven creation. The MVP omits OID pricing, sealed-bid clearing, and SPV model selection — the prose lifecycle is richer than the code.

    function createLoan(
        address asset,
        address borrower,
        uint256 amount,
        uint256 expiration,
        uint16 feeBps
    ) external override returns (uint256 loanId) {
        require(asset != address(0), "Invalid asset");
        require(borrower != address(0), "Invalid borrower");
        require(amount > 0, "Invalid amount");
        require(expiration > block.timestamp, "Invalid expiration");
        require(feeBps <= MAX_FEE_BPS, "Fee too high");
        
        loanId = nextLoanId++;
        
        loans[loanId] = Loan({
            loanId: loanId,
            asset: asset,
            borrower: borrower,
            amount: amount,
            expiration: expiration,
            feeBps: feeBps,
            state: LoanState.Funding,
            totalFunded: 0,
            repaid: 0
        });
        
        emit LoanCreated(loanId, borrower, asset, amount, expiration, feeBps);
    }

lend — Funding & atomic activation POC/src/LoanController.sol

When the last lender pushes totalFunded over the line, the same call transitions state, transfers proceeds, and emits LoanActivated. This is the “Token Issuance” phase from the prose, made atomic.

    function lend(uint256 loanId, uint256 amount) 
        external 
        override 
        nonReentrant 
        loanExists(loanId) 
        inState(loanId, LoanState.Funding) 
    {
        require(amount > 0, "Invalid amount");
        
        Loan storage loan = loans[loanId];
        uint256 remaining = loan.amount - loan.totalFunded;
        uint256 actualAmount = amount > remaining ? remaining : amount;
        uint256 refundAmount = amount - actualAmount;
        
        IERC20(loan.asset).safeTransferFrom(msg.sender, address(this), actualAmount);
        
        loan.totalFunded += actualAmount;
        
        bondToken.mint(msg.sender, loanId, actualAmount);
        
        emit Lended(loanId, msg.sender, actualAmount);
        
        if (refundAmount > 0) {
            IERC20(loan.asset).safeTransferFrom(msg.sender, msg.sender, refundAmount);
            emit OverfundRefunded(loanId, msg.sender, refundAmount);
        }
        
        if (loan.totalFunded >= loan.amount) {
            loan.state = LoanState.Active;
            IERC20(loan.asset).safeTransfer(loan.borrower, loan.amount);
            emit LoanActivated(loanId);
        }
    }

Receipt Token Specification

Each deal produces fungible receipt tokens — the lender's claim on future cash flows. Fungible within a single deal only. Transferable only to KYC-verified wallets.

Property	Value
Naming	`BOND__` (e.g., BOND_AAVE_2512)
Fungibility	Within single deal only
Transferability	KYC-verified wallets only (token-level restrictions)
Entitlements	Pro-rata repayment share, on-chain tracking, exchange trading rights

Token Architecture

Issuance: ERC-1400 — compliance-controlled, tranche-partitioned, KYC/AML hooks. UUPS proxy for upgradability.
Trading: ERC-20-compatible wrappers for exchange compatibility
Streaming: Super Token wrappers (Superfluid) for per-second repayment flows

ℹ

ERC-1400 for Phase I: $36B+ tokenized assets, custodian support (Anchorage/BitGo), proven via Polymath/Securitize. ERC-7518 evaluate for Phase III. Gas mitigated by L2.

Escrow: ERC-4626 vault standard — standardized deposit/withdrawal, DeFi composable, well-audited.

        Implementation
        POC · 1 excerpt
      

BondToken — full contract POC/src/BondToken.sol

The prose specifies ERC-1400 with KYC hooks and tranches. The POC uses ERC-1155 with an authorization allowlist — a deliberate scope cut for the MVP.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {ERC1155} from "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";

contract BondToken is ERC1155, Ownable {
    string public name;
    string public symbol;
    
    mapping(address => bool) public authorized;
    
    event AuthorizationUpdated(address indexed account, bool status);
    
    modifier onlyAuthorized() {
        require(authorized[msg.sender] || msg.sender == owner(), "BondToken: Not authorized");
        _;
    }
    
    constructor(
        string memory _name,
        string memory _symbol,
        string memory _uri
    ) ERC1155(_uri) Ownable(msg.sender) {
        name = _name;
        symbol = _symbol;
    }
    
    function mint(
        address to,
        uint256 id,
        uint256 amount
    ) external onlyAuthorized {
        _mint(to, id, amount, "");
    }
    
    function burn(
        address from,
        uint256 id,
        uint256 amount
    ) external onlyAuthorized {
        _burn(from, id, amount);
    }
    
    function setAuthorized(address account, bool status) external onlyOwner {
        authorized[account] = status;
        emit AuthorizationUpdated(account, status);
    }
    
    function setURI(string memory newuri) external onlyOwner {
        _setURI(newuri);
    }
}

Repayment Mechanics

The core differentiator. The Router — a per-deal contract between revenue source and escrow — atomically splits each inflow r% / (1−r)% and positions lenders at the top of the revenue waterfall.

The Router Primitive

On-chain source: Router holds a transferFrom approval against the borrower's revenue address and pulls r% on each inflow.
Off-chain source: Router is paired with a PSP integration (Stripe, Visa, Plaid, Paxos, or a direct banking partner). Fiat lands in a bridging custodial account; Router executes the split on arrival.
Dispersion frequency is a security tradeoff: longer holding = bigger honeypot. Default policy is streaming or daily; weekly/monthly is flagged in §11 OQ4.

Flow

Router pulls r% of each revenue inflow.
Dynamic Repayment Engine applies the R schedule to compute target r%.
Real-time monitoring, algorithmic default detection.
Pro-rata push to receipt token holders.
Cumulative repayments = notional → tokens burn, excess returns to borrower.

`R` — Repayment Schedule Union

Type	Description	Use Case
Fixed %	Static revenue commitment	Phase-I default for revenue-linked deals
Floating interest rate	Traditional coupon indexed to a reference	Hybrid instruments
Fixed % of revenue	Stream-scoped commitment	`scope = single_stream`
PID-target IRR	Revenue % continuously updated by a PID controller driving toward a target lender IRR	Self-correcting; replaces step-function caps

PID-target is continuous and avoids trigger-threshold gaming, but introduces control-theory failure modes (oscillation, integral windup) that must be bounded.

Dynamic Caps (step-function fallback)

Available for deals that prefer a deterministic rule over continuous control:

Parameter	Value
Trigger	Repayments >10% behind projected amortization for 30+ days
Action	Revenue commitment raised by pre-agreed step (e.g., 500bps)
Constraints	Max cap at inception (e.g., 50%); 30-day cooldown
Reversal	≤5% behind for 60 days → cap reverts one step

Revenue Integration Verification

On-chain inflows verifiable via DefiLlama, Dune, or direct RPC. Off-chain inflows verified through the PSP integration's reporting API.

⚠

Stripe/Square ToS may not permit revenue-splitting to crypto escrow. Legal review required before off-chain onboarding with those providers.

ℹ

zkTLS (TLSNotary, Reclaim Protocol) remains experimental; primary strategy is direct payment integrations.

Idle escrow earns yield (tokenized Treasuries, 4-5%); yield share is additional platform revenue.

        Protocol Flow
        v3.2 · 1 diagram
      
      Repayment & secondary trading · unified flow
      v3.2 · SVG
    Protocol revenue → Router → Escrow → Lender distribution, then secondary exchange

Protocol bond repayment and secondary trading unified flow
A merged diagram showing the repayment lifecycle from protocol revenue through to lender distribution, followed by the secondary bond trading flow between participating lenders via an on-chain exchange hub.

REPAYMENT

  Protocol revenue
  % allocated

1
Stream

  Treasury
  Revenue stream

2
Route

  Repayment logic
  Daily / wkly / mthly

  Lender proceeds
  Pro-rata

3
Funds

  Amortizing repayment
  Surveillance active

4
Confirm

  Bond admin
  Platform

5
Distribute

DYNAMIC REPAYMENT CAPS
If repayment drags → rev % auto-increases
Shifts toward TRS to protect lender IRR

COMPLETION
Bond satisfied when cumulative repayments = notional. Excess → borrower.

SECONDARY TRADING

  Lender (seller)
  Holds bond tokens

1
Sell tokens

  Bond exchange hub
  On-chain · KYC only

2
Buy tokens

  Lender (buyer)
  Acquires position

3
Payment
Proceeds to seller

  Secondary lender
  New entrant

Enter

RESTRICTIONS
KYC-verified only. May restrict defaulted/disputed bonds. All trades on-chain.

Repayment · Router → Escrow → Lender
Protocol revenue streams through the treasury into the dynamic repayment engine.
Smart contract routes r% of each inflow to the per-deal escrow.
Platform bond admin confirms receipt and performs surveillance.
Pro-rata distribution pushed to lender wallets on cadence; tokens burn on satisfaction.
Secondary trading · atomic on-chain settlement
Participating lenders list receipt tokens on the exchange hub (KYC-gated).
Buyer acquires position via atomic swap; proceeds flow back to seller.
New entrants can enter by purchasing existing positions, providing exit liquidity for early lenders.
Defaulted tokens are composability-restricted via the ERC-1400 partition flag (§06) — distressed pricing allowed, downstream leverage frozen.

        Implementation
        POC · 3 excerpts
      

repayPartial — incremental cash flow POC/src/LoanController.sol

The prose describes “Routing → Logic → Surveillance → Distribution → Satisfaction.” The MVP collapses Routing to a borrower-initiated transfer; automated revenue diversion is not yet wired.

    function repayPartial(uint256 loanId, uint256 amount)
        external
        override
        nonReentrant
        loanExists(loanId)
        onlyBorrower(loanId)
        inState(loanId, LoanState.Active)
        notExpired(loanId)
    {
        require(amount > 0, "Invalid amount");
        
        Loan storage loan = loans[loanId];
        uint256 totalDue = amountDue(loanId);
        uint256 remaining = totalDue - loan.repaid;
        
        require(amount <= remaining, "Amount exceeds remaining due");
        
        IERC20(loan.asset).safeTransferFrom(msg.sender, address(this), amount);
        
        loan.repaid += amount;
        
        emit PartialRepayment(loanId, amount, loan.repaid);
        
        if (loan.repaid >= totalDue) {
            loan.state = LoanState.Settled;
            emit LoanSettled(loanId, totalDue);
        }
    }

_calculateClaimable — pro-rata share POC/src/LoanController.sol

Each lender’s claim is proportional to their bond balance over the original loan amount. Pull-based claims by design.

    function _calculateClaimable(
        uint256 loanId,
        address lender,
        uint256 bondBalance
    ) private view returns (uint256) {
        Loan storage loan = loans[loanId];
        
        uint256 lenderShare = (loan.repaid * bondBalance) / loan.amount;
        uint256 alreadyClaimed = claimed[lender][loanId];
        
        if (lenderShare <= alreadyClaimed) {
            return 0;
        }
        
        return lenderShare - alreadyClaimed;
    }

claimPartial — pull distribution POC/src/LoanController.sol

Lenders draw their share whenever they want. Avoids the gas-bomb risk of push distribution to large lender sets.

    function claimPartial(uint256 loanId)
        external
        override
        nonReentrant
        loanExists(loanId)
    {
        Loan storage loan = loans[loanId];
        require(
            loan.state == LoanState.Active || loan.state == LoanState.Settled,
            "Cannot claim in current state"
        );
        
        uint256 bondBalance = bondToken.balanceOf(msg.sender, loanId);
        require(bondBalance > 0, "No bond balance");
        
        uint256 claimable = _calculateClaimable(loanId, msg.sender, bondBalance);
        require(claimable > 0, "Nothing to claim");
        
        claimed[msg.sender][loanId] += claimable;
        
        IERC20(loan.asset).safeTransfer(msg.sender, claimable);
        
        emit PartialClaimed(msg.sender, loanId, claimable);
    }

Default Framework

★

Hexproof's primary failure mode is overleverage, not fraud. Factoring — financing already-earned receivables — is fraud-prone (the receivable may not exist). Hexproof — financing future revenue with programmatic top-of-waterfall diversion — is overleverage-prone (the revenue may not materialize at the projected rate). The monitoring, underwriting, and default stack should be tuned for this failure mode: risk-engine-addressable rather than forensic-accounting-addressable.

Payment Default: No funds received in escrow for 2 consecutive payment periods. Revenue Default: Revenue below agreed minimum threshold for 2 consecutive months.

Threshold Scaling

Cadence	Trigger
Biannual	2 missed (12 months)
Quarterly	2 missed (6 months)
Monthly	2 missed (2 months)
Weekly	4 missed (4 weeks)
Daily	14 missed (14 days)
Streaming	Flow <50% projected for 14 consecutive days

Enforcement Cascade

Detection: Real-time monitoring → on-chain event
Notification: Borrower, lenders, trustee. 7-day remediation window.
Remediation: Borrower may cure → DefaultCured(bondId), normal ops resume
Flagging: Uncured after 7 days → tokens flagged "in default," trading restricted
Cap Escalation: Revenue commitment % raised to contractual max (if applicable)
Guarantor Enforcement: Legal remedies via LabCo entity
Trading: Paused; may resume for distressed debt trading after review

⚠

Off-chain borrower recovery depends entirely on the legal guarantor if payment pipeline is disconnected. On-chain spending approvals are technically irrevocable (stronger recourse).

Blast Radius — Composability Restriction

The real default blast radius is downstream composable use, not same-venue secondary trading. If a tertiary buyer has posted receipt tokens as collateral in a Pendle-like yield-decomposition protocol, liquidation bots unwind the tertiary position on default and the narrative becomes "retail users lost money in a Hexproof deal" — regardless of eventual legal recovery. Brand risk is the binding constraint.

Policy: defaulted tokens are composability-restricted. Transfer hooks flag the ERC-1400 partition; downstream protocols treating tokens as collateral must recognize the flag and block new leverage. Same-venue distressed trading may resume after trustee review; downstream composability stays frozen until resolution.

Cross-Deal Default Semantics

single_stream default triggers default on that deal only. Parallel streams continue.
global_percentage default triggers on the entire entity; parallel single_stream deals are flagged for enhanced monitoring but not auto-defaulted.
Explicit cross-default clauses between deals are permitted but must be opted into at creation.

        Protocol Flow
        v3.2 · 1 diagram
      
      Capital structure & default cascade · $1B worked example
      v3.2 · SVG
    SPV tranching · 4-step default blast radius · v3.2 composability flag intervention

  WORKED EXAMPLE · $1B LOAN vs $500M REVENUE · OVERLEVERED

    Borrower
    $500M annual revenue
    data center / AI infra
  
  SPV
  issues $1B loan
  sole asset = credit agreement
  creditor of record

  revenue commitment

  Tranche A
  senior · 90¢

  Tranche B
  mezz · 50¢

  Tranche C
  first-loss · 10¢

    Lenders
    institutional QIBs
    plus downstream buyers
  
  DEFAULT CASCADE · WITHOUT v3.2 COMPOSABILITY FLAG

  STEP 1
  Borrower stops paying.
  SPV sues as creditor.

  STEP 2
  Bond value marks down
  ($0.90 → $0.45, 3 months)

  STEP 3 · BLAST RADIUS
  Tertiary collateral position
  liquidated by bots (Pendle-like)

  STEP 4 · BRAND RISK
  “Retail lost money in a
  Hexproof deal” — binding

  v3.2 INTERVENTION · COMPOSABILITY FLAG FREEZES STEP 3

  On default, ERC-1400 partition is flagged on transfer hook. Downstream protocols (Pendle, Sablier, etc.)
  MUST recognize the flag and refuse new collateral posting / leverage expansion / liquidation cascades.
  Result: same-venue distressed trading still allowed; downstream composability frozen until resolution.

  FAILURE MODE · FRAUD (FACTORING) vs OVERLEVERAGE (BONDS)

  Factoring · Fraud-prone
  Finances already-earned receivables
  Receivable may not exist · forensic accounting
  Credit Coop · working capital / AR loans

  Bond Protocol · Overleverage-prone
  Finances future revenue streams
  Revenue may not materialize · risk-engine addressable
  Top-of-waterfall programmatic diversion

SPV as creditor of record
Each deal is issued via an SPV whose sole asset is the signed credit agreement.
Token holders are not direct creditors. On default, the SPV is the entity that sues; token holders direct the SPV to exercise enforcement rights.
Tranches (A/B/C) price the same receipt token at different seniorities — the 90¢/50¢/10¢ structure is illustrative, not fixed.
Default cascade · 4 steps
Borrower stops paying → SPV initiates legal action.
Bond marks down as market prices recovery probability.
Real blast radius: tertiary positions where tokens were posted as collateral in downstream protocols (Pendle-style yield decomposition, etc.) get liquidated by bots.
Brand risk — not economic recovery — is the binding constraint. “Retail lost money in a Hexproof deal” is catastrophic even if eventual recovery is full.
v3.2 intervention: composability flag
On default event, ERC-1400 partitions are flagged via transfer hook.
Downstream protocols MUST recognize the flag and block new collateral posting, leverage expansion, and liquidation cascades.
Same-venue distressed trading is still permitted for price discovery; downstream composability stays frozen until the default resolves.
This contains the blast radius at the composability boundary, not the secondary-market boundary.
Failure mode: fraud vs overleverage
Factoring finances already-earned receivables. Primary failure mode is fraud — the receivable may not exist. Requires forensic accounting.
Bond Protocol finances future revenue streams. Primary failure mode is overleverage — revenue may not materialize at projected rate. Addressable via risk engine + monitoring.
Different monitoring stacks, different underwriting skills, different downstream composability risk profiles.

        Implementation
        POC · 1 excerpt
      

checkAndMarkDefaulted POC/src/LoanController.sol

Prose §06 specifies a 7-step enforcement cascade. The MVP implements step 1 (state flip) only — notification, remediation, cap escalation, and guarantor enforcement are still TBD.

    function checkAndMarkDefaulted(uint256 loanId)
        external
        loanExists(loanId)
        inState(loanId, LoanState.Active)
    {
        require(block.timestamp >= loans[loanId].expiration, "Not expired");
        
        Loan storage loan = loans[loanId];
        uint256 totalDue = amountDue(loanId);
        
        if (loan.repaid < totalDue) {
            loan.state = LoanState.Defaulted;
            emit LoanDefaulted(loanId);
        }
    }

Technical Architecture

Per-Deal Contract Architecture

A factory deploys five linked contracts per deal:

#	Contract	Responsibility
1	Bond Token (ERC-1400)	Partitioned, KYC-gated receipt token
2	Escrow Controller	Holds and routes funds through the lifecycle
3	Agreed-Terms Deal	On-chain reference to the signed loan agreement; stores `(P, R, B, S, scope)`
4	Revenue Waterfall Router	Splits inflows `r%` / `(1−r)%` (§05)
5	Dynamic Repayment Engine	Executes the `R` schedule

Security

Audits: 2 independent firms, at least one specializing in formal verification. Primary target: Kentima. Budget: $300-500K. Post-audit: Sherlock/Code4rena contest ($100K+). Bug bounty: Immunefi $500K (scaling to $1M at $100M+ TVL).

Smart Contracts: UUPS proxy, OpenZeppelin AccessControl (ADMIN/OPERATOR/PAUSER/KEEPER), ReentrancyGuard, circuit breakers (1-2 block freeze), timelocks (1 day routine / 7 days sensitive), per-deal circuit-breaker delay window between funding and atomic issuance (§03 step 8).

Emergency Shutdown: 3-of-5 multisig → halt issuance, pause trading, freeze escrow → orderly settlement → governance vote to restart.

Governance: Phase I: 3-of-5 Gnosis Safe, 7-day timelocks, 1-of-3 authorized pausers. Phase II: Governor Bravo with guardian cancellation.

Escrow

Unique per deal (never reused). Platform deploys logic contracts that issue instructions to custodial partner — platform never holds funds.

Three phases: Funding → Disbursement (proceeds minus fees, post-healthcheck) → Repayment (collect + distribute pro-rata).

ℹ

Custodial pass-through avoids MSB classification. Custodian's banking charter covers money transmission. See §09 for full rationale.

Order Book

Position Exchange: All receipt tokens auto-listed post-issuance. KYC-verified only. On-chain settlement. Thin order books: Pendle-style time-decay AMM ($800M proven liquidity).

Option Order Book: Deferred to Phase III (CFTC risk).

Offchain / Onchain Split

Offchain: Discovery, negotiation, legal signatures, KYC. Onchain: Escrow, token issuance, repayment routing, distributions, secondary trades, default events.

⇄

Sealed-bid auctions require bidding-phase privacy. Mitigation: post-clearing cryptographic commitment (hash of bid set) for participant verification.

Settlement

Phase I: Ethereum mainnet or Arbitrum. Single chain per deal.
Phase II+: CCIP atomic cross-chain settlement.
Stablecoins: USDC (Circle) primary, USDT secondary. GENIUS Act compliant only.

Streaming

Superfluid: CFA for per-second revenue diversion. Production on Polygon, Arbitrum, Optimism, Base. Sablier: Stream-as-NFT, lockup streams for structured schedules. OVRFLO = yield bond reference (beta).

        Implementation
        POC · 2 excerpts
      

Access & state guards POC/src/LoanController.sol

Modifier-based gating: existence, role, state, expiry. ReentrancyGuard wraps every state-mutating function.

    modifier loanExists(uint256 loanId) {
        require(loans[loanId].amount > 0, "Loan does not exist");
        _;
    }
    
    modifier onlyBorrower(uint256 loanId) {
        require(loans[loanId].borrower == msg.sender, "Only borrower can perform this action");
        _;
    }
    
    modifier inState(uint256 loanId, LoanState state) {
        require(loans[loanId].state == state, "Invalid loan state");
        _;
    }
    
    modifier notExpired(uint256 loanId) {
        require(block.timestamp < loans[loanId].expiration, "Loan expired");
        _;
    }

LoanLibrary — math primitives POC/src/libraries/LoanLibrary.sol

Pro-rata math is library code, not inlined — cheap to formal-verify in isolation.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

library LoanLibrary {
    uint256 internal constant BASIS_POINTS = 10_000;
    
    error InvalidLoanParameters();
    error LoanExpired();
    error InsufficientAmount();
    error ExcessiveRepayment();
    
    function calculateFee(uint256 amount, uint16 feeBps) internal pure returns (uint256) {
        return (amount * feeBps) / BASIS_POINTS;
    }
    
    function calculateTotalDue(uint256 principal, uint16 feeBps) internal pure returns (uint256) {
        return principal + calculateFee(principal, feeBps);
    }
    
    function calculateProRataShare(
        uint256 totalAmount,
        uint256 userShare,
        uint256 totalShares
    ) internal pure returns (uint256) {
        if (totalShares == 0) return 0;
        return (totalAmount * userShare) / totalShares;
    }
    
    function validateLoanCreation(
        address asset,
        address borrower,
        uint256 amount,
        uint256 expiration,
        uint16 feeBps
    ) internal view {
        if (asset == address(0) || borrower == address(0)) {
            revert InvalidLoanParameters();
        }
        if (amount == 0) {
            revert InvalidLoanParameters();
        }
        if (expiration <= block.timestamp) {
            revert InvalidLoanParameters();
        }
        if (feeBps > BASIS_POINTS) {
            revert InvalidLoanParameters();
        }
    }
    
    function checkExpiration(uint256 expiration) internal view {
        if (block.timestamp >= expiration) {
            revert LoanExpired();
        }
    }
}

Economics & Business Model

Cost Compression: $500K → $100K

Traditional deals cost ~$500K, forcing $75M+ minimums. Target: ~$100K through:

Modular contracts: Templatized credit agreements, dramatically fewer lawyer hours
AI-accelerated diligence: Financial models, doc processing, communications — fewer analysts
Platform standardization: Lead check sets structure; capital arm anchors deals
Programmatic servicing: Automated routing, monitoring, reporting

Opens the $5-50M segment previously uneconomical.

Revenue Model

Origination fee is gated on whether Hexproof originated the deal:

Fee	When it applies	Detail
Full origination fee	Deal negotiated in-protocol (RFQ → quotes → clearing via contracts)	Charged to lender; priced for origination value-add
Thin infra fee	Out-of-band deal using contracts as dumb rails	Infra pricing only
Secondary trading fees	Either path	Phase II revenue stream
Escrow yield share	Either path	Yield on idle balances (tokenized Treasuries, 4-5%)

Out-of-band deals are a volume loss-leader; platform capture shifts toward secondary markets and yield share. North star: successful repayments.

Capital Retention

Cheap ingress: Low friction to onboard. Potentially subsidize first deals.
Expensive egress: Withdrawal friction and fees.
Light internal tax: Minimal fees between deals.
Capital recycling: Immediate roll-into-next-deal offers.
No charge on internal profits: Charge only on withdrawal/profit realization.

★

Long-term models: asset management (5-10x earnings) → exchange (30-35x) → data business. Exchange is the target.

Market Pricing

Scenario	Rate	Notes
Equipment, unsecured	17-19%	H100-type equipment
Equipment, secured (2-3yr)	10-11%	Most common
Equipment, secured (aggressive)	7-9%	Competitive anchor offers
Target LTV (unsecured)	40-50%	40% validated by investors

IRR Sensitivity (0% coupon, 85 OID)

Bond Size	5% Rev	10% Rev	15% Rev	20% Rev	25% Rev	30% Rev
10%	18.0%	39.6%	64.2%	92.5%	129.3%	162.5%
20%	8.7%	18.0%	28.2%	39.6%	50.5%	64.2%
30%	5.7%	11.7%	18.0%	24.8%	32.0%	38.9%
50%	3.4%	6.9%	10.5%	14.3%	18.2%	22.1%

Sweet spot: 20-30% bond size, 10-20% revenue commitment → 11-40% IRR.

Deal Sizing Example

$60M/year revenue, 5% commitment → $3M/year repayment capacity. At 40% LTV of $240M (4× revenue) = $96M total capacity → $6M series, ~2-year payback each.

Tax

Phase I (0% interest, OID at par) is cleanly "debt." OID accrual creates phantom income — standard for zero-coupon, manageable for QIBs. Revenue royalties/TRS require independent tax counsel per product type.

Borrower Universe

Phase I: data center operators, frontier AI, AI consolidation survivors, DeFi protocols (Aave $122M Q2 2025, Lido $27.5B TVL, Hyperliquid $1B+, Jupiter $1.1B). Off-chain market (global private credit ~$2T AUM) = Phase II+ expansion.

US municipal issuers are a Phase-I candidate segment. Muni context: $4.2T market, ~1/3 inaccessible to retail, ~82% of issuance still on paper, 2-5% issuance costs. Legal precedent: J.P. Morgan's Quincy MA tokenized muni. Regulatory sleeve differs from Reg D 506(b) — see §09 Peirce innovation-exemption path.

Regulatory Posture

⚠

Not legal advice. Regulatory environment improved significantly in 2025 (GENIUS Act, OCC charters, SEC posture shift).

Securities Classification

Receipt tokens are investment contracts under Howey.

Exemption	Status
Reg D 506(b) — no general solicitation, hand-picked QIBs	Phase I
Reg D 506(c) — general solicitation, verified accreditation	Phase II
Reg A+ Tier 2 — up to $75M/year, non-accredited access	Phase III+
Reg S — offshore, combinable with Reg D	Secondary

ℹ

GENIUS Act stablecoin carve-out does not apply to yield-bearing instruments. Receipt tokens must be treated as securities.

Money Transmitter — Resolved

Custodial pass-through. All escrow through a banking-chartered custodial partner. Platform = technology provider, never holds funds. FinCEN rejected non-custodial defense (Paxful $3.5M penalty, Dec 2025).

Derivatives

Option order book deferred to Phase III (CFTC risk). Phase I excludes all derivative features.

ATS

Phase I: partner with existing ATS (tZERO, Securitize Markets). Phase II: proprietary ATS (6-12 months, $500K+/yr).

Custodial Partners

Anchorage Digital is the Phase-I lead custodian (strategic partner + Anchorage Ventures check expected). BitGo and Fidelity remain valid alternatives.

Partner	Role	Key Facts
Anchorage Digital	Phase I lead	OCC federal bank (2021). Atlas settlement. $4.2B valuation.
BitGo	Alternate	OCC national trust (2025). $90B+ AUC. NYSE IPO.
Fidelity Digital Assets	Alternate	OCC national trust (2025). $4T+ parent AUM.

Municipal Issuer Path

Muni deals route outside the Reg D ladder. Active paths:

Peirce innovation exemption — SEC Commissioner Peirce has publicly supported tokenized munis; strategy is to demonstrate NYC demand before requesting a carve-out.
Existing muni exemptions — open question whether a tokenized wrapper inherits the pre-existing exemption or requires new relief.
Legislation track — parallel work with Rohan Gray.

Stablecoin Compliance

Primary: Circle USDC (OCC charter, 46 state licenses, MiCA, Chainlink PoR). Secondary: Paxos USDP. GENIUS Act compliant: 1:1 reserves, no interest on payment stablecoins, holder priority in insolvency.

Product Trajectory

Three-phase arc, each unlocking a higher valuation multiple:

Phase 1: Origination (5-10x earnings)

SPV-structured deals between hand-picked borrowers and QIBs. North star: successful repayments. 0% interest amortizing bonds at OID, 10-year maturity. Revenue swap option. Platform fee to lender. Ethereum/Arbitrum. No public marketing.

★

Phase 1 exists to prove the rails work; the differentiated product (global-cashflow diversion, PID-target-IRR, router-integrated off-chain borrowers) arrives in Phase 2 once Phase 1 demonstrates borrower willingness.

Phase 1 candidate pipeline: data center operators, frontier AI companies, established DeFi protocols, and tokenized NYC municipal bonds under the Peirce innovation-exemption path (§09).

ℹ

Narrowest regulatory surface area: QIB-only (except munis), no derivatives, custodial pass-through via Anchorage, simple amortizing structures.

Phase 2: Credit Exchange (30-35x earnings)

Secondary market for platform-originated credit. Current private credit OTC is highly manual and opaque.

Reg D 506(c), broader lender base
Proprietary ATS
CCIP cross-chain settlement
Revenue royalty and RBF structures

ℹ

Low bond secondary volume is the opportunity — large assets, inadequate market structure. 1980s high-yield bonds were liquid; it dried up post-crisis.

Phase 3: Data & Pricing Authority

Deal flow compounds into proprietary data → pricing benchmarks, creditworthiness patterns → pricing oracle.

Analog: Optum Health → pricing registry → price-setter → $230B+ business → "Bloomberg terminal for private credit"
Reg A+ for non-accredited access
Full product spectrum: options, pooling/tranching, TRS, perpetuals

Why Now

Equity drought: VCs concentrating on winners; increased demand for debt/alternatives
Distressed window: Potential generational opportunity in 6-10 months
Private credit liquidity crisis: Fund gating → forced sellers at $0.80-0.90/dollar
Regulatory tailwinds: GENIUS Act, OCC charters, SEC shift. 76% institutions expanding digital asset exposure.

Competitive Context

Player	Focus	Differentiation
Maple ($4B+ AUM)	Pool delegate underwriting	Head start but different model; no revenue-backed structures
Valinor ($25M seed)	On-chain private credit	Ex-Blackstone; similar thesis, later to market
Plume/Figured (~$25M)	Short-term working capital	<30-day tenors, infrastructure-only
Traditional (Apollo, KKR)	Large-cap ($75M+)	Gap: tech-forward $5-50M deals

First-mover dynamics: Window is quarters, not years. Move fast, set the standard, build the data moat.

MVP Milestones

✓KYC + Wallet Verification
✓Bond Request Order Model
✓Bid Engine + Clearing Logic
✓Escrow + Tokenization Smart Contracts
○Repayment Routing (on-chain + payment providers)
○Secondary Trading Venue (ATS partnership)
○Real-time Monitoring (revenue health + default detection)
○Security Audit Cycle
○Trustee Enforcement Framework
○Default/Dispute Protocols

Open Questions

Resolved

Question	Resolution
Token standard	ERC-1400 (Phase I)
MSB classification	Custodial pass-through
Off-chain integration	Direct payment provider integrations
Streaming default threshold	Scaled by cadence; 14-day deficit for streaming
Dynamic cap trigger	Real-time monitoring, algorithmic, non-discretionary
Option order book	Deferred to Phase III
Secondary trading	ATS partnership (Phase I)

Open

Architecture: Cross-chain settlement (Phase II) · Payment processor ToS review · Payment infra partnerships · [OQ6] Router contract templates — fork Superfluid CFA / Sablier / Maker spigot or build from scratch · [OQ4] Router dispersion frequency vs hot-wallet security tradeoff.

Credit: Phase II underwriting model (pool delegates / algorithmic / hybrid) · Internal credit ratings (build vs Credora) · Multi-bond seniority rules · [OQ9] Cross-default rules when an entity has N stream-scoped deals · [OQ7] single_stream default when the stream drops but entity total is healthy.

Legal: Entity wrapper (SPV / master trust / series LLC) · Trustee structure · DAO guarantor enforcement · [OQ1] Step-8 circuit-breaker cancel policy (either party / both / Hexproof only / 2-of-3); anti-griefing against straw-bid-and-yank · [OQ8] Muni regulatory path detail.

Product: Callable debt · Debt buyback · Bond pooling / tranching (Phase III) · Optional token collateralization · [OQ2] single_stream vs global_percentage — parameterized in v3.2, but the strategic question of which is the differentiated product remains open · [OQ3] Router multi-source aggregation — one Router collating multiple upstream integrations, or multiple Routers summed per deal.

Economic: Escrow yield risk management · Insurance / first-loss tranche · Capital retention fee structure · Platform capital arm.

BizDev: Tokenization partner · First deal pipeline · Lender pipeline · [OQ5] Revenue-source user research across Phase-1 borrower archetypes (data centers, H100 operators, DeFi protocols, munis) before Router design is committed.

Bond Protocol

Protocol Overview

Traditional Capital Stack

Why On-Chain Infrastructure

Product Spectrum

Transaction Types

Debt vs. Preferred Equity

Lender Types

Capital Flow

System Actors

Borrowers

Lenders

Platform

SPV / LabCo

Lifecycle

Canonical 10-Step Sequence

Discovery — Out-of-Band First

Negotiation — SPV Models

Disbursement — Pull for Borrower, Push for Lender

Repayment Loop & Principal Recycling

Secondary Trading

Receipt Token Specification

Token Architecture

Repayment Mechanics

The Router Primitive

Flow

R — Repayment Schedule Union

Dynamic Caps (step-function fallback)

Revenue Integration Verification

Default Framework

Threshold Scaling

Enforcement Cascade

Blast Radius — Composability Restriction

Cross-Deal Default Semantics

Technical Architecture

Per-Deal Contract Architecture

Security

Escrow

Order Book

Offchain / Onchain Split

Settlement

Streaming

Economics & Business Model

Cost Compression: $500K → $100K

Revenue Model

Capital Retention

Market Pricing

IRR Sensitivity (0% coupon, 85 OID)

Deal Sizing Example

Tax

Borrower Universe

Regulatory Posture

Securities Classification

Money Transmitter — Resolved

Derivatives

ATS

Custodial Partners

Municipal Issuer Path

Stablecoin Compliance

Product Trajectory

Phase 1: Origination (5-10x earnings)

Phase 2: Credit Exchange (30-35x earnings)

Phase 3: Data & Pricing Authority

Why Now

Competitive Context

MVP Milestones

Open Questions

Resolved

Open

`R` — Repayment Schedule Union