How it works
What the code guarantees, not what the marketing says
Every statement below names the contract and the function that enforces it. Not «solid architecture», but specific invariants that you — or an automated assessor — can check yourselves. The boundaries and the weak spots are named outright.
1 · Architecture and the trust boundary
Where everything lives — and what never crosses the line
Diagram: three zones and the red line the key never crosses
Customer's device
Private keyderived from the seed, lives only here
Transaction signinghappens on the device
On-chain (zkSync)
Obligation tokenissuance/burn, ceiling
Coveragepublishes the ceiling, attestation
Exchange · stakingswap, savings
Off-chain (server)
Indexerreads chain events for the history feed
APIstores no key; from the wallet it has the address
The server cannot sign on the customer's behalf and does not hold funds — it reads the chain and serves the interface. The authority to spend belongs to the key on the device, and to nothing else.
2 · Invariants the code enforces
Checkable statements — with contract and function
The source of every contract is published and verified — it matches this repository byte for byte. Open the address that holds the funds and read the Solidity yourself: not «believe the code is like this», but «check it». Every invariant below is held by the network, not by the application — it cannot be bypassed through the interface, or through us.
Issuance cannot exceed the attested ceiling
Minting is rejected when totalSupply() + amount exceeds the attested reserve. The check lives in the token contract; the interface cannot route around it.
contract OLTINfunction mintceiling — contract 0x9413F602…
A purchase that minted within the ceiling 0x344b763d…13add1
A stale attestation halts issuance by itself
If the attestation is older than one hour (maxAgeReserve = 3600), minting reverts. Stop attesting and issuance freezes. It fails towards safety.
contract OLTINfunction mint · maxAgeReserve
The attestation history, open-ended 0x9413F602…7d1B
A deposit is locked for 7 days — nobody can shorten that
Each deposit creates a lot with lockedUntil = now + 7 days. Withdrawal draws only from unlocked lots. Neither an administrator nor anyone else takes it out earlier.
contract Stakingfunction unstake · LOCK_PERIOD
A deposit, locked on-chain 0xc39f92b2…4a7022
An administrator cannot touch someone else's deposit
Withdrawal works only on the lots of msg.sender — the restriction is welded into the function itself, not into application rules. An administrator has no path to a depositor's funds.
contract Stakingfunction unstake (msg.sender)
The customer's key never leaves the device
The wallet derives the key from the seed on the device and signs locally. The server stores no key and cannot sign; from the wallet it holds only the public address (account data such as a Telegram id is stored, but grants no access to funds).
client lib/walletbackend — only wallet_address
The path of the money
What happens on a purchase, a swap and a sale
Diagram: eight steps, each labelled with its action
1
The customer deposits somthrough the partner's fiat rails
2
Approves the exchange to debitsigned on the device
3
Buys the obligationthe exchange mints the token — but only within the attested ceiling
4
Holds it in a non-custodial walletthe key belongs to the customer
5
Transfers it to someone elseor stakes it for a return
6
Sells it backthe exchange burns the token
7
Receives som from the exchange treasurysettled on-chain
8
Withdraws through the partner's railsfiat on the issuer's side
Roles and powers
Who can do what — and what nobody can do
Can
Publisher — sets the coverage ceiling (in production, the partner)
Exchange — mints and burns the token, within the ceiling. The MINTER role is held by exactly one address — the exchange contract, not a human key (verifiable by replaying the RoleGranted/RoleRevoked events)
Customer — signs only their own operations
Nobody can
Issue tokens above the ceiling
Withdraw someone else's deposit before its term
Sign for a customer, or extract their key
3 · The stack, with reasons
Every choice with a reason, not a logo
Why zkSync Era
Transaction cost
Transfers and swaps cost pennies. On an expensive network the micro-transactions of a retail product do not add up.
Why a non-custodial wallet
The issuer does not hold other people's funds
The key belongs to the customer — less operational and regulatory load on the partner, and no hot storage of other people's money.
Why no upgrade mechanism
The rules cannot be rewritten after the fact
The contracts are immutable — neither we nor anyone else can rewrite the logic under what has already been issued. The trade: a fix requires a new contract and a migration.
4 · Development discipline
Checkable in the open repository
405
tests · 204 contracts · 165 backend · 36 frontend
CI on every PR
gates before merge, no suppressions
Actions pinned by SHAsquash-only + branch auto-deletepush protection
The review process is part of the product: the significant blockers — fund drainage, authentication bypass, a race on the reserve, double issuance — were caught by adversarial review. All of it reads directly in the repository.
Open the repository on GitHub →
5 · Limits, stated plainly
What we name ourselves
A precise self-assessment is not weakness but a sign of maturity. A project with no weak spots reads as an advertisement.
Testnet.zkSync Era Sepolia; tokens carry no monetary value — this is proof that it works, not a production issuance.
No external audit yet.The internal adversarial review process is running; an independent audit comes before any production launch.
The contracts are immutable.Deliberately — the rules cannot be rewritten after the fact. The price: a fix requires a new contract and the migration of live positions.
Administration sits on a single key.Administrative roles are still on one EOA. Under a pause a user can do nothing (deposit, withdraw, claim), while the administrator can still withdraw the reward pool (withdrawRewardPool is not pausable). Principal and ceiling are untouched by this: nobody can seize a deposit or issue above the ceiling. Moving to a multisig is planned, and it takes priority over monetisation.
The indexer is not reorg-resistant.The history feed is built by reading events; on a chain reorganisation it may briefly lag — balances and on-chain invariants are unaffected.