feat(eip712): populate signature requests with additional data (WALLET-1318)#42
Open
Conversation
…esentation and enrichment support - Introduced `getPresentationForType` to classify types into `account`, `hash`, `number`, or `string`. - Updated display model rows to include additional metadata: `presentation`, `accountInfo`, and `contractPackage`. - Added `IEIP712DisplayEnrichment` for optional domain/message row enrichment. - Expanded unit tests to validate type classification, presentation logic, and enrichment capabilities.
…ests - Implemented `getAccountHashesFromTypedData` to extract and deduplicate account hashes from typed data, including signing key-derived hashes. - Added comprehensive test cases for address-based field collection, deduplication, and edge cases handling. - Updated exports to include the new utility in the `eip712` module.
- Introduced `EIP712SignatureRequestDto` for encapsulating EIP-712 signature request details. - Implemented support for account info resolution, contract package enrichment, and hash artifacts forwarding. - Added comprehensive unit tests to validate field mappings, enrichment logic, and fallback behavior. - Updated exports to include the new DTO in the `eip712` module.
… enrichment Adds EIP712Repository.prepareSignatureRequest, which returns a fully populated IEIP712SignatureRequest: fields classified by presentation type, address fields resolved to account info, contract_package_hash resolved to contract package, and chain_name mapped to CasperNetwork. Enrichment is best-effort (each lookup isolated); only invalid typed data throws EIP712Error. Wires the repository constructor in setup.ts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: ost-ptk <ostap@make.services>
…n domain rows - Updated `buildTypedDataDisplayModel` to force `hash` presentation for `contract_package_hash`, even if undeclared in `types.EIP712Domain` or specified as `string`. - Added test case to validate shortened display and full value copyability for undeclared `contract_package_hash`.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Implements WALLET-1318 — populate EIP-712 signature requests with additional data.
Follow-up to WALLET-1255 (base
eip712module). Where WALLET-1255 added validate → digest → display model → sign → recover/verify, this PR adds enrichment: core now prepares fully-populated, ready-to-render typed-data, the same wayTxSignatureRequestRepositorydoes for deploys — so consumer apps (extension, mobile) render the entity without doing their own lookups.Closes WALLET-1318.
What's added
EIP712Repository.prepareSignatureRequest(...)(async) → returns a fully-populatedIEIP712SignatureRequest:bytes*→hash,uint*/int*→number,address→account, else→string);addressfields resolved to account info (name, logo, CSPR.name, explorer link);contract_package_hashresolved to contract package data;chain_namemapped toCasperNetwork;rawJson.computeDigest,buildDisplayModel,signDigest,signTypedData,recoverSigner,verifySignature) are unchanged.IEIP712DisplayRow.isAddress→presentationenum, plus optionalaccountInfo/contractPackage.accountInfoRepository+contractPackageRepository(wired insetup.ts).Design notes
try/catch(mirrorsTxSignatureRequestRepository), so a flaky API never breaks the request. Only invalid typed data throwsEIP712Error.domain.chain_nameviagetCasperNetworkByChainName, with an optionalnetworkparam fallback; if unresolved, the entity is returned without network-dependent enrichment (rows still classified).addressvalue format is heuristic. Thecasper-eip-712addressencoder accepts a 20-byte Ethereum address or a 33-byte Casper public key (not a 32-byte account hash), while the ticket pseudo-code calls these "account hash" — the sources disagree.resolveEip712AddressToAccountHashtherefore auto-detects: strips an optional0x, treats01/02-prefixed 66/68-hex values as public keys (→ account hash), otherwise treats the value as an account hash. The same resolver is used both when collecting hashes to fetch and when looking them up, so keys always match. ETH-style 20-byte addresses won't map to a Casper account (classification only). This will be revisited against real payloads once the wallet exercises it.rawJsonuses abigint→stringJSON replacer (EIP-712 message values can bebigint).Testing
yarn code:check— tsc (strict) + eslint + prettier clean.yarn test— 435/435 pass (44 suites). New/updated coverage: presentation classification, account-hash collection, address resolver (public key / account hash /0x), DTO assembly (incl. bigintrawJson), and the repository's happy path + degraded lookups + unmappable network + invalid-typed-data error.Developed via spec → plan → subagent-driven execution; design/plan in
docs/superpowers/.