Wallets

Nora only allows mints and burns to flow through wallets your organization has explicitly authorized. The Wallets page is where an org admin adds those wallets, picks a role, and signs the on-chain transaction that actually grants permission. Expect to visit this page twice in setup (once to add a whitelister, once to add a destination wallet) and then only when your destinations change.

Where to find it

Sidebar → Wallets. Organization owners and admins only — the backend requireOrgAdmin check means members see a locked state and the item doesn't even render in their sidebar. If you got here from a failed mint, the Add wallet dialog will open automatically with the offending address pre-filled.

The page is environment-scoped: the instance picker at the top chooses Sandbox or Production, and your whitelist lives separately in each.

Add the first whitelister

A whitelister is the root-of-trust wallet that can authorize other wallets. You need at least one active whitelister before you can add any minter, buyer, or buyerAndMinter wallet.

1. On the Whitelisters tab (shown by default when the list is empty), click Add whitelister.
2. Pick Wallet address (paste a Solana public key) or Existing party (choose one from the dropdown of parties with Solana wallets on file).
3. Confirm Role is set to whitelister.
4. Click Continue. The backend grants the whitelister role directly; no signature is required for the first whitelister in this environment.

Add another wallet (minter / buyer / buyerAndMinter)

Once you have an active whitelister, you can authorize destination wallets.

1. Click Add wallet in the top right (or switch to the Approved Wallets tab and click Add wallet in the empty state).
2. Choose Wallet address or Existing party as the source.
3. Pick a Role: minter, buyer, or buyerAndMinter.
4. Pick a Signing whitelister — one of your active whitelister wallets will do the on-chain grant.
5. Click Continue. Nora prepares a Solana transaction and moves the dialog to the signing step.

Sign prepared transaction

1. The signing step shows the Required signer address and a Connect wallet button.
2. Connect the Solana wallet whose address matches the required signer. A mismatch surfaces a yellow Switch wallets to continue banner with a Switch wallet button.
3. Click Sign and submit. Your wallet extension (Phantom, Backpack, etc.) prompts you to approve the transaction.
4. Approve in the extension. Nora submits the signed transaction on-chain (idempotency-keyed, so duplicate submits are safe).
5. The dialog closes with a success toast; the wallet's state moves to active.

Prepare again

If a prepared transaction sits too long, the network blockhash expires. When that happens:

1. On a pending wallet row, click Prepare again.
2. The dialog reopens with the wallet pre-filled at the signing step — or, if the prepared transaction is already gone, at the form step so you can regenerate it.
3. Proceed through Sign and submit as above.

You can also click Prepare new transaction in the signing step itself if your wallet extension times out.

Copy wallet address

Each wallet row has a Copy button that puts the full base58 address on your clipboard — handy when you need to paste it into an intent, a support ticket, or a block explorer.

Gotchas

• Admin only. Org members without owner or admin role see DashboardLockedState with a message to ask an admin. There's no way for them to reach the add dialog.
• Wallet states are active, pending, or banned. Pending wallets are stuck waiting on a signature; banned wallets have been rejected by the backend and can't be reused.
• Reconciliation status matters. Wallets carry a reconciliation flag: synced (matches on-chain), drifted (on-chain state diverged — warning banner, admin review needed before trusting), or missing_onchain (no on-chain status yet).
• The signing wallet adapter must match exactly. Nora refuses the submit if the connected wallet's public key differs from the prepared signer.
• Sandbox and production whitelists are separate. Switching instances shows a different set of wallets; approvals don't carry across.
• Auto-open from Mint / Burn. When an intent hits destination_wallet_not_authorized, the dashboard bounces you here with the add dialog pre-filled, source marked as intents, and a yellow banner at the top summarizing the blocked mint. Finish the add, and the banner turns green with a Back to Mint / Burn button.

See also

• Mint / Burn intents — where unauthorized-wallet errors send you here from.
• Parties setup (integrators) — how wallets bind to parties on the integrator side.