Digital Asset Initial Offering
How a DALP Digital Asset Initial Offering models primary distribution through a token sale configuration, investor participation, settlement, refunds, and vesting.
System context
A Digital Asset Initial Offering, or DAIO, sells a newly issued EVM asset through a configured on-chain sale. DALP binds timing, currencies, purchase limits, soft-cap handling, terms acknowledgement, presale access, and vesting to that sale contract.
Offering model
A DAIO uses the token sale capability for an issued EVM asset. The issuer creates a sale for a token address, then sets the operating rules:
- start time and duration
- hard cap
- ERC-20 currencies accepted for payment
- purchase limits, when needed
- soft cap, when needed
- vesting, when needed
- presale rules, when needed
- terms hash, when needed
Each sale has its own contract address. DALP reads the active chain context during sale listing. The response status combines indexed state with that network's clock. Presale timing uses the same rule. A PRESALE status moves to the public phase after the presale end time passes on that network. The list route does not aggregate status across networks.
Configuration boundary
The create operation defines the sale rules:
| Area | What it controls |
|---|---|
| Token address | The EVM asset sold by the offering. |
| Sale start and duration | When participation can start and how long the sale remains open. |
| Hard cap | The maximum token amount available for the sale, represented in raw token units. |
| Payment currencies | ERC-20 addresses accepted as payment, with a price ratio multiplied by 1e18. |
| Purchase limits | Optional per-investor minimum and maximum purchase amounts in raw units. |
| Soft cap | Optional minimum raise threshold. If the threshold is not met, the refund path is available. |
| Vesting | Optional start, duration, and cliff values, all expressed against chain time. |
| Presale | Optional early phase with end time, discount multiplier, per-address cap, and whitelist. |
| Terms hash | Optional bytes32 reference to the terms the investor acknowledges. |
Some controls stay available after creation. The issuer can:
- activate, pause, unpause, end, and finalize the sale
- configure vesting
- add or remove payment currencies
- update purchase limits, the soft cap, or the terms hash
- add or remove presale whitelist entries
Treat the sale contract as the execution source of truth. Treat the DALP API response as the indexed view of that truth.
Investor participation flow
A participation request depends on current sale rules and network state. The contract checks five things before it accepts a buy transaction:
- The sale is active.
- The payment currency is allowed.
- The requested amount fits the configured limits and caps.
- Presale restrictions, if present, allow the investor wallet.
- Required terms have been acknowledged.
Settlement is an on-chain purchase transaction against the sale contract. The platform returns an asynchronous blockchain mutation response. You should track the transaction hash and read the indexed sale state after confirmation instead of assuming a synchronous final state.
Presale, terms, and vesting
Presale is an early access phase. When enabled, the phase uses an end time, discount multiplier, per-address cap, and optional whitelist addresses. The issuer can add or remove whitelist entries through dedicated sale operations. After the end time passes, the list response treats the sale as public-sale state for the active network.
Terms acknowledgement is separate from sale setup. The sale can carry a bytes32 hash, and investors can acknowledge those terms before participating. The hash references the terms document. The hash is not the document itself.
Vesting is optional. When enabled, the sale records a start time, total duration, and cliff duration. The cliff cannot exceed the total duration. Use the token sale capability page for current operational details of vesting configuration and claim behavior.
Soft cap, close, and refund path
A soft cap sets the minimum raise threshold. When the issuer configures a soft cap, that threshold determines whether the sale can complete normally or whether participants can use the refund path after close.
The lifecycle exposes operations to end and finalize a sale, withdraw raised funds, withdraw tokens or unsold tokens, and claim refunds. These operations keep closeout explicit. Funds and tokens do not move as a side effect of the list or read routes.
Operational notes
- One active chain context: Token sale list responses are scoped to the active chain. Do not use one response as proof of state on another chain.
- Raw units: Token amounts and caps use raw units. Payment currency price ratios are multiplied by
1e18. - Chain time: Sale start, duration, presale end, and vesting times resolve against EVM chain time rather than a browser clock.
- Indexed view: Read and list routes return indexed sale state. Blockchain mutations return a transaction hash and require later confirmation through indexed reads.
- No native non-EVM sale path: The DAIO flow documented here is for EVM token sale contracts and ERC-20 payment currencies.
Related
Feeds update flow
End-to-end lifecycle of publishing, validating, and consuming feed values in DALP, covering both issuer-signed scalar feeds and Chainlink adapter reads.
Airdrop distribution flow
How DALP moves tokens from a funded airdrop contract to eligible addresses, including Merkle proof checks, claim tracking, strategy variants, and failure modes.