Skip to main content
Withdrawals are not open. You cannot submit a request.The server hard-blocks the create step, so any submission immediately returns:
This is not an operational toggle or a gradual rollout — it is a constant compiled into the code. The reason is that no automated payout channel exists yet: the “complete” step in the review pipeline only flips a database status to completed; it does not actually transfer money.
Your diamond revenue is unaffected and stays in your account. The rules below are already implemented and will apply as written once withdrawals open.
Figures on this page verified 2026-08-11; sources listed under “Sources of truth” at the end.

​
Implemented rules

​
Thresholds and limits

The payout amount is floored, and any remainder below ¥1 stays in your diamond balance:
For example: withdrawing 10,050 diamonds at a rate of 100 pays out ¥100, leaving 50 diamonds in the account.

​
Validation order on submission

The server validates in a fixed order and rejects on the first failure:
  1. Is the feature open? → WITHDRAWAL_NOT_OPEN (currently always stops here)
  2. Is the amount positive? → Amount must be positive
  3. Have 3 requests already been made in 24 hours? → WITHDRAWAL_RATE_LIMIT: Maximum 3 withdrawal requests per 24 hours
  4. Does the amount meet the minimum? → Minimum withdrawal amount is 10000
  5. Is the withdrawable balance sufficient? → Insufficient balance
Note that the frequency check runs before the amount check: if you have already submitted 3 requests in 24 hours, a fourth with an invalid amount still reports the frequency error, not the amount error.

​
State machine

Three properties worth knowing:
  • Record first, then deduct. A pending row is inserted before the balance is deducted. If the deduction fails, that row is marked failed — so there is never a state where money left the balance with no record of it.
  • Transitions are conditional updates. Every transition carries WHERE status = <expected>, so concurrent operations like double-approving or approving after a rejection fail rather than overwrite.
  • Refunds reverse both sides. Rejection and payout failure both roll back the balance and the cumulative-withdrawn counter, so reporting figures never inflate.

​
Why the freeze period exists

Revenue passes through a freeze period between being earned and being withdrawable:
  1. A user pays to use your Expert
  2. The platform computes your share based on your level, and diamonds land in a frozen state
  3. Frozen diamonds cannot be withdrawn (30 days by default)
  4. At the end of the freeze period they automatically become withdrawable
  5. You submit a withdrawal request
The freeze period exists to leave a window for refunds and dispute handling. Achievement rewards have no freeze period — they are withdrawable on arrival, because they are written in an already-thawed state, unlike sales revenue.

​
Balance states

​
FAQ

Withdrawals are not open; the server hard-blocks the request. See the warning at the top of this page.
Newly earned sales revenue must clear the freeze period (30 days by default) before becoming withdrawable — a window for refunds and disputes. The conversion is automatic; no action is needed from you.
Not currently. Withdrawals cannot be submitted, and the background achievement worker has no code path that writes progress for first_withdrawal. Both will be wired up when withdrawals open. See Bounties and Achievements.
No. Rejection and payout failure both refund the full amount to your withdrawable balance, along with a stated reason. You can correct the issue and reapply.
There is no fee-deduction logic in the code today — the payout is simply the floored conversion at the exchange rate. If a fee is introduced when withdrawals open, this page will be updated.

​
Tax note

Creator revenue is personal income and may be taxable. Please file according to the requirements of your jurisdiction. The platform may withhold and remit tax where regulations require it.

​
Sources of truth

Verified 2026-08-11. Sources:
  • Hard-block constant, the 3-per-24h frequency cap, validation order, state machine, and refund logic: services/core/src/db/service/withdrawal.ts
  • Defaults for the 10,000-diamond threshold, 30-day freeze periods, and 100:1 exchange rate: services/core/src/db/service/platform-config.ts (DEFAULT_WITHDRAWAL_RULES)
Items marked “ops-configurable” live in the system config table, so the effective value may differ from the default — your withdrawal page is authoritative. Items marked “code constant” require a release to change.

​
Next steps

Revenue System

Revenue share rates and level thresholds

Analytics

Data-driven revenue optimisation