Purpose
Specifications in this section:- Define normative behavior using precise, unambiguous language
- Follow RFC 2119 conventions for requirement levels (MUST, SHOULD, MAY)
- Include data structures with exact field definitions and types
- Document protocol flows with sequence diagrams and state transitions
- Specify error handling and edge cases
Audience
These specifications are written for:- Protocol implementers building x402 facilitators or clients
- SDK developers creating libraries that interact with Nevermined
- Integration engineers connecting existing systems to Nevermined
- Security auditors reviewing protocol designs
Relationship to Other Documentation
Specifications are the source of truth for protocol behavior. Other documentation may simplify or summarize, but specifications define what implementations MUST do.
Conventions
Requirement Levels
This documentation uses RFC 2119 terminology:- MUST / REQUIRED / SHALL — absolute requirement
- MUST NOT / SHALL NOT — absolute prohibition
- SHOULD / RECOMMENDED — there may be valid reasons to ignore, but implications must be understood
- SHOULD NOT / NOT RECOMMENDED — there may be valid reasons to do this, but implications must be understood
- MAY / OPTIONAL — truly optional behavior
Data Types
- JSON structures use TypeScript-style type annotations
- Hexadecimal values are prefixed with
0x - Base64 encoding uses standard alphabet with
=padding - Timestamps use ISO 8601 format unless otherwise specified
Available Specifications
x402 Smart Accounts Extension
Extends x402 with ERC-4337 smart accounts, session keys, and programmable smart contract settlement
x402 Card Delegation Extension
Extends x402 with credit/debit card delegation via Stripe for fiat-based payment settlement