Protocol intelligence
One system at a time: what it is, where it runs, what can be proven.
UR Account / Card Protocol
DRAFT Interpreted hereNo 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 UR Account / Card Protocol completes a payment
- F01fact
- F02fact
- F03inference
- F04disproven
- F05disproven
- F06inference
- +3 more on Functions
- F07fact
- F10disproven
- F11disproven
- +3 more on Functions
Architecture overview
System architecture and how value moves through it
Runs on one chain · Decides each payment · profile arch-ur-v7 · 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
Activity & adoption analytics
Only metrics with a published definition
UR Account / Card Protocol carries 17 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 |
|---|
2015 committed publication batches across 1 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 |
|---|---|---|---|---|---|---|---|
| ur-mantle-mainnet | 5000 | Active | 2015 | 31,420,289 – 100,056,858 | 47,816,147 | 15iCommitted batches whose block range overlaps another — a repair republished the range. Facts are not double-counted; batch fact counts would be, which is why this terminal publishes no fact total. | 2026-09-01 06:21 UTC |
Evidence coverage
17 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
- ur
- Registry
- ur-
mantle · 0.2.0 - Registration
- DRAFT
- Programme
- ur
- Account model
- ERC721_
TOKEN_ ID - Custody
- PROTOCOL_
CUSTODY - Settlement locus
- CARD_
NETWORK - Networks
- mantle-
mainnet - Deployments
- ur-
mantle- mainnet - 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.