Navid
46 lines
3.0 KiB
Markdown
46 lines
3.0 KiB
Markdown
# Product flows confirmed from staging screenshots
|
|
|
|
## Wallet and balances
|
|
|
|
- Portfolio shows total value, available value, locked value, per-asset balance/value/price, and allowed actions.
|
|
- “Locked” is a first-class user-visible balance. GL must expose at least `available`, `locked`, and `total = available + locked` per user/asset, with the lock reason and owning operation.
|
|
- History exposes asset, time, amount, transaction type, state, tracking number, and Kuknos/hash-like reference.
|
|
|
|
## Transaction gate
|
|
|
|
Every value-changing request can require configurable 2FA (`SMS`, `TOTP`, or `EMAIL`) and an agreement acceptance. An agreement may be:
|
|
|
|
- a generated legal contract;
|
|
- transaction-specific terms and conditions; or
|
|
- acceptance of site/platform policy.
|
|
|
|
The accepted agreement version, content hash, actor, transaction/request ID, timestamp, and 2FA method/result must be immutable audit evidence.
|
|
|
|
## Trade and ICO
|
|
|
|
- Secondary market: maker posts an order; taker accepts all or part of its remaining quantity. Contract acceptance precedes settlement.
|
|
- ICO: taker buys only from a specific authorized publisher maker order. Asset/user whitelisting may reject the request before agreement/settlement.
|
|
- Reserved quantities and balances must be locked atomically when an order/request becomes executable, then consumed or released exactly once.
|
|
|
|
## Money movement
|
|
|
|
- Kuknos subscription imports observed blockchain transactions/deposits.
|
|
- External bank deposit causes IRT issuance/transfer from the server treasury to the user.
|
|
- IPG flow: create gateway token -> redirect -> confirm callback -> transfer IRT from treasury.
|
|
- IRT withdrawal: create request -> freeze IRT -> 2FA/agreement if required -> admin approve/deny -> finalize state and consume/release lock.
|
|
- Authorized third party: API-token request -> manual/user/admin decision -> lock asset as collateral -> success, denied, or failed result; later release/consume must reference the original lock. Automatic acceptance policy is explicitly a future feature.
|
|
|
|
## Platform availability rule
|
|
|
|
- GL is the primary, append-only source of truth and is mandatory for every value-changing workflow.
|
|
- Kuknos is the secondary settlement/verification source of truth. `NORMAL` mode requires both GL and Kuknos.
|
|
- GL/GL-database failure puts transaction admission and transaction workers into a fail-closed halt until health is restored.
|
|
- Kuknos failure also halts transactions unless an authorized operator explicitly selects `KUKNOS_DISABLED` using AdminPanel or configuration. There is no automatic switch.
|
|
- Public health must expose the incident as critical/not-ready, and transitions into, during, and out of the incident must be observable through OpenTelemetry.
|
|
- Non-mutating views can remain available if their data can be labelled consistently and safely.
|
|
|
|
## Bank and referral
|
|
|
|
- Bank information maintains verified Sheba/IBAN accounts; the account must belong to the identified user before withdrawal.
|
|
- Referral tracks invitation code/link, referred users, commission share, received/withdrawable reward, and reward withdrawal.
|