User principal and promised rewards must remain separately accounted so every position can close without spending another user's stake.
The answer in 30 seconds
Ample Protocol directly engaged Zealynx to review a Base staking contract that combined locked token positions, time-based rewards, and an NFT reward boost. The seven-day review covered one 125-line Solidity contract at commit 45f12c5d992d82c14166aba34a455fe9412045ba.[1][2]
The pivotal issue was not a bad reward formula. Staked principal and reward funding shared one contract balance with no separate accounting. A withdrawal could therefore appear affordable while consuming tokens needed to return principal to later stakers. Zealynx reframed the review around a reserve invariant, demonstrated the accounting failure, and recommended explicit reward tracking through funding and position closure. The report records the High-severity issue as fixed by Ample and verified by Zealynx.[1]
This is a technical engagement narrative based on public provider-authored evidence, not a customer transformation story. It does not claim exploitation, production deployment, monetary exposure, customer sentiment, or continuing assurance.
The buyer decision: can every staking promise be funded at once?
Ample describes its wider protocol as protecting intellectual property at the intersection of culture, AI, and blockchain on Base.[3] The reviewed scope was narrower: StakingContract.sol, which accepted user stakes, assigned lock periods and reward rates, applied an NFT boost, and paid principal plus rewards when positions closed.[1]
For a staking founder or protocol engineer, the decision is: before enabling rewards, how do you prove that the contract can return every user's principal while also honoring every accrued reward?
The relevant invariant was:
User principal and reward reserves must be accounted separately, and closing one position must never consume principal owed to another position.
A large token balance does not prove this property. Solvency depends on what each part of that balance is obligated to fund.
The dangerous assumption: one balance means one pool of available liquidity
The reviewed contract accepted the same token for stakes and rewards. Reward funding increased the contract's ERC-20 balance, but the contract did not track how much of that balance represented user principal, funded rewards, or rewards already promised to open positions.[1]
That made the balance ambiguous. The following numbers are an illustrative model of the report's mechanism, not observed Ample balances or transactions:
- Two users each stake 100 tokens.
- The protocol funds 10 reward tokens.
- The contract balance is 210 tokens.
- The first position closes with principal plus a 20-token reward.
- The transfer succeeds because the contract holds enough tokens.
- Only 90 tokens remain for the second user's 100-token principal.
The example shows why a first withdrawal can be locally valid while the system-wide reserve invariant is already false. It does not show that this sequence occurred in production. The report-supported defect is that transfer success could conceal a liability shortfall until a later user exited.[1]
How Zealynx tested the reserve invariant
1. Classify every token by obligation
The review separated three economically different quantities that the implementation represented with one ERC-20 balance: deposited principal, reward tokens supplied by the protocol, and rewards promised to active positions.[1]
2. Follow liabilities through the full position lifecycle
The relevant path began at reward funding and stake creation, continued through reward calculation and NFT-boost assignment, and ended at closePosition(). Zealynx checked whether each transition updated enough state to answer two questions: how much principal must still be returned, and how much funded reward remains available?[1]
3. Test withdrawals in sequence, not isolation
A single happy-path withdrawal only proves that the current balance covers one transfer. The reserve test instead asks whether an early principal-plus-reward payment can reduce the balance below the principal still owed to open positions.
4. Make the reserve state observable
The report recommended separate reward accounting, updating that accounting when positions close, and adding view functions so available reward capacity could be inspected rather than inferred from the combined token balance.[1]
The pivotal discovery: transferability was not solvency
The contract could transfer principal and rewards from its balance, but it could not determine whether the transferred reward came from funded rewards or another user's principal. The report describes the resulting state as a fractional-reserve risk: early reward payments could leave later users unable to withdraw their stake under high-withdrawal conditions.[1]
The connected mechanism was:
| State transition | Local interpretation | System-level question that was missing |
|---|---|---|
fundRewards() adds tokens | contract balance increased | how much reward reserve is actually available? |
| a user stakes | more tokens arrived | how much of the balance is now principal owed back? |
| a position records interest | reward amount calculated | is that promise covered by uncommitted reward reserve? |
closePosition() transfers principal plus reward | current transfer can execute | will remaining principal and rewards still be covered? |
The dangerous assumption was equating tokens held with tokens available for any purpose. Custody was visible; the liabilities attached to that custody were not.
Before, intervention, and verified after-state
| Before the review | Zealynx intervention | Verified after-state in the public report |
|---|---|---|
| Principal and reward tokens shared one undifferentiated balance | Modeled principal, funded rewards, and promised interest as separate obligations | Report records separate reward accounting as implemented |
| A successful early payout could consume later-user principal | Tested reserve sufficiency across sequential position closure | Reward tracking is updated during position closure |
| Reward capacity could only be inferred from total balance | Recommended explicit reserve view functions | Report records the finding as fixed by Ample and verified by Zealynx |
“Fixed and verified” is limited to the reviewed remediation recorded in the May 2025 report. The public evidence does not identify a final remediation commit or establish that the corrected code was deployed.[1]
A reusable solvency model for staking contracts
Teams using one asset for both deposits and rewards should maintain an explicit liability model:
principal liability = sum(principal owed to open positions)
reward liability = sum(rewards already promised to open positions)
free reward reserve = funded reward tokens - reward liability already paid or committed
required assets >= principal liability + reward liability
The exact implementation can differ, but these quantities should not collapse into token.balanceOf(address(this)). A balance is an asset snapshot; it is not a ledger of who is owed what.
Before launching or changing a staking system, verify:
- Principal accounting: Can the contract calculate principal owed to all open positions?
- Reward funding: Is new reward capacity created only by an explicit, accounted funding action?
- Promise-time solvency: Can a position promise more reward than the uncommitted reserve can cover?
- Closure ordering: Does the result remain solvent regardless of which valid position closes first?
- Boost liabilities: Are NFT or tier boosts included when reward obligations are reserved?
- Token recovery: Can an administrative withdrawal remove principal or committed rewards?
- Observability: Can users and monitoring systems compare assets with principal and reward liabilities?
- Boundary tests: Do zero funding, maximum boost, many simultaneous positions, and high-withdrawal sequences preserve the invariant?
Impact and evidence limits
The strongest supportable result is finding-specific: the report documents a High-severity accounting design that could spend staked principal as rewards and records separate reward accounting as fixed and verified.[1]
The wider review reported 21 findings: one High, four Medium, five Low, and 11 Informational. The public audit record says all non-informational findings were fixed and verified.[1][2] This narrative does not turn those statuses into a claim that the entire protocol was secure.
No public source establishes that the affected contract was deployed, that any user encountered a failed withdrawal, or that a dated amount of principal was exposed. No TVL, funds-protected, money-saved, loss-avoided, or business-outcome claim is made.
Evidence and attribution
- Canonical technical record: the Zealynx report identifies Ample Protocol, the reviewed contract and commit, the seven-day review, H-01's mechanism, recommendations, and its fixed-and-verified response.[1]
- Public audit record: Zealynx's engagement page reports the same scope, finding distribution, direct review team, and final non-informational remediation state.[2]
- Client-controlled context: Ample's site describes the wider protocol and its Base positioning; it does not independently verify the audit outcome.[3]
- Attribution class: direct Zealynx engagement. The public Zealynx report identifies Zealynx as provider and contains no partner-delivery attribution.
- Evidence cutoff: the May 2025 report and the public pages retrieved for this narrative.
- Limitations: provider-authored evidence supports technical scope and recorded remediation, but not deployment, customer sentiment, commercial impact, or later-code security.
Designing staking rewards around the same token as principal?
Zealynx can test whether funding, accrual, boosts, withdrawals, and administrative controls preserve principal and reward solvency across the full position lifecycle. Explore smart contract security audits or request a staking-accounting review.
Frequently asked questions
Why was the contract balance not enough to prove solvency?
The balance combined principal and reward funding without recording their separate obligations. A transfer could succeed while consuming tokens owed as principal to another open position.[1]
What invariant should a staking contract enforce?
Assets held by the staking contract should cover principal owed to open positions plus rewards already promised to those positions. Reward payments should reduce an accounted reward reserve, not an undifferentiated token balance.
What was the recorded fix?
The report recommended separate reward accounting, updating reward tracking during position closure, and exposing reserve information through view functions. It records Ample's response as fixed and Zealynx's review as verified.[1]
Were all findings fixed?
The public record says all 10 non-informational findings were fixed and verified; the 11 Informational observations were acknowledged. That is a point-in-time statement about the reviewed scope, not proof of deployment or a guarantee about later code.[1][2]
Was this a direct Zealynx engagement?
Yes. The public Zealynx report identifies Zealynx as the audit provider and contains no partner-delivery attribution.[1]
How much value did the review protect?
The public evidence provides no dated, scoped asset amount for the reviewed contract. This narrative therefore makes no monetary exposure, value-protected, money-saved, or loss-avoided claim.
Sources
[1] https://raw.githubusercontent.com/ZealynxSecurity/audits/main/web3/2025-05-zealynx-ample.pdf — Ample Protocol Smart Contract Audit [2] https://zealynx.io/audits/ample-protocol/ample-staking-q2-2025 — Ample Protocol Staking Smart Contract Audit [3] https://ampleprotocol.xyz — Ample Protocol