FSA approved

Approval at the key: hardware signing in SQRL's settlement flow

On SQRL, approval happens where it matters most: on the device that holds the key. This is how hardware signing connects to a Bitcoin anchor and a replayable contract result.

SQRL team, , 3 min read

A hardware signing device sends a beam of light into a data grid, with the Trezor and SQRL logos.

In any settlement system the most important control is approval: who signs, what they saw when they signed, and whether what was executed is exactly what was approved. SQRL puts that approval on dedicated hardware, at the Bitcoin transaction. Our first integration uses Trezor.

Keep each job separate

The signer approves the Bitcoin transaction that carries the contract commitment. SQRL assembles that transaction, binds it to the call envelope and validates the signed result. The SQRL virtual machine runs the contract. Lightning carries payments. Bitcoin settles.

The private key never leaves the device. SQRL receives only the public account data and the signatures it needs.

Register a verified account

SQRL requests the public account data for a defined BIP84 native SegWit policy (the first receiving address sits at m/84'/0'/0'/0/0). The signer confirms a receiving address on its own screen, and SQRL checks it matches the address derived from the registered account. The seed and private keys are never requested.

Bind one transaction to one call

Every operation has two linked records: the Bitcoin transaction, with a protocol stamp committing the call, and the call envelope itself, with contract, method, payload, signing authority and the named outpoint.

Both are prepared before the device is asked to sign. Change the call and the commitment changes. Change an output or the fee and the transaction changes. Either way, a fresh approval is required. SQRL uses a Partially Signed Bitcoin Transaction (BIP174) as the portable record.

Make the approval meaningful

The device shows the Bitcoin effects: destination, fee and total. SQRL shows the contract context: the contract, the method and the envelope hash. When the signed transaction comes back, SQRL checks that the commitment, outputs and fee are unchanged before broadcast. Any change restarts the approval.

From anchor to replayable result

After broadcast, the call envelope goes to a SQRL node, which checks the contract, the outpoint and the commitment, then runs the call in the bounded virtual machine (100,000 instructions, stack depth 1,024, call depth 64, 64 KB storage per contract). Any independent node can load the same inputs, replay the change and compare the result.

What a reviewer can follow

  1. Register the BIP84 account and verify an address on the device.
  2. Build the call envelope and its commitment hash.
  3. Build the Bitcoin transaction carrying the stamp.
  4. Approve and sign on the device.
  5. Validate and broadcast the signed transaction.
  6. Submit the call to a SQRL node.
  7. Replay the result against the same Bitcoin context.

The device approves. Bitcoin anchors. SQRL executes. Independent nodes replay. Lightning moves the money.

Keep reading. More from Engineering and the rest of the newsroom.