# Digital Asset Initial Offering

Source: https://docs.settlemint.com/docs/architecture/flows/daio-offering
How a DALP Digital Asset Initial Offering models primary distribution through a token sale configuration, investor participation, settlement, refunds, and vesting.




## System context [#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.

<Mermaid
  chart="`
flowchart LR
  Issuer[Issuer]
  Token[Issued EVM asset]
  Sale[DAIO token sale]
  Investor[Investor wallet]
  Currency[Accepted payment currency]
  Terms[Terms hash and acknowledgement]
  State[Sale state and chain clock]
  Vesting[Vesting schedule]
  Refund[Refund path]

  Issuer --> Token
  Issuer --> Sale
  Token --> Sale
  Currency --> Sale
  Terms --> Sale
  State --> Sale
  Investor -->|buy| Sale
  Sale -->|tokens or vesting claim| Investor
  Sale -->|payment funds| Issuer
  Sale -->|soft cap not reached| Refund
  Sale --> Vesting

`"
/>

## Offering model [#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 [#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 [#investor-participation-flow]

<Mermaid
  chart="`
sequenceDiagram
  participant Investor as Investor wallet
  participant DALP as DALP token sale API
  participant Sale as Token sale contract
  participant Chain as Active EVM chain

  Investor->>DALP: Acknowledge terms when required
  DALP->>Sale: Record terms acknowledgement
  Investor->>DALP: Buy amount with accepted payment currency
  DALP->>Sale: Submit purchase transaction
  Sale->>Chain: Check sale state, limits, presale, currency, cap
  alt Purchase accepted
      Sale-->>DALP: Transaction hash and indexed sale update
      DALP-->>Investor: Participation recorded
  else Purchase rejected
      Sale-->>DALP: Contract error
      DALP-->>Investor: Error response
  end

`"
/>

A participation request depends on current sale rules and network state. The contract checks five things before it accepts a buy transaction:

1. The sale is active.
2. The payment currency is allowed.
3. The requested amount fits the configured limits and caps.
4. Presale restrictions, if present, allow the investor wallet.
5. 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-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 [#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 [#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 [#related]

* [Architecture flows](/docs/architecture/flows)
* [Token sale capability](/docs/architecture/components/capabilities/token-sale)
* [Asset policy](/docs/architecture/concepts/asset-policy)