Playground

See what the attester sees.

Pick a sample scenario or paste your own intent payload. The browser computes the canonical hash, simulates the on-device renderer, and shows the exact digest the attester would sign. Zero install.

This page runs the same canonical renderer the firmware and host bridge use. The decode and hash logic is identical, so the byte-level output you see here is the byte-level output a real attester device would produce. The only thing missing is the device screen and the human pressing CONFIRM.

Pick a scenario below, or edit the form fields directly to construct your own.

Inputs

What the device shows

simulated 240×135 IPS, JetBrains Mono

Canonical bytes



    
Intent hash

    


    
Digest the attester signs

    

  






What just happened



Four things, all client-side, all matching the firmware byte-for-byte:



    
  
  1. Decoded the raw action_args hex into a structured intent using the registered adapter for that action_kind. Unknown kinds fail closed.
    2. 
  
  2. Canonicalised the structured intent into a deterministic byte sequence (sorted-key, length-prefixed, type-tagged). The firmware does the same on its own CPU.
    3. 
  
  3. Computed the intent hash as H(domain_sep || vault || u64_le(nonce) || u32_le(action_kind) || canonical). SHA-256 for Solana, Keccak-256 for EVM. This is the value the on-chain guard recomputes from the actual call and compares against what the signers approved.
    4. 
  
  4. Computed the attest digest as H(domain_sep || vault || u64_le(nonce) || u32_le(action_kind) || intent_hash || u64_le(signed_at)). This is what the attester device’s signing key actually signs. The on-chain guard verifies the same digest against the device’s enrolled pubkey.
    5. 




If a malicious laptop swapped the action_args between rendering and signing, the recomputed intent hash would not match the bound hash and the action would not execute. That is the entire point of the primitive.



Try the Drift scenario



Click “Replay the Drift attack” above. The screen shows what a Drift Council member would have seen on their attester device the day of the attack: a WHITELIST_COLLATERAL action whitelisting a token they had no reason to trust, at a fair value of $1.00, with a $500M deposit cap. Compare that screen to the routine USDC listing scenario right next to it. Same action kind, same shape of payload. The difference is in the fields. The point of putting the rendered intent on a separate trust domain is that a human gets a chance to see that difference.



Read