Resources · AKADATA invention
AIP-56 Human Recovery
AIP stands for AKADATA Improvement Proposal. AIP-56 is Saphira's human recovery key: a private secret written as ordinary words, which you can print, store, read, and type back in. It does not rely on email, a particular device, or an online account, so it remains yours to use even when those are unavailable.
What AIP-56 is
AIP means AKADATA Improvement Proposal. AIP-56 is a human recovery key format: a sizeable recovery secret written as words, not as a short code or a password hint.
The current reference produces a phrase containing 15 five-letter words. Every character is independently assigned an upper- or lower-case form using cryptographically secure randomness.
The complete displayed phrase representation has approximately 544 bits of search space. This is not a claim that every surrounding account system or attack path has 544-bit security.
Why it exists
Account recovery is often tied entirely to an email mailbox or a device. AIP-56 provides an independent value that the account holder can keep offline and retain under their own control.
It is deliberately human-readable without being a sentence, password hint or short recovery code. The reference algorithm balances selection across all initial letters and uses cryptographically secure randomness throughout.
How the phrase works
The canonical source contains 9,074 validated five-letter words grouped by their first letter. The picker selects two distinct words from every a–z group, producing a 52-word candidate pool. It securely shuffles that pool, takes 15 words, and applies secure random case to every character.
Word order matters. The spaces between words matter. Every character's case matters. lodge, LODGE and lODgE are different recovery values.
A phrase must be recorded and re-entered exactly as generated. Keep it private and offline where practical.
Self-contained reference implementations
The AIP-56 reference implementations are self-contained and published by AKADATA, Saphira's parent company. They are written in PHP, ECMAScript for the browser, Node.js, Python, Go, C, C#, Java, Rust, Perl, Lua, and Ruby. Each runtime embeds the compressed canonical chunk data in its own native structure, so there is no external wordlist file to load.
No implementation reads an external wordlist file at runtime. The embedded data is compressed token data, not an expanded wordlist. Each implementation inflates and validates it in memory before generating a phrase.
Implementations validate chunk counts, raw lengths, per-chunk SHA-256 checksums, the total word count and the global checksum. PHP can additionally reconstruct the canonical JSON byte-for-byte for OpenPGP verification.
Canonical source, integrity and authenticity
The signed wordlist.json is the canonical wordlist source. Its SHA-256 is ea0be8d452c422f154358b386c0c5bfc1f4e8e0670f9cd4ddf1a662cb3c96ec8.
Checksums detect corruption, invalid token streams, incorrect chunk lengths and inconsistent content. OpenPGP verification proves that the release came from AKADATA.
OpenPGP verification is tied to the canonical JSON artifact and the AKADATA signing key 7915B0831DF20BAFF4218F347D88C5B374E65D90 (Andrew Smalley <andrew.smalley@akadata.ltd>). The reference code is published in multiple languages so implementations can be checked against canonical PHP behaviour.
No database dependency
AIP-56 generation and validation do not require a database, cookie, session, remote service or network request.
That independence belongs to the format, algorithm and reference implementations. A website may choose to publish documentation around AIP-56, but the recovery key itself does not depend on that website being available.