Skip to main content
POST
Prepare a token burn
Prepares unsigned transactions for burning tokens from the signer’s balance. Use POST /prepare-transactions with method=burnToken. Burning reduces the token’s current totalSupply. It does not reduce the configured maximum supply.

The signer’s balance is what burns

The prepared transaction calls burn(amount), which burns the caller’s own tokens. The API checks the balance of signerAddress and returns Insufficient token balance when it is short.
investorEmail is required, but it only attributes the burn in Brickken’s records. It does not select whose tokens are burned, and there is no investorAddress selector on this method.A tokenizer wallet that holds none of the token therefore gets Insufficient token balance even when the investor named in the request holds plenty.

Burning tokens an investor holds

The API does not expose a delegated burn. Two supported routes:
  • The investor signs. Use the investor’s wallet as signerAddress, so the burn comes out of the balance that actually holds the tokens.
  • Recover, then burn. Have the investor approve the company wallet, use transferFrom to move the tokens to it, then burn from the company wallet.
If your application only ever acts for the issuer and can never obtain an investor signature, only the second route is available.

Next step

Preparing does not touch the chain. The response gives you txId and an array of unsigned transactions — you still have to sign and submit them.
1

Sign every returned transaction

Sign each entry locally with the wallet that sends the transaction — signerAddress, or investorAddress for newInvest and claimTokens. It must be whitelisted by Brickken, and it needs native gas on the target chain.
2

Submit the signed payloads

POST them to /send-transactions as { txId, signedTransactions } and Brickken broadcasts for you.If you would rather broadcast yourself, prepare with executionMode: "client-broadcast" and confirm afterwards with { txId, txHash } instead.
3

Poll until it confirms

Call GET /get-transaction-status with the txId. A pending status means it is broadcast but not yet mined — do not resubmit.
Full walkthrough: Tokenize an asset and run an STO.

Authorizations

x-api-key
string
header
required

Body

application/json
method
enum<string>
default:burnToken
required

Required. Operation to prepare. Must be burnToken for this endpoint.

Available options:
burnToken
Example:

"burnToken"

chainId
string
required

Required. Blockchain network identifier. Hex format is recommended, for example Sepolia aa36a7.

Example:

"aa36a7"

signerAddress
string
required

Required. Wallet whose tokens are burned. It also signs the transaction and must hold at least amount.

Example:

"0x742d35Cc6634C0532925a3b844Bc454e4438f44e"

tokenSymbol
string
required

Required. Symbol of the token to burn. Must be 2 to 5 uppercase letters or numbers.

Example:

"EXMPL"

amount
string
required

Required. Amount of tokens to burn.

Example:

"100"

investorEmail
string<email>
required

Required. Email used to attribute the burn in the Brickken records.

Example:

"investor@example.com"

Response

200 - application/json

Successful response

transactions
object[]
required

Array of unsigned transaction objects ready for signing

txId
string
required

Unique identifier for this transaction batch (required for /send-transactions). This is NOT a blockchain transaction hash.

Example:

"0x46adea7bdf49c576a760102e0d6bc9ecd650b3998588cd3d7f576a7973426aad"

info
object

Metadata about the operation