Non-Custodial DeFi Staking and Governance

Project overview

We built a staking and governance application for a Web3 protocol team preparing to decentralise decisions to its token holders. Users connect their own wallet, stake tokens into time-based pools, watch rewards accrue, withdraw on their own schedule and vote on proposals with voting power derived from their stake.

The engagement covered tokenomics workshops, Solidity contract design and testing, the Next.js front end, subgraph indexing, an external security audit hand-off and a staged mainnet launch. It sits within our blockchain development services and our work with fintech and digital asset businesses.

The client and the challenge

The protocol had a token but no way for holders to participate. The team wanted staking that never took custody of user funds, reward rules that anyone could verify, and governance that could not be captured by someone borrowing tokens for a single vote.

They also needed a front end ordinary users could understand: clear gas costs, transaction states that did not leave people guessing, and a full history of stakes, rewards and votes without the page stalling on slow blockchain queries. Because contract code is hard to change once deployed and holds real value, the team also asked for a delivery process that treated testing and independent review as release gates rather than optional extras.

Solution architecture & delivery

The Solidity contracts are split into a staking vault, a rewards distributor and a governor. Tokens move from the user's wallet into the vault only through the user's own signed transaction, and only the user can withdraw them; no admin function can move staked balances. Rewards use a per-share accumulator, so each claim is calculated in constant gas regardless of how many stakers exist, and reward rates can be changed only through governance with a timelock.

Voting power is taken from a snapshot of stake at the block a proposal is created, which prevents buying or borrowing tokens to swing a live vote. Proposals pass through review, voting, queue and execution states, and the timelock gives stakers time to exit before an approved change takes effect. Pausing is limited to new deposits, so users can always withdraw.

Reading chain state directly would have made history pages slow, so we defined a subgraph on TheGraph that indexes deposit, withdrawal, claim, proposal and vote events into queryable entities. The Next.js app reads balances that must be exact straight from the contracts and loads history, leaderboards and proposal lists from the subgraph. Before each transaction the app estimates gas, shows the cost in plain language and then tracks the transaction from pending to confirmed, with a clear retry path if it is dropped.

Contracts were covered by unit, fuzz and invariant tests and then reviewed by an independent auditor before launch. Deployments and front-end releases ran through staged testnet environments following our CI/CD and testing pipeline. We did not provide investment or legal advice; the client's own counsel reviewed token and governance terms.

Key features we built

• Non-custodial staking where only the wallet owner can withdraw
• Multiple staking pools with transparent, on-chain reward rates
• Constant-gas reward calculation and claim from the dApp
• Snapshot-based voting power to resist borrowed-token vote swings
• Proposal lifecycle with timelocked execution
• Gas estimates and clear pending, confirmed and failed transaction states
• Indexed history of stakes, claims and votes via TheGraph
• Deposit-only pause switch that never blocks user withdrawals

How we delivered it

1. Discovery and tokenomics. Workshops with the protocol team defined pool rules, reward sources, governance thresholds and the admin powers that would deliberately not exist.
2. Contract design and testing. Contracts were specified, built and tested with unit, fuzz and invariant tests on a local chain before any front-end integration.
3. dApp and indexing build. Two-week sprints delivered the Next.js interface, wallet connection flows and the subgraph, tested end to end on a public testnet.
4. Audit and launch. Findings from the independent audit were fixed and re-reviewed, then contracts were deployed and verified with deposits opened gradually.
5. Support. Ongoing monitoring of contract events, subgraph health and front-end updates, with any contract change routed through governance.

Technology choices

• Next.js — a fast, search-friendly web front end with server rendering for public proposal pages and client-side wallet interaction.
• Solidity — the standard language for EVM smart contracts, with mature testing tools and audit familiarity for staking and governance logic.
• TheGraph — indexes contract events into queryable data so history, proposals and leaderboards load quickly without heavy chain queries.

Outcomes

• Token holders can stake, earn and withdraw without handing custody to the protocol team
• Reward and governance rules are publicly verifiable on-chain
• Protocol changes now go through proposals and a timelock rather than team decisions alone
• Users see gas costs and transaction status clearly instead of guessing whether an action worked
• History and proposal pages load from indexed data rather than slow chain scans
• Launch followed an independent audit with deposits opened in controlled stages

FAQ