User Story
As a developer integrating via direct Gateway smart-contract calls, I want clear documentation on how to attribute my createOrder transactions onchain with an ERC-8021 data suffix derived from my API key ID, so my orders link to my sender profile and webhooks without (or in addition to) putting apiKey in encrypted recipient metadata.
Acceptance Criteria
-
GIVEN a reader of the Smart Contract Interaction guide
WHEN they follow the new onchain attribution section
THEN they can encode an ERC-8021 schema-0 suffix from their API key UUID (dashes stripped) and append it to outer createOrder calldata before signing / gas estimation
-
GIVEN the same guide's existing metadata.apiKey instructions
WHEN the docs are updated
THEN backward compatibility is explicit: metadata.apiKey still works; onchain suffix is preferred for new EVM integrations; when both are present the aggregator prefers onchain
-
GIVEN Base vs other EVM chains
WHEN the docs explain codes
THEN they clarify that bc_julg9gbq is Paycrest/noblocks' Base Builder Code (not for arbitrary senders to claim) and sender attribution uses the API key ID code
-
GIVEN Starknet / Tron (or other non–ERC-8021 paths)
WHEN the docs discuss attribution
THEN they state those networks continue to use metadata.apiKey only
-
GIVEN wallet / AA constraints
WHEN the docs cover where the suffix must live
THEN they require the suffix on outer tx.data / userOp.callData (not buried in an inner call), consistent with aggregator/noblocks implementation notes
-
GIVEN cross-links
WHEN docs ship
THEN Smart Contract Interaction (and optionally Sender API / changelog) links to ERC-8021 / Base Builder Codes references; embed host attribution is documented as a noblocks widget concern (not required for direct SC senders)
Tech Details
- Primary surface:
docs/implementation-guides/smart-contract-interaction.mdx (Data Encryption / createOrder sections).
- Add a dedicated Onchain attribution (ERC-8021) section with:
- Why (sender linkage / webhooks without putting API key ID only in encrypted blob)
- How to get the API key ID from the dashboard
- Encode helper example (JS at minimum; align with Viem examples already in the guide)
- Multi-code note for Base only if co-branding with Paycrest — default sender example is API key ID alone
- Deprecation/migration note for
metadata.apiKey
- Optional: short changelog entry under
docs/resources/changelog.mdx when aggregator support lands.
- Coordinate copy with aggregator + noblocks tickets so examples match the shipped suffix format.
Notes/Assumptions
User Story
As a developer integrating via direct Gateway smart-contract calls, I want clear documentation on how to attribute my createOrder transactions onchain with an ERC-8021 data suffix derived from my API key ID, so my orders link to my sender profile and webhooks without (or in addition to) putting
apiKeyin encrypted recipient metadata.Acceptance Criteria
GIVEN a reader of the Smart Contract Interaction guide
WHEN they follow the new onchain attribution section
THEN they can encode an ERC-8021 schema-0 suffix from their API key UUID (dashes stripped) and append it to outer
createOrdercalldata before signing / gas estimationGIVEN the same guide's existing
metadata.apiKeyinstructionsWHEN the docs are updated
THEN backward compatibility is explicit:
metadata.apiKeystill works; onchain suffix is preferred for new EVM integrations; when both are present the aggregator prefers onchainGIVEN Base vs other EVM chains
WHEN the docs explain codes
THEN they clarify that
bc_julg9gbqis Paycrest/noblocks' Base Builder Code (not for arbitrary senders to claim) and sender attribution uses the API key ID codeGIVEN Starknet / Tron (or other non–ERC-8021 paths)
WHEN the docs discuss attribution
THEN they state those networks continue to use
metadata.apiKeyonlyGIVEN wallet / AA constraints
WHEN the docs cover where the suffix must live
THEN they require the suffix on outer
tx.data/userOp.callData(not buried in an inner call), consistent with aggregator/noblocks implementation notesGIVEN cross-links
WHEN docs ship
THEN Smart Contract Interaction (and optionally Sender API / changelog) links to ERC-8021 / Base Builder Codes references; embed host attribution is documented as a noblocks widget concern (not required for direct SC senders)
Tech Details
docs/implementation-guides/smart-contract-interaction.mdx(Data Encryption / createOrder sections).metadata.apiKeydocs/resources/changelog.mdxwhen aggregator support lands.Notes/Assumptions