Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-13 · Instrument version 1.0.0
What Matters
- Transfer volume measures value moved under a specified counting rule. It does not identify how many humans, agents or organizations controlled the activity.
- Adjusted series depend on classifications and methodology versions. A revised label set can change the chart without a new transaction occurring.
- DN’s local reconciler keeps unclassified value visible and calculates turnover only with a comparable supply denominator. It infers no actor count.
DN Alpha Thesis
One hundred tokens move through three addresses and return to the starting point. Depending on the transfer boundary, the record can contain three movements and 300 tokens of gross transferred value. That does not establish three customers, three purchases or three autonomous agents.
The distinction matters when a stablecoin chart becomes evidence for a commercial claim. A service can process a great deal of value while serving a small group. An agent can use several wallets. A shared wallet can support several systems. Transferred value, transaction count, unique addresses and separately identified actors are different measurements.
DN’s instrument begins earlier in the analysis: can the stated transfer total be reconciled to mutually exclusive classifications, and does the supply used for turnover describe the same asset, network, units and period? Those checks do not discover who controlled a transaction. They expose the assumptions that must be settled before a volume chart can support a narrower economic statement.
DN Evidence Block
Sources reviewed 13 November 2026: Visa’s transaction methodology, the Visa/Allium changelog, its agentic-payments panel, ERC-20, Coin Metrics’ transfer-value and velocity definitions, and Circle’s contract directory. They document interfaces, classification choices and metric boundaries. No headline market totals were independently reproduced here.
DN supplies a reconciliation method and synthetic cases. Categories entered into the worksheet are the reader’s classifications, not verified payment labels. The tool does not reproduce Visa’s adjusted series, identify wallets, query chains or estimate the share of activity performed by AI.
Original DN instrument · version 1.0.0
DN Stablecoin Transfer Boundary Reconciler
Reconcile supplied transfer classifications and calculate comparable period turnover without inferring actor identities.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Enter inputs or load an illustrative example.
One declared asset/network/cohort, selected native-token denomination and UTC date window. Six decimal places; one billion selected units per field. No chain access, wallet labelling or independent evidence verification.
Name the quantity before interpreting its growth
| Measurement | What it can describe | What it does not establish by itself |
|---|---|---|
| Transfer value | Summed amounts under a declared event and valuation rule | Final purchases or distinct actors |
| Transaction count | Included transactions under the dataset’s rule | Number of customers or autonomous decisions |
| Unique addresses | Distinct address identifiers in the selected scope | Unique people, organizations or software instances |
| Payment-purpose classification | Activity assigned to a use case using stated evidence | That an AI rather than a person initiated it |
| Transfer turnover | A flow divided by a specified supply measure | A population or a causal driver of demand |
For ERC-20 tokens, the standard transfer event contains sender, recipient and value fields. Those fields do not include a verified human-versus-agent label. DN’s inference is limited: actor attribution needs evidence beyond that event interface. Other token systems need their own interface and counting review.
A payment dashboard still needs an attribution boundary
Visa’s current Agentic Payments panel describes tracking x402 and MPP activity. It separately labels payment volume, transaction count, buyer wallets and merchant wallets. Its buyer-wallet metric is described as unique buyer addresses, and the category breakdown says it excludes unlabeled volume.
That is a more specific observation boundary than “all stablecoin transfers.” Preserve it when reusing the data. A protocol-based series can be useful while leaving questions about software identity, manual initiation, shared credentials or operator control unresolved.
Suppose one fictional service rotates its paying address every day. A monthly unique-address count can exceed the number of service operators. Conversely, multiple agent processes can share one treasury wallet. Neither example proves a real dashboard is wrong; each shows why converting its address metric into an agent census requires an additional mapping.
Keep that mapping versioned and challengeable if one exists. Do not quietly substitute address count, transaction frequency or payment size for independently supported actor labels.
Adjustment is a method, not a universal truth label
Visa’s transaction page describes probabilistic address labels and heuristic filters intended to reduce distortions from activity including routing, trading and internal operations. It also distinguishes use-case categories from inclusion in an adjusted series. A category can intersect more than one reporting boundary.
Coin Metrics documents its own adjusted transfer-value rules, with different treatment for UTXO and account-based systems. The shared word “adjusted” does not make the two providers’ outputs interchangeable. The correct comparison starts with the precise metric definition, asset coverage and revision.
Do not rename everything removed by a filter “fraud,” or everything retained “human commerce.” An internal treasury movement may be legitimate yet outside a particular payment statistic. A small transfer can still be a test, rebate, routed amount or automated interaction. The measurement purpose determines what belongs in the numerator; it does not assign moral or legal status to the transaction.
A methodology revision can move the historical chart
The Visa/Allium changelog dated 18 September 2026 reports a data refresh, broader labeling, additional heuristics and changes to adjusted volume. That is a concrete reason to preserve the data and methodology version alongside a time series.
If an older extract and a refreshed extract report different values for the same month, first ask whether the definition, coverage, labels or backfill changed. Do not automatically describe the difference as an economic collapse or a new surge in adoption. The underlying transactions may be unchanged while their inclusion changes.
This article deliberately does not compare label-count totals presented on different documentation surfaces. Without an aligned definition and version, those figures cannot establish a common coverage rate. The supported conclusion is narrower: metadata and classification revisions can materially change the interpretation of a published series.
Reconcile one declared transfer population
The DN worksheet uses four entered classifications plus an unresolved remainder. The classifications are purpose-built for this exercise; they are not a replica of any provider’s taxonomy.
| Entered classification | Boundary |
|---|---|
| Issuance/redemption | Events placed in this class under the source and reviewer’s rule |
| Internal/routing | Transfers supported as internal movement or intermediate routing |
| Payment purpose | Transfers assigned to payment activity with retained supporting evidence |
| Other classified | Other understood activity that does not belong in the preceding classes |
| Unclassified | Gross value not assigned to any entered class |
Each included transfer belongs in at most one class. Retain the priority rule used to resolve overlaps. If a routing transaction also touches an exchange, choosing both classes would count it twice. The worksheet rejects classified totals above gross value, but totals below gross can still hide offsetting mistakes; the reader must declare whether exclusivity has been established.
Zero in a classification means no value has been assigned to that class in this record. It does not prove that no such activity exists. Missing classification belongs in the unresolved remainder. If exclusivity is unknown, the tool withholds that remainder and the category shares.
Read the synthetic reconciliation without inventing agents
Consider a fictional cohort with 1,000,000 token units of gross transfer value. The reviewer assigns 100,000 to issuance/redemption, 600,000 to internal/routing activity, 150,000 to payment purpose and 50,000 to other classified transfers. The categories are declared mutually exclusive.
The classified total is 900,000. Unclassified value is 100,000, or 10% of gross. The payment-purpose class represents 15% of gross. Those calculations describe the supplied classification. They do not establish that the remaining 85% is waste, that payments were human initiated or that 10% was performed by unidentified agents.
If the same asset/network had a time-weighted average supply of 200,000 token units over that exact period, gross transfer turnover would be 5× and payment-classified turnover 0.75×. Neither number tells you how many agents participated. The instrument reports actor count as “Not inferred” in every case.
Return to the three-hop example: 300 token units transferred against an average supply of 100 produces gross turnover of 3×. If all 300 units belong to internal/routing movement, payment-classified turnover is zero under that declared rule. The number of software participants still remains unresolved.
Match the supply denominator to the transfer numerator
Coin Metrics’ velocity documentation distinguishes active-supply and current-supply formulations over a trailing year. That distinction matters: a metric name must specify which supply measure is used and when it is measured.
DN chooses a separate, explicit convention for this worksheet: user-supplied time-weighted average supply over the selected window. Gross turnover is gross transfer value divided by that average; payment-classified turnover substitutes the payment class in the numerator. This is a DN period-turnover calculation, not a reproduction of a named Coin Metrics metric.
Use the same native token denomination on both sides. The worksheet supports native token units or millions of those units, applied to every amount together. Changing that selector does not convert existing entries. It does not assume that one token currently trades for one US dollar.
Identify the asset and network precisely. Circle’s directory distinguishes USDC contract addresses by blockchain and environment. A ticker alone is not enough to align a chain-specific transfer dataset with a supply series. If a wider multichain scope includes representations of the same backing, document the treatment instead of adding them blindly.
Keep unknown, zero and incompatible denominators different
A blank supply amount is unknown. A supplied zero cannot support division. A positive amount with a different asset, network or time window is not a comparable denominator. The calculator preserves those distinctions instead of producing a convenient turnover number.
Both activity and supply windows use UTC dates, with the start included and the end excluded at 00:00. Equal dates therefore describe no observation period and are rejected. If supply dates are provided and differ from the activity window, the tool rejects the comparison. Missing dates or an unresolved scope declaration withhold turnover.
A zero gross total with zero classifications has no category-share denominator. The tool returns an undefined share, not 100% classification accuracy. No result estimates payment adoption, model autonomy, investment demand, causal economic output or annualized growth.
Publish the boundary with the number
A defensible chart caption includes the dataset, token/network scope, period, counting unit, classification version, supply convention and treatment of unknowns. Keep the extraction query or report reference where an authorized reviewer can inspect it. A new export timestamp does not update the underlying evidence.
When comparing periods, hold the method stable or publish a restated history with a clear revision note. When comparing providers, map the definitions before comparing the totals. When claiming agent adoption, supply the separate attribution method and its uncertainty; do not ask transfer turnover to do that work.
The useful output is a narrower claim that survives inspection: a specified amount moved, a specified subset was classified under a stated rule, and a stated denominator produces a particular turnover. Everything beyond that remains a separate research question.
Methodology and limits
DN Stablecoin Transfer Boundary Reconciler v1.0. Let G be gross value and I, R, P and O the entered issuance/redemption, internal/routing, payment-purpose and other-classified values. Under a declared mutually exclusive classification, unclassified value is U = G − I − R − P − O. Category shares divide the relevant value by G when G is positive.
All quantities use the selected native-token denomination. Inputs support up to six decimal places and a maximum of one billion selected units per field; selecting millions changes the denomination for every quantity together. The calculation converts entered decimal amounts to integer millionths before adding and subtracting, avoiding an artificial residual from ordinary floating-point subtraction. This is aggregate arithmetic, not raw-token event decoding.
Turnover divides gross or payment-classified value by the supplied time-weighted average supply only when its scope is declared comparable, its dates exactly match and its value is positive. No annualization is performed. Unknown exclusivity withholds the residual and shares; unknown supply or scope withholds ratios; explicit mismatched dates/scopes and impossible category totals reject. No amount is converted to a count of actors.
The worksheet cannot verify a payment purpose, label a wallet, identify common control, remove duplicate records or authenticate supply. Its numeric checks do not detect every semantic double count. Provider-defined adjusted volumes can use different event models and exclusions, so do not place an already-filtered total over incompatible raw-transfer classifications.
The source review establishes documented interfaces and methodological choices, not a newly measured DN stablecoin dataset. Every worked quantity is synthetic. Use non-sensitive aliases instead of addresses, customer information or private transaction records. Corrections should identify the claim or calculation, method version and supporting evidence through DN’s published contact route.
Machine-readable record schema · 1.0.0
This JSON Schema documents the downloadable record, including input provenance, missing-value handling and method versions. The creation timestamp records the calculation time; it does not certify when the underlying evidence was observed.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:dn:record:dn-stablecoin-transfer-boundary:1.0.0",
"title": "DN Stablecoin Transfer Boundary Reconciler record",
"type": "object",
"additionalProperties": false,
"required": [
"schemaVersion",
"recordType",
"createdAt",
"articleSourceReviewDate",
"inputEvidenceStatus",
"inputBasis",
"exampleLabel",
"engineVersion",
"inputs",
"result"
],
"properties": {
"schemaVersion": {
"const": "1.0.0"
},
"recordType": {
"const": "dn-stablecoin-transfer-boundary"
},
"createdAt": {
"type": "string",
"format": "date-time"
},
"articleSourceReviewDate": {
"const": "2026-11-13"
},
"inputEvidenceStatus": {
"const": "user_entered_not_independently_verified"
},
"inputBasis": {
"enum": [
"user_entered",
"illustrative_example",
"illustrative_example_modified"
]
},
"exampleLabel": {
"type": [
"string",
"null"
]
},
"engineVersion": {
"const": "1.1.0"
},
"inputs": {
"type": "object",
"additionalProperties": false,
"required": [
"asset_scope",
"start",
"end",
"denomination",
"gross",
"issuance",
"routing",
"payments",
"other",
"partition",
"supply",
"supply_start",
"supply_end",
"supply_scope"
],
"properties": {
"asset_scope": {
"type": "string",
"maxLength": 200,
"minLength": 1
},
"start": {
"type": "string",
"maxLength": 2000,
"minLength": 1,
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
},
"end": {
"type": "string",
"maxLength": 2000,
"minLength": 1,
"pattern": "^\\d{4}-\\d{2}-\\d{2}$"
},
"denomination": {
"type": "string",
"enum": [
"native",
"millions"
]
},
"gross": {
"type": "number",
"minimum": 0,
"maximum": 1000000000
},
"issuance": {
"type": "number",
"minimum": 0,
"maximum": 1000000000
},
"routing": {
"type": "number",
"minimum": 0,
"maximum": 1000000000
},
"payments": {
"type": "number",
"minimum": 0,
"maximum": 1000000000
},
"other": {
"type": "number",
"minimum": 0,
"maximum": 1000000000
},
"partition": {
"type": "string",
"enum": [
"unknown",
"declared"
]
},
"supply": {
"type": [
"number",
"null"
],
"minimum": 0,
"maximum": 1000000000
},
"supply_start": {
"type": "string",
"maxLength": 2000,
"pattern": "^(?:\\d{4}-\\d{2}-\\d{2})?$"
},
"supply_end": {
"type": "string",
"maxLength": 2000,
"pattern": "^(?:\\d{4}-\\d{2}-\\d{2})?$"
},
"supply_scope": {
"type": "string",
"enum": [
"unknown",
"same",
"different"
]
}
}
},
"result": {
"type": "object",
"additionalProperties": false,
"required": [
"summary",
"metrics",
"findings"
],
"properties": {
"summary": {
"type": "string"
},
"metrics": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"label",
"value"
],
"properties": {
"label": {
"type": "string"
},
"value": {
"type": [
"number",
"string",
"null",
"boolean"
]
},
"unit": {
"type": "string"
},
"note": {
"type": "string"
}
}
}
},
"findings": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"level",
"text"
],
"properties": {
"level": {
"enum": [
"note",
"warning",
"error"
]
},
"text": {
"type": "string"
}
}
}
}
}
}
},
"allOf": [
{
"if": {
"properties": {
"inputBasis": {
"const": "user_entered"
}
}
},
"then": {
"properties": {
"exampleLabel": {
"type": "null"
}
}
},
"else": {
"properties": {
"exampleLabel": {
"type": "string",
"minLength": 1
}
}
}
}
]
}Related DN research
Frequently asked questions
Can stablecoin transfer volume reveal the number of AI agents?
Not by itself. Value, transactions, addresses and independently identified actors are different quantities. The instrument never converts volume or turnover into an agent count.
Does adjusted volume mean verified human payments?
No universal interpretation follows from that label. Read the provider’s metric definition, categories, filters, coverage and version. Different adjusted series answer different questions.
Why can a historical volume figure change?
A provider may revise labels, coverage, heuristics or historical data. Compare methodology versions before treating a changed past figure as new economic activity.
What supply does the DN tool use?
A user-supplied time-weighted average supply for the exact same asset/network, denomination and UTC window. This is explicitly different from a metric using an end-of-period or active-supply denominator.
What happens when a classification or supply is unknown?
Unknown exclusivity withholds residual/category-share calculations. Missing or noncomparable supply withholds turnover. Unclassified value remains unresolved rather than being called bot or human activity.
Sources and review dates
- Visa Onchain Analytics: Transactions methodology. Probabilistic labels, heuristic adjustments and use-case categories; no headline totals are reproduced. Reviewed 2026-11-13.
- Visa/Allium: Adjusted Volume Refresh. Historical-series changes following label/heuristic refresh; incompatible documentation label totals are not compared. Reviewed 2026-11-13. Source date: 2026-09-18.
- Visa Onchain Analytics: Agentic Payments. Published x402/MPP panel boundaries, distinct volume/transaction/address metrics and exclusion of unlabeled category volume. Reviewed 2026-11-13.
- ERC-20 token standard. Token transfer and supply interfaces; the transfer event does not supply an independently verified actor-type field. Reviewed 2026-11-13. Source date: 2015-11-19.
- Coin Metrics: Transfer Value. Provider-specific adjusted transfer-value definitions and differing UTXO/account heuristics. Reviewed 2026-11-13.
- Coin Metrics: Velocity. Distinct active/current supply formulations; DN explicitly uses its own average-supply convention instead. Reviewed 2026-11-13.
- Circle: USDC contract addresses. Asset identification by blockchain and mainnet/testnet environment; no new address or chain-support recommendation. Reviewed 2026-11-13.
Turn the finding into a decision
For a bounded review of the evidence and unresolved questions behind a specific operational decision, contact the DN Research Desk. Scope, feasibility, fee and delivery terms must be agreed before work begins.
Disclosure: This is independent DN editorial research. The instrument evaluates entered assumptions and does not independently verify your evidence or approve transactions. Illustrative examples are labelled. Any affiliate placement is identified where it appears; a commercial relationship does not determine the findings. No provider endorsement or guaranteed outcome is implied.
