Protocol intelligence
One system at a time: what it is, where it runs, what can be proven.
RedotPay
DRAFTNo published research note describes this system in prose. What follows is the registration and what has been observed against it.
Registryredotpay · 0.1.0
System idredotpay
Programmeredotpay
Observed activityAmount aggregation
Not observedAmounts are published per denomination; a single figure would need a rate SpendGraph does not observe.
Payment eventsC06 · C09
Not yet publishedNo payment-event count is published for this system yet.
Active payment addressesAddress attribution
—
Connected chainsC01 deployment model
3
0 carrying published facts
First observedC06 publication
Not yet publishedNo committed publication batch yet.
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 RedotPay completes a payment
Native
Integrated
Dependent
Not observed
iWhere a function happens and whether it can be seen. Not a grade, not a ranking, and not ordered best to worst.
Identity
Who is involved
Not observed
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
Where value is held
Dependent
1/1
1 private only
Key evidence
- F01private only
Funding
How value enters
Integrated
Dependent
2/2
1 inference 1 private only
Key evidence
- F02private only
- F03inference
Authorization
How payments are approved
Dependent ×5
Not observed
6/6
3 private only 2 inference 1 unknown
Key evidence
- F04inference
- F05private only
- F06inference
- +3 more on Functions
Settlement
How value moves
Dependent ×5
Not observed
6/6
3 private only 2 inference 1 unknown
Key evidence
- F07private only
- F10inference
- F11unknown
- +3 more on Functions
Credit
How credit is provided
Not observed
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 overview
System architecture and how value moves through it
Not observedNo published architecture profile. A draft profile is a claim under review and is not shown as one — this is an absence of research, not of architecture.
Multi-chain presence
Where this system runs
Not observedNo published architecture profile, so no chain roles are declared. The deployment record below is what is known.
Activity & adoption analytics
Only metrics with a published definition
Not applicableActivity has no published metric definition. The tab is kept because the module is part of the design; a series would have to be invented.
Not yet publishedC09 has published no post_auth_funds_action_count series for this system at this revision.
Not yet publishedC09 has published no active_payment_address_count series for this system at this revision.
Not applicableFlows has no published metric definition. The tab is kept because the module is part of the design; a series would have to be invented.
Not applicableVelocity has no published metric definition. The tab is kept because the module is part of the design; a series would have to be invented.
Not applicableRetention has no published metric definition. The tab is kept because the module is part of the design; a series would have to be invented.
Not applicableUse cases has no published metric definition. The tab is kept because the module is part of the design; a series would have to be invented.
RedotPay 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 |
|---|
Not observedThis surface reads only what C10 publishes, and a raw event is a domain record C10 does not publish. The From and To columns would also name addresses, which this site does not disclose for any system.
0 committed publication batches across 0 deployment records — the block ranges are in Publication coverage below.
Related systems
Declared dependencies
Not observedNo rail is declared for this system, and no component computes a graph between registered systems.
Publication coverage
Which blocks the figures above rest on
Not observedThe registration declares no deployment, so there is no range to publish.
Evidence coverage
private only9
inference6
unknown2
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
- redotpay
- Registry
- redotpay ·
0.1.0 - Registration
- DRAFT
- Programme
- redotpay
- Account model
- not declared
- Custody
- not declared
- Settlement locus
- not declared
- Networks
- tron-
mainnet, ethereum- mainnet, bsc- mainnet - Deployments
- none declared
- 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
Not applicableno signals engine exists; the design's signal feed has no component behind it yet
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.