spec_v2/discussion-notes-synthesis.md for the full 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.
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.
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 proceedsSystem Actors
Borrowers
Revenue-generating protocol, company, off-chain business, or — as of v3.2 — a named revenue stream within such an entity. Each deal carries an explicit scope parameter:
scope = single_stream— the deal attaches to one identified revenue stream (e.g., a specific Stripe account, one protocol's fee switch, one data center's power-purchase contract). Repayment routes only from that stream. Factoring-shaped; cleaner default math; closer to per-stream receivables financing.scope = global_percentage— the deal attaches to a percentage of the borrower entity's total cash flow, aggregated across all revenue streams. Corporate-bond-shaped; larger deal sizes; this is where the "top-of-waterfall programmatic diversion" thesis sits.
A single legal entity with N streams may run up to N single_stream deals in parallel, or one global_percentage deal covering the whole entity, or a hybrid (see §06 on cross-default handling). The protocol is agnostic; the borrower picks per deal.
Requirements: revenue integration capability (on-chain transferFrom approval OR payment provider integration via the Router, §05), defined repayment commitment, legal guarantor (SPV, §07), KYC completion.
Outputs: issuer details, use of proceeds, revenue integration verification, minimum revenue threshold, existing obligation disclosure, scope declaration.
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 (unified terminology)
Per-deal special-purpose vehicle that issues the receipt tokens and holds the signed loan agreement as its sole asset. For DAO borrowers without traditional legal entities, a LabCo development entity sits between the DAO and the SPV. On default, the SPV — not the token holders — is the creditor of record; token holders' recourse is to direct the SPV to exercise its enforcement rights against the borrower.
v3.2 unifies the v3.1 vocabulary: earlier drafts used "LabCo" generically; we now use SPV for the issuing entity and reserve LabCo for the DAO-bridging development company specifically.
- 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).
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.
- 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.
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;
}
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
v3.2 pins the lifecycle to a concrete, numbered sequence. The taxonomy categories (Discovery / Negotiation / Initialization / Signing / Locking / Token Issuance / Repayment Loop / Principal Recycling) remain as informal section labels; the numbered steps below are the normative process definition.
- Borrower initiates — RFQ, either off-chain → platform or directly on-chain. Deal tuple:
(P, R, B, S, scope)— principal, rate/commitment, borrower entity, revenue stream, scope parameter. - Lender submits a quote —
P', R'for(B, S). Standard path is out-of-band (see below); in-protocol quoting is available as an add-on for in-platform origination. - Optional negotiation loop — iterative quote/counter-quote, terms, structure.
- Borrower creates the loan offer —
(P, R, B, S, scope), whitelisted to a specific lender address. This is the leap-of-faith moment for the borrower. - Proof of legal agreement — verified by Hexproof (or a deferred third-party verifier). Hard gate; toggleable per-loan, default = on. The platform "turns its key" only after verifying real legal recourse exists.
- Lender (or custodian) funds escrow — capital lands in the per-deal escrow controller, unspent. See D2 below on custodian-vs-lender triggering.
- Borrower counter-signs the funded transaction — on-chain double-confirmation now that real money is in escrow.
- Circuit-breaker delay window opens — configurable, e.g. 24h. During this window, the loan can be cancelled by either party or by Hexproof (final policy under legal review — see §11 OQ1). Anti-griefing rules prevent straw-bid-and-yank attacks.
- Atomic issuance — delay elapses → receipt tokens minted → transferred to lender → principal released from escrow to borrower (pull, not push — see below). This atomic step is triggered by the lender address.
- Repayments & recycling — cash flows route via the Router (§05) → escrow → lender pro-rata claim by burning receipt tokens. Principal recycling and secondary trading proceed as before.
Discovery — Out-of-Band First
v3.1 treated sealed-bid discovery as a primary mechanism; v3.2 reverses this. The default Phase-I experience is out-of-band handshake: two counterparties agree to terms on Signal, email, or via a Privy email directory lookup; the borrower creates a deal, receives a deal ID, and whitelists the lender's address. The whitelist is mutable by the borrower until funding.
In-protocol RFQ / sealed-bid auction / open-market clearing remains supported, and is specifically the path where Hexproof can defensibly claim it originated the deal and charge a full origination fee (see §08 two-tier fee model).
Privacy layering:
- Deal terms may be opaque to outside observers.
- Borrower identity is never opaque at the protocol layer — the borrower address must be knowable for KYC, legal recourse, and default monitoring.
- Pre-commit-signature full privacy is a separable optional add-on.
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.
Token Issuance — Pull for Borrower, Push for Lender
At step 9 the atomic operation executes. v3.2 splits disbursement semantics:
- Initial proceeds → borrower: pull pattern. Borrower must explicitly
claim()USDC from escrow after issuance. Reason is tax-driven (explicit consent to receipt of funds triggers the right tax event) and matches OFAC-style "affirmative act" requirements. - Ongoing repayments → lender: push pattern. Automated distribution, manual claim as fallback. No reason to hold up repayments.
v3.1 conflated these; v3.2 separates them.
| Flow | Direction | Pattern | Amount |
|---|---|---|---|
| Lenders → Escrow | step 6 | direct fund | Notional (or Notional × OID) |
| Escrow → Borrower | step 9 | pull | Proceeds minus fees |
| Escrow → Platform | step 9 | direct | Tiered issuance fee (§08) |
| Router → Escrow | step 10 | push | r% of revenue stream |
| Escrow → Lender | step 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. For thin order books: Pendle-style time-decay AMM for continuous liquidity. Defaulted tokens are composability-restricted, not just trading-restricted — see §06 T2 on the overleverage blast-radius analysis.
- 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.
- 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.
- 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.
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
}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);
}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
Escrow: ERC-4626 vault standard — standardized deposit/withdrawal, DeFi composable, well-audited.
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 contract routes cash flows per pre-agreed terms to escrow, positioning lenders at the top of the revenue waterfall (see §01).
The Router Primitive (v3.2)
The Router is a per-deal contract that sits between a revenue source and the escrow, and atomically splits each incoming payment into r% (to escrow) and 1-r% (back to the borrower). It is what v3.1 described abstractly as "revenue integration"; v3.2 names it as a first-class protocol primitive.
- On-chain source: Router holds a
transferFromapproval against the borrower's revenue address. On each inflow, it pullsr%and forwards to escrow. - Off-chain source: Router is paired with a payment-provider integration (Stripe, Visa, Plaid, Paxos, or a direct banking partner). Incoming fiat lands in a third-party custodial account that bridges on-chain, and the Router executes the
r% / 1-r%split the moment funds arrive on-chain. - Dispersion frequency matters for security: the longer the Router holds funds before forwarding, the more attractive it is as a honeypot. Default policy is to forward on every inflow (streaming) or on a daily cadence at most. Weekly/monthly is flagged as an open security tradeoff — see §11 OQ4.
Flow
- Routing: Router pulls
r%of each revenue inflow (on-chain approval or off-chain payment integration). - Logic: Dynamic repayment engine applies the
Rschedule (see below) to determine the target pull rate. - Surveillance: Real-time monitoring, algorithmic default detection.
- Distribution: Pro-rata push to receipt token holders (§03 Token Issuance).
- Satisfaction: Cumulative repayments = notional → tokens burned, excess to borrower.
R is a Union Type (v3.2)
v3.1 treated R as a scalar "revenue commitment %." v3.2 makes R a union of repayment-schedule structures, any of which may be selected per deal:
| Type | Description | Use Case |
|---|---|---|
| Fixed % | Static revenue commitment | Simplest; Phase-I default for revenue-linked deals |
| Floating interest rate | Traditional coupon, tied to an index | Hybrid instruments |
| Fixed % of revenue | Like fixed % but explicitly stream-scoped | scope = single_stream deals |
| Variable % PID-targeted to an IRR | Revenue commitment % continuously updated by a PID controller driving toward a target lender IRR | Replaces step-function dynamic caps; self-correcting |
The PID-targeted option is the v3.2 replacement for v3.1's step-function Dynamic Caps. Instead of discrete 500bps bumps on a trigger, the revenue-commitment % is continuously adjusted by a proportional-integral-derivative controller to hold the projected IRR on-target. Continuous feedback is more elegant and avoids gaming around trigger thresholds, but introduces control-theory failure modes (oscillation, integral windup) that must be modeled and bounded.
Dynamic Caps (Optional, v3.1 step-function fallback)
Still supported as the discrete-trigger alternative for deals where a deterministic rule is preferred:
| Parameter | Value |
|---|---|
| Trigger | Repayments >10% behind projected amortization for 30+ days |
| Action | Revenue commitment % increased by pre-agreed step (e.g., 500bps) |
| Constraints | Max cap at inception (e.g., 50% revenue); 30-day cooldown |
| Reversal | ≤5% behind for 60 days → cap reverts one step |
Revenue Integration
On-chain: transferFrom approvals against revenue addresses. Verifiable via DefiLlama, Dune, or direct queries.
Off-chain: Direct integrations with payment providers (Stripe, Visa, Plaid, banks, clearinghouses). Near-term: partner with Paxos or similar for existing rails. Long-term: proprietary infrastructure.
Disbursement
Automated distribution, manual claim fallback. Idle escrow earns yield (tokenized Treasuries, 4-5%). Escrow yield share = additional platform revenue.
- Per-deal contract sitting between revenue source and escrow. Atomically splits each inflow r% / (1−r)%.
- On-chain: holds a
transferFromapproval against the borrower's revenue address. - Off-chain: paired with a PSP integration (Stripe, Visa, Plaid, Paxos). Fiat lands in a bridged custodial account; the Router executes the split on arrival.
- Dispersion frequency is a security tradeoff — streaming or daily is safe; weekly+ becomes a honeypot risk (§11 OQ4).
- v3.2 treats
Ras a union type rather than a scalar %. - Fixed %, floating rate, and fixed-% of revenue are the v3.1 baseline.
- PID-target-IRR is the new continuous option: the revenue-commitment % is updated by a PID controller driving toward a lender-IRR target. Replaces v3.1's discrete step-function dynamic cap.
- Step-function caps remain supported as a deterministic fallback.
- Escrow accumulates the r% share and pushes pro-rata to lender wallets on cadence (daily / weekly / monthly / streaming).
- Lenders may claim manually as a fallback, but the default is automated.
- On satisfaction (cumulative repayments = notional), tokens burn and excess returns to borrower.
- Contrast with §03: borrower initial proceeds are pull for tax reasons; lender ongoing repayments are push.
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);
}
}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;
}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
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
Blast Radius — Composability Restrictions (v3.2)
The real default-event blast radius is not same-venue secondary trading — it's downstream composable use of the receipt tokens. If a tertiary buyer has posted receipt tokens as collateral in a Pendle-like yield-decomposition protocol, and the underlying deal defaults, liquidation bots unwind the tertiary position and the narrative becomes "retail users lost money in a Hexproof deal," regardless of eventual legal recovery.
Brand risk is the binding constraint, not economic recovery.
Policy: defaulted tokens are composability-restricted — transfer hooks flag the ERC-1400 partition such that downstream protocols treating the tokens as collateral must recognize the flag and block further leverage. Same-venue secondary trading may resume for distressed-debt pricing after trustee review; downstream composability remains frozen until the default resolves.
Cross-Deal Default Semantics
Because a single legal entity can run multiple deals (one per single_stream scope, or one global_percentage deal, or a hybrid), v3.2 must specify cross-default behavior explicitly. Current policy (subject to §11 OQ9):
single_streamdefault triggers default on that deal only. Other streams continue normally. The SPV's enforcement scope is the specific stream and its legal sub-agreement.global_percentagedefault triggers on the entire borrower entity; any parallelsingle_streamdeals are not automatically cross-defaulted but may be flagged for enhanced monitoring.- Explicit contractual cross-default clauses between deals are permitted but must be opted into at deal creation.
- 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.
- 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.
- 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.
- 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.
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 (v3.2)
Each deal is instantiated via a factory that deploys five linked contracts, one set per deal:
| # | Contract | Responsibility |
|---|---|---|
| 1 | Bond Token (ERC-1400) | Partitioned, KYC-gated receipt token for the specific deal |
| 2 | Escrow Controller | Holds and routes funds through the deal lifecycle |
| 3 | Agreed-Terms Deal Contract | On-chain reference to the off-chain signed loan agreement; stores deal parameters (P, R, B, S, scope) |
| 4 | Revenue Waterfall Router | The §05 Router primitive; splits inflows r% / 1-r% |
| 5 | Dynamic Repayment Engine | Executes the R schedule — fixed, floating, PID-target-IRR, or step-function dynamic cap |
This pattern is the v0 MVP shape; production may consolidate or re-split these as audit feedback lands. The five-contract factory is documented here so subsequent specs can reference it directly.
Security
Audits: 2 independent firms, at least one specializing in formal verification. Primary target: Kentima (formal-verification, deep kernel-level systems background; reversed from v3.1 which named Trail of Bits / OpenZeppelin). Budget: $300-500K. Post-audit: Sherlock/Code4rena contest ($100K+). Bug bounty: Immunefi $500K max (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).
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.
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).
- All trades settle on-chain atomically. Only KYC-verified wallets can transact.
- Listed automatically post-issuance; no manual market-maker required.
- Thin order books use a Pendle-style time-decay AMM — proven at $800M+ single-pool liquidity.
- Primary exit path for early lenders without waiting for loan satisfaction.
- New entrants buy into existing positions — provides liquidity and secondary price discovery for duration risk.
- Defaulted tokens may still trade at distressed-debt pricing after trustee review.
- The real default blast radius is downstream composable use, not same-venue secondary trading.
- On default, ERC-1400 partitions are flagged on transfer hooks. Downstream protocols treating tokens as collateral must recognize the flag and block further leverage expansion.
- Same-venue secondary trading may resume for distressed-debt pricing; downstream composability stays frozen until the default resolves.
- Brand risk is the binding constraint — prevent retail-facing unwinds even when eventual economic recovery is full.
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");
_;
}
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 — Two-Tier Origination Fee (v3.2)
v3.2 gates the origination fee on whether Hexproof can defensibly claim it originated the deal. Two tiers:
| Fee | When it applies | Detail |
|---|---|---|
| Full origination fee | Deal negotiated in-protocol (RFQ → quotes → clearing, all via the contracts) | Charged to lender; priced for origination value-add |
| Thin infra / escrow fee | Deal negotiated out-of-band, borrower whitelists lender, parties use contracts as dumb rails | Infra pricing only; Hexproof is not the originator |
| 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 the default (§03 Discovery) — they function as a loss-leader that pulls volume and data through the platform. Hexproof's capture mechanism shifts toward secondary markets and escrow yield share rather than pure origination. North star remains successful repayments, not fee revenue.
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.
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.
New in v3.2 — US municipal issuers. Tokenized municipal bonds are a concrete Phase-I deal candidate, specifically NYC munis. Context: $4.2T market, ~1/3 not accessible to retail, ~82% of issuance still on paper, 2-5% issuance costs. Legal precedent: J.P. Morgan's tokenized muni bond pilot in Quincy, Massachusetts. Regulatory sleeve is different from Reg D 506(b) — see §09 on the Peirce "innovation exemption" path. Backing discussions in progress with Ethereum Foundation; policy coordination via Decentralized Park / NYC mayoral office channel.
Regulatory Posture
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 |
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 v3.2 lead custodian, reflecting a strategic partner-and-investor relationship (Anchorage Ventures strategic check expected). BitGo and Fidelity remain valid alternatives but are not Phase-I primary.
| Partner | Role | Key Facts |
|---|---|---|
| Anchorage Digital | Phase I lead | OCC federal bank (2021). Atlas settlement (~600 participants). $4.2B valuation. Strategic investor. |
| BitGo | Alternate | OCC national trust (2025). $90B+ AUC. NYSE IPO ($2.08B). Zero hacking losses. |
| Fidelity Digital Assets | Alternate | OCC national trust (2025). $4T+ parent AUM. Advocating ATS standards. |
Municipal Issuer Path (v3.2)
For tokenized municipal bond deals, Reg D 506(b) is not the right framework. Active regulatory paths:
- Peirce "innovation exemption" — SEC Commissioner Hester Peirce has publicly stated interest in tokenized municipal bonds. A mayor-office-first strategy is being coordinated via Decentralized Park to demonstrate demand before approaching Peirce for an innovation-exemption carve-out.
- Existing municipal bond exemptions — munis already have a well-developed exemption framework that predates securities-law modernization; the question is whether a tokenized wrapper inherits the existing exemption or requires new relief.
- Legislation track — parallel work with Rohan Gray (prior Lummis / crypto-reg drafting) on supporting legislation; dependent on SEC movement.
This is a separate regulatory sleeve from the Reg D / Reg S / Reg A+ ladder above, not a replacement for it.
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) — "Prove the Rails"
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 deal candidate pipeline: data center operators, frontier AI companies, established DeFi protocols, and — new in v3.2 — tokenized NYC municipal bonds under the Peirce innovation-exemption path (see §09). The muni pilot would demonstrate the rails with a counterparty that has clear legal recourse, genuine cash flow, and existing exemption infrastructure.
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
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 (v3.2 additions flagged inline)
Architecture: Cross-chain settlement (Phase II) · Payment processor ToS review · Payment infra partnerships (Paxos etc.) · [OQ6] Router contract templates — fork Superfluid CFA / Sablier lockup / Maker spigot, or build from scratch? · [OQ4] Router dispersion frequency vs security — streaming vs daily vs weekly hot-wallet tradeoff.
Credit: Phase II underwriting model (pool delegates / algorithmic / hybrid?) · Internal credit ratings (build vs. Credora?) · Multi-bond seniority rules · [OQ9] Coexistence of multiple deals per borrower — cross-default rules when a legal entity has N stream-scoped deals · [OQ7] Cross-source default definitions — does a single_stream default trigger when the stream drops but the entity's total revenue is healthy?
Legal: Entity wrapper (SPV / master trust / series LLC?) · Trustee structure · DAO guarantor enforcement · [OQ1] Circuit breaker cancel policy — during the §03 step-8 delay window, who can cancel (either party alone / both parties / Hexproof only / 2-of-3)? Anti-griefing requirement against straw-bid-and-yank attacks · [OQ8] Muni regulatory path detail — Peirce innovation-exemption mechanics, state-level muni exemption inheritance, required legislation.
Product: Callable debt / early repayment · Debt buyback · Bond pooling / tranching (Phase III) · Optional token collateralization · [OQ2] Scope parameter resolution — single_stream vs global_percentage is a deal parameter in v3.2, but the underlying strategic question of which is the differentiated product remains open (Apr 7 vs Apr 8 tension) · [OQ3] Multi-source router aggregation — one router collating multiple upstream integrations, or multiple routers summed per deal?
Economic: Escrow yield risk management · Insurance (Nexus Mutual / first-loss tranche?) · Capital retention fee structure · Platform capital arm
BizDev: Tokenization partner · First deal pipeline · Lender pipeline · [OQ5] Revenue-source user research — realistic Phase-1 borrowers (data centers, H100 operators, DeFi protocols, munis) need direct interviews mapping their actual revenue streams before router design is committed.