The Transaction Authorization Protocol (TAP) creates a pre-transaction authorization layer that operates independently from the blockchain settlement layer. This separation allows participants to exchange compliance information, perform risk assessments, and obtain proper authorization before assets move on-chain.
Key Concepts
- Pre-Transaction Authorization: All transactions are authorized before on-chain settlement
- Message Threading: All authorization messages reference the original transaction using DIDComm thread IDs
- State Transitions: Transactions move through specific states (proposed → authorized → settled)
- Split Responsibility: Originators propose transactions, beneficiaries authorize, originators settle
Basic Authorization Flow
The standard TAP authorization flow consists of three main steps:
- Transaction Proposal: Originator sends a Transfer/Payment message
- Authorization Decision: Beneficiary responds with Authorize or Reject
- Settlement Confirmation: Originator notifies of on-chain settlement via Settle message
sequenceDiagram
participant Originator
participant Beneficiary
Originator->>Beneficiary: Transfer
Note over Beneficiary: Compliance checks
Beneficiary->>Originator: Authorize
Note over Originator: Execute on-chain transaction
Originator->>Beneficiary: Settle (with settlement proof)
Authorization Messages
Authorize
The Authorize message indicates the beneficiary approves the transaction after completing their compliance checks. It references the original Transfer/Payment via the DIDComm thread ID.
Business Implications:
- Confirms the beneficiary has completed all compliance requirements
- Provides the originator legal clearance to execute the transaction
- Creates an audit trail of approval for regulatory purposes
Complete
The Complete message is specifically used in the Payment flow, sent by the merchant’s agent to indicate the transaction is ready for settlement. It replaces the previously confusing use of Authorize for this purpose.
Business Implications:
- Clearly distinguishes merchant readiness for settlement from general authorization
- Provides the settlement address where funds should be sent
- Can specify an adjusted final amount (which must be less than or equal to the original requested amount)
- Enables flexible payment scenarios like partial fulfillment or applied discounts
- Creates a precise payment instruction for the customer’s agent to follow
sequenceDiagram
participant Customer as Customer (Originator)
participant Merchant as Merchant (Beneficiary)
Merchant->>Customer: Payment (initial request)
Note over Customer: Customer reviews and decides
Customer->>Merchant: Authorize (accepts payment)
Note over Merchant: Process payment request
Merchant->>Customer: Complete (with settlement address, optional adjusted amount)
Note over Customer: Execute on-chain payment
Customer->>Merchant: Settle (with settlement proof and matching amount)
Reject
The Reject message indicates the beneficiary cannot approve the transaction. A clear reason must be provided to help the originator understand the compliance issue.
Business Implications:
- Stops the transaction flow, preventing non-compliant transactions
- Requires a specific reason to support remediation efforts
- Creates a compliance record of rejection and reasoning
sequenceDiagram
participant Originator
participant Beneficiary
Originator->>Beneficiary: Transfer
Note over Beneficiary: Compliance issue detected
Beneficiary->>Originator: Reject (with reason)
Note over Originator: Transaction flow ends
Settle
The Settle message confirms that the originator has executed the authorized transaction on-chain. It includes settlement proof (e.g., transaction hash) that links the TAP authorization to the blockchain settlement.
Business Implications:
- Creates a record linking off-chain authorization to on-chain settlement
- Enables reconciliation between compliance systems and blockchain transactions
- Completes the authorization-settlement cycle for audit purposes
- May include an amount field that must match any amount specified in a preceding Complete message
- Supports partial payment scenarios when used with the amount field
Cancel
The Cancel message allows the originator to withdraw a transaction proposal before it’s authorized or settled.
Business Implications:
- Provides clean transaction termination for changed business circumstances
- Helps manage transaction queues during operational issues
- Creates clear records for incomplete transactions
sequenceDiagram
participant Originator
participant Beneficiary
Originator->>Beneficiary: Transfer
Note over Originator: Business circumstances change
Originator->>Beneficiary: Cancel
Note over Beneficiary: Transaction flow ends
Revert
The Revert message addresses situations where a transaction was settled incorrectly or needs to be reversed. It creates a clear record that the original transaction should not be considered valid.
Business Implications:
- Addresses settlement errors or compliance issues discovered post-settlement
- Creates a compliance record of the reversal decision
- May trigger compensating transactions to correct the blockchain state
sequenceDiagram
participant Originator
participant Beneficiary
Originator->>Beneficiary: Transfer
Beneficiary->>Originator: Authorize
Originator->>Beneficiary: Settle
Note over Beneficiary: Post-settlement issue found
Beneficiary->>Originator: Revert (with reason)
Note over Originator: Corrective action required
Complex Authorization Flows
Payment Flow
When using the Payment message type, the flow now includes the Complete message to clearly indicate settlement readiness.
sequenceDiagram
participant Customer as Customer (Originator)
participant Merchant as Merchant (Beneficiary)
Merchant->>Customer: Payment
Note over Customer: Customer reviews and decides
Customer->>Merchant: Authorize (accepts payment)
Note over Merchant: Process payment request
Merchant->>Customer: Complete (provides settlement address, optional adjusted amount)
Note over Customer: Execute on-chain payment
Customer->>Merchant: Settle (with settlement proof and matching amount)
This improved flow:
- Clearly separates the customer’s acceptance of the payment (Authorize) from the merchant’s readiness to receive it (Complete)
- Allows merchants to specify a final settlement amount that may differ from the original requested amount
- Ensures the customer’s wallet sends the correct amount specified in the Complete message
- Creates a more intuitive payment experience that mirrors traditional payment flows
Authorization with Travel Rule Information
For transactions requiring Travel Rule compliance, additional identity information is exchanged before authorization.
sequenceDiagram
participant Originator
participant Beneficiary
Originator->>Beneficiary: Transfer (with originator info)
Note over Beneficiary: Request additional information
Beneficiary->>Originator: RequirePresentation policy
Originator->>Beneficiary: Provide beneficiary information
Note over Beneficiary: Complete compliance checks
Beneficiary->>Originator: Authorize
Note over Originator: Execute on-chain transaction
Originator->>Beneficiary: Settle (with settlement proof)
Implementation Considerations
When implementing TAP authorization flows, consider:
- Policy Enforcement: Define clear policies for which transactions require special handling
- Timeout Handling: Establish processes for transactions that don’t receive timely responses
- Compliance Record Keeping: Maintain authorization messages for regulatory requirements
- Integration with On-chain Systems: Ensure settlement proofs accurately reference blockchain transactions
- Error Handling: Develop clear processes for handling various rejection scenarios
Technical Integration
For technical details on authorization message formats, see the full message reference.