Skip to content

fix(atlas): E16b claimed x402 clear-signs; the test asserts it is REFUSED - #47

Merged
BitHighlander merged 1 commit into
masterfrom
fix/atlas-e16b-tells-the-truth
Aug 21, 2026
Merged

fix(atlas): E16b claimed x402 clear-signs; the test asserts it is REFUSED#47
BitHighlander merged 1 commit into
masterfrom
fix/atlas-e16b-tells-the-truth

Conversation

@BitHighlander

Copy link
Copy Markdown
Owner

The worst kind of catalog defect, and it shipped green in the PDF.

E16b read:

"x402 EVM EIP-3009 payment clear-signs structured data"
"The device computes the EIP-712 hashes itself and displays the Base Sepolia USDC domain plus every TransferWithAuthorization field: payer, recipient, exact value, validity window and nonce."
screens: ['USDC domain fields', 'TransferWithAuthorization fields']

The test underneath had already been rewritten to assert the opposite:

with self.assertRaises(CallException) as ctx:
    self.client.ethereum_sign_typed_data(...)
self.assertIn("Structured EIP-712 disabled", str(ctx.exception))

So the row was passing while proving refusal. Anyone reading the report — which is the point of the report — would conclude x402 EVM payments clear-sign on this firmware. They do not.

The screenshot audit could not catch this. The test captures a PNG from the apply_policy confirm, so "declared screens but captured none" never fired. The audit proves a screen was captured, not that it is the screen declared. Worth knowing about that gate's reach.

E16 was collateral — it described the hashed path as a legacy fallback and pointed at E16b for "the separate device-parsed path", a path that does not run. Rewritten to say what is true and load-bearing: the hashed path is the only working EIP-712 path, and every signature a KeepKey produces today — Permit2 approvals included — is blind-signed behind AdvancedMode.

…USED

The worst kind of catalog defect, and it shipped green in the PDF.

E16b read:

  "x402 EVM EIP-3009 payment clear-signs structured data"
  "The device computes the EIP-712 hashes itself and displays the Base
   Sepolia USDC domain plus every TransferWithAuthorization field: payer,
   recipient, exact value, validity window and nonce."
  screens: ['USDC domain fields', 'TransferWithAuthorization fields']

The test underneath had already been rewritten to assert the opposite:

  with self.assertRaises(CallException) as ctx:
      self.client.ethereum_sign_typed_data(...)
  self.assertIn("Structured EIP-712 disabled", str(ctx.exception))

So the row was PASSING while proving refusal. Anyone reading the report --
which is the point of the report -- would have concluded that x402 EVM payments
clear-sign on this firmware. They do not. 7.14.2 disabled the structured path
because the JSON parser could not guarantee the displayed value was the value
being hashed, and it is still disabled.

The screenshot audit could not catch this. The test captures a PNG from the
apply_policy confirm, so "declared screens but captured none" never fired --
the audit proves a screen was captured, not that it is the screen declared.
Worth knowing about that gate's reach.

E16 was collateral: it described the hashed path as the legacy fallback and
pointed at E16b for "the separate device-parsed path", a path that does not
run. Rewritten to say what is true and load-bearing -- the hashed path is the
ONLY working EIP-712 path, and every signature a KeepKey produces today,
Permit2 approvals included, is blind-signed behind AdvancedMode.

E16b now documents the refusal, keeps the empty screen list (a refusal draws
nothing; the evidence is the Failure on the wire), and records that the V4
reference hashes stay in the fixture as the vector to re-assert when the
streaming implementation lands.
@BitHighlander
BitHighlander merged commit c4563ad into master Aug 21, 2026
2 of 5 checks passed
@BitHighlander
BitHighlander deleted the fix/atlas-e16b-tells-the-truth branch August 21, 2026 21:26
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