Supporting a creator after approval

The creator console you cannot act through — the dashboard, the capped Team and Roadmap tabs, the delivery and vesting desks, plan upgrades, and what to do when delivery stops.

13 min readUpdated 6 August 2026admin, creator, delivery, vesting, launch-plan

Approving an offering is the start of the creator's work, not the end of yours. From that moment they are running a sale on your platform with screens you do not share, and you are the person they call when a delivery will not record or a cap refuses them.

This page is the operator's map of those screens: what each one does, what it refuses and why, and what you can do about it from your side.

Every route under /api/ico/creator/token/[id] that moves money, records a delivery or adds content is matched on ownership of the offering, not on a permission. There is no key to grant that gets you in.

The routes that look up the offering by owner — adding a team member, adding a roadmap item, the plan upgrade, the offering itself — return 404 "Offering not found" for anybody else.
The delivery and vesting routes look it up first and then compare, so they return 403 "You are not the owner of this offering".

Both look identical to a Super Admin and to an ordinary user. You cannot record a delivery hash for a creator who has gone quiet, you cannot add a team member for one who cannot work the form, and you cannot post an update on their behalf. Your levers are on the admin side — verify, reject, pause, cancel — and they are the ones documented in Transactions and payouts and Reviewing offerings.

Four routes under that prefix are an exception, and they are a defect rather than a lever: editing and deleting an existing team member, and editing and deleting an existing roadmap item. Each of those four finds the row by its own id plus the offering id from the URL and then writes, with no ownership check of any kind — the offering is never even loaded. Any signed-in account that knows both ids can change or remove another creator's team member or roadmap entry. Nothing else is reachable that way: no contribution, no delivery, no plan and not the offering itself. It is not a supported route for helping a creator, and it is the answer when a creator reports team or roadmap content changing under them without their account having been compromised.

The read-only list endpoints for team members, roadmap items and update posts are not ownership-matched either, because that content is already public on the offering's page. Do not treat anything a creator puts in those three places as private.

The creator's screens

Screen	Path	What it is
Dashboard	`/ico/creator`	Overview, My Tokens, Investors
Launch form	`/ico/creator/launch`	The ten-step submission
Token simulator	`/ico/creator/token-simulator`	A modelling toy; writes nothing
Token page	`/ico/creator/token/[id]`	Team, Roadmap, Updates
Delivery desk	`/ico/creator/token/[id]/release`	Contributions and vesting tranches
Plan upgrade	`/ico/creator/token/[id]/plan/upgrade`	Change the launch plan

None of them carry a permission. Any signed-in user reaches /ico/creator; what they see there is whatever offerings they own, which for most of your users is nothing.

The dashboard

/ico/creator is fed by three endpoints, all scoped to the caller.

Counts and growth over the caller's own offerings

The funds-raised series behind the chart

Investors across all of the caller's offerings

The page shows total raised, active offers and a success rate in the hero, four detail tiles under it, and three tabs — Overview (chart plus their ICO notifications), My Tokens, and Investors.

The dashboard falls back to a launch your first token splash whenever the creator holds no ACTIVE and no PENDING offering — regardless of how much history they have.

The list behind it, GET /api/ico/creator/token, fetches every offering the caller owns and then sorts them into exactly three buckets: ACTIVE, PENDING and SUCCESS. Nothing is filtered out on the way in — a REJECTED, FAILED or CANCELLED offering is fetched like any other and then falls into no bucket, so it appears nowhere on My Tokens either.

A creator whose only sale failed, or whose only submission you rejected, sees the same screen as somebody who has never used the product. They have not lost anything — the offering, its contributions and its refunds are all still on /admin/ico/offer — but they cannot see it, so they will ask you.

Two things about those figures are worth knowing before you answer a question about them:

Total raised is SUM(price × amount) over every contribution to their offerings that is not REJECTED. Like the admin figure, it includes money that is still PENDING and money that has been REFUNDED, and it is not currency-converted. It is not "what I have been paid".
Success rate is ACTIVE ÷ total offerings. It is a snapshot of how many of their offerings are open right now, not a measure of how many succeeded. It falls when a sale ends, which surprises people.

The amber Pending approval banner on this page is what your review queue looks like from the creator's side. It appears whenever they hold any PENDING offering and it does not name a target date, so a creator who has been waiting four days has been told nothing except that you exist.

The token page and its three capped tabs

/ico/creator/token/[id] carries the project's public-facing content in three tabs. All three carry a launch-plan cap, but only two of the three are enforced by the server.

Tab	Endpoint	Cap	Refusal message
Team	`POST /api/ico/creator/token/[id]/team`	`features.maxTeamMembers`	Team member limit reached. Upgrade your plan to add more team members.
Roadmap	`POST /api/ico/creator/token/[id]/roadmap`	`features.maxRoadmapItems`	Roadmap item limit reached. Upgrade your plan to add more roadmap items.
Updates	`POST /api/ico/creator/update`	`features.maxUpdatePosts`, per calendar month — browser-side only	You've reached the maximum number of updates for this month on your plan.

The team and roadmap caps are counted against rows that already exist on the offering and compared with the plan the offering points at now, so they move the moment a plan upgrade lands. Edits and deletions are never capped — only additions.

The launch plan's feature blob carries maxUpdatePosts, the plan editor at Admin → ICO → Settings → Launch plans asks for it, and the creator's plan cards advertise it. The Updates tab counts the posts already made on that offering in the current calendar month, compares that with the plan's number and, once the creator is at the limit, disables both Post Update buttons and shows an amber banner with an upgrade link.

That check lives entirely in the creator's browser. No backend route reads maxUpdatePosts, so POST /api/ico/creator/update accepts an unlimited number of posts: the cap holds for anybody working the console and holds against nothing that calls the API directly. The month boundary is the browser's local one, not UTC. And the check fails closed — an offering whose plan cannot be loaded, or whose feature blob is malformed, leaves both buttons disabled, so a creator reporting a greyed-out Post Update with no posts this month has a plan problem rather than a cap problem.

The other three — maxTeamMembers, maxRoadmapItems, maxOfferingPhases — are enforced on the server, where a creator cannot get around them. The first two are checked on every addition; the third is checked only when the offering is created, so it constrains the launch form and nothing after it.

Once an offering is ACTIVE the page shows a standing amber notice: This token has been launched and basic information can no longer be edited, followed by You can still manage team members, roadmap, and updates. That is accurate — the name, symbol, price, dates and supply are yours to change from /admin/ico/offer/[id], not theirs.

The delivery desk

/ico/creator/token/[id]/release is where the creator records what they sent.

Contributions on this offering, filtered by status

Records a delivery hash for a WHOLE allocation

The page opens with four clickable tiles, each a true server-side count for that status, over the contribution lifecycle you already know:

Tile	Status	Means
Pending Release	`PENDING`	Paid, in escrow, nothing sent. The creator's work queue.
Pending Verification	`VERIFICATION`	Hash submitted, waiting on you
Released	`RELEASED`	You verified it; escrow paid out to the creator
Rejected	`REJECTED`	You refused it; the buyer was refunded

The PUT records one hash against one contribution and settles the entire allocation. It accepts a bare hash or a full block-explorer URL, extracts the hash from the URL, and validates the format against the offering's blockchain. On success the contribution moves PENDING → VERIFICATION, the buyer is notified that tokens are on the way, and the row lands on your desk.

It refuses in four ways, and these are the four questions you will be asked:

The creator sees	Because
You are not the owner of this offering	They are signed in as somebody else — usually a second account
Cannot release tokens for transaction with status: X	Only `PENDING` contributions can be delivered here. A row already at `VERIFICATION` is waiting on you, not on them
This contribution vests…	The contribution has an active vesting schedule and must be delivered tranche by tranche on the vesting section below
Invalid `<chain>` transaction hash format	The string does not match the shape expected for the offering's blockchain

Only the shape of the hash is validated, and only for the chains the addon knows. Nothing queries a block explorer. A creator can record a well-formed hash that transferred nothing, to the wrong address, on the wrong chain — and the contribution will arrive on your desk looking exactly like a real one.

Verification is the human step, and it is yours. See Verifying a delivery.

The vesting desk

For an offering that vests, the same page carries a Vesting Schedules section under the transaction tabs. It renders nothing at all on offerings that do not vest.

Every schedule on the offering, with its tranches

Records the hash for ONE due tranche

Four summary tiles sit above the schedules: Schedules, Tranches due now, Amount due, and Delivered as released-over-scheduled. Due now counts tranches that are PENDING, on an ACTIVE schedule, with a release date at or before this moment — it is the creator's to-do list for today.

Each schedule shows the investor, the wallet address, the shape, the totals and every tranche with its date, amount, percentage and status. The wallet address is the one the buyer supplied at purchase, frozen on the contribution. It is never re-read from the buyer's profile, so a buyer who changed their address afterwards has not changed where the tokens go.

The PUT refuses:

when the schedule is not ACTIVE — this vesting schedule is cancelled and cannot accept releases;
when the tranche is not PENDING — this tranche is already released;
before the tranche's date, with the date it unlocks. Without that, a creator could record all twelve months on day one and the schedule would be a formality;
on a badly-formed hash, as above.

Recording the first tranche also flips the contribution to VERIFICATION. Verifying that one contribution releases the whole purchase amount from escrow while the rest of the schedule is still outstanding — there is no partial escrow release. Read When the creator gets paid before you verify the first tranche of a long schedule.

The arithmetic to do before you approve a vesting sale

Every tranche is a manual on-chain transfer plus a manual hash submission, per buyer, forever. The obligation is the product of the schedule and the crowd, and it is the single most common reason a creator stops delivering.

Shape	50 buyers	200 buyers	1,000 buyers
12-month linear	600 transfers, 50/month	2,400 transfers, 200/month	12,000 transfers, 1,000/month
4 quarterly milestones	200 transfers	800 transfers	4,000 transfers
No vesting	50 transfers, once	200 transfers, once	1,000 transfers, once

The monthly column is the one that matters. A twelve-month schedule is not a 2,400-item task, it is a 200-item task that recurs on a date for a year, executed by hand by a team that is also trying to build a product. When a creator asks you to "turn off vesting" three months in, the answer is that you cannot: the terms are frozen per contribution at purchase and no screen anywhere can rewrite an existing buyer's entitlement.

Plan upgrades

/ico/creator/token/[id]/plan/upgrade is reached from the Upgrade Plan button on the token page, which passes the current plan in the URL. Opening the page without that parameter bounces straight back to the token page.

Points the offering at a different launch plan

The endpoint takes a planId, confirms the offering belongs to the caller, writes it, and notifies them. That is all it does.

What changes. The three enforced caps — team members, roadmap items and offering phases — are read from the plan the offering points at, so they become the new plan's the moment the write lands. A creator blocked at five team members can add the sixth immediately after upgrading.

What does not change:

The sale currency. purchaseWalletCurrency and purchaseWalletType were copied onto the offering from the plan it launched on, and nothing here rewrites them. An offering that launched on a USDT-priced plan keeps taking USDT after an upgrade to a plan priced in something else.
Anything already bought. Contributions, escrow, phases and vesting schedules are untouched.
Content already over the new cap. The caps are checked when a row is added. Moving to a smaller plan does not delete team members or roadmap items; it just refuses new ones until the count falls back under the limit.

The launch fee is charged once, by the launch route, when the offering is created. The upgrade route charges nothing: it checks no balance, moves no money and writes no transaction. A creator who upgrades from your cheapest plan to your most expensive one pays the difference only if you collect it some other way.

It also accepts any plan id, so it is a downgrade path as much as an upgrade one. If plan pricing is meant to be enforced on upgrades on your install, that has to happen outside this screen.

The creator-facing plan list returns every launch plan ordered by sortOrder, with no filter on the plan's status flag. A plan you disabled at Admin → ICO → Settings → Launch plans still appears on both the launch form and this upgrade page.

Delete is what actually takes a plan off both lists, and it does not endanger anything. The button sends a plain DELETE with no force flag and the plan is a soft-delete model, so the row is only stamped deletedAt: nothing leaves the database, the CASCADE on the offerings' foreign key never fires, and every offering on that plan keeps running exactly as it was.

The one thing it does change is those offerings' caps. A deleted plan no longer loads as an offering's plan, and the team-member and roadmap-item checks skip when an offering has no plan — so offerings left on a deleted plan become uncapped rather than staying at their old numbers. If that matters, move them onto another plan before you delete theirs.

When a creator abandons delivery

Buyers' money is sitting in escrow and the person who is supposed to send tokens has stopped answering. What you can do depends entirely on where the contributions are.

None of these paths can recover tokens a creator has already sent on-chain. A buyer who was delivered and then refunded keeps both. The platform has no custody of the token and no ability to reverse a transfer.

The longer a stalled sale runs, the more of it you are writing off. Decide early.

Where the contributions are	What you can do
`VERIFICATION` — a hash was submitted and it does not check out	Reject it on the transaction desk. Escrow is debited, the buyer is credited, the tokens go back to the phase that sold them, the participant count is recomputed, and any vesting schedule behind it is cancelled.
`PENDING` — nothing was ever submitted	Neither verify nor reject is allowed from this status. You cannot refund one buyer here.
The whole offering is compromised	Pause it to stop new contributions, then Super Admin emergency cancel to refund every outstanding contribution at once.
The offering is already `FAILED` or `CANCELLED`	Run the refund endpoint. It is idempotent — nobody who has already been repaid is paid twice.

Stop the money first. pause on /admin/ico/offer/[id] is enforced on the purchase path and refuses every contribution. flag is not — it marks the offering and notifies the creator and stops nothing.
Work the VERIFICATION rows individually. Each rejection refunds one buyer and restores that allocation, and it is reversible only in the sense that the tokens go back on sale. Do these before you consider cancelling, so the ones you have actually adjudicated are settled on their merits.
Do not verify to be helpful. Verification is what pays the creator. On a sale you are about to cancel, every contribution you verify is money you have handed over and cannot claw back.
Cancel if the project is gone. The emergency cancel is Super Admin only — the check is on the role name, so no permission grant substitutes for it — it requires a reason of at least ten characters, and it refunds every outstanding contribution, restores phase supply and cancels the vesting schedules behind them. See Emergency cancel and refund.
Tell the buyers what happened. Every refund path notifies the affected user, but none of them explains the decision. If the sale was cancelled for fraud, that sentence has to come from you.