Recent build · GIWA GASOK
05 / 12
Mulle
A testnet investment MVP that lets a verified GIWA account request an external-chain position, track settlement, and claim shares without holding native gas.
- Role
- Frontend Lead · Product Engineer · Jul 2026
- Problem
- A signed request, destination-chain execution, vault fulfillment, and the final claim are separate events, but the user still needs one trustworthy investment journey.
- Strategy
- The frontend treats request, execution, fulfillment, and claim as explicit states backed by current chain data. It separates wallet intent from sponsored submission, restores progress from contract snapshots, and stops transaction UI from starting when runtime configuration is unsafe.
- Outcome
- Delivered a live testnet MVP spanning GIWA Sepolia and Robinhood Chain Testnet with request, external execution, fulfillment, and claim flows for test assets.
Live testnet MVP · Jul 2026
01
Problem definition
Why this problem had to be solved
Mulle connects a verified GIWA testnet account to an external test market. The user requests an investment, follows each settlement step, and claims the result. A backend sponsor pays the network fee and a trusted solver handles the external execution.
What users and the system were facing
Accessing an external-chain product normally requires bridging assets, switching networks, obtaining destination-chain gas, and repeating approvals.
Submitting a transaction does not mean an externally executed investment has settled or become claimable.
A refresh, concurrent request, relayer timeout, or solver delay could otherwise leave the interface showing a misleading completion state.
Frontend ownership
I led the frontend and product UX, turning the initial proof of concept into a public landing page, market and product routes, deposit and redeem workspaces, settlement tracking, and a portfolio. Teammates owned the contracts and backend solver.
Product structure, responsive interface, and EN/KO experience
Privy embedded wallet and EIP-7702 / EIP-712 signing UX
ERC-7540 deposit, redeem, fulfill, and claim state
Runtime configuration, security boundaries, testing, and release checks
02
Solution strategy
A system strategy carried into production
The frontend treats request, execution, fulfillment, and claim as explicit states backed by current chain data. It separates wallet intent from sponsored submission, restores progress from contract snapshots, and stops transaction UI from starting when runtime configuration is unsafe.
System model
A verified GIWA account signs a sponsored request, a trusted solver executes on an external testnet, the vault fulfills the asynchronous request, and the user claims settled shares.
Product evidence
Selected product surfaces
Historical product interfaces. Values shown are captured UI states, not current TVL, APY, or performance claims.
Implementation decisions
Modeled ready, signing, submitted, pending, claimable, claimed, and failed states from contract snapshots instead of temporary component state.
Restored pending and claimable work after refresh and kept simultaneous deposit and redeem requests distinct.
Kept sponsor keys on the backend while the browser produced only signatures and optional authorization, then tested the production bundle for secret exposure.
Failed closed on unsafe relayer URLs, invalid chain or contract configuration, decimal mismatches, and incomplete deployment data before enabling wallet actions.
03
Outcome
What changed—and what I learned
Delivered a live testnet MVP spanning GIWA Sepolia and Robinhood Chain Testnet with request, external execution, fulfillment, and claim flows for test assets.
Passed 29 logic and configuration tests, four Chromium smoke tests, TypeScript, production build, and bundle-security checks at the Jul 2026 release review.
Kept the public landing route separate from the wallet-heavy runtime and reduced polling when settlement was inactive or the tab was in the background.
Learning
Web3 frontend completion must follow the business settlement state, not the success of a single transaction submission.
Today
The MVP still relies on a trusted solver and testnet assets. I would add verifiable cross-chain messaging, request-to-destination transaction correlation, and a smaller wallet runtime before moving beyond a controlled testnet environment.
Built with
Public links
Work together