Skip to content

feat(x402): stamp BlockRun builder-code service code on payments#13

Open
KillerQueen-Z wants to merge 1 commit into
BlockRunAI:mainfrom
KillerQueen-Z:feat/builder-code-service-code
Open

feat(x402): stamp BlockRun builder-code service code on payments#13
KillerQueen-Z wants to merge 1 commit into
BlockRunAI:mainfrom
KillerQueen-Z:feat/builder-code-service-code

Conversation

@KillerQueen-Z

Copy link
Copy Markdown
Collaborator

What

Tags every x402 payment XClawRouter signs with the ERC-8021 Schema 2 service code s: ["blockrun"], so payments routed through XClawRouter are attributed to BlockRun on-chain.

Reference: CDP Builder Codes

How

  • New src/builder-code.ts: withBuilderCodeServiceCode() merges s: ["blockrun"] into a payload's builder-code.info, preserving any app code (a) the server echoed back. Pure, non-mutating.
  • In proxy.ts, an onAfterPaymentCreation hook stamps it onto context.paymentPayload.extensions.

Why a hook (not registerExtension / a dep bump)

The official BuilderCodeClientExtension only enriches when the server advertises builder-code in its 402, and needs @x402/* bumped 2.11 → 2.17. The hook mirrors that extension's output but fires unconditionally with no dependency change. Safe because the EIP-712 signature covers the authorization, not extensions; the CDP facilitator reads builder-code.info.s and does the CBOR/ERC-8021 encoding.

Test

  • src/builder-code.test.ts (4 cases). Full suite green: 510 passed, typecheck + build (ESM + DTS) clean.

Related

Mirror of BlockRunAI/ClawRouter#198. Tracked in BlockRunAI/blockrun#199. Sibling PRs: blockrun-llm-ts#9, blockrun-llm#21, blockrun-llm-go#2.

Tag every x402 payment XClawRouter signs with the ERC-8021 Schema 2 service
code s: ["blockrun"] so BlockRun-originated traffic is attributed on-chain.

An onAfterPaymentCreation hook stamps builder-code.info.s onto the payload,
preserving any app code (a) the server echoed back. Mirrors @x402/extensions'
BuilderCodeClientExtension but fires unconditionally (independent of the server
advertising the extension) and needs no @x402 upgrade. The EIP-712 signature
covers the authorization, not the extensions, so stamping after creation is
safe. Encoding into settlement calldata is done by the CDP facilitator.

Docs: https://docs.cdp.coinbase.com/x402/core-concepts/builder-codes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant