Protocol intelligence

One system at a time: what it is, where it runs, what can be proven.

Ether.fi Cash (cash-v3)17/17 Gnosis Pay Safe Card Protocol17/17 RedotPay17/17 UR Account / Card Protocol17/17

Gnosis Pay Safe Card Protocol

DRAFT

No published research note describes this system in prose. What follows is the registration and what has been observed against it.

Registrygnosis-pay · 0.2.0 System idgnosis-pay Programmegnosis-pay Versiongnosis-pay-v5-2026-06

Observed activityAmount aggregation

Not observedAmounts are published per denomination; a single figure would need a rate SpendGraph does not observe.

Payment eventsC06 · C09

538

11 published windows on this system

Active payment addressesAddress attribution

—

Connected chainsC01 deployment model

1 carrying published facts

100

First observedC06 publication

47,817,934

earliest published block · through 2026-09-01 06:40 UTC

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 Gnosis Pay Safe Card Protocol 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

Native

1/1

1 fact

Key evidence

F01fact

Funding

How value enters

Native Integrated

2/2

1 fact 1 inference

Key evidence

F02fact
F03inference

Authorization

How payments are approved

Native ×2 Integrated ×2 Dependent ×2

6/6

3 fact 3 disproven

Key evidence

F04disproven
F05fact
F06fact
+3 more on Functions

Settlement

How value moves

Native ×2 Integrated ×2 Dependent ×2

6/6

4 disproven 2 fact

Key evidence

F07fact
F10disproven
F11fact
+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

Account

Who participates, and what the account is

SMART_ACCOUNT_ADDRESS

Account identity does not survive an address change

Funding

How value enters, and how a balance is held

DIRECT_ONCHAIN_TRANSFER / PREFUNDED

OFFCHAIN_FUNDING / PREFUNDED

Settlement

Where the obligation settles

CARD_NETWORK

Runs on one chain · Constrains what the account may spend · profile arch-gnosis-pay-v5 · 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

gnosis-mainnetPrimaryfacts published

Activity, events and amount by chain

Not yet publishedC09 publishes no metric broken down by chain for one system, so there is no per-chain figure to state a basis for.

Funding mix, by declared share

DIRECT_ONCHAIN_TRANSFER / PREFUNDED · external_inbound83.0%
DIRECT_ONCHAIN_TRANSFER / PREFUNDED · hold_return8.1%
OFFCHAIN_FUNDING / PREFUNDED · emoney_mint7.1%
DIRECT_ONCHAIN_TRANSFER / PREFUNDED · account_to_account1.8%

Basis: declared share of funding, in basis points of 10,000. Not a measured amount, and not a share of any market.

Activity & adoption analytics

Only metrics with a published definition

Activity Payment events Active payment addresses Flows Velocity Retention Use cases

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 groups post_auth_funds_action_count by protocol and the terminal reads this system's own daily series — 11 published windows at this revision. This module does not draw it yet, so the frame is kept empty rather than filled from another population.

Not yet publishedC09 groups active_payment_address_count by protocol and the terminal reads this system's own daily series — 4 published windows at this revision. This module does not draw it yet, so the frame is kept empty rather than filled from another population.

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.

Gnosis Pay Safe 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

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.

7085 committed publication batches across 1 deployment records — the block ranges are in Publication coverage below.

Related systems

Declared dependencies

rail-gp-onchain-accountRail

rail-gp-card-networkRail

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
gnosis-pay-gnosis	100	Active	7085	47,817,934 – 48,021,665	48,021,665	0	2026-09-01 06:40 UTC

Evidence coverage

disproven8

fact7

inference1

private only1

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: gnosis-pay
Registry: gnosis-pay · 0.2.0
Registration: DRAFT
Programme: gnosis-pay
Account model: SMART_ACCOUNT_ADDRESS
Custody: RESTRICTED_SELF_CUSTODY_SMART_ACCOUNT
Settlement locus: CARD_NETWORK
Networks: gnosis-mainnet
Deployments: gnosis-pay-gnosis
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.