An IDO launchpad on Cardano cannot simply port an Ethereum sale contract. Cardano uses an extended UTXO (eUTXO) model in which a piece of on-chain state can be consumed by only one transaction at a time, so a sale that thousands of people join in the same minute needs a batching design. Tokens are native to the ledger, which removes the token contract but changes how sales and vesting are built.
What is different about Cardano
Native tokens instead of token contracts
On Cardano, a fungible token is defined by a minting policy, a script or rule that decides when tokens can be minted or burned. Once minted, tokens move like ADA in ordinary transactions with no contract call. That is safer in some ways, since there is no transfer function to exploit, but logic you might put in an ERC-20, such as transfer fees or blacklists, does not exist. Fix supply by using a time-locked minting policy that expires after the initial mint.
Validators instead of contract accounts
Smart contracts are validators: scripts that approve or reject spending a UTXO locked at their address, given the UTXO's datum (state) and a redeemer (action). Most logic, such as building transactions and selecting inputs, runs off-chain in your app; the chain only checks that the result is valid. Validators are commonly written in Aiken today, with Plutus (Haskell), Helios and OpShin as alternatives. See the Cardano developer portal for the current toolchain.
Concurrency
If your sale keeps a single "total raised" UTXO, only one contributor can update it per block, and everyone else's transaction fails. Cardano DEXs such as Minswap and SundaeSwap solved the equivalent problem with an order-and-batcher pattern, and launchpads use the same idea.
A batcher-based sale design
- Contribution orders. Each participant locks ADA or a stablecoin at an order script with a datum recording their address, amount and allocation proof. Many people can do this in parallel because each creates their own UTXO.
- Batching. An off-chain batcher collects orders and submits transactions that consume several at once, updating the sale state and checking caps.
- Allocation and refunds. For overflow sales, the batcher or a settlement step computes pro-rata allocations and returns excess.
- Distribution. Tokens are sent to buyers directly or locked in per-user vesting UTXOs that unlock after a POSIX time, enforced by the transaction's validity interval.
- Liquidity. A share of ADA and tokens seeds a pool on a Cardano DEX, with LP tokens locked at a time-locked script.
The batcher must not be able to steal or misdirect funds. Each order validator should only permit spending that pays the user's allocation or refund to the address in the datum. Users should also be able to cancel their own orders if batching stalls.
Other Cardano-specific details
- Minimum ADA per UTXO. Every output carrying tokens needs a minimum amount of ADA. Factor it into vesting outputs and refunds so small allocations are not swallowed.
- Time. Validators do not read a clock; they check the transaction's validity range. Design sale windows and vesting with that in mind.
- Reference scripts and inputs. Publishing scripts once and referencing them cuts fees and transaction size significantly.
- Wallet connection. Browser wallets such as Lace, Eternl and Yoroi expose the CIP-30 API for signing. Off-chain libraries such as Mesh or Lucid Evolution, plus indexers like Blockfrost or Kupo with Ogmios, handle transaction building and chain queries.
- Token metadata. Register name, ticker and decimals using the CIP-68 on-chain metadata standard or the token registry, so wallets and DEXs display your token properly.
ISPOs: a Cardano-native alternative
An initial stake pool offering distributes tokens to ADA holders who delegate to a project's stake pool, with the project keeping the staking rewards that delegators forgo. Participants never lock or send their ADA, which is attractive. But it is still a way of raising value in exchange for tokens, and should get the same legal scrutiny as any sale. It also requires running stake pools properly.
Security and auditing
eUTXO bugs look different from EVM bugs. Common issues include double satisfaction (one payment satisfying two validators), missing checks that outputs go to the correct address with the correct datum, unbounded datum sizes that lock funds, and minting policies that can be reused. Choose auditors with specific Cardano experience; general EVM audit experience is not enough.
Cost and timeline drivers
As a reasoned estimate, a Cardano launchpad with an order-and-batcher sale, vesting and a web app is a four-to-six-month project for three or four engineers with Cardano experience, plus a specialist audit. Fewer reusable open-source components exist than on EVM chains, and experienced Cardano engineers are scarcer, which raises cost. For comparison with EVM approaches, see the Ethereum IDO guide; for ecosystem context, the Cardano NFT marketplace guide covers similar UTXO design problems. General sale formats and vetting are in the launchpad buyer's guide.
Frequently asked questions
Do I need a smart contract to create a Cardano token?
No. Tokens are minted under a minting policy, which can be a simple native script. Sale, vesting and liquidity logic is where validators come in.
Why do Cardano sales use batchers?
Because a shared state UTXO can be spent only once per block, so parallel users would collide. Individual order UTXOs plus batching avoids this.
Which language should I use for validators?
Aiken is the most widely used choice for new projects because of its tooling and efficiency. Plutus suits Haskell teams.
Is an ISPO safer legally than a token sale?
Not necessarily. Regulators look at the economic substance: participants give up value in expectation of tokens. Get legal advice either way.