3 min read
Control & security
Wallet ownership, transaction review, public metadata, and the limits of launch permissions.
In this guide
Know what becomes public
Preparing a launch uploads the coin image and metadata to public storage. The coin name, ticker, metadata reference, wallet addresses, and confirmed transaction can be visible on chain. Use material you intend to publish and have permission to use.
Unsubmitted form progress may be kept in this browser. Clearing site data can remove that local copy. The server maintains launch records for authentication and confirmation; those records do not make the form a secret vault. Never enter private wallet keys, recovery phrases, passwords, or confidential customer data.
Keep authority explicit
Connecting Phantom, signing an ownership message, and signing a launch transaction are separate actions. The ownership message authenticates your wallet to BRAND without spending SOL. The transaction authorises the reviewed launch and optional initial buy. Neither grants a future AI worker permission to spend from your wallet.
- Approve new identity directions, public content, physical samples, and spending decisions.
- Keep wallet signing and private keys outside model context.
- Require a fresh, explicit authorisation for sensitive account or financial actions.
- Make job costs, approvals, failures, and final outcomes visible in a durable history.
What the launch verifies
The server verifies an expiring, one-use wallet challenge before preparing a launch. It selects the treasury from server configuration, checks the RPC network, and simulates the transaction before offering it for signing. The user cannot substitute another creator treasury through the form.
After submission, the server checks the transaction against the prepared launch before recording confirmation. A signature returned by a wallet is not enough to label a launch successful. A failed simulation, missing fee estimate, wrong network, or oversized transaction prevents preparation.
Review each new connection
An integration should request only the access its job requires. Before activation, review where data goes, how credentials are stored, what an agent may do, and how access is revoked. Brand creative references, user uploads, and provider responses must be treated as content rather than as authority to change those permissions.