Skip to main content
POST
Prepare a new STO
Prepares unsigned transactions for creating a new Security Token Offering (STO). Use POST /prepare-transactions with method=newSto. Wait for the tokenization to succeed before preparing the STO, and use the exact token symbol available to the API key on the selected chain.

Fields

All of the following are required: method, chainId, signerAddress, tokenizerEmail, tokenSymbol, offeringName, tokenAmount, acceptedCoin, startDate, endDate, minRaiseUSD, maxRaiseUSD, minInvestment, maxInvestment. Three field names are commonly guessed and are not accepted:
A rejected field name currently surfaces as a message about txId and transaction values not matching, rather than naming the field. If you see that message, check your field names against the list above before anything else.

There is no token price input

Price is derived as maxRaiseUSD / tokenAmount. To offer 50,000 tokens at 1 USD each, send tokenAmount: "50000" and maxRaiseUSD: "50000". minRaiseUSD is the offering’s soft cap. It decides what happens at the end: an offering that reaches it can deliver tokens, and one that does not enters rollback and refunds investors instead.

Timing

Send startDate and endDate as explicit UTC, with a Z suffix — 2026-09-01T00:00:00Z — or as a unix timestamp. A timestamp with no offset is read as UTC by the server, so a local-time value such as 2026-09-01T14:00:00 schedules the offering at a different moment than you intended. Every newInvest in that gap reverts with IssuanceNotStarted.
startDate is validated against the timestamp of the block that mines the STO transaction. Set it at least 10 minutes after the time you expect to send the transaction, rather than from the prepare time. This buffer covers signing, broadcast, and block inclusion; an elapsed startDate makes the transaction revert on-chain. There is no minimum offering duration. A short window is a legitimate way to exercise close and claim in testing.

One ongoing offering per token

A token can have only one offering in the ONGOING state. Preparing a second returns Tokenizer already has an ongoing STO.
An offering cannot be cancelled, and it cannot be closed before its endDate has passed. A mistake in newSto therefore blocks that token until the window elapses. Use a short endDate on test offerings so you can close and recreate quickly.

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. Once the offering is live, see newInvest, then closeOffer and claimTokens for the rest of the lifecycle.

Authorizations

x-api-key
string
header
required

Body

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

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

Available options:
newSto
Example:

"newSto"

chainId
string
required

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

Example:

"aa36a7"

signerAddress
string
required

Required. Tokenizer wallet that signs the offering creation.

Example:

"0x742d35Cc6634C0532925a3b844Bc454e4438f44e"

tokenizerEmail
string<email>
required

Required. Email of the tokenizer that owns the token. The token must not already have an ongoing offering; a second one is rejected with Tokenizer already has an ongoing STO.

Example:

"tokenizer@example.com"

tokenSymbol
string
required

Required. Symbol of the token offered. The token must already be deployed on chainId.

Example:

"EXMPL"

offeringName
string
required

Required. Name of the STO offering.

Example:

"Series A"

tokenAmount
string
required

Required. Number of tokens offered in the STO. This is the field some clients call totalTokensOffered, which is not accepted.

Example:

"1000"

acceptedCoin
string
required

Required. Symbol of the payment token accepted for investments. It must be supported on chainId. This method does not accept paymentTokenSymbol.

Example:

"USDT"

startDate
string<date-time>
required

Required. STO start date, as explicit UTC with a Z suffix or a unix timestamp. A timestamp with no offset is read as UTC. It must be in the future when the transaction is mined and earlier than endDate; set it at least 10 minutes after the planned send time.

Example:

"2026-09-01T00:00:00.000Z"

endDate
string<date-time>
required

Required. STO end date, as explicit UTC with a Z suffix or a unix timestamp. There is no minimum offering duration, but the offering cannot be closed before this date has passed.

Example:

"2026-12-31T23:59:59.000Z"

minRaiseUSD
string
required

Required. Minimum raise amount in USD. This is the offering's soft cap: an offering that ends below it enters rollback and refunds investors instead of delivering tokens.

Example:

"10000"

maxRaiseUSD
string
required

Required. Maximum raise amount in USD. Token price is derived as maxRaiseUSD / tokenAmount; there is no tokenPrice input.

Example:

"100000"

minInvestment
string
required

Required. Minimum investment amount.

Example:

"100"

maxInvestment
string
required

Required. Maximum investment amount.

Example:

"10000"

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