Aria — stRWIP is always minted for RWIP in a 1:1 ratio

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 63676-h-01-strwip-is-always-minted-for-rwip-in-a-11-ratio-pashov-a. Standalone Foundry PoC and full write-up: 63676-h-01-strwip-is-always-minted-for-rwip-in-a-11-ratio-pashov-a_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/reward-calculation · reward-theft · reward-accounting

Reproduction: a self-contained Foundry PoC that compiles & runs in an isolated project with only forge-std — no fork, no RPC, no anvil_state. Full trace: output.txt. PoC: test/63676-h-01-strwip-is-always-minted-for-rwip-in-a-11-ratio-pashov-a_exp.sol.

AuditVault taxonomy: severity/high · sector/staking · sector/vault · platform/pashov · reward-calculation · reward-theft · reward-accounting · timestamp-dependence

Key info#


Impact	HIGH — attacker steals staking rewards belonging to honest stakers
Protocol	Aria (RWIP / stRWIP staking)
Vulnerable code	`RWIPStaking.burnTicket` — mints stRWIP 1:1 with ticket RWIP
Bug class	Fixed-ratio share mint vs variable-rate redeem
Finding	Pashov Aria security review 2025-05-12 · #63676
Report	Pashov Aria review
Source	AuditVault
Status	Audit finding — fixed in PR 51. Reproduced as a reduced local synthetic.
Compiler	`^0.8.24` (PoC)

TL;DR#

burnTicket always mints stRWIP equal to the ticket's RWIP amount (1:1).
unstake redeems stRWIP at the live exchange rate balance / supply.
After rewards inflate the rate, stake → burnTicket → unstake yields more RWIP than deposited.
An attacker loops this while honest stakers hold shares and drains their rewards.

The vulnerable code#

SOLIDITY

function burnTicket(uint256 id) external {
    Ticket storage t = tickets[id];
    require(t.owner == msg.sender, "owner");
    require(!t.burned, "burned");
    t.burned = true;
    stRWIP.mintShares(msg.sender, t.amount); // @> VULN: 1:1 mint instead of exchange rate
    // FIX: mint shares = amount * supply / assets (with virtual shares offset)
}

Root cause#

Share issuance ignores the current pool exchange rate. Redemption uses the rate, so newly issued shares capture a free slice of prior rewards.

Preconditions#

At least one honest staker has burned tickets and holds stRWIP.
Rewards (or donations) of RWIP sit in the staking contract.
Attacker can stake, burn tickets, and unstake (hold period set to 0 / elapsed in the real protocol).

Attack walkthrough#

Alice stakes 1000 RWIP and burns her ticket → 1000 stRWIP.
500 RWIP rewards are deposited → rate > 1.
Bob stakes his balance, burns at 1:1, unstakes at the inflated rate.
Repeat; Bob extracts most of the 500 rewards; Alice is left with dust.

Diagrams#

flowchart TD A["Alice holds 1000 stRWIP"] --> B["500 RWIP rewards deposited"] B --> C["Rate rises above 1:1"] C --> D["Bob stake then burnTicket"] D --> E["VULN: mint stRWIP 1:1"] E --> F["Bob unstake at inflated rate"] F --> G["Bob extracts Alice rewards"]

Impact#

Honest stakers lose essentially all deposited rewards. RWIP staking becomes economically broken for long-term depositors.

Sources#

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 63676-h-01-strwip-is-always-minted-for-rwip-in-a-11-ratio-pashov-a_exp (evm-hack-registry mirror).
AuditVault finding: 63676-h-01-strwip-is-always-minted-for-rwip-in-a-11-ratio-pashov-a.

Alerts & third-party analyses

Web3Sec X hacked database: search.
Rekt leaderboard: search.
Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.

Source-level debugger — step opcodes and Solidity in sync