# [keystore@1.0.0-canary.20](https://github.com/algorandfoundation/wallet-provider-extensions/compare/keystore@1.0.0-canary.19...keystore@1.0.0-canary.20) (2026-08-13)

### Features

* keystore migrations ([a7ed907](https://github.com/algorandfoundation/wallet-provider-extensions/commit/a7ed90757812833b0712b85438651d008a1e49dc))

# [react-native-keystore@1.0.0-canary.16](https://github.com/algorandfoundation/wallet-provider-extensions/compare/react-native-keystore@1.0.0-canary.15...react-native-keystore@1.0.0-canary.16) (2026-08-13)

### Features

* keystore migrations ([a7ed907](https://github.com/algorandfoundation/wallet-provider-extensions/commit/a7ed90757812833b0712b85438651d008a1e49dc))

feat: keystore migrations

# [keystore@1.0.0-canary.19](https://github.com/algorandfoundation/wallet-provider-extensions/compare/keystore@1.0.0-canary.18...keystore@1.0.0-canary.19) (2026-08-13)

### Features

* **migrations:** opt-in data migrations engine for provider extensions ([495f336](https://github.com/algorandfoundation/wallet-provider-extensions/commit/495f33636d62c9ada84d13fd8ea82e18cc3a888d))

### BREAKING CHANGES

* **migrations:** instead of hand-rolling a startup fix-up pass.

WithMigrations is placed first in the extensions array, so provider.migrations
exists for every later extension, and the run is scheduled as a microtask so
the registry is complete before the first revision executes. Opted-in packages
import only `type { Migration }` and carry no runtime dependency on the engine.

- Storage-agnostic: each module declares its own opaque context type, so
  IndexedDB, MMKV and a sealed file all work without a shared interface.
- Ledger written per revision, never batched, so a killed run resumes exactly
  where it stopped.
- Forward-only and always from revision zero; migrations tolerate empty data.
- Per-module failure isolation: a failing revision halts only its own module,
  other modules still run, then `ready` rejects with an aggregate error.
- A ledger ahead of the installed code is reported and warned about, not
  thrown, since bricking an app on a downgrade is worse.
- Run-scoped SecretScratch for key material in flight: bytes only, zeroed in a
  finally, use-after-wipe throws, non-serializable. Hook payloads carry
  { module, revision } only.

react-native-keystore is the first adopter, with migrateLegacyPasskeys tracked
as revision 0001, and the react-native example wallet is wired up.
* **migrations:** legacy passkey flagging no longer runs automatically on engine
start. It is now revision 0001 of the package's migration manifest and requires
WithMigrations from @algorandfoundation/provider-migrations to be installed on
the provider. Applications that do not add it will never flag legacy passkeys.

# [react-native-keystore@1.0.0-canary.15](https://github.com/algorandfoundation/wallet-provider-extensions/compare/react-native-keystore@1.0.0-canary.14...react-native-keystore@1.0.0-canary.15) (2026-08-13)

### Features

* **migrations:** opt-in data migrations engine for provider extensions ([495f336](https://github.com/algorandfoundation/wallet-provider-extensions/commit/495f33636d62c9ada84d13fd8ea82e18cc3a888d))

### BREAKING CHANGES

* **migrations:** instead of hand-rolling a startup fix-up pass.

WithMigrations is placed first in the extensions array, so provider.migrations
exists for every later extension, and the run is scheduled as a microtask so
the registry is complete before the first revision executes. Opted-in packages
import only `type { Migration }` and carry no runtime dependency on the engine.

- Storage-agnostic: each module declares its own opaque context type, so
  IndexedDB, MMKV and a sealed file all work without a shared interface.
- Ledger written per revision, never batched, so a killed run resumes exactly
  where it stopped.
- Forward-only and always from revision zero; migrations tolerate empty data.
- Per-module failure isolation: a failing revision halts only its own module,
  other modules still run, then `ready` rejects with an aggregate error.
- A ledger ahead of the installed code is reported and warned about, not
  thrown, since bricking an app on a downgrade is worse.
- Run-scoped SecretScratch for key material in flight: bytes only, zeroed in a
  finally, use-after-wipe throws, non-serializable. Hook payloads carry
  { module, revision } only.

react-native-keystore is the first adopter, with migrateLegacyPasskeys tracked
as revision 0001, and the react-native example wallet is wired up.
* **migrations:** legacy passkey flagging no longer runs automatically on engine
start. It is now revision 0001 of the package's migration manifest and requires
WithMigrations from @algorandfoundation/provider-migrations to be installed on
the provider. Applications that do not add it will never flag legacy passkeys.

# provider-migrations@1.0.0-canary.1 (2026-08-13)

### Bug Fixes

* skip release git commits on protected main ([46710fe](https://github.com/algorandfoundation/wallet-provider-extensions/commit/46710fe34848f7dfbee565b033566583b56e9daa))

### Features

* **migrations:** opt-in data migrations engine for provider extensions ([495f336](https://github.com/algorandfoundation/wallet-provider-extensions/commit/495f33636d62c9ada84d13fd8ea82e18cc3a888d))

### BREAKING CHANGES

* **migrations:** instead of hand-rolling a startup fix-up pass.

WithMigrations is placed first in the extensions array, so provider.migrations
exists for every later extension, and the run is scheduled as a microtask so
the registry is complete before the first revision executes. Opted-in packages
import only `type { Migration }` and carry no runtime dependency on the engine.

- Storage-agnostic: each module declares its own opaque context type, so
  IndexedDB, MMKV and a sealed file all work without a shared interface.
- Ledger written per revision, never batched, so a killed run resumes exactly
  where it stopped.
- Forward-only and always from revision zero; migrations tolerate empty data.
- Per-module failure isolation: a failing revision halts only its own module,
  other modules still run, then `ready` rejects with an aggregate error.
- A ledger ahead of the installed code is reported and warned about, not
  thrown, since bricking an app on a downgrade is worse.
- Run-scoped SecretScratch for key material in flight: bytes only, zeroed in a
  finally, use-after-wipe throws, non-serializable. Hook payloads carry
  { module, revision } only.

react-native-keystore is the first adopter, with migrateLegacyPasskeys tracked
as revision 0001, and the react-native example wallet is wired up.
* **migrations:** legacy passkey flagging no longer runs automatically on engine
start. It is now revision 0001 of the package's migration manifest and requires
WithMigrations from @algorandfoundation/provider-migrations to be installed on
the provider. Applications that do not add it will never flag legacy passkeys.

feat(migrations): opt-in data migrations engine for provider extensions

There were FOUR copies of the signed-message construction and no test
compared any two:

  sdk/src/trelyan_pq/message.py    the SDK's, published to PyPI
  contracts/falcon_det1024.py      the contracts-side signer
  contracts/deploy_testnet.py      a local copy - deleted here
  contracts/test_inscription.py    a local copy - deleted here

The deleted copies were not harmless duplication. deploy_testnet.py's omitted
the length checks entirely:

  return DOMAIN_TAG + app_id.to_bytes(8,"big") + cell_id.to_bytes(8,"big") \
         + artifact_hash + genesis

so a 31- or 33-byte artifact hash produced a 101- or 103-byte M and was signed
without complaint - in the script that signs REAL TestNet inscriptions. The
ABI's StaticArray[Byte, 32] stops that reaching the chain, which is why this is
low rather than high, but "a later layer catches it" is a mitigation, not a
reason for the earlier layer to be wrong.

Both files already imported falcon_det1024, so removing the local definitions
is a deletion, not a refactor.

Two implementations remain on purpose: contracts/ has to work without the SDK
installed. Two is a decision; four was an accident. What makes two safe is that
something compares them, which is what
sdk/tests/test_build_message_differential.py now does:

  - both implementations agree across six inputs, including uint64 max and the
    live TestNet vector
  - both reproduce the exact M the chain accepted for cell 763809098, read from
    the live inscription record - an anchor that is neither implementation's
    opinion but what TestNet actually took
  - both reject wrong-length artifact and genesis hashes, which is the
    divergence that actually existed
  - the two names resolve to different function objects, so the comparison
    cannot become a function compared with itself

Mutation-proved: flipping the contracts-side cell_id to little-endian turns 5
of the 15 tests red. Restored: 15 passed.

Fixes AUDIT_READINESS.md S2.3, which cited three tests as covering this; each
exercised one implementation and none compared two.

Contract suite still 22 passed on LocalNet.

Note for reviewers: the SDK suite reports 3 unrelated errors on this machine -
PermissionError on pytest's tmp_path directory, in test_seal.py and
test_isolated_signer.py, both last modified in 2ec798e and untouched here. It
is local file-locking, not this change; CI runs on Linux.

Found by an independent re-check of the risk register (TCE-26).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The reviewer script printed

    full falcon verify available locally: YES (run verify(M, sig, pk))

unconditionally. Two defects in two lines.

`verify` is re-exported from trelyan_pq/__init__.py:48, so
`from trelyan_pq import verify` succeeds whether or not the C library exists
and the `except` branch was unreachable. The script therefore told every
reviewer that full local verification was available, including on machines
with no library at all - which is most of them, since building it is a
documented manual step.

And the hint it printed had the arguments backwards. The real signature is

    verify(sig, pubkey, message)

so a reviewer following `verify(M, sig, pk)` passes the message where the
signature belongs and gets a failure that looks like a bad signature.

Now forces the load via default_signer()._lib_ref() and reports what actually
happened, including the underlying error when it did not load. Verified both
ways on this machine:

  without FALCON_DET1024_LIB
    full local falcon verify: NOT available (RuntimeError: FALCON_DET1024_LIB
    is not set. Build the deterministic Falcon-1024 shared library ...)

  with a locally built library
    full falcon verify available locally: YES
    (signature order is verify(sig, pubkey, message) - sig FIRST, not the message)

Uses a private accessor deliberately: the public API is lazy, so probing it
answers "did the import work", which is the question that produced the wrong
answer in the first place.

Also makes the remaining printed lines ASCII. This script runs in CI and on
reviewers' terminals; an em-dash mojibakes to a replacement char on a Windows
console codepage, and a verification tool should not look corrupted.

Found by an independent re-check of the risk register (TCE-09), which reported
the mechanism accurately after the original sweep's headline claim for that
finding had been refuted.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Asset 0 encodes as an empty ResourceRef, which the AVM treats as an
empty box rather than an asset. Reject it when composing Access lists
and require an explicit empty box reference instead.

Fixes #764.

Protocol/goal omitempty drops votefst=0. Restore 0 on decode when
other online keyreg fields are present so Lora can read those txns.

register_cell asserts three things about a Cell ASA:

  :205  clawback == zero_address
  :206  freeze   == zero_address
  :207  manager  == zero_address

Only :205 had a test. test_register_rejects_clawback_cell's docstring claims
to cover "clawback (or freeze/manager)" but its fixture sets only `clawback`,
and the asserts are sequential, so it trips :205 and the other two are never
evaluated. The words freeze and manager appear in this file only in prose.
Deleting :206 and :207 turns nothing red.

Not cosmetic. A live freeze address can freeze the holder AFTER registration,
and a live manager can RE-ADD clawback and freeze afterwards - which restores
both AssetHoldingGet timing vectors the hardening closed at the source. The
manager guard is the load-bearing one: it is what makes the cell's config
immutable rather than merely clean at registration time.

Adds one fixture per guard and asserts WHICH guard fired, so a future
reordering of the three asserts cannot silently leave one uncovered again.

VERIFICATION IS INCOMPLETE, and deliberately not overstated: unlike the other
contract test added in this series, these two are NOT mutation-proved. Docker
Desktop on this machine wedged part-way through (orphaned runtime sockets that
cannot be deleted without a reboot - my own hard-kill of the process is the
likely cause), so LocalNet is unavailable and the suite cannot run here.

What HAS been checked:
  - both tests collect (24 collected, up from 22)
  - the asserted strings match the contract's messages exactly, one occurrence
    each in inscription.py and in the test
  - the fixtures mirror test_register_rejects_clawback_cell, which passes

What has NOT been checked: that they fail when :206/:207 are deleted. The CI
job in the contract-suite PR runs LocalNet successfully on a GitHub runner, so
that is where this should be confirmed.

Found by an adversarial claim-vs-enforcement sweep (TCE-19).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>