loading...

Unlock the Full Definition

Done. Keep scrolling.
Oops! Something went wrong while submitting the form.

Preparing for a new era of blockchain-based payments experiences

Context

This document is an initial public draft of something we hope to evolve into a standard. The goal of this draft is to seek input from payments stakeholders, and to better inform the key choices needed to turn this into a full standard. If you have any questions, or thoughts, do speak to us at info@blockchainpaymentsconsortium.com.

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

In preparing this working definition, a number of discussion topics came up which we feel are worthy of sharing publicly. We have explicitly sought to keep the definition simple in this first iteration, but we want to also acknowledge that the topic is complex and that addressing some of the discussion points will be key to adoption.

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:

Flow Types with examples

1. Consumer-to-Business (C2B)

E.g. Paying for a product or service

3. Peer-to-Peer (P2P)

E.g. Sending to a friend

2. Business-to-Consumer (B2C)

E.g. Receiving a refund, payouts, payroll

4. Business-to-Business (B2B)

E.g. Paying a supplier

5. Consumer-to-Consumer (C2C)

E.g. Buying via online marketplace (platform mediates unknown party), remittances

6. Consumer-to-Government (C2G)*

E.g. Paying personal taxes

7. Government-to-Consumer (G2C)*

E.g. Receiving benefits

8. Business-to-Goverment (B2G)*

E.g. Paying corporate taxes

9. Government-to-Business (G2B)*

E.g. Receiving subsidies
*For the purpose of this definition, we are assuming Government flows today occur in much the same way as interactions with a business. As more Government payments are made available onchain, we expect to update the definition with any unique considerations.

Detailed properties

1. C2B, 2. B2C, 6.C2G, 7. G2C

Payments/Refunds for services and goods where one party is typically classified as a “merchant” or “business”
All Musts are minimum for trx to be counted as a payment

Transaction type

About the goods / service / asset:
Depending on the blockchain, a transaction may contain one or many goods/ services for each payment.
Data Point / Category
Requirement
Object/Asset ID
Must
This denotes the on-chain representation of the thing being purchased e.g. token, NFT, points, ticket etc.
Chain-specific, as per today.
Item/Goods Description
Must
Often captured within the smart contract or trx digest.
Cost of Items
Must
Cost denoted exclusive of any blockchain fees.
Currency of Items
Must
Cost shown in listed currency i.e. what the BUSINESS wants to receive - can be any currency including fiat*.
*This assumes merchant solution allows purchase of crypto in order to settle the transaction.
Image
Optional
Image for one or more items in the transaction.
Often available via other data in transactions today e.g. on Sui, the existence of Display.
Should not be text or data captured as an image. Where not actual image or image file exists, there is nothing shown.

Transaction parameters

Purchase Category Code NEW
Must
Opportunity - add a layer to transactions to build towards better risk modelling of on-chain payment types
Total to Pay
Must
Inclusive of any fees.
Currency of Payment
Must
This denotes the currency the CONSUMER chose to pay in.
On some chains, this may be reflected via a separate transaction to purchase relevant assets first.
Payment Outcome
Must
I.e. Success / Failure. Some chains take a fee for transaction failures. Failure can be due to any reason.
Fraud Score (Where available) NEW
Optional
Semi available today via blockchain monitoring services. Could be valuable at trx level e.g. tagging known/risky wallets gives apps a choice. Likely to be unpopular with degens.
Redemption (e.g. single, recurring) NEW
Optional
Future-case, recurring payments are not widely available on-chain today. Example entries would be: SingleRecurringInstallment (e.g. BNPL)Repayment (e.g. loan)

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

About the payee / payer / intermediary:
This category borrows liberally from IVMS 101.2023 which is already broadly adopted by regulated blockchain participants (typically VASPs).
It is assumed data in this category may be offered as public or private, with limited disclosure to select third parties.
Wallet Address / Account
Must
As is today, typically a 32-bit hash. Can be shielded as per emergent privacy solutions.
On-Chain Name / Sub-name
Must
Where available, blockchain name services which represent wallet addresses. Sub-names (on Sui) subject to app and/or owner policy.
E.g. Jim.Sol, Ella@Visa (Sui sub-name standard)
On blockchains, names are considered domain name equivalents (i.e. designed for public disclosure).
Onchain names are social and do not have a direct relationship with a legal entity off-chain.
Businesses should consider this useful as a confidence signal (for payment services providers and regulators), and may consider keeping this public even as other information may be private.
MCC / TCC General NEW
Must: merchants only
In fiat, these classifications govern the risk level of all transactions, therefore using them onchain, will provide a broader range of metadata for payment use-cases AND act as a trust signal.
For fiat transactions this is set by the acquiring banks (via merchant payment processors).
We propose to use the same classifications for onchain transactions, such that nature of the transaction and associated risks are correctly identified for all the parties involved.
KYC / AML Available NEW
Optional
A statement that a KYC result is available off-chain. Paths for verifying the actual result to be explored.
E.g. PRESENT / AVAILABLE
A metafield denoting that a KYC action has taken place would help provide trust signals about the transaction and participants.
Note: Exact KYC results (e.g. Pass/Fail) are not desirable onchain.
Tokenized Credential NEW
Optional
Future-case, there are no widely adopted examples of this.
A metafield for a cryptographically signed asset or object. Likely meets W3C standards. Verification of credentials by an authorised party happens off-chain.
It is expected that a payment transaction onchain will EITHER have a KYC Available asset or a Tokenized Credential but not both.
Location NEW
Optional
Country only, key to understanding domestic vs cross-border activity.
This should reflect the Consumer’s known country as often determined by IP addresses which are freely available to browsers and applications.
Where VPN is detected, this may be tagged as additional metadata to the transaction.
Provided in the ISO 3166 Alpha 2 format for consistency with many standards and reporting formats in payments.
E.g. US, DE, NG, CN, GB

Payments between two parties
3. P2P, 4. B2B, 5. C2C, 8. B2G, 9.G2B

Payments directly between two parties for any reason, inclusive of cross-border remittances and payments mediated by a third party (e.g. escrow services)
All Musts are minimum for trx to be counted as a payment

Transaction parameters

Data Point / Category
Requirement
Send Amount and Currency Code
Must
This denotes the currency the PAYER chose to pay in.
On some chains, this may be reflected via a separate transaction to purchase relevant assets first.
Receive Amount and Currency Code
Must
This denotes the currency the PAYEE chose to pay in.
On some chains, this may be reflected via a separate transaction to purchase relevant assets first.
FX rate applied
Must
As per today. FX or Swap rate at the time of the transaction.
Total to Pay
Must
Paid by the payer, inclusive of any fees.
Payment Outcome
Must
I.e. Success / Failure. Some chains take a fee for transaction failures. Failure can be due to any reason.
Escrow
Optional
Where the payment is mediated via a platform (i.e. C2C), typically an escrow or smart contract will hold funds on-chain.
E.g. TRUE/ FALSE
One some chains, the Escrow may have a custom smart contract available.
Fraud Score (Where available) NEW
Optional
Semi available today via blockchain monitoring services. E.g.tagging known/risky wallets gives apps a choice.

Participants

About the SENDER (Payer):
This category borrows liberally from IVMS 101.2023 which is already broadly adopted by regulated blockchain participants (typically VASPs).
It is assumed data in this category may be offered as public or private, with limited disclosure to select parties.
Wallet Address
Must
As is today, typically a 32-bit hash. Can be shielded as per emergent privacy solutions.
Name / Sub-name NEW
or Transacting Entity / Business Name NEW
Optional
Where available, blockchain name services which represent wallet addresses. Sub-names (on Sui) subject to app and/or owner policy.
E.g. Jim.Sol, Ella@Visa (Sui sub-name standard)
On blockchains, names are considered domain name equivalents (i.e. designed for public disclosure).
Onchain names are social and do not have a direct relationship with a legal entity off-chain.
Businesses should consider this useful as a trust signal (for payment services providers and regulators), and may consider keeping this public even as other information may be private.
KYC/ KYB/AML Available NEW
Optional
A statement that a KYC result is available off-chain. Paths for verifying the actual result to be explored.
e.g. PRESENT/ AVAILABLE
A metafield denoting that a KYC action has taken place would help provide trust signals about the transaction and participants.
Note: Exact KYC results (e.g. Pass/Fail) are not desirable onchain.
Tokenized Credential NEW
Optional
Future-case, there are no widely adopted examples of this.
A metafield for a cryptographically signed asset or object. Likely meets W3C standards. Verification of credentials by an authorised party happens off-chain.
It is expected that a payment transaction on-chain will EITHER have a KYC Available asset or a Tokenized Credential but not both.
Location NEW
Optional
Country only, key to understanding domestic vs cross-border activity.
This should reflect the Consumer location.
Provided in the ISO 3166 Alpha 2 format for consistency with many standards and reporting formats in payments.
E.g. US, DE, NG, CN, GB