Configuration and storage keys

A lookup table. Configuration and environment explains the reasoning behind these; this page is the list.

Build-time variables

Read at build time from extension/.env, and never committed. Absent, each one makes the wallet report the feature as unconfigured rather than failing at a fetch.

.env loads on every build. .env.production loads afterwards for a production build and overrides only what it sets.

Aquarius, CCTP and the asset directory need no configuration. All three are keyless.

Network fields

One entry per network in extension/src/core/config.ts.

A knownAssets entry is { code, issuer }. The Stellar Asset Contract id is derived rather than stored, and a trustline the account does not hold is omitted rather than shown as zero.

A confidential entry

What the wallet writes to disk

All of these live in chrome.storage.local, and everything sensitive among them is encrypted.

Three of these are worth reading twice

pocket.openings is not a cache. The chain stores commitments; only these pairs make one spendable. Discarding them makes funds visible on chain and permanently unspendable. That is why the extension requests unlimited storage and why the archive exists.

The key carries both the wrapper and the account, so it is enumerated rather than named:

pocket.openings.<token>.<address>

The format lives in one function, because a caller that builds the string itself can drift from the one that enumerates. Both failure modes are silent: a read that misses reports no record of your balances, and an erase that misses leaves a blob no future key can open.

pocket.address is in the clear on purpose. It is on the ledger the moment the account is funded, so storing it plainly reveals nothing. It exists so a user who has forgotten their password can still be checked against the wallet they are trying to erase, which is the only way to authorise that erase without the password.

pocket.auditorid has to be recorded because the registry allocates the id and returns it. Losing it does not lose funds, but it orphans a registered key and the next attempt allocates another, so a retry reuses this. It is per deployment, per account, and enumerated for the same reason openings are.

What lives in RAM

chrome.storage.session is RAM-backed, wiped on browser close, and restricted to trusted extension contexts.

The seed is deliberately absent from it. The plaintext seed lives in service-worker memory only and is never written anywhere, not even here. What is mirrored is the one value needed to re-open the vault, so a routine worker eviction does not force the password again while a real lock still does.

The vault and locking.

What the popup writes

One key, and it is in the popup's own localStorage rather than in extension storage:

The addresses themselves are public on the ledger, which is why they are stored in the clear. Who this device paid is not public, and that is what the list is, so erasing the wallet clears it. It is cleared explicitly, because the worker's sweep over chrome.storage.local cannot reach the popup's localStorage.

What an erase removes

In this order, and the order is load-bearing:

pocket.vault  pocket.state  pocket.inflight  pocket.staged
pocket.address  pocket.dapps  every pocket.openings.*  every pocket.auditorid.*

Vault first, openings last. A process kill part way through leaves orphaned blobs and no vault, which a fresh install sweeps. The reverse would leave a working wallet whose openings are gone, which means funds visible on chain and permanently unspendable.

Chrome documents the multi-key form but does not promise atomicity, so this is one window rather than a transaction.

Auditor ids survive when the same account is coming back, and only then.

Archive environment

HORIZON_URL is not optional in practice. Without it, transfer payloads are not stored and every recipient rebuilding from the archive is refused.

Script environment

Test environment