A lending program does not end when capital leaves the treasury.
That is where the exposure begins.
The Blockchain Casebook — Resolved File 002
Author: cxclrfx
Version: 1.0
Date: 23 August 2026
Status: Independent technical reconstruction based on public materials
BLAZE proposes a recyclable lending facility for the Arbitrum ecosystem. Its public materials contain a plausible capital-allocation thesis, a six-position financial model, an operating flow, risk language, funding alternatives, and a set of performance targets.
The first useful result of an independent review is not that the headline number is wrong.
It is that the published base case can be reconstructed.
Using the midpoint of each published yield range and the default/recovery assumptions in the model:
weighted midpoint yield = 11.524%
expected loss = 0.619%
base estimate = 10.905%
That reproduces the published approximately 10.9% base case.
But reproducing the number reveals the more important question:
What exactly does that number describe?
The answer is narrower than a complete lending program. It is a simplified allocation-weighted return estimate. It does not yet bind the timing of cash flows, funding costs, legal and operating costs, cumulative originations, correlated defaults, recovery delays, impairment, liquidity, or the full post-funding lifecycle.
This paper reconstructs the public model, follows the capital beyond approval, and shows the missing system needed to turn a lending proposal into a measurable capital-preservation process.
The central conclusion is simple:
The proposal does not need a better headline return. It needs a complete route from approval to final reconciliation.
This is an independent analysis of the BLAZE materials available publicly on 21 August 2026.
The review basis includes:
- the public BLAZE proposal and discussion;
- the published financial model;
- the operational-flow diagram;
- the scenario-return, allocation, and cumulative-return charts;
- the linked liquidity-pool agreement;
- public clarifications in the proposal thread;
- official Aave borrowing and liquidation mechanics;
- standard credit-risk measurement disciplines.
This is not:
- an audit of deployed BLAZE smart contracts;
- a legal opinion;
- a statement that BLAZE is a regulated bank;
- a claim that the proposed borrowers will default;
- a claim that the project should be abandoned.
No pinned production repository, executable portfolio engine, immutable legal version, machine-readable portfolio ledger, or final deployed lending system was part of the public review object.
The object being reviewed is therefore a proposed capital system and financial model.
The published model contains six candidate allocations:
| Project | Size | Duration | Yield range | Default probability | Recovery |
|---|---|---|---|---|---|
| Fist Commerce | $700,000 | 2 months | 10–20% | 1% | 100% |
| Bulla Network | $500,000 | 1 month | 8–10.5% | 2% | 95% |
| DualMint | $200,000 | 6 months | 10–15% | 3% | 90% |
| Fractalized | $500,000 | 6 months | 15–18% | 2% | 100% |
| Estate Protocol | $1,500,000 | 24 months | 8–10% | 3% | 80% |
| Locale | $250,000 | 9 months | 9.5–12% | 10% | 50% |
Total modeled deployment:
$3,650,000
Using the midpoint of each yield range and weighting by loan size:
weighted midpoint yield = 11.524%
Using the simple expected-loss expression implied by the available table:
expected loss
=
Σ weight × PD × (1 − recovery)
=
0.619%
Therefore:
11.524% − 0.619% = 10.905%
The published approximately 10.9% result is therefore reproducible from the exposed inputs.
That matters.
A serious review should not attack a number merely because the surrounding system is incomplete. The first job is to determine whether the number itself can be reconstructed.
Here it can.
The next question is harder.
It proves a simplified expected-return result under the published assumptions.
It does not yet prove:
- net portfolio return;
- realized return;
- capital preservation;
- liquidity on demand;
- recovery capacity;
- two-year program performance;
- resilience under correlated default;
- safety of a leveraged funding route.
The calculation is a useful starting point.
It is not yet the whole system.
3. The hidden variable inside “2% default probability”
The model combines exposures with terms ranging from one month to 24 months.
But a probability of default is meaningless without a time horizon.
Consider the one-month Bulla position:
duration = 1 month
PD = 2%
There are several possible interpretations.
If 2% means a probability for each one-month lending cycle, and the position is repeatedly recycled for 24 independent cycles:
1 − (1 − 0.02)^24 = 38.42%
If 2% is an annual probability and must be converted to a one-month equivalent:
1 − (1 − 0.02)^(1/12) ≈ 0.168%
Those are not small variations of the same model.
They are different risk objects.
The model therefore needs explicit time labels such as:
PD_30d
PD_90d
PD_12m
PD_lifetime
and a documented conversion to the actual exposure term.
Verification Point V-01 — what is the horizon?
If a public BLAZE source defines the PD horizon for every candidate position, that source would materially change this part of the analysis. Without it, duration is visible in the table but its role in expected-loss calculation remains undefined.
The proposal permits repaid capital to be reused.
That turns the design from a static set of loans into a revolving origination mandate.
If the six modeled lines were continuously recycled at their stated durations for two years:
Σ loan size × 24 / duration ≈ $25.37M
Using complete cycles only gives approximately:
$25.2M
This does not mean that $25M is simultaneously at risk.
It means something different and operationally important:
The amount of capital outstanding at one moment and the amount of lending decisions made over the program's life are not the same quantity.
A revolving facility therefore needs at least two independent limits:
maximum outstanding exposure
maximum cumulative originations
It also needs rules for:
- repeat borrowers;
- extensions;
- renewals;
- changed terms;
- re-underwriting;
- connected counterparties;
- cumulative exposure by borrower;
- total delegated origination authority over time.
“Capital can be reused” is not just a treasury convenience.
It expands the decision surface.
Verification Point V-02 — static budget or revolving mandate?
A useful counter-calculation is any public schedule that constrains actual re-use, idle periods, or origination frequency. If those constraints materially reduce cumulative originations, the estimate should be recomputed from that schedule rather than from continuous recycling.
The published KPI states that locked positions should not exceed 20% of total capital.
The modeled Estate Protocol allocation is:
$1.5M
24 months
41.1% of the modeled $3.65M deployment
30% of the full $5M requested budget
If a 24-month real-estate bootstrap/backstop exposure is treated as structurally illiquid, this one position exceeds the stated 20% threshold.
A second mismatch appears in the terms matrix.
The highest expected loan-size band is:
$350K–$500K
while the candidate model contains:
Fist Commerce $700K
Estate Protocol $1.5M
There are several legitimate ways to resolve this:
- declare the terms matrix illustrative;
- resize the candidate exposures;
- create a documented exception-approval path.
The problem is not that an exception is impossible.
The problem is that risk limits cannot be binding in one document and optional in another without an explicit transition rule.
The concentration is substantial:
Estate alone = 41.1% of modeled deployment
Estate + Fractalized + DualMint = 60.3% of modeled deployment
But name count is not the same as independent risk.
Several positions can share:
- the same sector;
- the same legal jurisdiction;
- the same insurer;
- the same liquidity source;
- the same collateral;
- the same protocol;
- the same recovery path;
- the same macroeconomic shock.
The portfolio should therefore publish both single-name and common-dependency concentrations.
At minimum:
largest borrower
top-three borrowers
product type
sector
jurisdiction
insurer
debtor
protocol
collateral
common recovery dependency
This is where the problem stops being a return calculation and becomes a capital-lifecycle problem.
A claim can be legally valid and still be illiquid.
An asset can be fully backed and still be subordinated.
An insured receivable can exist while the insurance claim is disputed.
A loan can be recalled while the borrower has no cash available.
A real-estate claim can be recoverable over two years while the treasury needs liquidity in 30 days.
A credit can be sellable only at a price that realizes a material loss.
Therefore the dashboard must not compress all of these states into one “capital preserved” label.
A cleaner accounting view is:
economic NAV
=
cash
+ fair value of performing claims
+ recoverable value
− expected losses
− costs
− liabilities
while liquidity is measured separately:
available liquidity
=
cash
+ assets realizable inside the required time window
Net asset value and available liquidity are different observables.
The proposal includes the ability for a supervising entity to revoke the multisig and trigger a full recall.
That is meaningful governance authority.
It is not proof of immediate liquidity.
A recall order can be instantaneous while repayment takes:
- one day;
- 30 days;
- six months;
- the remaining contractual term;
- an insurance claim;
- a court process;
- collateral realization;
- a discounted secondary sale.
The system therefore needs a liquidity/recovery ladder for each exposure:
| Horizon | Expected recoverable cash |
|---|---|
| T+1 day | $X |
| T+7 days | $X |
| T+30 days | $X |
| T+90 days | $X |
| T+180 days | $X |
| Beyond 180 days | $X |
The ladder should exist under both normal and stressed assumptions.
Verification Point V-03 — what does “recall” mean operationally?
If a facility can contractually force cash settlement inside a defined horizon, publish that horizon and enforcement mechanism. The right to demand payment and the capacity to receive payment should be measured separately.
The public chart shows approximately:
pessimistic 7.5%
base 10.9%
optimistic 13.5%
stress 5.0%
T-bills 3.52%
A real credit stress test must allow the system to produce outcomes such as:
- delayed principal;
- principal impairment;
- failed insurance;
- forced sale at a haircut;
- correlated defaults;
- funding-cost spikes;
- liquidation of funding collateral;
- legal/recovery costs;
- multi-quarter illiquidity;
- negative annual return.
The optimistic result is close to the weighted maximum input yield of approximately 13.493%.
The base case can be reconstructed.
The public inputs reviewed do not expose an equally reproducible transformation for the pessimistic and stress bars.
Every scenario should therefore publish:
changed inputs
formula
output
affected positions
time horizon
scenario purpose
sensitivity/stress/expected-case label
Verification Point V-04 — reproduce the stress bar.
If a reader can derive the published 5.0% stress result from a complete public input transformation, that calculation should be added. If it cannot be reproduced, the bar should remain a reported scenario rather than a verified one.
One public KPI uses:
T-bills = 4.5%
while a chart uses:
T-bills = 3.52%
A benchmark can legitimately change over time.
But a reproducible comparison needs:
source
observation timestamp
maturity
gross/net treatment
update frequency
cost treatment
The same applies to Aave borrowing rates.
A current floating borrow rate is not a frozen two-year funding cost.
The relevant comparison is not:
portfolio yield > today's borrowing rate
It is closer to:
net portfolio return
after expected loss
after funding cost
after operating cost
after legal cost
after incentives
after impairment
>
matched benchmark over the same horizon
The proposed funding alternative uses DAO ETH/stETH as collateral to borrow stablecoins.
That creates a second system:
DAO ETH/stETH collateral
→ onchain stablecoin debt
→ BLAZE loan
→ offchain or protocol claim
→ repayment
→ stablecoin debt repayment
→ collateral release
The funded loan may have a six-, 12-, or 24-month recovery cycle.
The collateralized debt can react to market conditions continuously.
It is exposed to:
- ETH/stETH price movement;
- liquidation thresholds;
- variable borrow rates;
- utilization;
- oracle updates;
- collateral parameter changes;
- health-factor deterioration.
That creates a timing mismatch:
The onchain liability can demand action within minutes while the financed asset may require months or years to recover.
The public slide describes borrowing $4M against $16M of collateral as 400% LTV.
The conventional arithmetic is:
LTV = $4M / $16M = 25%
collateralization ratio = $16M / $4M = 400%
The position may still begin conservatively.
The terminology should simply identify the correct metric.
If leverage remains in scope, the system needs:
- initial and minimum health factor;
- collateral drawdown stresses;
- borrow-rate stresses;
- interest accrual;
- liquidation penalty;
- emergency repayment source;
- 24/7 monitoring responsibility;
- authority to add collateral or repay;
- maximum response time;
- minimum liquid stablecoin reserve.
For a first pilot, the simplest design is:
Do not introduce treasury leverage until the lending process itself has a real performance history.
The request includes:
$30K operational expenses
up to $100K/year committee compensation
two-year duration
Maximum stated two-year program cost:
$30K + 2 × $100K = $230K
Relative to the modeled $3.65M deployment, that is approximately:
3.15% per year
If the reconstructed 10.905% base estimate is reduced only by that annualized overhead:
10.905% − 3.151% = 7.754%
This remains positive.
But it is still before:
- stablecoin borrowing cost;
- additional legal/enforcement cost;
- insurance cost;
- KYB cost beyond assumptions;
- ARB incentives;
- custody/execution costs;
- impairment;
- recovery expense;
- secondary-market discount.
Therefore the public comparison is still a gross-to-benchmark comparison, not yet a complete net-to-net comparison.
The public process is clear through origination:
Application
→ Initial screening
→ Business review
→ Legal review
→ Technical review
→ Committee decision
→ Credit-line terms
→ Agreement signed
→ Project-specific pool
→ Funds deposited
Then the diagram ends.
For lending, funding is not the terminal state.
It is the beginning of the exposure.
The missing half is:
ACTIVE
→ MONITORED
→ PAYMENT_DUE
→ PAID / EXTENDED / WATCHLIST
→ DELINQUENT
→ DEFAULT
→ RECOVERY
→ SETTLED / IMPAIRED / WRITTEN_OFF
→ RECONCILED
Each state needs:
owner
entry condition
exit condition
required evidence
allowed action
accounting treatment
disclosure rule
This is the missing operating system between approval and capital recovery.
The proposal correctly asks for verifiable backing such as:
- insurance;
- audited financials;
- verified invoices;
- third-party proof.
But backing is not a permanent property.
An invoice verified at T0 can later be:
- disputed;
- assigned elsewhere;
- subordinated;
- paid to a different account;
- excluded from coverage;
- unenforceable under the assumed structure.
A property can remain real while:
- lien priority changes;
- another creditor is senior;
- valuation falls;
- enforcement takes years;
- senior claims consume proceeds.
The evidence state therefore needs:
evidence type
issuer
issue time
freshness window
jurisdiction
beneficiary
assignment
seniority
coverage
exclusions
verification method
last re-verification
adverse-change trigger
BACKED = true should never be an eternal boolean.
The proposal groups together several economically different facilities:
- insured invoice factoring;
- general working-capital lending;
- AMM/protocol liquidity bootstrapping;
- long-duration RWA backstop liquidity;
- potentially leveraged real-estate lending;
- ARB incentive support.
These do not share the same:
- cash-flow source;
- legal structure;
- collateral behavior;
- liquidity horizon;
- technical risk;
- valuation method;
- default definition;
- recovery route.
A cleaner design separates them.
- verified invoice;
- perfected assignment;
- defined seniority;
- identifiable debtor;
- insurance or strong recourse;
- maximum 90-day term;
- self-liquidating cash flow.
- audited contracts;
- transparent vault and withdrawal path;
- explicit oracle/liquidity assumptions;
- limits based on real exit depth;
- separate technical and market-risk model.
- separate mandate;
- independent valuation;
- legal perfection;
- explicit recovery timeline;
- liquidity haircut;
- no short recall promise;
- lower concentration;
- separate approval.
These facilities should not share one launch pool merely because all of them can be described as “liquidity.”
The public model can be strengthened through four connected calculations.
Net Return
=
Interest
+ Fees
+ Realized Upside
+ Idle-Cash Yield
− Funding Cost
− Operating Cost
− Legal Cost
− Incentives
− Expected Credit Loss
− Realized Impairment
A simple starting structure:
ECL = EAD × PD(term) × LGD
where:
EAD= exposure at default;PD(term)= probability of default over the actual exposure term;LGD= loss after realistic recovery, seniority, delay, cost, insurance, and liquidity haircut.
L(t) = expected cash realizable by time t under a defined scenario
At minimum:
1 day
7 days
30 days
90 days
180 days
contractual maturity
stressed recovery
Measure:
- borrower;
- top-three exposure;
- sector;
- jurisdiction;
- insurer;
- debtor;
- protocol;
- collateral;
- shared recovery dependency.
A position should not move to FUNDING_READY merely because one committee approves it.
- KYB complete;
- beneficial ownership verified;
- signatory authority verified;
- recipient account/vault bound to agreement;
- related parties disclosed.
- cash-flow source identified;
- PD horizon defined;
- EAD and LGD calculated;
- concentration limit passed;
- connected exposure aggregated;
- downside case passed.
- governing law fixed;
- assignment/lien perfected;
- seniority documented;
- enforcement party identified;
- default events defined;
- recovery rights operational.
- policy verified with issuer;
- beneficiary/amount confirmed;
- exclusions reviewed;
- claim route tested;
- expiry monitored;
- duplicate encumbrance checked.
- audit scope matches deployment;
- contract addresses fixed;
- admin/upgrade authority mapped;
- withdrawal path tested;
- oracle/bridge/custody dependencies identified;
- incident/pause route defined.
- source of capital fixed;
- funding cost included;
- reserve floor preserved;
- health-factor stress passed if leverage is ever used;
- emergency repayment liquidity identified.
- approvals reference a versioned evidence package;
- documents have hash, timestamp, owner, and expiry;
- unresolved conditions block funding.
A complete system separates at least:
- origination;
- credit underwriting;
- technical review;
- legal review;
- risk control;
- execution/custody;
- monitoring;
- recovery;
- accounting.
The same person should not originate, approve, execute, and mark the same exposure.
The policy should also define:
- conflicts;
- recusal;
- connected-party rules;
- approval quorum;
- exception authority;
- limit changes;
- emergency pause;
- replacement of committee members;
- audit rights;
- termination;
- wind-down.
A dashboard is an interface.
It should not be the canonical ledger.
The source of truth should be versioned and exportable, containing at least:
facility ID
borrower/connected-party ID
agreement version/hash
vault/address
approved amount
funded amount
outstanding amount
accrued yield
fees
incentives
funding cost
maturity
status
PD horizon
LGD
expected loss
backing state
evidence freshness
liquidity by horizon
impairment
recovery proceeds
realized loss
approval references
last update time
Every quarterly snapshot should preserve its prior state rather than silently overwrite history.
Before expansion, the model should survive cases such as:
- largest borrower defaults with zero recovery for 12 months;
- two correlated borrowers default simultaneously;
- insurance is denied or delayed 180 days;
- secondary liquidity exists only at 20%, 35%, or 50% discount;
- full recall is issued;
- extensions increase weighted-average life 50%;
- recovery cost consumes 10% or 25% of proceeds;
- funding rates rise 300, 600, or 1,000 bps;
- ETH/stETH collateral falls 25%, 40%, or 60% if leverage exists;
- protocol/oracle/bridge route fails;
- incentives fail to attract replacement liquidity;
- one jurisdiction becomes temporarily unenforceable.
For each:
net NAV impact
cash at 7/30/90 days
health factor if applicable
limit breaches
required action
residual loss
recovery time
A safer first cohort can be much smaller:
Total program capital $1,000,000
Maximum outstanding loans $750,000
Minimum liquid reserve $250,000
Maximum per borrower $250,000
Maximum borrowers 3
Eligible product verified short-duration receivables
Maximum term 90 days
Leverage none
ARB incentives none
Automatic rollover none
Long-duration real estate excluded
Secondary-market backstop excluded
The question becomes measurable:
Can the DAO originate, monitor, collect, reconcile, and recover short-duration credit through a repeatable public process?
A successful first cycle creates evidence for expansion.
A weak first cycle limits loss and identifies the failing layer.
A complete public package should include:
- versioned program charter;
- separate facility definitions;
- hard outstanding and cumulative-origination limits;
- complete post-funding state machine;
- reproducible financial model;
- explicit PD horizons;
- net return after all material costs;
- liquidity ladder and principal-loss stresses;
- versioned legal template per facility;
- collateral/assignment/priority/insurance requirements;
- role separation and conflict policy;
- monitoring/default/recovery/write-off procedures;
- machine-readable ledger schema;
- no-leverage first-pilot specification;
- wind-down plan.
These are not administrative decorations.
They are the objects that turn:
"The DAO has a claim"
into:
"The DAO can measure, collect, impair, recover, and reconcile capital."
Falsification Point F-01.
This analysis should change if a reproducible public model can show all of the following simultaneously: term-aligned PDs, all-in funding and operating costs, a principal-loss stress transformation, liquidity by horizon, cumulative origination limits, and a complete post-funding recovery lifecycle. A stronger public model should replace the weaker reconstruction rather than be forced into this conclusion.
The strongest part of BLAZE is not the 10.9% headline.
The fact that the base number can be reconstructed is useful.
It lets the analysis move past the easy argument about whether the chart is arbitrary.
The real problem appears one layer later.
A recyclable lending facility is not only:
screen
→ approve
→ fund
It is:
screen
→ approve
→ fund
→ monitor
→ collect
→ detect deterioration
→ impair when required
→ recover
→ account
→ reconcile
And a $5M budget is not only a $5M exposure number when the same capital can be originated repeatedly.
The clean recommendation is therefore:
Begin with a small, unlevered, receivables-only pilot with explicit liquidity, recovery, accounting, and evidence states. Expand the mandate only after the first full capital cycle has been settled and independently reviewed.
The proposal does not need a more attractive return bar.
It needs a complete capital lifecycle.
- BLAZE proposal and discussion
- BLAZE Financial Model
- BLAZE Liquidity Pool Agreement
- Aave — Borrow Tokens
- Aave — Health Factor & Liquidations
- Basel Committee — Principles for the Management of Credit Risk
- IFRS — probability-weighted expected credit losses and time value of money
This repository contains an independent technical analysis of publicly available material.
BLAZE and the referenced project materials belong to their respective authors and publishers. This work does not claim authorship of the BLAZE proposal.
No open-source license is granted for this article in version 1.0. Copyright remains with the author.
Readers with:
- a reproducible PD-horizon definition;
- a full transformation for the published stress case;
- a stronger cumulative-origination calculation;
- a documented liquidity/recovery schedule;
- or a falsifying public model
can open an issue and reference V-01 through V-04 or F-01.
The purpose is not discussion for its own sake. It is to make technical disagreement reproducible.
Copyright © 2026 cxclrfx. All rights reserved.