Two signatures before a withdrawal

Money leaving a platform is the one operation where care costs almost nothing and carelessness costs everything. This is what happens between your request and the transfer.

WHEN YOU REQUEST

A withdrawal starts with a one-time code. The code is consumed atomically, so it is valid exactly once even if two requests arrive at the same moment.

Your balance is then checked inside the same database transaction that writes the withdrawal, not before it. There is a daily cap, and the day is a UTC day computed from a single place in the code, so the window cannot quietly shift when a server's timezone changes.

The request also carries an idempotency key. If your connection drops and the app retries, you get the same withdrawal back rather than a second one.

WHEN WE DECIDE

A withdrawal is not released by whoever happens to be logged in.

Staff roles are separated. An operator can see and prepare, but the decision on a withdrawal can be made only by an approver or an administrator. And whoever created a request cannot approve it. That is the four-eyes rule.

Both halves matter, and we learned why the hard way. On its own, the four-eyes rule says the creator cannot approve. For a withdrawal, the creator is the investor, so the rule never triggered, and the lowest staff role could approve money leaving with no second signature at all. The approver role existed in the code and guarded nothing. A permission that is declared but not enforced is more misleading than one that was never there.

If a withdrawal is rejected, the amount returns to your available balance and you are notified. Nothing is left in limbo.

WHAT WE HAVE NOT DONE YET

Referral rate changes do not require a second signature today. Such a change does not damage history, because commissions already paid stay bound to the rate version they were calculated with, but the future rate is currently set by one person.

We would rather publish the gap than the impression.