feat: Update network field to use caip2 schema BREAKING CHANGE #29

jsutaria · 2025-09-19T16:54:11Z

Description

While building wallet infrastructure, we've found that using string literals for chain names can get - I'd recommend using the caip2 standard which is standard across all chain types, regardless of the network!

BREAKING CHANGE

google-cla · 2025-09-19T16:54:17Z

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

gemini-code-assist · 2025-09-19T16:54:33Z

Summary of Changes

Hello @jsutaria, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant change by migrating the 'network' field from arbitrary string literals to the CAIP-2 standard across the codebase and documentation. This standardization aims to enhance interoperability and provide a consistent way to identify various blockchain networks, addressing challenges encountered with string literals in wallet infrastructure development. This is a breaking change that impacts how network identifiers are specified in payment requirements and related configurations.

Highlights

Standardization of Network Identifiers: The 'network' field across various configurations and payment requirements has been updated to use the CAIP-2 standard. This includes examples like 'eip155:8453' for Base mainnet, 'eip155:84532' for Base Sepolia testnet, 'bip122:...' for Bitcoin, and 'lightning:mainnet' for Lightning Network.
Breaking Change: This update is explicitly marked as a breaking change, as it modifies the expected format of network identifiers in payment-related configurations and API specifications, requiring consumers to adapt to the new CAIP-2 format.
Improved Interoperability: Adopting the CAIP-2 standard ensures a consistent and universally recognized format for identifying blockchain networks, which is crucial for enhancing interoperability within wallet infrastructure and across different blockchain types.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request is a great step towards standardizing network identification by adopting the CAIP-2 schema. The changes are consistent across most of the codebase. However, I've identified a few critical areas, primarily in error handling paths and documentation examples, where network identifiers are hardcoded to Base mainnet. This could cause incorrect behavior and misleading receipts when your system operates on other networks. My review provides specific suggestions to dynamically determine the network from the available context, ensuring the system is robust and network-agnostic.

gemini-code-assist · 2025-09-19T16:55:57Z

python/x402_a2a/executors/client.py

            # Payment processing failed
            from ..types import SettleResponse, x402ErrorCode
-            failure_response = SettleResponse(success=False, network="base", error_reason=f"Payment failed: {e}")
+            failure_response = SettleResponse(success=False, network="eip155:8453", error_reason=f"Payment failed: {e}")


In the case of a payment processing failure, the network in the SettleResponse is hardcoded to "eip155:8453" (Base mainnet). This can lead to incorrect failure receipts if the payment was for a different network. The network should be derived from the payment_required response. Using the network from the first available option is a safer default.

Suggested change

failure_response = SettleResponse(success=False, network="eip155:8453", error_reason=f"Payment failed: {e}")

network = payment_required.accepts[0].network if payment_required and payment_required.accepts else "eip155:8453"

failure_response = SettleResponse(success=False, network=network, error_reason=f"Payment failed: {e}")

gemini-code-assist · 2025-09-19T16:55:58Z

python/x402_a2a/executors/server.py

    async def _fail_payment(self, task, error_code: str, error_reason: str, event_queue: EventQueue):
        """Handle payment failure."""
-        failure_response = SettleResponse(success=False, network="base", error_reason=error_reason)
+        failure_response = SettleResponse(success=False, network="eip155:8453", error_reason=error_reason)


The network is hardcoded to Base mainnet ("eip155:8453") when creating a failure response. This is problematic as the payment could have been for any network. This method should determine the correct network, for instance by looking up the original PaymentRequirements from the _payment_requirements_store using the task.id. Using a hardcoded mainnet value can lead to misleading failure receipts.

Suggested change

failure_response = SettleResponse(success=False, network="eip155:8453", error_reason=error_reason)

accepts_array = self._payment_requirements_store.get(task.id)

network = accepts_array[0].network if accepts_array else "eip155:8453"

failure_response = SettleResponse(success=False, network=network, error_reason=error_reason)

gemini-code-assist · 2025-09-19T16:55:58Z

python/x402_a2a/README.md

        task = utils.record_payment_failure(
            task, "verification_failed", 
-            SettleResponse(success=False, network="base", error_reason=verify_response.invalid_reason)
+            SettleResponse(success=False, network="eip155:8453", error_reason=verify_response.invalid_reason)


The network is hardcoded to "eip155:8453" (Base mainnet) in this failure case. This is incorrect if the payment was intended for a different network. You should use the network from the payment_requirements object, which is available in this function's scope.

Suggested change

SettleResponse(success=False, network="eip155:8453", error_reason=verify_response.invalid_reason)

SettleResponse(success=False, network=payment_requirements.network, error_reason=verify_response.invalid_reason)

gemini-code-assist · 2025-09-19T16:55:58Z

python/x402_a2a/README.md

        success=settle_response.success,
        transaction=settle_response.transaction,
-        network=settle_response.network or "base",
+        network=settle_response.network or "eip155:8453",


The fallback network is hardcoded to "eip155:8453" (Base mainnet). If settle_response.network is None, it's safer to fall back to the network specified in the original payment_requirements rather than assuming Base mainnet.

Suggested change

network=settle_response.network or "eip155:8453",

network=settle_response.network or payment_requirements.network,

jorellis · 2025-09-23T20:38:19Z

I think this is a good call to migrate these to CAIP2. Can we move 'eip155:8453' into an a2a x402 python variable to be used in the tools?

- Updated docstrings to explicitly mention CAIP-2 format - Added examples for EVM, Bitcoin, Solana, and Cosmos networks - Clarified that Lightning Network uses Bitcoin's CAIP-2 identifier - Changed "Ethereum address" to "Address" (format depends on network) - Added note about namespace:reference format in config This improves developer experience by showing how to use the network field with non-EVM chains that have CAIP-2 identifiers. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> Committed-By-Agent: claude

Reverted whitespace-only formatting changes (bullet points, trailing spaces, table alignment) that were automatically applied by IDE formatter. Kept substantive changes: network field values updated from "base" to "eip155:8453" (CAIP-2 format) in spec.md examples. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> Committed-By-Agent: claude

jsutaria requested a review from a team as a code owner September 19, 2025 16:54

gemini-code-assist bot reviewed Sep 19, 2025

View reviewed changes

jsutaria changed the title ~~BREAKING CHANGE: Update network field to use caip2 schema~~ feat: Update network field to use caip2 schema Sep 19, 2025

jsutaria changed the title ~~feat: Update network field to use caip2 schema~~ feat: Update network field to use caip2 schema BREAKING CHANGE Sep 19, 2025

feat: Update network field to use CAIP-2 format instead of plain strings

7cea318

madeleine-c force-pushed the main branch from 7a3c0a1 to 7cea318 Compare October 1, 2025 20:31

madeleine-c and others added 3 commits October 1, 2025 16:47

remove non caip2 chains

4416d0c

jorellis self-requested a review November 4, 2025 18:16

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: Update network field to use caip2 schema BREAKING CHANGE #29

feat: Update network field to use caip2 schema BREAKING CHANGE #29

Uh oh!

jsutaria commented Sep 19, 2025 •

edited

Loading

Uh oh!

google-cla bot commented Sep 19, 2025

Uh oh!

gemini-code-assist bot commented Sep 19, 2025

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot Sep 19, 2025

Uh oh!

gemini-code-assist bot Sep 19, 2025

Uh oh!

gemini-code-assist bot Sep 19, 2025

Uh oh!

gemini-code-assist bot Sep 19, 2025

Uh oh!

jorellis commented Sep 23, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	failure_response = SettleResponse(success=False, network="eip155:8453", error_reason=f"Payment failed: {e}")
	network = payment_required.accepts[0].network if payment_required and payment_required.accepts else "eip155:8453"
	failure_response = SettleResponse(success=False, network=network, error_reason=f"Payment failed: {e}")

-        failure_response = SettleResponse(success=False, network="eip155:8453", error_reason=error_reason)
+        accepts_array = self._payment_requirements_store.get(task.id)
+        network = accepts_array[0].network if accepts_array else "eip155:8453"
+        failure_response = SettleResponse(success=False, network=network, error_reason=error_reason)

	SettleResponse(success=False, network="eip155:8453", error_reason=verify_response.invalid_reason)
	SettleResponse(success=False, network=payment_requirements.network, error_reason=verify_response.invalid_reason)

	network=settle_response.network or "eip155:8453",
	network=settle_response.network or payment_requirements.network,

feat: Update network field to use caip2 schema BREAKING CHANGE #29

Are you sure you want to change the base?

feat: Update network field to use caip2 schema BREAKING CHANGE #29

Uh oh!

Conversation

jsutaria commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

google-cla bot commented Sep 19, 2025

Uh oh!

gemini-code-assist bot commented Sep 19, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

jorellis commented Sep 23, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jsutaria commented Sep 19, 2025 •

edited

Loading