Status Codes

OOLIN retains detailed processing states internally and exposes a simplified customer-facing status where applicable.

Withdrawal customer status (user_status)

The table below describes withdrawal user_status. Detailed withdrawal status uses separate values such as REQUESTED, HOT_STAGE, and HOT_FAILED; do not treat the two fields as the same enum.

Status	Meaning	Terminal
PENDING	Accepted, awaiting confirmation or inspection	No
PROCESSING	Approval, signing, or blockchain execution	No
COMPLETED	Successfully finalized	Yes
FAILED	Processing failed	Yes
REJECTED	Rejected by policy or operation	Yes
CANCELLED	Cancelled before completion	Yes

Internal transfers normally complete synchronously but must still be confirmed through transaction detail. External withdrawals can pass through multiple processing states and are successful only with completed statuses and a valid transaction hash.

Deposits remain pending until required confirmation and policy processing completes. Cursor discovery does not replay later status changes; poll non-final records by ID.

For withdrawals, persist both raw status and user_status for diagnostics and reconciliation rather than translating the value destructively in storage.

Deposit detail status (status)

Deposit lists and details return status rather than user_status. Interpret external deposit states as follows.

status	Handling
PENDING, INSPECTED, APPROVE_PENDING, APPROVED, VERIFIED	Confirmation, inspection, approval, or verification. Continue detail polling without marking the deposit complete.
REFUND_REQUIRED, REFUND_REQUESTED, REFUND_PENDING	Refund required or in progress. Maintain operational follow-up and status tracking without crediting a successful deposit.
COMPLETED	Deposit complete. Use this to confirm a successful customer deposit.
REFUNDED	Ended by refund. Do not treat it as a successful customer deposit.
FAILED	Processing failed. Do not treat it as a successful customer deposit.

Internal deposit queries show PENDING or COMPLETED. Confirm an individual payment through the original internal withdrawal's detail. The current contract always returns null for refund_withdrawal_id; do not assume it provides a refund withdrawal ID. See the API Reference for field-level contracts.

Transition handling

Store the previous and new status with observed time. Trigger customer notifications and irreversible business effects only from a validated transition, and make the handler idempotent so the same response can be processed twice.

An unexpectedly old status can be a delayed read or replica observation; do not roll a terminal business state backward automatically. A contradiction after a terminal state requires investigation with resource and request IDs.

Use localized labels only at presentation time. Monitoring, storage, and reconciliation must use the stable enum value.