# Falcon wallet protocol (/docs/design/falcon-accounts)

# Falcon wallets [#falcon-wallets]

Falcon wallets use the original Falcon padded signature format. They are not a
claim of conformance to a future final FN-DSA standard. The four immutable account
profiles extend the existing signed-v4 authorization envelope; existing SR, ED
and ML-DSA identities and encodings stay unchanged.

| Wallet               | CLI                                                          | SDK crypto ID | Wire profile | Registration reserve              |
| -------------------- | ------------------------------------------------------------ | ------------- | ------------ | --------------------------------- |
| Fixed Falcon-512     | `btcli wallet create --crypto-type falcon512`                | 9             | 7            | None                              |
| Rotating Falcon-512  | `btcli wallet create --crypto-type falcon512 --type hashed`  | 10            | 6            | Chain-configured; default 0.2 TAO |
| Fixed Falcon-1024    | `btcli wallet create --crypto-type falcon1024`               | 11            | 9            | None                              |
| Rotating Falcon-1024 | `btcli wallet create --crypto-type falcon1024 --type hashed` | 12            | 8            | Chain-configured; default 0.2 TAO |

Normal transaction fees and operation-specific deposits still apply. Changing
scheme or account mode creates a different identity; it is not an upgrade of an
existing address. Restore with the original mnemonic, scheme and account mode.

`HashedAccounts.HashedAccountRegistrationDeposit` sets the shared deposit for future
classical hashed, rotating post-quantum, and protected derived registrations.
Sudo can change it with `sudo_set_hashed_account_registration_deposit(value)`
in rao, including zero. Existing permanently reserved amounts remain unchanged.

## Addresses and authority [#addresses-and-authority]

Each descriptor is `version (2) || profile || initial commitment (64 bytes)`.
Commitments use SHAKE256 with 64 output bytes and bind the profile and exact
public key. The permanent AccountId is BLAKE2b-256 of the Falcon account domain
and descriptor. Fixed profiles search a bounded, deterministic sequence of
transaction keys until the account cannot also encode an Ed25519 or Sr25519
public key. This preserves the existing MS protection against a classical
signature bypass of a post-quantum account.

Fixed wallets display their permanent SS58 address. Their proof supplies the
public key, proves its descriptor hashes to that address, and authenticates the
transaction. No registration or registration reserve is needed. Proof generation
is zero; the native transaction nonce still advances and is retained across
balance reaping to prevent replay.

Rotating wallets retain their permanent descriptor and account address while
updating the authorized key commitment and generation. They use the existing
registration/sponsorship flow, including the registration reserve, consent and
Shield behavior. Their `tao_` receiving descriptor and SS58 identify the same
account; only the descriptor contains the information needed to register it.
After restoration, the SDK reads finalized authority and derives the current
and next signing keys from the mnemonic. The existing admin enable switch also
applies to all four Falcon profiles.

## Wire and cryptographic contract [#wire-and-cryptographic-contract]

The outer extrinsic remains signed-v4 with `MultiAddress::Raw` and the existing
64-byte carrier marker. No `MultiSignature` variant is added. The actual Falcon
authorization is in the Raw address; the marker itself grants no authority.
Metadata-aware existing explorers can decode blocks. Wallet software must support
Falcon to create or sign its transactions.

| Parameter         | Falcon-512  | Falcon-1024 |
| ----------------- | ----------- | ----------- |
| Public key        | 897 bytes   | 1,793 bytes |
| Padded signature  | 666 bytes   | 1,280 bytes |
| Raw authorization | 1,669 bytes | 3,179 bytes |

Authorization bytes are `account[32] || version:u8 || profile:u8 ||
generation:u64-LE || public_key || next_commitment[64] || signature`. The key and
signature have the exact length selected by the profile, with no SCALE vector
prefixes inside Raw. Unknown profiles, malformed lengths and noncanonical
signature padding fail closed before or during verification.

Falcon signs a domain-separated SHAKE256-512 application transcript. It binds
the profile, purpose, public key, full authorization header and complete encoded
transaction payload, including call, signed extensions and implicit chain/era
data. The runtime streams the payload with a protocol size ceiling instead of
copying it or applying Substrate's 256-byte message-shortening convention.
Limit orders use a normal signed transaction to record approval of each order.
Arbitrary message signatures and HTTP authentication are unsupported for Falcon wallets.

The backend is pinned to `fn-dsa-{comm,kgen,sign,vrfy} = 0.3.0` in original-Falcon
mode with `no_avx2`. Only integer verification is needed by the production
runtime; signing/key generation are feature-gated. SDK keys use HKDF-SHA512 with
the Falcon derivation domain and `(version, profile, role, index)`, with transaction
role 0; the backend
receives a domain-separated SHAKE256 seed stream. This exact seed-to-key behavior
is a wallet recovery contract. A dependency upgrade must preserve the pinned
vectors or use new profile identifiers. SDK signing obtains fresh OS randomness,
fails closed if it is unavailable, and verifies its output before returning it.

## Operations and release checks [#operations-and-release-checks]

Falcon reuses existing native calls, safe composite derivations, EVM association,
account-approved orders and registration calls. Mixed-key multisigs are supported;
their quantum resistance depends on the quorum and delegates. Separate ECDSA
Ethereum accounts do not become post-quantum. Existing hardware-wallet apps
need their own Falcon implementation before they can sign these profiles.

Reference measurements are required for Falcon transaction authorization.
Production verification weights must come from approved reference measurements;
test-only weights exercise the functional paths.
Smaller proofs alone do not establish fees or safe execution limits. Release
validation must cover native/Wasm verification, independent known-answer vectors,
recovery, malformed proofs, old-wallet compatibility, Shield sizing/nonces and
the full operation matrix. Backend integration tests are not an independent
cryptographic or side-channel audit.