Protocol intelligence
One system at a time: what it is, where it runs, what can be proven.
Ether.fi Cash (cash-v3)
DRAFTNo published research note describes this system in prose. What follows is the registration and what has been observed against it.
Deployment-wide metrics are on the Overview page at revision metric-v4.iThe registry describes each system separately; C09 computes over the facts the deployment holds. The first can be split per system and the second cannot.
Payment system anatomy
How Ether.fi Cash (cash-v3) completes a payment
- F01fact
- F02fact
- F03inference
- F04disproven
- F05disproven
- F06fact
- +3 more on Functions
- F07fact
- F10disproven
- F11fact
- +3 more on Functions
Architecture overview
System architecture and how value moves through it
One primary chain, funded from others · Decides each payment · profile etherfi-cash-arch-optimism · revision 1iEvery value in the lanes is a registry declaration bound to evidence, at the protocol version named in the header. Nothing here is inferred from activity.
Multi-chain presence
Where this system runs
Activity, events and amount by chain
Funding mix, by declared share
- DIRECT_
ONCHAIN_ 92.3%TRANSFER / PREFUNDED · Debit mode - COLLATERALIZED_
CREDIT / CREDIT · 7.7%Credit mode
Basis: declared share of funding, in basis points of 10,000. Not a measured amount, and not a share of any market.
1 further declared funding profile carries no share, so it is absent from the ring rather than zero.
Activity & adoption analytics
Only metrics with a published definition
Ether.fi Cash (cash-v3) carries 19 assessment rows; none of them is a time series.
On-chain evidence preview
The shape of the evidence behind every figure on this page
| Time | Chain | Event type | From | To | Amount | Tx hash |
|---|
0 committed publication batches across 2 deployment records — the block ranges are in Publication coverage below.
Related systems
Declared dependencies
Rails this system settles or funds through, as the registry declares them. A graph across registered systems is not published, so none is drawn.
Publication coverage
Which blocks the figures above rest on
| Deployment | Chain | Activity | Batches | Blocks | Contiguous | Republished | Data through |
|---|---|---|---|---|---|---|---|
| etherfi-cash-optimism | 10 | Active | 0 | — | — | 0 | — |
| etherfi-cash-scroll | 534352 | Dormant | 0 | — | — | 0 | — |
Evidence coverage
19 assessment rows over 17 functions iRows, not functions: a pack that splits one function into two aspects contributes two rows and one function.
Key facts
- System id
- etherfi-
cash - Registry
- etherfi-
cash · 0.1.0 - Registration
- DRAFT
- Programme
- etherfi-
cash - Account model
- SMART_
ACCOUNT_ ADDRESS - Custody
- RESTRICTED_
SELF_ CUSTODY_ SMART_ ACCOUNT - Settlement locus
- SHARED_
POOL - Networks
- optimism, scroll, ethereum, base, arbitrum, bsc, hyperevm, polygon, sonic, mantle, avalanche, linea, chain-
9745, chain- 4217 - Deployments
- etherfi-
cash- optimism, etherfi- cash- scroll - Issuer / operator
- not declared
- Reserve transparency
- not declared
- Regulatory status
- not declared
- Smart contract upgradeability
- not declared
The rows marked not declared have no field in any registration pack. C01 asserts a legal entity only where the chain record establishes one, and for these systems it does not.
Recent signals
Changes and events
industry_signals
Registry and facts read through 2026-09-01 06:40 UTC
Methodology
- Every count here is SpendGraph's observed coverage. It is not a total for the on-chain payment market, and no denominator for that market is published anywhere on this site.
- Counts are read from C09's published series at a pinned catalog revision. This page performs no count of its own — a second implementation of a published metric is a second thing that can be wrong.
- Publication batches answer how far coverage reaches, never how many facts exist. A repair republishes a range, so summing batch fact counts double-counts the repaired part: on 2026-08-21 that sum was 85,021 against 81,034 actual facts, with zero retractions.
- A registration status describes how far SpendGraph's own review of a pack has got. It is not an assessment of the protocol, and every review state is compatible with a deployment that stopped carrying payments months ago — which is why activity is a separate column.
- The payment function catalog is frozen at seventeen entries. A new protocol term is mapped onto an existing function rather than growing the catalog, so a function absent from a protocol's assessment means nobody has assessed it — not that it does not exist.
- The six capability groups are defined by this site alone, as a presentation over the seventeen. Two of them — Identity and Credit — have no catalog function, so no protocol can be assessed against them and they are shown as such.