Supply allocation and liquidity after deploy
On the Robinhood rail, total supply is minted once at deploy to disclosed recipients. Opening a market is optional, explicit, and never implied by a green deploy receipt.
The short answer
Choose total supply and decimals carefully—they define the unit of the entire token forever on that contract. Split initial mint across up to four disclosed addresses that sum to 100%. Renounce ownership at deploy if you want a fixed-meme posture. Verify source. Only then decide whether to seed a pool with deliberate size and quote asset.
Multi-recipient allocation
Constructor mint is the cleanest disclosure: amounts are fixed in the deploy transaction. Use separate addresses for treasury, team, and ops only when each wallet is real and controlled by the party you name. Empty “team” slots filled with the deployer address are not multi-party allocation—they are self-allocation with extra labels.
Renounce ownership
Renouncing at deploy removes owner-gated control if the contract was written that way. For TrenchablesERC20 fixed-supply tokens, renounce is the default recommendation when you claim there is no post-deploy mint path. Leave ownership only if you have a written reason and accept the trust cost of an owner key.
Verification
Download the verification package from the receipt panel. Submit source on the Robinhood explorer with the optimizer settings and ABI-encoded constructor args from that package. Unverified bytecode is not automatically malicious—but it raises the cost for every honest reader.
Liquidity as a separate stage
Deploy creates an address and balances. A pool creates a price surface. Trenchables can prepare Uniswap V2-style approve + addLiquidity transactions when venue addresses are configured; both are separate signatures from deploy. If the product says venue is not configured, treat liquidity as fully out-of-band and document where you will seed it.
Related network primer: how tokens launch on Robinhood Chain.
Primary and official sources
Next