Offerings lists every token sale across the organisation, and each sale opens a screen where you fund it, activate it, pause it, finalise it and settle the result. Each sale is a contract-governed first sale of a token that already exists, from the issuer to investors, at prices the issuer fixed per payment currency. A sale has a soft cap, the minimum that makes the raise a success, and a hard cap, the most it sells. Once it ends, someone finalises it, which records success or failure. Trading is where a token changes hands afterward, at the price an order book gives, and Issue asset creates the token itself.
The same sale shows two different screens depending on who opens it. The list under Asset lifecycle and the operating console behind it belong to accounts with the system role “Permission manager” or “Asset manager”, and to the Offering admin and Funds manager of a sale, who see only the sales they hold a role on. An account with none of these roles sees “Access restricted”. An investor meets the sale through its own subscription view instead: an overview with a “Subscribe” control, plus tabs for their investment, their activity, pricing and documents. The operating console shows the whole raise, and it also shows your own vesting position read-only when the account operating the sale holds one. The Primary Offering concept page explains the sale and settlement model.
The Offerings list shows every offering of the organisation, with the “Create offering” button for roles that may create one.
Steps
Open the offering list
In the Console, open “Asset lifecycle”, then Offerings. The page lists sales across the organisation, with filters for status, attention, token and currency. An account with the “Permission manager” or “Asset manager” role also sees an “Insights” tab beside it, which Read the offerings insights describes.
A live sale ending within 30 days shows the time left under its date in the “Ends” column, for example “in 25 hours” or “in 3 days”. The count never rounds up: under two days it counts whole hours, and from two days on it counts whole days. A row's details sheet lists its start, presale end and end as a date and a time in UTC. In the list, a sale that starts and ends on the same UTC day shows a date and a time in UTC in its “Ends” and “Starts” columns, so two such sales on one day can be told apart. Every other sale shows the date alone.
A row carries at most one flag in the Attention column, and it marks a sale that needs a decision. When more than one applies, the row shows the first in this order:
- “Near hard cap” shows while a presale or public sale has sold 90% or more of its hard cap.
- “Presale ended” shows when a sale still in its presale phase has passed its presale end time.
- “Awaiting finalization” shows when the sale end time has passed and nobody has finalised the sale.
- “Refund grace window” shows for 30 days after a sale fails.
The Needs attention card on the “Insights” tab lists the same sales and offers “Finalize”, “Move to public” and “Review”.
Create an offering
From the list, select Create offering and complete the wizard. Once you choose the token, the wizard reads your Governance role on it. “Checks before signing” on the Review step confirms the role, and already shows on every step while the role is missing or cannot be read. “Subscription step”, the unit every buyer's running total must be a whole multiple of, opens only when you hold Offering admin on that token. Without that role the field says so, and you use “Set subscription step” on the offering once you hold it. If the Console cannot read your roles on the token, the field stays open and the Governance check blocks signing until the roles can be read. In “Token and pricing”, the Currency picker lists eligible payment tokens. It does not list people or the sale token itself, and its “Recent” list shows only tokens, never a wallet address you picked in another field. If you dismiss the picker without choosing, the field reports “Select a payment currency.” The wizard rejects selecting the sale token as its own payment currency before wallet confirmation. The Review step shows the same end time that appears on the created offering's Schedule, including windows that cross a daylight-saving change. “Checks before signing” also asks the platform whether it would accept the offering as entered. It runs when every step is complete and valid. A refusal, for example a wallet that does not hold the Governance role on the token or a start time that is not after the next block, shows as a blocked check with its reason and fix, and signing stays off, so you learn it before the PIN. The check creates nothing and signs nothing. The platform checks again when you sign. If the check cannot answer, it does not block you and the creation returns its own refusal.
The “Create offering” wizard opens on its first step, “Token and pricing”.
Open an offering
Select a sale to open its operating console. The banner reads the sale's current state, funding, and soft cap position. The tabs cover the overview, purchases, currencies, whitelist, vesting, marketing, and permissions. The overview links the sold token to its token page when your organisation issued it, and to its external token page otherwise. Cap table is the one tab that appears only when your account holds Offering admin or Funds manager on the sold token.
The overview tab charts the commitments over time against the soft and hard caps, with a dashed projection to the close once the sale has run for 14 days. Below it, a sale manager sees the offering funnel. Read the commitments chart explains both.
Run the operation the sale's state offers
Open Actions and pick the control the sale's state offers. A sale moves from setup to active to ended in one direction only. Setup offers funding, terms, the subscription step, and activation. An active sale offers transition, pause, resume, extend, and end. An ended sale offers finalisation. A final sale offers the withdrawals. “Finalize offering” shows from the presale on and stays disabled until the sale has ended or its end time has passed, also while the sale is paused. The Console asks for wallet verification before each on-chain signature. The menu lists only the entries your sale roles cover.
An equivalent flow exists for integrations: the token sale endpoints drive creation, activation, purchase, finalisation, refunds, and withdrawals.
Fund and activate an offering
The creation wizard fixes the commercial terms of the sale. It sets the token, the payment currencies, and the price in each currency. The wizard also sets the caps, purchase limits, and the optional presale with its discount and per-address cap. An optional vesting schedule delays delivery of purchased tokens and releases them over time. No Console screen and no Platform API endpoint changes these terms after creation. An Offering admin can still call the sale contract's setters directly while the sale is in setup, so check the terms the contract reports before activation.
During setup, “Actions” offers two more settings:
- Set terms records the hash of the terms documents you uploaded to the sale. While an uploaded terms document is not recorded, “Activate offering” stays disabled and says so. Terms can be recorded only once.
- Set subscription step changes the step that every buyer's running total must be a whole multiple of, and 0 switches the rule off.
Both are offered only during setup. An Offering admin can add, remove, or import presale addresses on the Whitelist tab at any time, but whitelist edits do not affect public-sale eligibility after the presale ends.
To reduce what one investor may take after you build your book, set a per-investor allocation in the “Allocation caps” section below the whitelist table on the “Whitelist” tab. Select Set cap to cap a wallet, or “Change cap” or “Remove cap” on a row. The cap covers every wallet of that investor. You can change it after activation until the sale takes no more purchases. The token sale endpoints set the same allocations.
What this screen does own in setup is funding and the go decision. A sale that takes direct purchases must hold the full hard cap in tokens before activation, and the banner states whether it does. While an unfunded sale still takes direct purchases, the banner also says to set application mode before funding when the offering should take applications. A sale in application mode holds none of the offering and takes no funding. Its settlement mints each allocation, so activation needs the sale's own address to hold the Supply management role on the token. For such a sale the banner asks for that grant instead of funding: on the token's Permissions tab, grant the offering's address Supply management, then choose “Activate offering”. Until the screen has read whether the sale takes applications, the banner shows a placeholder rather than either instruction.
Fund offering mints the shortfall it reads to the contract, so a partially funded sale is topped up. The entry shows to an Offering admin or Funds manager on the token, and the mint itself needs the token's Supply management role, because the mint happens on the token. “Activate offering” then enables the sale under its configured schedule, and setup is over: after purchases begin, the contract holds investor payments and the path in How an offering moves through its states governs.
Activation and opening are separate moments. Activate before the configured start time and the sale stays closed to buyers, with a banner naming the exact date it opens. A purchase attempted early reverts on chain whatever any screen shows, so activating ahead of the start opens the sale at the configured time.
Pause, extend or end an offering
An active sale needs no operator input. Where a presale is configured, it rolls into the public sale on its own when the configured presale end passes. A sale with no presale starts in public sale. Either way, the sale stops taking purchases at its end time. A full hard cap does not end the sale: further purchases are refused, and the sale still waits for its end time or for “End offering” before it can be finalised. The presale can use a discounted price and its own per-address cap. It also requires the buyer to be whitelisted. Public-sale buyers still need to meet the offering's other eligibility rules. Whitelist edits made after the presale has passed change nothing about who can purchase, and the Whitelist tab warns about this once the offering has moved past presale.
Four controls interrupt that schedule, and each carries a different cost:
- Transition to public sale ends the presale early, and it is available only while the sale is in its presale phase.
- Pause offering stops new purchases on this sale only: nothing changes for the token itself, for its transferability, or for any other instrument that trades it, and “Resume offering” reopens purchases where they left off.
- Extend offering moves the end date later by a whole number of days, while the sale is active or paused. When vesting is configured, the end date cannot move past the vesting start.
- End offering ends the offering permanently. There is no resume from it, so it is the one control here whose cost is irreversibility, and the confirmation says so before you sign.
Read why a purchase is blocked
Before an investor reaches a purchase at all, the Console evaluates their eligibility and shows one of three verdicts:
- Eligible means the current pre-check found no blocker. State can change before execution.
- Action required means every blocking reason is one the investor can resolve, such as an unverified identity or a missing, revoked, or expired claim, and the Console routes them into that flow directly.
- Not eligible names a rule only an administrator can lift.
A blocked investor can still open Subscribe and inspect the purchase sheet. Its submit control remains disabled until the eligibility blockers clear.
The purchase form validates before it submits. The form checks the first-purchase minimum, the subscription step, the cumulative buyer maximum, and any presale cap. Returning buyers can top up below the first-purchase minimum, but every top-up must keep the running total on the subscription step. A per-investor allocation is checked on chain only. An amount beyond the sale's remaining headroom is reduced to that headroom, with a notice. The sale contract takes the payment from the buyer's wallet, so the buyer first approves the sale to spend it, then submits the purchase. The buy flow asks for that approval only when the existing allowance is too small.
When a purchase still reverts on-chain, the Console tells the buyer two things. The spend approval is in place, so approving again is wasted effort. And the sale contract refused for a specific, named reason. The named reasons are the contract's own. The buyer was not eligible, was not on the whitelist, or had not accepted the terms. The sale contract sits on the system's compliance bypass list, so the token's transfer check does not stop tokens moving into it, and these eligibility checks run on the buyer. The purchase would have crossed the hard cap or the buyer's own maximum allocation. The sale had not started, was not active, or its soft cap rule blocked the operation.
Run a book-built offering
An offering can take applications instead of direct purchases. While the offering is in setup, an Offering admin selects Set application mode in the “Applications and allocation” section of the “Purchases” tab. Set it before “Fund offering”. A sale that issues its shares at settlement holds none of the offering, so once such an offering is funded the section no longer offers “Set application mode” and says why: switching it on would issue each share twice. The offering then takes direct purchases. To take applications, create a new offering and set application mode before you fund it. A sale whose contract delivers the tokens it holds can still switch after funding. Application mode cannot be changed after activation, and an offering activated without it takes direct purchases only.
In application mode, investors apply with an escrowed payment that may exceed what the offering can deliver. The section lists each “Applicant” with the “Payment amount”, the “Tokens requested”, the allocation and refund, the “Status”, and the “Lock-up”. Until the allocation runs, the allocation and refund columns are projected from the current book.
After the sale ends and applications close, the Offering admin selects Request allocation and names the “Recipient of the payment”. One run allocates the closed book pro rata, rounded down to whole tokens, finalises the offering, and settles every applicant: each investor is charged the price of the tokens they were allocated, rounded down in their favour, receives those tokens and the rest of their payment back in the same step, an applicant whose tokens cannot be delivered is refunded in full, and the tokens lost to rounding stay unissued with the issuer. When the sale missed its soft cap, no allocation is made and every applicant is refunded in full. When the allocation does not start within 30 days after the sale ended, every applicant reclaims their own payment with “Reclaim payment”.
Two optional terms sit beside the applications table as the “Greenshoe” and “Lock-ups” cards. A greenshoe is extra supply the issuer may add when demand exceeds the hard cap, and a lock-up keeps delivered tokens from moving for a number of days. Only an Offering admin sets them, and only while the sale is in setup.
Set greenshoe, and “Change greenshoe” once one is set, asks for the size as a percentage of the hard cap, with up to two decimals and at most 655.35%. Zero removes the greenshoe. The exercise is “Automatic” or “Discretionary”. An automatic greenshoe covers the demand above the hard cap, up to its size, when the allocation starts.
For a discretionary greenshoe, an Offering admin selects Exercise greenshoe once the sale has ended and before the allocation starts. The amount is a whole number of tokens, at most the smaller of the greenshoe capacity and the demand above the hard cap. On a token with a supply cap, the room the cap leaves above the hard cap also limits it. An exercise happens once and its amount cannot change. It joins the book, so an allocation run requested earlier must be requested again. Starting the allocation without an exercise leaves the offering at the hard cap and the greenshoe can no longer be used. The book totals then show “Base offering”, “Greenshoe” and “Total offering”.
Set lock-ups, and “Change lock-ups” once they are set, takes up to eight categories. Each category is a claim topic, a type of verified identity claim, with a number of days, and “Days locked for other investors” covers everyone else. The first category the investor's wallet is verified for sets the lock-up, so list the longest first. The longest lock-up is 1,826 days and zero locks nothing. A sale with lock-ups needs the Governance role on the token for the sale's address and an active lock-up rule on the token, or the offering cannot be activated. Grant the role on the token's permissions page. A lock-up set where every duration is zero needs neither. After the allocation is delivered, the “Lock-up” column on each application shows the locked amount, “Unlocks” with the date, and the category, or “Other investors” for the default.
Request allocation opens the allocation run. It asks for the “Recipient of the payment”, and the wallet that signs the request needs both the Offering admin and the Funds manager role on the token. When offerings approval is on, a second person must approve the run, and the approval fails if the book changes before then.
Finalise an offering
A sale with no configured soft cap always finalises as a success. It records no payment per buyer, so investors have no refund claim on it. A sale with one finalises as a success only if total tokens sold reached it. Once the sale has ended, Finalize offering appears with a checklist beside it showing the soft cap status, the hard cap status, and the outcome those numbers predict. The checklist is a preview only. The on-chain finalise transaction is what decides and records the outcome. Until someone sends it, the sale sits in its ended state and every investor position stays undecided.
On a sale with a soft cap, a successful finalisation releases the tokens the sale held, on the vesting schedule when one is set. A sale without a soft cap does not wait for it: tokens transfer at purchase, or release on the vesting schedule. The server resolves the claimable figure each investor sees from the vesting schedule and any soft-cap hold. A zero after finalisation is always explained: the position sits before its vesting cliff, was already claimed in full, has not started vesting yet, or has nothing unlocked yet at this point in the schedule. Before finalisation, an ended sale shows a hold naming the undecided outcome, with the progress bar locked until the finalise transaction resolves it. Success also frees the issuer's own Withdraw funds: unlike a failed sale, there is no waiting period, so the funds manager can pull the raise the moment finalisation records success.
Refund investors and withdraw funds
Failure opens refunds, and refunds are per currency: each payment currency settles as its own independent transaction, because no single on-chain step refunds them all at once. Claiming all currencies from one verification step drives each one in sequence and reports partial progress as it goes. A currency that reverts keeps its failed status with the decoded reason inline, and does not roll back one that already settled. Only the failed currency needs a retry. When everything is claimed, the section says so instead of showing an empty table.
The issuer's own Withdraw funds comes last. After a sale finalises as failed, that withdrawal stays locked for thirty days from the moment of failure. After that, the issuer can pull only the balance above the refunds that investors have not claimed yet. On a sale that took purchases before it ran the current sale implementation, those earlier contributions are not reserved, and only the thirty-day wait protects their refunds. The withdrawal itself asks for a recipient: it defaults to your own wallet, and a treasury address routes the raise elsewhere. The sale's own token is never offered as a withdrawable currency, because the contract was never holding it on the issuer's behalf. Recovering unsold tokens is the separate “Withdraw unsold tokens” control.
Release a purchase the sale cannot deliver
A sale with a soft cap holds every buyer's tokens until a successful finalisation, and a buyer can lose the right to receive them in that time: the wallet is frozen, or the identity verification lapsed. A freeze by the token's custodian is enough, so the issuer's roles together can return a buyer's purchase to the unsold pool and refund the payment. The “Cap table” tab shows each buyer's delivery state. It names each buyer by the user, participant or contact that owns the wallet, a smart account included, and shows the wallet address when the platform knows no name. When the sale can no longer deliver to a buyer, a funds manager sees Refund undeliverable purchase on that buyer's rows. The release returns the undelivered tokens to the unsold pool and records a refund of the undelivered share of the payment, in every currency the buyer paid in. The row then reads “Refund recorded”, and “Pay out refund” pays one currency at a time to the buyer's wallet, or to the wallet that replaced it through identity recovery. A paid currency reads “Refund paid”. The token sale endpoints expose the same two steps.
A buyer can also lose the wallet itself. When identity recovery replaces a lost wallet, the sale cannot deliver to the old wallet, and nobody can sign from it. The cap table then shows Deliver to recovered wallet on that buyer's rows once tokens can be withdrawn. The sale never offers a release for a recovered buyer, so the buyer keeps the tokens they paid for. Before the first tokens vest, the rows show no action. It sends the tokens the buyer can withdraw now to the wallet that the identity registry names as the replacement. The vesting schedule still applies, so a vesting buyer gets each vested part the same way. Any wallet can send the delivery, because the sale takes the recipient from the identity registry and the caller cannot change it. The sale refuses the delivery for a buyer whose own wallet is not lost. That buyer withdraws as usual.
When a sale fails, the refund of a lost wallet's contribution cannot be claimed from that wallet either. The Platform API route POST /api/ takes the lost wallet and pays the refund to the replacement wallet that the identity registry names. The sale refuses it for a wallet that is not lost.
A sale with vesting and no soft cap records no payment per buyer, so it cannot calculate a refund and does not offer the release. When this sale cannot deliver to a buyer, for example because the wallet is frozen, the cap table marks the buyer's rows Undeliverable, held in sale. The tokens stay in the sale, and the buyer keeps the right to them. A regulated issuer decides each case outside the platform, for example under a sanctions rule or a court order, and settles any repayment or seizure there. When the issuer lifts the freeze, or the buyer is verified again, the buyer withdraws as usual. Do not use a forced transfer to move held tokens out of the sale: the sale still counts them as owed to the buyer, so the transfer leaves the sale short for that buyer or for the unsold pool.
Read the commitments chart
The overview tab charts what investors committed in each period and the running total, grouped by day, week or month depending on the sale's length, with the soft and hard caps drawn as reference lines. Every viewer of the operating console sees it.
A sale that is still open also shows a dashed projection to its close, labelled with the projected total. It carries the last seven full days' pace forward, slows it each week by as much as the last seven days fell against the seven before, never speeds it up, and stops at the hard cap, reaching the cap on the day that pace would fill it. The projection appears once the sale has run for 14 days and has commitments, and until then the chart says there is no projection. A sale that already reached its hard cap, or no longer takes commitments, shows none.
Below the chart, a sale manager sees the offering funnel, counting investors: Whitelisted, Committed and Settled for an offering with a presale, and Committed and Settled for any other offering. View as table on either chart lists the same numbers as text.
Read the offerings insights
The Insights tab beside the offering list summarises all the organisation's offerings. It appears for an account with the “Permission manager” or “Asset manager” role. Its range and comparison controls work as on asset Insights.
- Headline. When an offering closes within a week, a line over the figures reads, for example, “The next offering closes in 3 days.” It counts whole hours under two days and whole days from two days on, and never rounds up. Otherwise the line does not show.
- Key figures. “Raised (all offerings)” is the amount raised per payment currency, net of refunds, with the largest currency first and the others listed beside it. The amounts are never added across currencies. “Investors” counts unique buying wallets, so one person who buys from two wallets counts twice. “Soft cap reached” counts the offerings that reached their soft cap, out of all offerings. “Purchases” counts purchases in the selected range, with the change on the prior period.
- Needs attention. A card lists up to six offerings in this order, each with its button: awaiting finalisation with “Finalize”, which opens the offering to finalise it there, near the hard cap with “Review”, presale ended with “Move to public”, and inside the refund grace window with “Review”. “Show in list” opens “Offerings” filtered to those offerings. The card is absent when nothing needs attention.
- Composition and trend. The “Purchases” trend sits beside “Offerings by status”. “Sold vs hard cap” shows up to eight offerings, with a tick on each bar for the soft cap. Beside it, “Investors by country” also says how many investors have no registered country.
The attention card and the status table read the 200 offerings with the latest start dates.
Roles and approvals
Two role systems meet on this screen. Organisation-wide system roles decide what you can open: “Permission manager” or “Asset manager” reaches the list of every sale and any sale's operating console. On-chain sale roles decide what you can sign: each entry under Actions requires a specific role held on the sold token's access manager, Offering admin or Funds manager for “Fund offering” and “Finalize offering”, Funds manager for “Withdraw funds”, and Offering admin for “Activate offering” and the remaining lifecycle controls. “Actions” lists only the entries your sale roles cover. An asset manager who was never granted a sale role can open every sale but sign none of its transactions. The offering then has no “Actions” menu. While the offering is in setup, its banner says your wallet lacks the Offering admin role. An Offering admin or Funds manager without an organisation-wide role still reaches “Offerings”, which then lists only the sales of tokens your organisation issued on which you hold that role.
The Permissions tab is where that gap closes: it assigns Offering admin and Funds manager on this sale without granting full token administration. “Manage roles” is enabled only for an account with the Permission manager role on the token. For everyone else it is disabled, and its reason names the permission managers who grant offering roles. The “Cap table” tab follows the sale roles too: it shows only to an Offering admin or Funds manager on the sale's token, the two roles its request answers to. Editing the “Whitelist” tab needs Offering admin specifically. The “Allocation caps” section on that tab shows to Offering admin and Funds manager, and only Offering admin changes it. “Fund offering” takes either Offering admin or Funds manager on the offering's token. “Activate offering” and the other actions keep their own role. Roles and permissions shows how a Permission manager of the token grants and revokes the two roles on this tab.
When your organisation turns on the “Offerings” row under Approvals on General, creating an offering, opening it, ending it and running its allocation wait for a second person, who sees the offering terms. The approver is an organisation owner unless the approval policy names other approver roles, and the person who made the change cannot approve it. The platform holds the transaction until the approval is decided. The sale contract does not check the approval, and the row is off until an owner turns it on. An allocation run under that approval starts only once it is approved, and the approval fails if the book changes before then.
How an offering moves through its states
Every offering moves one way through setup, active and ended, then success or failure. Pause and resume interrupt the active state, and an application-mode sale is finalised by its allocation run. In setup the issuer funds the sale contract and activates it. An optional presale admits whitelisted addresses under its own price and per-address cap, and the sale then moves to the public sale under the standard price. Without a presale, eligible buyers start in the public phase. When its end arrives, what happens next turns on one number: whether total tokens sold reached the soft cap, the minimum the issuer configured for the raise to count as a success.
A sale moves from setup to active to ended, and finalising records success when the soft cap is met or none is set and opens refunds when it is missed.
Troubleshooting
Offerings is missing or says Access restricted
Your account holds neither the “Permission manager” nor the “Asset manager” system role, and no Offering admin or Funds manager role on a token your organisation issued. Ask an organisation administrator for one of those roles, or ask a permission manager on the token to grant you a sale role from the sale's Permissions tab.
Create offering is missing or disabled
The control needs two things at once: the “Asset manager” role, and at least one token your account governs, because creating an offering needs the Governance role on the token you sell. The wizard lists every token, then checks Governance on the one you choose and blocks signing until you hold it there. Without the role, the control is disabled and its reason says that asset managers create offerings. With the role but no governed token, the control is disabled and names the Governance role. Ask an administrator for the role, or for governance on the token you intend to sell.
Activate offering is disabled or refused
An uploaded terms document whose hash is not recorded keeps it disabled: select Set terms first. A sale that takes direct purchases must hold the full hard cap: select “Fund offering”. A sale in application mode needs the sale's own address to hold the Supply management role on the token, and a sale with lock-ups needs the Governance role on the token for the sale's address and an active lock-up rule on the token.
Actions is missing or lacks an entry
You opened the console through an organisation-wide role, but the entries need an on-chain sale role on the sold token. Without Offering admin or Funds manager the offering has no Actions menu. With one of them, the menu lists only the entries that role covers: Fund offering and Finalize offering take either role, Withdraw funds needs Funds manager, and the other entries need Offering admin. Have a permission manager on the token grant the role from the sale's “Permissions” tab, then retry. The grant is an on-chain transaction, so allow it to settle first.
A purchase reverts after the spend approval already succeeded
Do not approve again for the same attempt: the toast already confirms the spend allowance is in place, and the failure is the sale contract's own decoded refusal. Match that reason against Read why a purchase is blocked, clear the underlying condition, an eligibility, whitelist, or terms gap, the sale's own numbers, or its timing, and resubmit the same amount.
A vesting position shows nothing claimable
The tile's status label names the reason. Before finalisation it reads “Pending finalization”. See Finalise an offering for what unlocks it. After a successful finalisation it reads one of “You can claim from” followed by the cliff date and time in UTC, Fully claimed, “Not started”, or “Nothing claimable yet”, each resolved on the server from the vesting schedule.
A refund claim fails for one currency
The usual cause is the refusal “No contribution to refund, so no money moved”: the sale holds no contribution from this account in that currency. The payment was already refunded or reclaimed, or it was paid from another account or in another currency, so the row is stale. No money moved. Refresh the page and check the account's balance instead of retrying. Other failures include token restrictions or too little refundable balance. Read the reason and the prior transaction outcome before retrying. Keep currencies that already settled unchanged.
Withdraw funds is locked on a failed sale
The refund grace period is running: for thirty days from the moment the sale failed, the contract protects the refund pool and refuses the issuer's withdrawal. Wait out the window. After it, the issuer can withdraw only the balance above the refunds that investors have not claimed yet, so a withdrawal can return zero while refunds stay unclaimed. The sale's own token also never appears among the withdrawable currencies. Recover unsold tokens through “Withdraw unsold tokens” instead.
Frequently asked questions
Can investors pay in more than one currency?
Yes. A sale lists one or more payment currencies, each with its own price in that currency, and every purchase spends exactly one of them. One investor can buy several times in different currencies, which is why a failed sale refunds per currency rather than in one combined amount: each currency's contribution is tracked and returned in its own units.
Does pausing a sale change its schedule?
No. The start and presale end times are fixed at creation, and the clock keeps running while purchases are stopped. A pause spends part of the sale window rather than extending it, so a long pause near the end can leave little or no time to buy after “Resume offering”. To give buyers that time back, use Extend offering to move the end date later. “End offering” stops the sale early, and it does so permanently.
What happens to tokens that never sold?
They stay in the sale contract until a sale administrator recovers them with Withdraw unsold tokens, which the Console offers once the sale is finalised in either direction. Through the token sale endpoints, the withdrawal also works on a sale closed with “End offering” before finalisation, including a sale that was never activated. A sale that takes direct purchases must hold the full hard cap before activation, so one that ends short of that cap holds unsold tokens worth reclaiming. An application-mode sale holds none of the offering, because its settlement mints each allocation.
What happens to a live sale during a stock split?
A sale that holds the offered token keeps running, re-based. Purchases so far, the remaining inventory, the price and the per-buyer limits move by the action's ratio, and the sale's holdings follow the units the action mints or burns for it. From the action's record date until its step lands, the sale is frozen for that token: purchases, allocation, delivery, claims, refunds and withdrawals are refused with a message that names the token and the action. Buy, claim or refund again once the action has finished. See corporate actions for how the freeze starts and ends.
Who can see who the investors are?
The Purchases tab shows buyer wallet addresses to anyone operating the sale. Resolved identities, names, KYC status, and country, appear only in the “Cap table”, whose request answers solely to a sale administrator or funds manager on that sale. In the Console, an investor's subscription view shows only their own purchases.
Can the terms document change after investors accept it?
No. The platform records the terms hash on-chain once, during setup, and refuses a second set-terms call. The sale contract accepts a hash only while the sale is in setup, and investors can acknowledge only after a hash is recorded. Each acknowledgement event carries the hash it accepted. A buyer must acknowledge terms when the sale requires them. Retain the accepted hash and acknowledgement event as evidence.
How do I replace a brochure or another offering document?
On the “Marketing” tab, open the document's menu and choose Upload new version. The dialog keeps the document type and starts with the current visibility, title, and description, and you choose the replacement file. After the upload, the new file is the current version and the earlier version stays in the list. The menu offers the action only on the current version, and only to an account that can delete that document. A terms document takes a new version only while the sale is in setup and before its hash is recorded.