Preparing for a new era of blockchain-based payments experiences
Context
If you'd like to share feedback on the definition, please complete this form.
What is a payments definition and why have we produced it?
A common definition for payments that happen onchain, is the first step to a standard, and a standard is critical for shaping a new generation of interoperable solutions at scale. In a world where activity like payments can happen in a well structured and interoperable manner, businesses and consumers gain choice about their tech stack without losing access to key points of value.
Companies waste millions reconstructing basic payment context that should be built into the transaction. Is this a payment? Who is the merchant? What's the nature of the transaction? Can it be refunded? Every blockchain company - from exchanges to payment processors to compliance vendors - builds proprietary tools to answer these questions. This fragmentation kills interoperability and locks businesses into specific chains and vendors.
Second, stablecoin transaction volumes are widely cited but often distorted. Self-reported data often inflates true payment activity and mischaracterizes transactions - fiat on-ramps are clearly payments, but crypto-to-crypto transactions lack the metadata to distinguish actual payments from exchange deposits, bot activity, or treasury movements.
Giving context to blockchain transactions enables businesses to manage their operations and risks effectively, and blockchain builders to tailor their services for specific use cases. With more context, we aim to remove the default association of blockchains with high risk transactions. Confidence signals can be valuable onchain, even when regulated counterparties are not involved.
We believe there is significant value to be found in having a shared definition, that can be applied across chains, that helps all stakeholders understand when a transaction is a payment, as well as the context of that payment. Without standardized classification, we cannot accurately assess how stablecoins are used or whether reported volumes represent genuine economic activity. This payment definition aims to solve that problem.
Why now?
Today, blockchain infrastructures today process ~$7T in over 8B transactions. Regulated on/off-ramps and stablecoin companies manage payment flows with custom tooling. It works at current scale, but as adoption of stablecoins and other fiat-backed tokens continues, fragmented approaches won't hold. At this point, tracking the payment flows in a standardized way becomes critical.
We are creating building blocks to deliver a verified payments layer that works across all our networks. We believe that this is necessary to drive the next wave of adoption.
Our approach
Approach to data
The initial scope focuses specifically on metadata that can be made available onchain - establishing a common way to identify and describe payment activity at the blockchain level. Starting with this narrow scope lets us deliver immediate value, while creating a foundation that evolves into a more comprehensive standard with both onchain and offchain elements.
We place ourselves in the context of public and/or private ledgers with publicly verifiable data. However, we recognize that:
- much of the payment activity will continue to happen offchain (as happens today for fiat).
- different parties or use cases may require a different level of privacy, and we assume that such information can be consumed in a public, private or shielded way.
Our current position is that this definition will be complimentary to any privacy solution implemented directly at the protocol level. Many blockchains and payments services providers are actively exploring solutions for using public ledgers while supporting varying levels of privacy, in order to protect sensitive data for consumers and businesses. There is a natural tension between the public nature of blockchains and the data necessary to ensure activities are conducted with eligible and authorized users.
Importantly, all PII* is kept offchain. Anonymity and pseudonymity remain foundational principles onchain, however to ensure mainstream adoption under regulatory frameworks, knowing one’s counterparty is necessary. We believe traditional mechanisms (offchain messaging) can be augmented - and perhaps one day replaced - by a combination of novel approaches such as blockchain analytics and zero-knowledge proofs.
*We recognize that under GDPR, wallet addresses can be considered a form of PII, however they are not considered as such for this definition. Please procure your own legal advice.
Critically, we want to welcome additional parties into this discussion, including regulators, policy makers and data analysts supporting compliance activities. We believe that we can support shaping regulation that enables the full intention of privacy regulations while verifying the transaction meets AML/CFT requirements (e.g. using zero knowledge and tokenized credentials)
Approach to data integrity
It should not be assumed that just because a transaction has been immutably posted onchain, it meets some standard of integrity or verifiability. We recognize that validating that the information provided is coming from the right entity, and is correct and reliable, will require more than just additional metadata. First we will define the information to understand the transaction. Over time, verifiability and integrity can later be layered on top using a range of methods.
The agreements, trust scenarios and data sharing that are needed for various parties to view, access or report against the data, are a distinct and separate step. This includes privacy-preserving setups where a limited number of parties have the right to access the underlying data.
We welcome discussion with parties who may want to contribute thought leadership and ideas for shaping practices for integrity and verifiability, and expect to provide more explicit guidance in future versions of this definition.
Approach to implementation
The goal is to ensure the data is present and consistent, not to control how it is provided. At this stage, we intentionally avoid technical specification, allowing each chain, its guardians and third-party ecosystem to develop patterns specific to their architecture. It falls short of being enforceable at this stage by avoiding this. We accept this limitation and seek to encourage explorations which may eventually lead to a more formal technical definition that can be deployed across chains.
Our definition does not promote any singular blockchain stack, nor does it specify any specific products or services. At this stage, this is intentional. We seek merely to show that in moving towards standardizing payments on-chain, we can start exploiting the best blockchains have to offer.
Guidance on using the definition
For Blockchains and blockchain developers
This definition is the beginning of a long journey, one where we bring the opportunities for better compliance, consumer protection AND innovation to the world of payments. Our definition does not yet meet the level of a formal standard. More crucially, due to the various differences within blockchain constructs (e.g. cryptographic approach and smart contract languages), there will need to be different approaches to collecting and emitting the data provided in the definition.
However, common cross-protocol standards like Solana Pay and Sui Payment Kit offer a way forward. They codify expected data values and processes. More importantly, these standards offer application developers tools to access payments features and desirable payment flows. In doing so, they also offer a template for developers asking the question “How do I offer my users high quality, trustable payments options in my app?”.
This payments definition will ultimately be critical in building the future guardrails that facilitate organic adoption, while ensuring that payments operate in a safe and sound manner. Where you can, consider the definition in how you build your smart contracts, in the assumptions you make about what information needs to be collected and shared, in key decisions on privacy and ultimately, see it as a tool for growing your business payments with confidence.
For Payments Services Providers & Financial Institutions
Cross-chain interoperability is already a challenge. There are bodies and standards emerging to help shape how additional information can be used to assess and manage risk for onchain payments, but these standards assume everything is off-chain. We want to change this.
We see the definition as an opportunity for the payment services industry, inclusive of the fraud monitoring services, analytics providers and analysts. For the first time, this definition could lead to independently demonstrable and attributable metadata about the types of payment activities.
Crucially, with privacy solutions emerging, the usage of tokenized credentials and verifiable proofs means that there is limited risk of data leakage, while ensuring bespoke accessibility to those with verifiable credentials. Using the definition as a starting point should provide you with PII-free data, which will be the basis for more insightful analyses.
We welcome industry participation to further evolve the definition so it really helps catalyze more transaction activity.
For Regulators
This definition will hopefully lead to onchain payments standards that prioritize user protection and help track and minimize illicit activity. We believe clear and fit-for-purpose regulation is important, and designed this definition to foster dialogue with regulators and global standard setters on how blockchain-based payments can be safely adopted. We believe that stablecoins and blockchains will significantly transform the payments landscape; preparing for that with care while preserving the technological opportunities is important to us.
We look forward to exploring your feedback on this first draft.
The definitions
Principles
We are providing a definition for blockchain initiated and/or blockchain settled transactions. For transactions involving fiat, there will also be offchain data points; we do not specify those as they are governed by existing standards (e.g. ISO 20022) and practices.
Onchain payments will assume as broad a definition as offchain payments. To make room for novel opportunities and stablecoins, things like deposits and lending will not be payments. Swaps are up for discussion, particularly where a swap may occur in order to facilitate the availability of a desired payment token. E.g. Swapping token A for a stablecoin for the purpose of making a payment. In this context, swaps can be included when they can be linked within the same transaction data.
Not all stablecoin activity is payments, stablecoins will often be the primary currency in a payment. Volatile assets can make payments very challenging. Stablecoins offer a significant benefit. This definition explicitly seeks to offer a mechanism for tagging payments transactions in any onchain asset or currency, thereby providing a clearer and more reliable methodology to analyze and assess the growth of onchain payments.
Taxonomy
For the purposes of the initial payments definition draft document, we have categorized payments-related data into three broad groups:
1. Participant(s)
a. Role (i.e. Payee, Payer, Intermediary)
b. Account (i.e. wallet address, wallet name)
c. Identification
d. Geolocalisation
2. Transaction type
a. Use case (i.e. what is being purchased item, service, asset)
b. Merchant information (e.g. MCC, Business name)
3. Transaction parameters
a. Transaction identifier
b. Payment method (e.g. push, pull)
c. Payment details (e.g. amount, currency, FX, fees)
d. Transaction routing (e.g. chain, payment protocol)
e. Status and timestamps
f. Contextual data (as needed)
As discussed, this document focuses exclusively on a subset of data points across these groups.
The definitions are oriented around payment flow types, this allows us to group activities with common characteristics together. The flow types considered are as follows:
1. Consumer-to-Business (C2B)
3. Peer-to-Peer (P2P)
2. Business-to-Consumer (B2C)
4. Business-to-Business (B2B)
5. Consumer-to-Consumer (C2C)
6. Consumer-to-Government (C2G)*
7. Government-to-Consumer (G2C)*
8. Business-to-Goverment (B2G)*
9. Government-to-Business (G2B)*
Detailed properties
1. C2B, 2. B2C, 6.C2G, 7. G2C
Transaction type
Transaction parameters
Future-case, recurring payments are not widely available on-chain today. Example entries would be:
- Single
- Recurring
- Installment (e.g. BNPL)
- Repayment (e.g. loan)
Participants
Payments between two parties
3. P2P, 4. B2B, 5. C2C, 8. B2G, 9.G2B
Transaction parameters
Participants
or Transacting Entity / Business Name NEW
