d-bis/proxmox
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
dc8abb06e2bbd33e30803ca59d284ead8ea970c6
proxmox/docs/04-configuration/CHAIN138_X402_TOKEN_SUPPORT.md
defiQUG 7ac74f432b chore: sync docs, config schemas, scripts, and meta task alignment 
- Institutional / JVMTM / reserve-provenance / GRU transport + standards JSON
- Validation and verify scripts (Blockscout labels, x402, GRU preflight, P1 local path)
- Wormhole wiring in AGENTS, MCP_SETUP, MASTER_INDEX, 04-configuration README
- Meta docs, integration gaps, live verification log, architecture updates
- CI validate-config workflow updates

Operator/LAN items, submodule working trees, and public token-aggregation edge
routes remain follow-up (see TODOS_CONSOLIDATED P1).

Made-with: Cursor
2026-03-31 22:31:39 -07:00

3.6 KiB
Raw Blame History

Chain 138 Token Support for x402 Payments

Purpose: Record which Chain 138 tokens support ERC-2612 (permit) or ERC-3009, and thus can be used with thirdweb x402 payments.

References: thirdweb x402, CHAIN138_TOKEN_ADDRESSES.md, plan: x402 and Permit Support for Chain 138.

On-chain check results

Run the verification script (from repo root, with Chain 138 RPC reachable):

./scripts/verify/check-chain138-token-permit-support.sh [RPC_URL] [--token SYMBOL=ADDRESS]...
# Optional: --dry-run to print RPC and token addresses only

For the full operational + token readiness picture, use:

./scripts/verify/check-chain138-x402-readiness.sh [CORE_RPC] [PUBLIC_RPC] [EXPLORER_STATS] [--token SYMBOL=ADDRESS]...
# Optional: --strict to exit non-zero until Chain 138 is fully x402-ready

Last run: March 31, 2026. Script confirms the following for deployed contracts on Chain 138.

Token Address ERC-2612 (permit) ERC-3009 (transferWithAuthorization) x402-compatible
cUSDT 0x93E66202A11B1772E55407B32B44e5Cd8eda7f22 Not supported Not supported No
cUSDC 0xf22258f57794CC8E06237084b353Ab30fFfa640b Not supported Not supported No
cUSDT V2 0x8d342d321DdEe97D0c5011DAF8ca0B59DA617D29 Supported Supported Yes
cUSDC V2 0x1ac3F4942a71E86A9682D91837E1E71b7BACdF99 Supported Supported Yes

WETH and WETH10 on Chain 138 (see CHAIN138_TOKEN_ADDRESSES.md) are standard approve/transferFrom implementations and do not expose permit or ERC-3009 in the repo; they are not x402-compatible in their current form.

Implications

  • thirdweb x402 requires the payment token to support either ERC-2612 permit or ERC-3009 (e.g. sign + transferWithAuthorization / receiveWithAuthorization). See Chain and token support.
  • Current state: Chain 138 is now x402-ready through the staged V2 compliant USD tokens.
  • Standards target: this x402 capability is the repo-wide target profile for future c* V2 currencies as captured in GRU_STANDARDS_PROFILE.md and config/gru-standards-profile.json. The broader standards profile applies to all GRU manifest currencies, even where deployment is still staged.
  • Important coexistence note: V1 cUSDT and cUSDC still back the live PMM/pool/liquidity routes, while cUSDT V2 and cUSDC V2 are the permit/auth-capable contracts for x402 and the next transport cutover.
  • Options:
    1. Use V2 contracts for x402 immediately: point x402 pricing to cUSDT V2 or cUSDC V2.
    2. Complete the liquidity/transport cutover: migrate GRU transport, registry aliases, and cW pool mappings from V1 to V2 before making V2 the primary explorer/liquidity surface.

When a Chain 138 token gains permit

After a token on Chain 138 supports ERC-2612 or ERC-3009:

  1. Re-run ./scripts/verify/check-chain138-token-permit-support.sh --token SYMBOL=ADDRESS for the active V2 inventory and update this doc.
  2. In the x402 API, use network: chain138 (custom chain definition) and set price to the V2 token object, e.g. price: { amount: "<base units>", asset: { address: "0x1ac3F4942a71E86A9682D91837E1E71b7BACdF99", decimals: 6 } } for cUSDC V2.
  3. Keep V1/V2 symbol resolution explicit in transport and explorer integrations until the canonical cutover is complete.
Reference in New Issue View Git Blame Copy Permalink