Compare payment systems
Registered systems side by side. Differences described, never scored.
etherfi-cash
Ether.fi Cash (cash-v3)
DRAFT no chain with facts
17/17
Categoryno fieldiNo registration pack declares a category and the registry model has no field for one, so any category here would be this site's invention rather than a reading. The slot is kept and named rather than dropped.
AccountThe account is a contract-controlled address
ChainsOne primary chain, funded from others
gnosis-pay
Gnosis Pay Safe Card Protocol
DRAFT 100
17/17
Categoryno fieldiNo registration pack declares a category and the registry model has no field for one, so any category here would be this site's invention rather than a reading. The slot is kept and named rather than dropped.
AccountThe account is a contract-controlled address
ChainsRuns on one chain
redotpay
RedotPay
DRAFT no chain with facts
17/17
Categoryno fieldiNo registration pack declares a category and the registry model has no field for one, so any category here would be this site's invention rather than a reading. The slot is kept and named rather than dropped.
ArchitectureNot observed
ur
UR Account / Card Protocol
DRAFT 5000
17/17
Categoryno fieldiNo registration pack declares a category and the registry model has no field for one, so any category here would be this site's invention rather than a reading. The slot is kept and named rather than dropped.
AccountThe account is a token id, not an address
ChainsRuns on one chain
Comparison insights
Execution routes as the registry declares them
Decides each payment
Ether.fi Cash (cash-v3) · UR Account / Card ProtocolAUTHORIZATION_CENTRICConstrains what the account may spend
Gnosis Pay Safe Card ProtocolCONSTRAINT_CENTRICNo route declared
RedotPay§六 also draws on research notes for the reasoning behind each route. No component here writes one, so this panel carries the declared routes and not the analysis of them.
Capability differences
Design decisions each registration declares
Ether.fi Cash (cash-v3)
- The account is a contract-controlled address
- One primary chain, funded from others
- Decides each payment
Gnosis Pay Safe Card Protocol
- The account is a contract-controlled address
- Runs on one chain
- Constrains what the account may spend
RedotPay
Not observedThis registration declares no architecture profile, so it states no design decisions to compare.
UR Account / Card Protocol
- The account is a token id, not an address
- Runs on one chain
- Decides each payment
§七 pairs each decision with the trade-off it costs. What a decision costs is a research conclusion, and nothing here produces one — so the decisions are listed and their consequences are not asserted.
Best fit scenarios
Not yet published§八 builds this from function coverage and architecture pattern, and both are published — but its output is a use-case name, and no use-case vocabulary is declared anywhere in this system. Naming one here would invent the mapping rather than read it.
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.
Capability comparison
Differences described; nothing scored, nothing called better
| Capability | Ether.fi Cash (cash-v3) | Gnosis Pay Safe Card Protocol | RedotPay | UR Account / Card Protocol |
|---|---|---|---|---|
| Identity no catalog function | Not in catalogiThe frozen function catalog defines no function for this group, so no assessment can exist. Not a gap in this protocol's registration. | Not in catalogiThe frozen function catalog defines no function for this group, so no assessment can exist. Not a gap in this protocol's registration. | Not in catalogiThe frozen function catalog defines no function for this group, so no assessment can exist. Not a gap in this protocol's registration. | Not in catalogiThe frozen function catalog defines no function for this group, so no assessment can exist. Not a gap in this protocol's registration. |
| Account F01 | 1/1 1 fact | 1/1 1 fact | 1/1 1 private only | 1/1 1 fact |
| Funding F02 F03 | 2/2 1 fact 1 inference | 2/2 1 fact 1 inference | 2/2 1 inference 1 private only | 2/2 1 fact 1 inference |
| Authorization F04 F05 F06 F08 F09 F14 | 6/6 5 disproven 1 fact | 6/6 3 fact 3 disproven | 6/6 3 private only 2 inference 1 unknown | 6/6 2 inference 2 disproven 1 fact 1 unknown |
| Settlement F07 F10 F11 F12 F13 F15 | 6/6 4 fact 4 disproven | 6/6 4 disproven 2 fact | 6/6 3 private only 2 inference 1 unknown | 6/6 3 disproven 2 fact 1 unknown |
| Credit no catalog function | Not in catalogiThe frozen function catalog defines no function for this group, so no assessment can exist. Not a gap in this protocol's registration. | Not in catalogiThe frozen function catalog defines no function for this group, so no assessment can exist. Not a gap in this protocol's registration. | Not in catalogiThe frozen function catalog defines no function for this group, so no assessment can exist. Not a gap in this protocol's registration. | Not in catalogiThe frozen function catalog defines no function for this group, so no assessment can exist. Not a gap in this protocol's registration. |
Architecture comparison
One route per system, same four decisions — a system with no published profile keeps its column and says so
Axis
Ether.fi Cash (cash-v3)etherfi-cash
Gnosis Pay Safe Card Protocolgnosis-pay
RedotPayredotpay
UR Account / Card Protocolur
Account model
Chain topology
Payment architecture
Identity continuity
The account is a contract-controlled addressSMART_ACCOUNT_ADDRESS
One primary chain, funded from othersPRIMARY_WITH_FUNDING_CHAINS
Decides each paymentAUTHORIZATION_CENTRIC
Survives an address changetrue
The account is a contract-controlled addressSMART_ACCOUNT_ADDRESS
Runs on one chainSINGLE_CHAIN
Constrains what the account may spendCONSTRAINT_CENTRIC
Does not survive an address changefalse
No published profileThe registry declares no architecture profile for this system, so its route is unknown rather than empty.
The account is a token id, not an addressERC721_TOKEN_ID
Runs on one chainSINGLE_CHAIN
Decides each paymentAUTHORIZATION_CENTRIC
Survives an address changetrue
Observed coverage
Active nothing published
Dormant nothing published
Dormant nothing published
Active 7085 batches · 47,817,934 – 48,021,665 · contiguous 48,021,665
No deployment
Active 2015 batches · 31,420,289 – 100,056,858 · contiguous 47,816,147
The same fields as a table of axes
| Axis | Ether.fi Cash (cash-v3) | Gnosis Pay Safe Card Protocol | RedotPay | UR Account / Card Protocol |
|---|---|---|---|---|
| Account model | The account is a contract-controlled address SMART_ACCOUNT_ADDRESS | The account is a contract-controlled address SMART_ACCOUNT_ADDRESS | No published profile | The account is a token id, not an address ERC721_TOKEN_ID |
| Chain topology | One primary chain, funded from others PRIMARY_WITH_FUNDING_CHAINS | Runs on one chain SINGLE_CHAIN | No published profile | Runs on one chain SINGLE_CHAIN |
| Identity continuity | Survives an address change true | Does not survive an address change false | No published profile | Survives an address change true |
| Payment architecture | Decides each payment AUTHORIZATION_CENTRIC | Constrains what the account may spend CONSTRAINT_CENTRIC | No published profile | Decides each payment AUTHORIZATION_CENTRIC |
| Observed coverage | Active nothing published Dormant nothing published | Active 7085 batches · 47,817,934 – 48,021,665 · contiguous 48,021,665 | No deployment | Active 2015 batches · 31,420,289 – 100,056,858 · contiguous 47,816,147 |
System profile & key metrics
SpendGraph observed data, not protocol reported — for scale, not rank
| System | Active payment addresses | Chains |
|---|---|---|
| Ether.fi Cash (cash-v3) | Not yet published | optimism · scroll · ethereum · base · arbitrum · bsc · hyperevm · polygon · sonic · mantle · avalanche · linea · chain-9745 · chain-4217 |
| Gnosis Pay Safe Card Protocol | Not yet published | gnosis-mainnet |
| RedotPay | Not yet published | tron-mainnet · ethereum-mainnet · bsc-mainnet |
| UR Account / Card Protocol | Not yet published | mantle-mainnet |
§九 also asks for Payment Events and Observed Activity per system, and neither column is here. Payment events are published for the deployment as a whole and not split by system, so there is no per-system figure to read and dividing the total would invent one. Observed activity has no per-system total at all: the coverage record carries committed batches and their block ranges, and some of those ranges overlap, which is the reason it publishes no fact count to total.