Live staking at Alkimi Labs, where mistakes cost money
Role: Frontend engineer — ongoing collaboration · 2023 — present
Alkimi Labs is the live staking platform for the ALKIMI token on Sui: users stake into a pool, claim rewards proved by Merkle proofs, and manage on-chain positions. I work on it as a frontend engineer in heavy, ongoing collaboration with the team, most deeply on the staking transaction layer, the enrollment surface, and the account migration flow. This case study covers what correctness means in a UI where a wrong number is someone's money.
Index terms: Sui, staking, Merkle proofs, optimistic UI, token precision
Context
Alkimi Labs is the staking platform for the ALKIMI token. Users connect a Sui wallet, stake into a live pool, claim rewards, and follow the token unlock schedule; an explorer surfaces the ad exchange's auction activity alongside: around 8.9 million impressions settled per day as of July 2026. It is a team product, and a live one: real balances move through it every day.
This case study stays close to the features I know from the inside: the Sui transaction layer for staking, unstaking, and claiming, the staking enrollment surface, the rewards chart data, the tokenomics model behind the unlock page, and the flow that migrates an Ethereum account to Sui. None of it is solo work. I built these with the frontend team, and the wider platform belongs to the whole team.
Problem & constraints
The central problem of this UI is that it renders other people's money, read from systems that briefly disagree. The chain is the truth; the indexer the backend reads from lags it by seconds; the user expects the number to change the moment their wallet closes. Showing stale balances reads as broken. Showing invented ones is worse than broken.
Precision is the second constraint. ALKIMI carries nine decimals, so any float arithmetic in the wrong place mints or destroys dust. The third is that every write is gated: wallet linked, KYC passed, terms accepted, minimums met. The enrollment surface has to tell the truth about which gate the user is standing in front of, in the right order, before a transaction is ever built.
Architecture & decisions
Optimistic truth with scheduled reconciliation. When a claim succeeds, the UI zeroes the claimable amount in the query cache immediately; a new stake prepends a provisional row. Eight seconds later, a revalidation pass refetches from the indexer and replaces the provisional state with recorded state. The trade-off is a short window where the interface is ahead of the records. We accepted it because the alternative, numbers frozen for seconds after the wallet closes, teaches users not to trust the page. The eight-second constant is honest about the indexer rather than elegant.
Plan for the RPC to be wrong. Building a stake transaction requires the wallet's coin objects, and under load the node's index sometimes reports a funded wallet as empty. The stake path degrades through three tiers: a paginated coin query, cross-checked against the wallet's reported balance; a full coin scan filtered client-side; and finally a raw object query by type. More code paths, and each one needs its own tests against mocked failures, but a wallet with funds must never be told it has none.
Floats never touch money. Base units live as BigInt and are formatted to strings by hand; transfer amounts pass through a decimal library that rounds down, always down, to nine places; the input field refuses anything past the ninth decimal before validation even runs. On the claim path, every Merkle proof element is checked to be exactly 32 bytes before serialization, so a malformed proof fails in the client instead of on chain.
Prove ownership twice. The Ethereum-to-Sui account migration builds one canonical message, stamped with a timestamp and a nonce, and requires a signature from both wallets before the request can be submitted. Two wallets connected in one session is real friction, and the form spends most of its code explaining which of the four connect-and-sign states the user is in. We accepted the friction because the alternative is support tickets about asset linkage, and those are settled by proof, not by sympathy.
What shipped
The platform is live at labs.alkimi.org, with public documentation at docs.alkimi.org. The features I worked on include the staking pool surface with its gating and validation, on-chain Merkle claims, the auto-stake toggle, rewards history with CSV export, the token unlock visualization, and the dual-signature migration form.
The test suite runs about 515 cases across 19 files, and the staking hook is tested against mocked RPC failure modes, including each tier of the coin-fetch fallback. Coverage runs on every pull request in CI.
What I'd do differently
The transaction layer keeps a proper state machine, and then the buttons mostly ignore it: in-flight guarding leans on the wallet's own modal instead of the interface disabling itself, which works until a wallet is slow to open. The eight-second reconciliation delay was tuned by watching the indexer, not by measuring it, and a constant chosen by feel deserves to be replaced by an event. And a pending transaction does not survive a page reload; the toast is the only witness. None of these has cost a user money. All three are the kind of debt that waits.
Stack: Next.js, TypeScript, React Query, Sui, wagmi/viemlabs.alkimi.org · docs.alkimi.org