| layout | default |
|---|---|
| title | Changelog |
| permalink | /changelog/ |
All notable structural changes to the Transaction Authorization Protocol (TAP) are documented in this file.
This changelog focuses on:
- New TAIPs and their acceptance status
- Message format changes
- Protocol structural changes
- Breaking changes
- TypeScript Package Extracted: The
@taprsvp/typesTypeScript package has moved to its own repository at TransactionAuthorizationProtocol/tap-ts- Full git history preserved via
git mv; usegit log --followin the new repo to trace any file back to its original commit in this repo - The
packages/typescript/directory has been removed from this repository - NPM package name (
@taprsvp/types) is unchanged —npm install @taprsvp/typescontinues to work - Future TypeScript-specific changelog entries will live in the tap-ts CHANGELOG
- Full git history preserved via
- TAIP-17 Composable Escrow: Status advanced from Draft to Review
- TAIP-17 Composable Escrow: Renamed
Escrowmessage type toLockbased on feedback from both payment and institutional users, who recognized the term as the standard name for this pattern in payments and institutional finance- Message type identifier
https://tap.rsvp/schema/1.0#Escrowis nowhttps://tap.rsvp/schema/1.0#Lock - JSON-LD
@typevalue changed fromEscrowtoLock - Schema file renamed from
schemas/messages/escrow.jsontoschemas/messages/lock.json - Test vectors moved from
test-vectors/escrow/totest-vectors/lock/ - TypeScript:
Escrow/EscrowMessagetypes renamed toLock/LockMessage; validators and arbitraries renamed accordingly - "Composable Escrow" remains the TAIP title and the
EscrowAgentrole name is preserved; only the specific message identifier changed - TAIP-18 examples and flow diagrams updated to reference
Lockinstead ofEscrow
- Message type identifier
- TAIP-18 Asset Exchange: Status advanced from Draft to Review
- TAIP-18 Asset Exchange: Renamed
Exchangemessage type toRFQ(Request for Quote) based on feedback from both payment and institutional users, who recognized the term as the standard name for this pattern in payments and institutional finance- Message type identifier
https://tap.rsvp/schema/1.0#Exchangeis nowhttps://tap.rsvp/schema/1.0#RFQ - JSON-LD
@typevalue changed fromExchangetoRFQ - Schema file renamed from
schemas/messages/exchange.jsontoschemas/messages/rfq.json - TypeScript:
Exchange/ExchangeMessagetypes renamed toRFQ/RFQMessage; validators and arbitraries renamed accordingly - TAIP-14 references to
Exchange/Quoteflow updated toRFQ/Quote - "Asset Exchange" remains the title and conceptual name of the protocol; only the specific message identifier changed
- Message type identifier
- TAIP-20 On-Chain Transfer Correlation via Memo Hash: New draft standard for deterministic TAP ↔ on-chain reconciliation
- Defines canonical derivation
SHA-256(UTF8(tap_transfer_id)) - Standardizes text memo profile as
tap:1:<64-hex> - Defines binary/hash memo profile for chains with native hash memo support
- Documents verification workflow for counterparties and compliance systems
- Provides adaptation guidance for text memo, binary memo, and numeric-tag ecosystems
- Defines canonical derivation
- TAIP-19 ISO 20022 Message Mapping: New specification for bidirectional mapping between ISO 20022 and TAP messages
- Maps PAIN messages (payment initiation) to TAIP-14 Payment and TAIP-15 Connect
- Maps PACS messages (clearing/settlement) to TAIP-3 Transfer
- Maps CAMT messages (cash management) to TAIP-4 Cancel/Revert flows
- Defines party/agent mappings (Debtor/Creditor → originator/beneficiary, BIC → did:web:, LEI support)
- Uses RFC 8905 payto:// URIs for traditional account identifiers (IBAN, BBAN, ACH)
- Includes status code mappings (ACCP/ACTC → Authorize, ACSC → Settle, RJCT → Reject)
- Provides detailed field mappings for pacs.008, pain.001, pain.009
- Documents flow diagrams for credit transfers, direct debit mandates, and payment recalls
- Enables interoperability with SWIFT, SEPA, FedNow, and other ISO 20022 payment systems
- TAIP-14 Payment Requests: Enhanced supportedAssets field and composability integration
- Enhanced supportedAssets field: Now supports both string and object formats for flexible pricing
- String format: Simple asset identifiers for ~1:1 assets like stablecoins
- Object format: Pricing objects with
asset(CAIP-19, DTI, or ISO-4217),amount, and optionalexpires - Enables cross-currency payments (e.g., USD invoice accepting EUR at specific rate with IBAN settlement)
- Supports volatile asset pricing (e.g., ETH, BTC) with precise amounts and rate expiration
- Updated composability section: Replaced Transfer-based examples with Exchange/Quote pattern from TAIP-18
- Shows proper use of Exchange requests for currency conversion in payment flows
- Demonstrates parent-child relationship using
pthidto link Exchange to Payment - Added TAIP-18 to requirements and references
- Enhanced example demonstrates mixed payment methods: stablecoins, crypto with pricing, cross-currency fiat
- Enhanced supportedAssets field: Now supports both string and object formats for flexible pricing
- TAIP-18 Asset Exchange: Added Exchange and Quote message types for cross-asset transactions
- New Exchange message type for requesting asset conversion quotes (USDC to EURC, USD to crypto, cross-chain)
- New Quote message type for liquidity provider responses with pricing and expiration timestamps
- Support for multi-asset arrays enabling flexible routing and provider selection
- Compatible with existing TAIP-4 Authorize/Settle flows for quote acceptance and settlement
- Integration with TAIP-17 Escrow for counterparty risk management in exchanges
- Enables use cases: cross-asset payments, FX transactions, on/off-ramp services, cross-chain bridging
- Updated JSON Schemas: Added exchange.json and quote.json message schemas
- Updated TypeScript Package v1.12.0: Added Exchange and Quote interfaces and message wrappers
- See tap-ts CHANGELOG for complete details
- Updated Documentation: Enhanced messages.md and transactions.md with Exchange and Quote documentation
- TAIP-15 Agent Connection Protocol: Enhanced transaction constraints for improved security and control
- Added three new optional constraint fields to Connect messages:
allowedBeneficiaries- array of TAIP-6 Party objects for approved payment recipientsallowedSettlementAddresses- array of CAIP-10 addresses for approved settlement addressesallowedAssets- array of CAIP-19 asset identifiers for approved transaction assets
- Added comprehensive "Transaction Constraints" section explaining constraint purposes, enforcement requirements, and types
- Updated transaction validation requirements to include new constraint checks
- Enhanced test examples to demonstrate new constraint usage
- Added CAIP-10 and CAIP-19 references for address and asset identifier standards
- Updated JSON Schemas: Enhanced transaction-constraints.json schema to validate new constraint fields
- Updated TypeScript Package v1.11.0: Enhanced TransactionConstraints interface and Zod validators
- See tap-ts CHANGELOG for complete details
- Added three new optional constraint fields to Connect messages:
- TypeScript Package v1.10.0: Enhanced Zod v4 validation with strict ISO standards validation
- See tap-ts CHANGELOG for complete details
- BREAKING: TAIP-15 Agent Connection Protocol: Major restructure to support multi-party connections
- BREAKING: Replaced single
agentfield with requiredagentsarray following TAIP-3 pattern - BREAKING: Added required
requesterParty field to distinguish requesting party from principal - Agents array must include at least one agent with
@idmatching DIDCommfromfield andforattribute set to requester DID - Added "Parties and Agent Roles" section clarifying two-party connection model
- Added support for AddAgents messages to dynamically add agents during connection flow
- Updated all examples and diagrams to use Merchant/Customer/PSP Agent terminology
- Updated JSON schemas, and test vectors to match new structure
- Removed
typeattributes from all agent examples across codebase for consistency with TAIP-5 specification
- BREAKING: Replaced single
-
Agent Consistency: Updated TAIP-3 and TAIP-14 to require
forattributes in agent arrays- Added specification requiring requesting agent (from DIDComm
fromfield) to be included inagentsarray with properforattribute - Updated all TAIP-3 examples to include
forattributes mapping agents to the parties they represent - Updated TAIP-14 example to include merchant agent and proper
forattributes - Ensures consistency with TAIP-15 and TAIP-17 agent array requirements
- Added specification requiring requesting agent (from DIDComm
-
TypeScript Package v1.9.0: Released with TAIP-15 agent restructuring support
- See tap-ts CHANGELOG for complete details
-
TypeScript Package v1.8.0: Released with enhanced DIDComm v2.1 support and new message types
- See tap-ts CHANGELOG for complete details
- TypeScript Package v1.7.0: Released enhanced TypeScript library with comprehensive documentation and fixes
- See tap-ts CHANGELOG for complete details
- Test Vector Issues: Fixed incorrect TAIP references and missing required fields in test vectors
- Fixed
authorization-required/valid-authorization-required.jsonto reference correct TAIP-4 instead of TAIP-15 - Added required
settlementAddressfield tosettle/valid.jsontest vector per TAIP-4 specification
- Fixed
- Test Vector Organization: Reorganized test vector file structure for better maintainability
- Moved top-level test vectors to appropriate subfolders based on message type
valid-authorize.json→authorize/subfoldervalid-payment*.json→payment-request/subfoldervalid-revert.json→revert/subfoldervalid-settle.json→settle/subfolder- Ensures consistent organization with existing test vector structure
- Test Vectors: Updated test vectors to reflect recent protocol changes
- Updated AuthorizationRequired test vectors to reference TAIP-4 instead of TAIP-15
- Added test vectors for TAIP-17 Escrow messages with valid and invalid examples
- Added test vectors demonstrating PayTo URI support (RFC 8905) for traditional banking integration
- Added examples for Transfer messages with IBAN PayTo URIs
- Added Payment request examples with ACH/wire PayTo URIs
- IVMS101 Data Inclusion Documentation: Explicitly documented existing capability for including IVMS101 identity data directly in party objects alongside schema.org data
- Updated TAIP-6: Added explicit specification and examples for IVMS101 data in party objects
- Added comprehensive examples showing Person and Organization with IVMS101 fields
- Documented geographic addresses, national identifiers, and compliance data inclusion
- Added privacy recommendations for selective disclosure of natural person information
- Clarified that this capability was always supported by the JSON-LD extensibility but was not explicitly documented
- TypeScript Package v1.6.0: Released enhanced TypeScript library with comprehensive documentation
- See tap-ts CHANGELOG for complete details
- TAIP-6 (Transaction Parties): Enhanced documentation to explicitly describe IVMS101 data inclusion
- Documented that party objects can include both schema.org and IVMS101 properties
- Added concrete examples for natural persons and organizations with compliance data
- Added privacy recommendations for selective disclosure of sensitive information
- Made explicit what was previously implicit through JSON-LD extensibility
- TAIP-10 (IVMS101 Travel Rule): Updated to clarify dual approach for IVMS data exchange
- Documented direct inclusion in party objects for transparent compliance
- Maintained selective disclosure via presentations for enhanced privacy
- Clarified that both approaches have always been supported for different use cases
- TAIP-14 (Payments): Enhanced merchant examples to demonstrate IVMS101 compliance data
- Updated examples to show both schema.org and IVMS101 properties
- Demonstrated LEI codes, geographic addresses, and national identifiers for organizations
- Added privacy considerations for natural person merchants
- AuthorizationRequired Message: Moved from TAIP-15 to TAIP-4 as standard authorization message
- AuthorizationRequired is now part of the core transaction authorization protocol (TAIP-4)
- Added optional
fromfield to specify party type (customer, principal, originator) required to open URL - TAIP-15 now references TAIP-4 for complete AuthorizationRequired specification
- Updated interface with enhanced documentation for both transaction and connection authorization
- Added comprehensive test case example to TAIP-4
- Updated messages.md to document AuthorizationRequired as part of authorization flow
- RFC 8905 PayTo URI Support: Settlement addresses now support both blockchain (CAIP-10) and traditional payment systems (RFC 8905)
- Added to TAIP-4: Authorize, Settle, and Revert messages now accept PayTo URIs for bank transfers
- Added to TAIP-14: Payment messages support
fallbackSettlementAddressesfield - Added to Transfer, Capture, and Invoice messages
- Fallback Settlement Addresses: New optional field in Payment messages for redundancy
- Supports array of mixed CAIP-10 and RFC 8905 addresses
- Enables failover mechanisms for fiat payments and crypto transfers
- Purpose Code Types: Added ISO 20022 External Purpose Code union types
- ExternalPurposeCode: 331 standardized purpose codes
- ExternalCategoryPurposeCode: 48 category purpose codes
- See tap-ts CHANGELOG for TypeScript implementation details
- schema.org/Organization Attributes: Added optional organization metadata fields to Agents and Parties
- Based on schema.org/Organization standard
- Added fields:
name,url,logo,description,email,telephone - Available for both Agent (TAIP-5) and Party (TAIP-6) entities
- schema.org/Product Attributes: Added optional product metadata fields to Invoice Line Items
- Based on schema.org/Product standard
- Added fields to line items:
name,image,url - Enhances invoice line items in TAIP-16 with richer product information
- TypeScript Package (@taprsvp/types): Updated with RFC 8905 PayTo URI support, purpose code types, and schema.org attributes
- See tap-ts CHANGELOG for complete details
- JSON Schemas:
- Created
payto-uri.jsonandsettlement-address.jsoncommon schemas - Updated all message schemas to support new settlement address formats
- Fixed DIDComm message type pattern to match body @type format
- Enhanced
agent.jsonandparty.jsonschemas with organization attributes - Updated
invoice.jsonschema to include product attributes in line items
- Created
- TAIP-4: Added RFC 8905 reference and examples for traditional payment settlement
- TAIP-5: Added schema.org/Organization attributes to Agent specification
- TAIP-6: Added schema.org/Organization attributes to Party specification
- TAIP-14: Added
fallbackSettlementAddressesfield specification - TAIP-16: Added schema.org/Product attributes to invoice line items
- TAIP Status Updates:
- TAIP-1: Transaction Authorization Improvement Proposals - Advanced to Final status
- TAIPs 2-10 - Advanced to Last Call status:
- TAIP-2: Messaging
- TAIP-3: Virtual Asset Transfer
- TAIP-4: Transaction Authorization Protocol
- TAIP-5: Transaction Agents
- TAIP-6: Transaction Parties
- TAIP-7: Agent Policies
- TAIP-8: Selective Disclosure
- TAIP-9: Proof of Relationship
- TAIP-10: IVMS101 for Travel Rule
- TAIPs 15-16 - Advanced from Draft to Review status:
- TAIP-15: Agent Connection Protocol
- TAIP-16: Invoices
- JSON Schema definitions for all TAP message types in
/schemas/directory - Developer resources page with implementation guides
- TAIP-17: Composable Escrow workflow (Draft)
- New
Escrowmessage type for holding assets on behalf of parties - New
Capturemessage type for releasing escrowed funds - Supports both cryptocurrency assets and fiat currency denominations
- Enables payment guarantees and asset swap use cases
- New
- TypeScript Package: Added
byfield to Cancel interface- See tap-ts CHANGELOG for complete details
- Complete message type (replaced by extended Authorize message)
- Test vectors for removed Complete message
- BREAKING: Replaced
Completemessage with enhancedAuthorizemessage to simplify flow - Made
originatorfield optional in Transfer messages to support unknown originators - Made
rolefield optional in Agent structures - Added
principalas primary party in Connection messages
- TAIP-16: Invoices - Structured invoice format for payment requests
- MCC (Merchant Category Code) field to Party structure for merchant identification
expiryfields to Transfer, Authorize, and Connect messages for business intent expiration- Complete message for payment completion flows
amountfield to Settle message for partial settlement support
- Distinguished between message expiration (
expires_time) and business expiration (expiry)
- BREAKING: Renamed
PaymentRequesttoPaymentthroughout codebase - Updated all references and test vectors
- TAIP-15: Agent Connection Protocol - OAuth-style authorization flows for B2B integrations
- Connect message for establishing agent connections
- AuthorizationRequired message for connection approval flows
- TAIP-13: Transaction Purpose Codes - ISO 20022 purpose code integration
- Purpose and categoryPurpose fields to Transfer messages
- PaymentRequest message (later renamed to Payment)
- TAIP-14: Payment Requests - Merchant-initiated payment flows
- Cancel message for transaction termination
- Revert message for transaction reversal requests
- TAIP-11: Legal Entity Identifier (LEI) - Institutional participant identification
- TAIP-12: Hashed Participant Name Sharing - Privacy-preserving name matching
leifield to Party structurenameHashfield to Party structure
- TAIP-10: IVMS101 for Travel Rule - Regulatory compliance integration
ivms101field to Party structure for Travel Rule data
- TAIP-9: Proof of Relationship - Agent-party relationship verification
- ConfirmRelationship message
- CACAO attachment support for DID proofs
- TAIP-8: Selective Disclosure - Privacy-preserving credential sharing
- RequirePresentation policy type
- Presentation Exchange integration
- TAIP-7: Agent Policies - Requirement enforcement framework
- Policy structures: RequireAuthorization, RequirePresentation, RequirePurpose
- UpdatePolicies message
- TAIP-6: Transaction Parties - Party identification and representation
- Party data structure with name, LEI, and verification methods
- TAIP-3: Virtual Asset Transfer - Core transfer functionality
- TAIP-4: Transaction Authorization Protocol - Core authorization flow
- TAIP-5: Transaction Agents - Software agent framework
- Transfer message for asset transfers
- Authorization flow messages: Authorize, Settle, Reject
- Agent management messages: UpdateAgent, AddAgents, ReplaceAgent, RemoveAgent
- Agent data structure with roles and policies
- TAIP-1: Transaction Authorization Improvement Proposals - Framework document
- TAIP-2: Messaging - DIDComm v2 message format
- Base message structure and threading model
- JSON-LD context definitions
- Initial repository structure
- Transfer - Virtual asset transfer initiation
- Payment - Payment request with invoice support
- Authorize - Transaction authorization (enhanced to replace Complete)
- Settle - On-chain settlement confirmation
- Reject - Transaction rejection
- Cancel - Transaction cancellation
- Revert - Transaction reversal request
- UpdateAgent - Agent information update
- UpdateParty - Party information update
- AddAgents - Add agents to transaction
- ReplaceAgent - Replace existing agent
- RemoveAgent - Remove agent from transaction
- ConfirmRelationship - Confirm party-agent relationship
- UpdatePolicies - Update agent policies
- Connect - Establish agent connection
- AuthorizationRequired - Request authorization (moved to TAIP-4)
- Escrow - Hold assets in escrow with conditions (TAIP-17)
- Capture - Release escrowed funds (TAIP-17)
- Presentation - Present verifiable credentials (TAIP-8)
- Complete (2024-06-12) - Functionality merged into Authorize message
- Complete message removed - migrate to Authorize with settlement details
- Cancel message now requires
byfield
- PaymentRequest renamed to Payment - update all message type references
- Transfer message supports optional originator - handle missing originator cases
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning for protocol versions.