Place a new issue only with investors the token's own rules admit, and settle a fund's dealing days at its NAV. A placement run from spreadsheets and email checks eligibility after the money arrives, and every mistake becomes a refund someone has to chase. In DALP 3.2 a purchase the token's rules refuse takes no money, and a raise that misses its minimum keeps every refund owed in the contract until it is paid back.
One sale contract takes the payment, checks the buyer, allocates and then delivers or refunds
Issuers run the raise from Offerings in the Console, investors subscribe from the Console or the Investor portal, and fund operators settle each dealing day. Eligible means what the token's compliance rules admit, and your institution still sets the legal offering terms, the investor disclosures and the price.
- Eligibility
- Token's own rules, in the payment transaction
- Book-building
- Greenshoe and lock-ups by category
- Failed sale
- Refunds held back from the issuer
- Fund dealing
- Daily cut-off at 12:00 UTC, priced at NAV
Before and after
Before 3.2: eligibility was checked by hand against a list, payments arrived before anyone knew whether the buyer could hold the security, and a refused or failed placement meant refunds chased one investor at a time. Lock-ups lived in a side letter and the transfer agent's notes, and a fund's subscriptions and redemptions were priced and booked outside the register.
With 3.2: A purchase the token's compliance rules do not admit fails in the transaction that would take the payment, so no money changes hands. A book-built offering can fill an oversubscribed book with a greenshoe and lock each investor category on the token itself. A failed sale keeps every refund owed in the contract for its investor, and a fund's dealing day prices every open request at the fund's NAV.
An offering runs from the administrator's terms through presale and public sale to delivery or refund, with every purchase checked in the payment transaction.
Refuse an ineligible buyer before the money moves
An optional presale admits only buyers on the sale's allow list, at the discount, and the public sale that follows admits any buyer the token's compliance rules admit who has accepted the sale's terms, when it has any. The sale checks the token's compliance rules, the per-buyer limits and the remaining hard cap in the transaction that takes the payment. A refused purchase reverts, so the buyer pays nothing and there is no refund to chase. An investor in a country the offering does not admit opens it in the Investor portal and sees the Subscribe button turned off with a message that their country is not admitted, and an investor who lacks a verification the token requires sees Complete verification instead. An offering with recorded terms keeps its data room locked until the investor accepts them, and the acceptance is recorded on the sale contract. The portal also compares the payment, after any reduction to the remaining hard cap, with what the investor's wallet holds before Review: a purchase or application the wallet cannot pay stays on the amount step with both figures, and so does an application outside the offering's minimum, maximum or subscription step, so the investor never enters a PIN or signs the terms for it. The portal's early check cannot see rules that depend on balances or counts, such as an investor-count limit, so the check in the payment transaction is the one that decides, and a wallet that a compliance manager, or one of DALP's own factories, puts on the compliance bypass list skips the token's transfer checks.
The offerings desk shows each sale's status, how much it has sold and how much it has raised.
Fill an oversubscribed book with a greenshoe and lock-ups by category
A book-built offering takes applications, and a greenshoe grows the offering past the hard cap by up to the percentage set in its terms, either automatically when the allocation starts or when the offering administrator exercises it after the application window closes. In DALP the greenshoe is extra allocation capacity, and the platform runs no price stabilisation. The allocation run then divides the hard cap plus the greenshoe between the applicants pro rata to their demand, and its preview shows the base offering, the greenshoe and the total. The offering administrator reviews that preview before the run, and the run itself divides pro rata. The same offering can lock allocations by investor category, read from the claims on each investor's identity: for example 180 days for qualified institutional investors and 90 days for everyone else, or part of an allocation at three months and the rest at six. The sale contract records each lock in the token's lock-up rule in the same transaction that delivers the allocation, so the token itself refuses an early transfer and nobody depends on a side letter. The token's governance role can clear a lock, and a forced transfer skips the transfer rules by design, lock-ups included. Only a book-built offering on the 3.2 sale contract takes a greenshoe or category lock-ups.
See which sale needs a decision before it hits its cap
The Offerings list shows every sale in your organisation and flags the ones that need a decision: a sale at 90% of its hard cap, a presale past its end time, a sale waiting for finalisation and a sale in the 30 days after it failed. Each sale's overview shows what has sold against the hard cap, the soft cap when there is one, and the terms on record. An offering administrator who sees a sale near its cap decides whether to close it before the hard cap refuses the next buyer. The flags use fixed thresholds, and the decision to price, extend or close a sale stays with your team.
Refund every investor when the minimum raise is missed
A minimum raise, the soft cap, is optional. When a sale has one, buyers receive their tokens only once it finalises as successful, and when it misses, each investor gets their money back in the currency they paid. In a direct sale each investor claims their refund, and in a book-built offering the settlement run returns every escrow. On the 3.2 sale contract a refund has no deadline, and the issuer can withdraw only what is left over the refunds still owed. An issuer whose bond placement falls short has nothing to unwind by hand. Payments a sale took before it moved to the 3.2 sale contract are held back only for 30 days after the sale fails.
Settle a fund's dealing day at its NAV
An open-ended fund takes requests on each dealing day, Monday to Friday, with a cut-off at 12:00 UTC. Before the cut-off an investor asks to subscribe a cash amount in the fund's stablecoin or chooses Request redemption for a number of units, and can cancel the request until then. A supply manager settles the day: subscriptions are priced at the latest NAV the class price feed published after the cut-off, and a day with no such NAV is refused rather than priced at zero.
For redemptions, Settle dealing day prices each open request at the NAV and drafts a buyback that burns the units and pays the investor, which waits for a second approver when your organisation turns on the approval rule for corporate actions. The fund's register and its cash move together from the same NAV, with no separate booking to reconcile. The dealing calendar is fixed, with no holidays and no other cut-off. Subscriptions settle through the API with no approval step.
Mirror a share class whose register sits with an administrator
A fund whose legal register sits with a transfer agent or administrator can mirror each share class on chain. Units move only when the administrator books a movement with its register reference, and the token refuses every other transfer, mint or burn. An investor asks for a subscription, transfer or redemption, and the administrator books it against the register entry, which releases any hold and moves the units in one step. The token follows the register only while its booked-movements rule is installed, and its governance role can remove that rule, after which the token no longer follows the administrator's register.
Refund a failed sale to a recovered wallet
A failed sale refunds a lost wallet's contribution to the wallet that replaced it through identity recovery. The recovered- route takes the lost wallet and pays the replacement wallet that the identity registry names.
Upgrading
After the upgrade every organisation can run offerings, where 3.1 shipped them off. The same operator decision covers corporate actions and dividends, so an operator who keeps offerings off on a deployment turns those off too, as Decide on the offerings surfaces describes. An organisation still installs the offering contracts on its system before its issuers see the offerings pages. Sales created on 3.1 keep their address and terms, and run the 3.2 sale contract once the organisation runs System updates. The greenshoe and category lock-ups need that contract and a book-built offering created on it, and the share-class mirror needs the booked movements factory that System updates installs.
Why it matters
- Banks: A placement for your clients refuses an ineligible buyer before the money moves, and a failed raise keeps every investor's refund in the contract until it is paid back.
- Exchanges, CSDs and market infrastructures: A book-built offering carries a greenshoe and category lock-ups that the token itself enforces after listing.
- Regulators: the sale contract records each purchase, acceptance and allocation, and the token holds each lock until it ends or its governance role clears it.
- Partners: A fund administrator keeps the legal register, and the on-chain class follows its booked movements.