Add aptos build workflow #8
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update how-to-write-a-scheme documentation to reflect the new trait structure: - Rename X402SchemeHandler to X402SchemeFacilitator throughout - Document new X402SchemeId trait for scheme identification - Document new X402SchemeFacilitatorBuilder trait for instantiation - Explain X402SchemeBlueprint as a combined trait composition - Update code examples and checklist to match new architecture - Renumber implementation steps to reflect additional trait
…ation Introduce ChecksummedAddress newtype that wraps Address and provides custom serialization/deserialization with EIP-55 checksum formatting. Also add documentation comment for TokenAmount struct.
Add bidirectional conversion traits between ChecksummedAddress and Address to simplify usage in client code. Refactor x402-reqwest-example to use ChecksummedAddress directly instead of custom serialization functions, reducing boilerplate and improving type safety.
Add public from_secs constructor to UnixTimestamp, allowing direct instantiation from seconds. This removes the need for a local LocalUnixTimestamp wrapper in the reqwest example.
The PaymentCandidate struct now stores an Arc<dyn X402SchemeClient> instead of a client index, eliminating the need for index-based lookups during payment signing. This improves type safety and removes potential for index mismatches. The to_candidate method signature has been updated to accept the client reference directly, and all implementations have been adjusted accordingly. The payment signing process now uses the client reference stored in the candidate rather than looking it up by index.
Replace direct chain ID parsing with proper Eip155ChainReference implementation to improve type safety and error handling in EIP-712 domain construction
- Replace direct `v2::` module usage with imported types - Add `PaymentRequiredV2` struct for typed header parsing - Streamline candidate building with proper type validation - Remove manual version checking in favor of type system
Update all X402Version2 and ResourceInfo references to use the fully qualified v2 module path for consistency and to avoid potential naming conflicts. This change improves code clarity and maintains proper namespace organization in the x402 protocol implementation.
Move ChecksummedAddress type from v1_eip155_exact to shared eip155/types module and update imports across the codebase. This centralizes the type definition and makes it available for other modules to use. BREAKING CHANGE: ChecksummedAddress is now imported from x402_rs::chain::eip155::types instead of x402_rs::scheme::v1_eip155_exact
- Remove unused PaymentRequirementsExtra import - Update ChecksummedAddress trait implementations to use local type - Replace duplicate ExactEvmPayloadAuthorization with shared module import
Remove duplicate ExactEvmPayload and LocalPaymentRequirementsExtra structs in favor of using the shared types from x402_rs::scheme::v1_eip155_exact This reduces code duplication and ensures consistency with the core library types while maintaining the same functionality.
- Remove unused imports and dependencies - Move TokenAmount implementation from proto/util.rs to chain/eip155/types.rs - Update imports in examples to use the new location
…anization - Move PaymentRequired struct to shared proto/v2 module - Re-export types from v2_eip155_exact module - Update example code to use shared PaymentRequired type - Improve code formatting and readability in multiple places
…entSelector - Add PaymentCandidateLike trait to abstract payment candidate functionality - Make PaymentSelector generic over PaymentCandidateLike implementers - Update X402Client to be generic over selector type - Modify all selector implementations to work with trait objects - Update middleware and builder implementations to support generic types BREAKING CHANGE: PaymentSelector and X402Client now require generic type parameters
The PaymentCandidateLike trait has been relocated from the example code to the proto/client module to improve code organization and reusability. The trait is now properly exposed through the proto module's public API. This change consolidates payment-related abstractions in the proto module and removes duplication between the main library and example code.
Add Into<Vec<ChainIdPattern>> implementations for ChainId and ChainIdPattern to support priority-based chain selection. Update PreferChain selector to accept multiple patterns in priority order and implement builder methods for flexible pattern composition. BREAKING CHANGE: PreferChain now requires Vec<ChainIdPattern> instead of single ChainId, changing its constructor and usage pattern
The PaymentSelector trait and its implementations (FirstMatch, PreferChain, MaxAmount) have been moved from the example module to the core client module to improve code organization and reusability. This change consolidates payment selection logic in the main protocol implementation while maintaining the same functionality. The example module now imports these types from the client module instead of defining them locally.
…related types - Change `resource` field from `Option<ResourceInfo>` to `ResourceInfo` in v2 protocol - Update PaymentCandidate and related client implementations to handle non-optional resource - Remove unnecessary unwrapping logic for resource field - Reorder imports in chain/eip155/types.rs for consistency - Reorder module declarations in proto/mod.rs for better organization
…est-all recipe - Configure spl-token and spl-token-2022 with no-entrypoint feature to reduce unused dependencies - Add comprehensive test-all recipe to justfile for running tests across all workspace crates and examples
Remove deprecated "Protocol v2 Update Coming" banners from 5 README files, indicating v2 implementation is now complete. Update example environment configurations with proper multi-chain environment variables for EVM and Solana support.
Switch example dependencies from path-based references to version-based references for better dependency management and compatibility. Also clean up unused dependencies in the axum example.
Add detailed rustdoc comments across the crate to improve API documentation and developer experience. This includes: - Module-level documentation for all public modules with architecture overviews - Type and trait documentation with examples and usage patterns - Field documentation for public structs - Error type documentation with context - Builder and factory method documentation Documentation covers: - x402 protocol overview and role descriptions - Blockchain support (EVM via EIP-155 and Solana) - Payment scheme architecture and extensibility - Chain provider abstractions and nonce management - Protocol types for V1 and V2 versions - Utility types for serialization and parsing - Client-side payment handling and selection strategies
* chore: Cleanup network tests * feat(networks): Add Celo and Celo Sepolia
…2-rs#54) * fix: register schemes for all chains matching a wildcard pattern * fix: Update by_chain_id_pattern to return references to all matching chain providers and iterate over them in scheme handler building.
- Update module paths from `x402` to `x402_rs` in documentation examples - Fix code example formatting in various crates - Add missing imports and complete examples in x402-axum - Update Cargo.toml with new dev dependency - Change return type of ChainRegistry::by_chain_id to return reference
Fixed a bug where SchemeRegistry would only register a scheme handler for the first chain that matched a wildcard pattern (e.g., eip155:*), ignoring all subsequent matching chains. x402-rs#54
- Add `json` feature to Cargo.toml to enable JSON support in reqwest-middleware - Update README.md to document the new feature and usage examples
- Update builder image from rust:bullseye to rust:trixie - Update runtime image from debian:bullseye-slim to debian:trixie-slim - Remove redundant comment about image size - Fix missing newline at end of file
…vider type (x402-rs#56) * refactor(x402-rs): make V1Eip155ExactFacilitator generic over provider type Generalize V1Eip155ExactFacilitator to accept any provider implementing Eip155MetaTransactionProvider and ChainProviderOps traits instead of requiring Arc<Eip155ChainProvider>. - Add Eip155MetaTransactionProvider and ChainProviderOps impls for Arc - Change function signatures to take provider by reference - Remove unused Arc import from v1_eip155_exact module * refactor(x402-rs): make X402SchemeFacilitatorBuilder generic over provider type Make the scheme facilitator builder and related types generic over the provider type, enabling more flexible provider abstractions. Add FromChainProvider trait for extracting specific provider types from generic chain providers, similar to Axum's FromRequest pattern. BREAKING CHANGE: X402SchemeFacilitatorBuilder, SchemeBlueprints, and SchemeRegistry are now generic over the provider type P. The builder method signature changed from taking `ChainProvider` to `&P`. Existing implementations must be updated to use the new generic trait bounds with FromChainProvider. * refactor: expose chain config fields and add chain_id method Make chain_reference and inner fields public in both Eip155ChainConfig and SolanaChainConfig structs to enable external access. Add chain_id() convenience method to SolanaChainConfig that derives the chain ID from the chain reference. Make config_defaults module public for external access. * refactor(config): make Config generic and create ChainsConfig wrapper type Moves chains serialization logic from anonymous chains_serde module to a dedicated ChainsConfig wrapper struct, making Config generic over the chains configuration type. This improves code organization and allows for future flexibility in chains configuration. * refactor: align Eip155 variant storage with Solana pattern * refactor: make Config generic and reorganize impl blocks Move load(), load_from_path(), and chains() methods to the generic impl block to support different chains configuration types while maintaining shared functionality. * refactor: make chains() method generic in Config impl block This change moves the chains() method from the concrete Config impl to the generic Config<TChainsConfig> impl block, making it return the generic type TChainsConfig instead of the concrete Vec<ChainConfig>. This is part of making the Config type generic over its chains configuration type. * refactor: use ChainsConfig type in ChainRegistry::from_config Update the from_config method to accept ChainsConfig reference instead of Vec<ChainConfig>, utilizing the iter() method for iteration over chain configurations. * refactor: make load_from_cli generic over TChainsConfig Add generic type parameter with Default + Deserialize bounds to the Config impl block containing load_from_cli method, enabling proper deserialization of generic chain configurations. * refactor(chain): extract FromConfig trait from ChainProvider impl Introduce a generic `FromConfig<TConfig>` async trait to standardize configuration-based initialization across chain providers. Refactor `ChainProvider::from_config` to implement this new trait instead of being an inherent method. * refactor(chain): implement FromConfig trait for ChainRegistry Move from_config method from inherent impl to FromConfig trait implementation for ChainRegistry<ChainProvider>, aligning with the trait extraction done for ChainProvider. * refactor(chain): simplify FromConfig trait by removing associated Error type Replace associated Error type with concrete Box<dyn std::error::Error> return type and make ChainRegistry impl generic over TChainProvider. * refactor: implement FromConfig trait for Eip155ChainProvider Move from_config from inherent impl to FromConfig<Eip155ChainConfig> trait implementation for consistency with other chain providers. Also rename parameter from 'chains' to 'config' in trait definition. * refactor: implement FromConfig trait for SolanaChainProvider * refactor: simplify ChainRegistry with concrete type and add constructor Remove generic type parameter from FromConfig impl for ChainRegistry, using concrete ChainProvider type instead. Add new() constructor method for direct HashMap initialization. Relax async-trait version constraint. * refactor: add support for Custom error variant in MetaTransactionSendError Extend MetaTransactionSendError enum with a new `Custom` variant to allow more flexible error handling, including for contract call failures. * refactor(eip155): extract RPC client initialization into a dedicated method Simplify code by introducing a reusable `rpc_client` method for EIP-155 chain provider initialization, reducing duplication in transport setup logic. * refactor: update provider handling for V1Eip155Exact and remove unused imports Refactor `V1Eip155Exact` to streamline provider type requirements and simplify the `build` method by removing Arc-based extraction. Additionally, clean up unused imports to improve code clarity. * refactor: streamline provider handling for V2Eip155Exact and simplify facilitator structure Reduce complexity by directly using the provider without Arc-based extraction. Introduce `V2Eip155ExactFacilitator::new` for cleaner initialization and remove unused imports. * refactor: streamline provider handling and simplify facilitator interface across schemes Refactor various scheme implementations to use direct provider references, removing unnecessary Arc-based extraction. Update facilitator builders for cleaner initialization and enhance type consistency. Simplify trait definitions and clean up unused imports. * refactor: remove FromChainProvider trait and simplify provider extraction logic Eliminate the `FromChainProvider` trait and its implementations, switching to direct match-based extraction for cleaner and more explicit provider handling. Update affected facilitators and clean up unused imports for consistency. * refactor: implement Arc-based trait forwarding for providers and clean up unused imports Add generic trait forwarding implementations for `Arc`-wrapped types to reduce duplication. Update related provider traits and functions for consistency. Clean up unused imports across affected modules. * refactor: update logging messages for provider initialization in Solana and EVM handlers
- Update x402-axum to 0.8, x402-reqwest to 0.6, and x402-rs to 0.12 - Bump related dependencies across crates including OpenTelemetry, reqwest, and tracing - Update README code examples to reflect new version changes in affected crates - Synchronize Cargo.lock to match updated version requirements
…ling - Config is mandatory - Config path can be loaded from CONFIG env var
…terfaces - Introduce `SolanaChainProviderLike` trait for more flexible provider abstraction. - Refactor `Facilitator` structs and associated methods to be generic over provider types. - Remove redundant `Arc` wrapping and streamline method signatures across Solana modules.
- Refactor V1SolanaExact and V2SolanaExact facilitators to use generic provider types. - Simplify Solana provider handling by removing redundant `Arc` usage. - Update `X402SchemeFacilitatorBuilder` trait to support flexible provider interfaces.
- Add `Custom` error variant to `SolanaChainProviderError` for enhanced error handling. - Refactor `pubsub_client` to use `Option<Arc<PubsubClient>>` for better flexibility. - Expose `rpc_client` and `pubsub_client` methods for downstream consumption.
- Update `resource_info` field in `PayloadSigner` and `PaymentPayload` to use `Option<ResourceInfo>` to handle cases where the resource may be absent. - Adjust related facilitators and payload structures in V2 EIP155 and Solana schemes to accommodate the optional resource field.
- Add AptosChainProvider with fee payer signing for sponsored transactions - Implement v2 exact payment scheme for Aptos (aptos:1, aptos:2) - Add local patch for aptos-runtimes tokio compatibility - Support CAIP-2 chain identifiers
Use aptos-node-v1.39.2 tag instead of commit hash for better readability and maintainability. Functionally equivalent to the previous commit hash fb9e2f4.
Add workflow to build and push Docker images to Aptos GCP registry. This workflow will run on: - Push to main branch - Pull requests - Manual workflow dispatch Images are pushed to us-docker.pkg.dev/aptos-registry/docker/x402-rs with git SHA as the tag for unique versioning.
Add optional gas sponsorship for Aptos transactions, allowing facilitators to choose between sponsored mode (facilitator pays gas) and non-sponsored mode (client pays own gas). Changes: - Make AptosChainConfig.signer optional, add sponsor_gas boolean flag - Update AptosChainProvider to handle optional fee payer configuration - Update /supported endpoint to include extra.sponsored when enabled - Update settle flow to conditionally sponsor based on configuration - Add validation: signer required when sponsor_gas is true Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
Add documentation showing: - Sponsored mode: facilitator pays gas (requires signer) - Non-sponsored mode: client pays gas (no signer needed) Only signer field supports environment variables ($APTOS_PRIVATE_KEY). RPC URL and sponsor_gas are plain config values, consistent with Solana.
Allow RPC URL and sponsor_gas to be configured via environment variables: - APTOS_RPC_URL - RPC endpoint (can include API key in URL) - APTOS_SPONSOR_GAS - true/false for gas sponsorship - APTOS_PRIVATE_KEY - facilitator private key (existing) This provides deployment flexibility to switch between networks and RPC providers without modifying config files.
Add api_key field to AptosChainConfigInner for authenticated RPC access. If provided, API key is sent as Authorization: Bearer header with all requests. Useful for paid RPC providers like Geomi nodes to avoid rate limiting. Example config: api_key = "$APTOS_API_KEY" Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.