Authorization architecture

Keyra authorizes.
Wallet / custodian executes.

What you see is what you authorize.

Conceptual diagram where not yet implemented. Material property changes invalidate authorization.

Talk to Developer RelationsWallet integration

Proposed authorization flow

Conceptual — not yet implemented

  1. Wallet constructs transaction intent
  2. Deterministic transaction hash created
  3. Authorization request sent to Keyra
  4. Trusted Keyra device receives request
  5. Human reviews amount, destination, network and fees
  6. Hardware-rooted authorization produced
  7. Wallet/custodian executes through existing key/MPC path
  8. Result linked to authorization evidence
  9. Audit record preserved

What you see is what you authorize

  1. Transaction intentthen
  2. Deterministic serializationthen
  3. Hashthen
  4. User presentationthen
  5. Hardware authorizationthen
  6. Authorization recordthen
  7. Executionthen
  8. Executed transaction comparisonthen
  9. Audit evidence

If amount, asset, destination, network, source wallet, contract, function, or call data changes materially, authorization must be invalidated and repeated.

You are authorizing

250,000 USDC

From
Treasury Wallet
To
0x72F…98D
Network
Ethereum
Destination
Verified Business
Estimated fee
$14.22
Requested by
Treasury System
Security requirement
Keyra Hardware Verification

Amounts are illustrative. Value-moving actions never use ambiguous OK / Yes / Continue labels.

Absolute commands

Never collect private wallet material

01

No seed phrases

Never ask for or store a seed phrase.

02

No private keys

Never ask for, store, or log a private key.

03

No analytics leakage

Never place private material in analytics or crash reports.

04

Reject bad architectures

If a third party requires unnecessary exposure—stop.

Continue with wallet integration patterns

Provider-neutral adapters. Conceptual interfaces labelled.

Wallet integrationSecurity