Signing Modes
The studio supports two modes for signing on-chain transactions. Both modes are driven through the studio’s browser UI on the machine running the CLI — only the signing path differs. Pick whichever fits how you want signatures authorized.
Wallet Adapter (default)
Use this mode on a workstation with a browser wallet extension installed.
How it works:
- The studio opens a standard Solana wallet connect modal (Phantom, Solflare, all Wallet Standard wallets)
- Every transaction is signed by the connected wallet
- No secret keys are handled by the studio
Use it when:
- You are configuring the campaign on your own machine
- You already use a browser wallet for Solana
Local Keypair
Use this mode when the browser wallet flow is not a good fit — for example when signing from a dedicated deploy keypair that is not imported into a browser wallet, or when the recipient list is large enough that clicking through every wallet approval becomes impractical and you want signatures handled automatically in-process.
How it works:
- You paste a secret key into an unlock dialog
- The keypair is stored only in the locally running studio process memory on your own machine
- Transactions are signed in-process and sent via RPC
- Locking or ending the session clears the key from memory
The local keypair is held in RAM on your own machine for the duration of the studio session. It is never written to disk and never leaves your machine. Closing the terminal, clicking Remove, or stopping the locally running studio process drops the key.
Because a compromised host machine can read process memory, prefer a dedicated deploy keypair funded with only what the airdrop needs, rather than a high-value custody keypair.
Accepted Key Formats
- Base58-encoded secret key — the single-string format exported by browser wallets such as Phantom
- JSON byte array — a 64-byte array, the format produced by
solana-keygenand used by Solana CLI keypair files
Studio dialog for unlocking a local keypair, showing the secret key input, the format hint (Base58 or JSON byte array), and the unlock action.
Session Lifecycle
| UI action | API route | What happens |
|---|---|---|
| Check status | GET /api/signer/status | Whether the keypair is unlocked |
Unlock | POST /api/signer/unlock | Parses and stores the keypair in memory |
| Sign and send | POST /api/signer/sign-send | Signs a serialized transaction and submits it |
Remove | POST /api/signer/lock | Clears the keypair from memory |
The studio UI drives all of the above through buttons in the signer panel. These endpoints are served by the locally running studio process and are only reachable from the same machine on localhost. Direct API use is only relevant if you are scripting against the running studio from that machine.
Switching Modes
You can switch between modes at any time. The airdrop state itself is not affected — only the signing path changes. Signatures from both modes are recorded to .bonkit/activity-log.json with the same structure.
Next Step
Continue to Generated App for the output project structure.