Audits
On this page
Listapie’s contracts are audited by AstraSec. Their consolidated report covers ten audit rounds, from the original staking protocol in July 2024 to Listapie Lending v3 in August 2026.
- Audit rounds
- 10
- Findings
- 7
- Critical
- 0
- Addressed
- 5 of 7
Audit rounds#
| # | Completed | Scope | Audited → final commit |
|---|---|---|---|
| 1 | Jul 24, 2024 | Core protocol: mLISTA, staking and rewards | daf4229 → 5e1497e |
| 2 | Nov 4, 2024 | ListaVote | dfc406e → b1d87a1 |
| 3 | Nov 20, 2024 | Pool deposit and withdrawal logic | 73e33e8 → 9bd8415 |
| 4 | Jan 6, 2025 | vlLTP voting and bribery market | b7f97fc → 50361da |
| 5 | Jan 15, 2025 | vlLTP bribe market | 257029b → 8904fac |
| 6 | Aug 3, 2025 | USDT stable pool | 357da7e → 3f7bede |
| 7 | Jan 15, 2026 | vlLTP changes (50% force-unlock penalty) | c24235a → 8335127 |
| 8 | Feb 12, 2026 | Listapie scheduler (LIP-06) | 21e211e → 5795f23 |
| 9 | Feb 27, 2026 | mLISTA smart convertor | da61deb → 0a122eb |
| 10 | Aug 27, 2026 | Listapie Lending v3: vault, treasury, factory, fee vault | 2c77f13 → f2b88c3 |
The final commit of each round is the version that includes the fixes for that round’s findings.
Findings at a glance#
| Severity | Count | Addressed | Acknowledged |
|---|---|---|---|
| Critical | 0 | – | – |
| High | 1 | 1 | – |
| Medium | 1 | – | 1 |
| Low | 4 | 3 | 1 |
| Informational | 1 | 1 | – |
Addressed: resolved by the final commit. Acknowledged: the team accepted the risk without a code change. All seven findings are in the staking contracts; none is in the Lending v3 contracts.
Findings in brief#
H-1 · Reward-rate manipulation#
High · Addressed · StreamRewarder. When rewards were added to a running stream, the accrued reward per token was settled with the new rate instead of the old one, and anyone could trigger this by donating 1 wei of a reward token. Stakers could receive less than expected for that period. Recommendation: settle with the old rate and restrict who can donate rewards.
M-1 · Centralization risk#
Medium · Acknowledged · multiple contracts. Owner and minter roles control critical operations, such as minting mLISTA, setting reward distributors, creating rewarders and setting fee splits. Recommendation: hold these roles in a multi-sig and put changes behind timelocks. See Security & risk for what governance can do today.
L-1 · Missing reentrancy guard#
Low · Addressed · MasterListapie. Two functions that deposit and withdraw mLISTA on behalf of the mLISTA vault lacked reentrancy protection. Recommendation: add it.
L-2 · Leftover rewards can get stuck#
Low · Acknowledged · RewardDistributor. When distributing veLISTA rewards, any amount not covered by the active fee entries stays in the distributor with no way to withdraw it. Recommendation: send the remainder to the owner.
L-3 · Burn before harvest#
Low · Addressed · V2LiquidityPoolHelper. Withdraw-and-claim burned the user’s receipt tokens before harvesting, so a withdrawal could miss the expected harvest rewards. Recommendation: burn after the withdrawal and harvest.
L-4 · Bribe epoch checks#
Low · Addressed · ListapieBribeManager. Adding a bribe (and related routines) accepted a past epoch, or the current one after voting had closed. Recommendation: reject invalid epochs.
I-1 · Multi-claim revert#
Informational · Addressed · MasterListapie. Claiming several pools at once reverted when vlLTP was included with LTP claiming on. Recommendation: skip it instead of reverting.
Coverage#
- Staking (rounds 1–9): mLISTA, MasterListapie and its rewarders, vlLTP, the bribe market, pool helpers, the scheduler and the smart convertor.
- Lending v3 (round 10): the user vault, treasury, vault factory and fee vault, at commit
f2b88c3.
Internal security work#
- Holder-boost reentrancy (fixed). A confirmed critical was found where a caller-supplied distributor’s callback could re-enter the treasury and skim ring-fenced LISTA as fake reward. Fixed by pinning trusted distributors in the treasury registry, measuring reward as a balance delta above the ring-fenced principal, and re-asserting the ring-fence after every claim.
- Ring-fence invariant. The
lista.balanceOf(vault) ≥ allocatedTo(vault)invariant is fuzzed and fork-tested so a claim can never dip into lent principal. - Storage-safe upgrades. Beacon (vault) and UUPS (treasury, factory) upgrades are append-only and verified against the live storage layout before deployment.
- Keeper delegation. The EIP-1271 keeper path is fork-tested to confirm rewards can only be claimed to the owner, never redirected.
Reporting#
Found something? Please report security issues responsibly to the Listapie / Magpie team rather than disclosing publicly.