PlimsollStrongroom
NetworkHedera testnetAudit topic0.0.10451091Coverage feedLive, over MCP
Demonstration

Each note shows a dated reading from chain. Walk the states to see what each one does.

Issuer console

Moving a note's line and halting its market both take a mandate a person approved on a Ledger. Decline it and the device answers 6985 with no signature at all.

The mandate PLIM-B was opened with

The contract never parses this string. It rebuilds it from typed arguments plus its own address and chain id, so the only string that verifies is the one it would have written itself.

PLIMSOLL MANDATE v1
ACTION: SET-THRESHOLD
MARKET: PLIM-B
COVERAGE: 0.00%
LOAD LINE: 100.00%
NONCE: 5
EXPIRES: 2026-09-11T19:54:51Z
CHAIN: 296
VERIFIER: 0x835408327a72307e79826aa3a9b038c6d73429c1
  • Load line set100.00%
  • Nonce5Single use: the same approval cannot be replayed.
  • ExecutedSET-THRESHOLD

What the device showed

Paged exactly as the firmware paged it. The device reflows newlines into spaces and wraps at about nineteen characters, so no value may contain a space or a colon — otherwise a market code could impersonate a second field and the person would have no way to tell.

  1. Review message
  2. Message (1/4) PLIMSOLL MANDATE v1 ACTION: SET- THRESHOLD
  3. Message (2/4) MARKET: PLIM-B COVERAGE: 0.00% LOAD LINE: 100.00%
  4. Message (3/4) NONCE: 5 EXPIRES: 2026-09-11T19:54:51Z CHAIN: 296 VERIFIER:
  5. Message (4/4) 0x835408327a72307e 79826aa3a9b038c6d7 3429c1
  6. Sign message

A halt, a refusal, and two wrong doors

Recorded against PLIM-A on Hedera testnet. The same signed mandate was sent to the verifier and to the adapter directly: both refused it, and the approval was still unspent afterwards, so it worked when it finally went through the load line. Then the device declined a resume, and the market stayed halted.

  • device approves SET-THRESHOLD at 95.00%APPROVED on deviceSET-THRESHOLD · nonce 1
  • same mandate through LoadLine with 90.00% - must revertREVERTEDLoadLine.setThreshold · MandateValueMismatch
  • same mandate through LoadLine with the 95.00% it approvedSUCCESSLoadLine.setThreshold
  • after thresholdTradingLoad line 95.00%
  • device approves HALTAPPROVED on deviceHALT · nonce 2
  • valid HALT straight to the verifier - wrong door, must revertREVERTEDMandateVerifier.haltMarket · NotGatekeeper
  • valid HALT straight to the adapter - wrong door, must revertREVERTEDMandateVerifierAdapter.requireMandate · NotLoadLine
  • after both wrong doors - approval unspentTradingLoad line 95.00%
  • the same HALT through LoadLine - acceptedSUCCESSLoadLine.halt
  • after haltHaltedLoad line 95.00%
  • device REJECTS RESUMENO SIGNATURE (refused)RESUME · nonce 3 · 6985, no signature exists
  • RESUME signed by a non-device key - must revertREVERTEDLoadLine.resume · WrongAuthority
  • after rejected resumeHaltedLoad line 95.00%
  • device approves RESUMEAPPROVED on deviceRESUME · nonce 4
  • device-approved RESUME through LoadLine - acceptedSUCCESSLoadLine.resume
  • after approved resumeTradingLoad line 95.00%

The device that holds the authority

  • Applicationapp-ethereum 1.22.3
  • Modelnanosp
  • Running onSpeculos, private BIP-39 seedAn emulator running the real Ethereum application, on a seed held outside the repository. On hardware the key would additionally be non-extractable; that is a property of the hardware, not of anything shown here.

What the device does not govern

  • Deployment administrationOwnerWiring the oracle, registering notes, rotating an attestor and creating schedules are owner-gated. A mandate is only worth something if a person can read what they are approving, and raw hex on a four-line screen is a rubber stamp with extra steps.
  • The authority itselfOwnerThe owner can repoint it, so the accurate claim is that the device approves load-line changes — not that nobody can bypass the device.