# Security Audit: SvoStaking and DeployStaking (SovrnOne/sovrn-contracts @ 8a3222d)

| | |
|---|---|
| Repository | https://github.com/SovrnOne/sovrn-contracts |
| Branch / commit | `imd-pair` / `8a3222ded9c51bfb3324f954928cfc83e12fedbe` ("DeployStaking script (deploy, then separate fund step) with offline script test and real-IMD fork test") |
| In scope | `src/SvoStaking.sol` (269 lines), `script/DeployStaking.s.sol` (67 lines, `run()` and `fund()`) |
| Read for context | `src/SovrnToken.sol`, `src/Interfaces.sol` (`Guard`), `STAKING.md`, `test/SvoStaking.t.sol`, `test/DeployStaking.t.sol` |
| Out of scope | `src/LifeForceVault.sol`, `src/SovrnHook.sol`, the launch contracts and scripts (separate audits). Mentioned only where they touch the staking contract. |
| Toolchain | forge 1.8.3 (`cae51ad`), solc 0.8.26, via-IR, optimizer 200, cancun (per `foundry.toml`) |
| Date | 2026-10-10 |
| Reviewer | One automated reviewer (an AI model). This is not an independent multi-person audit. See "Limits". |

Line references such as `SvoStaking.sol:126` are to the file at commit 8a3222d, e.g.
`https://github.com/SovrnOne/sovrn-contracts/blob/8a3222d/src/SvoStaking.sol#L126`.

---

## 1. Executive summary

**Verdict.** I found **no Critical or High issue** in `SvoStaking.sol` and no way for a third party to steal or permanently lock stakers' SVO principal or earned IMD. Reward accounting is conservative. Every rounding step rounds against stakers, so the contract cannot become insolvent through rounding. Principal and the burn-match pool are kept apart: across 8,192 random stateful calls, the pool never used staked SVO. Unstaking never touches IMD.

The findings are Low and Informational. They are about trust assumptions, deployment safety and small accounting leaks:

| ID | Title | Severity | Status of evidence |
|---|---|---|---|
| L-1 | `DeployStaking.fund()` trusts whatever `STAKING_CONTRACT` points at and approves it the full fund amount | Low (high impact, needs operator error) | PoC passes (`test_F5`) |
| L-2 | Two funded burn-match contracts on the same SVO match each other's burns, so either pool can be drained for gas only | Low (only if a second pool is deployed) | PoC passes (`test_F6`) |
| L-3 | IMD's owner is a single EOA with `setBlocked`; it can freeze all claims (principal stays safe) | Low (trust assumption, partly documented) | Fork test on chain 4663 |
| L-4 | Constructor accepts `rewardToken == token`; staked principal would then be streamed as rewards | Low (the deploy script prevents it) | PoC passes (`test_F4`) |
| L-5 | A staker who adds ≥10% of the remainder can restart a running stream over 7 days and cut its rate | Low (griefing; costs real IMD) | PoC passes (`test_F3`) |
| L-6 | Deploy script identifies SVO only by `symbol()` and `totalSupply()`, and `fund()` does not check the chain | Low | Code reading |
| I-1 | Truncation in `rewardPerTokenStored`; free `claim()` calls make it happen more often | Informational (quantified, negligible at 18 decimals) | PoC passes (`test_F1`, `test_F1b`) |
| I-2 | Truncation dust stays in `rewardsReserved` forever and never returns to a stream; the STAKING.md "below a millionth of a token" bound holds per event, not in total | Informational | PoC passes (`test_F2`) |
| I-3 | Rolled-over (`undistributed`) emission and small Safe deposits cannot restart during a running stream | Informational (design) | PoC passes |
| I-4 | A burn just before `reclaim()` makes the pool burn the same amount first (documented by the project) | Informational | PoC passes (`test_F7`) |
| I-5 | Minor: event field naming, stale `undistributed` view, strict `fund` minimum, reclaim to a lost funder | Informational | Code reading |

---

## 2. Method and evidence

The checks I ran and their results (facts):

1. **Project build and tests.** `forge build && forge test --match-contract "SvoStaking|DeployStaking"`: 24/24 pass (23 in `SvoStakingTest`, 1 in `DeployStakingTest`). The fuzz test ran 256 times.
2. **Project fork test.** `StakingForkTest` ran against Robinhood Chain (chain id 4663) and passed: `test_overflowStreamsWithRealIMD`. The fork used a local RPC provider for chain 4663 that falls back to the public endpoint named in the brief. Chain head was about block 85,072,551 at query time.
3. **My own PoC suite** (`artifacts/poc/AuditPoC.t.sol`, 12 tests, all pass). Drop it into `test/audit/` of the repository at 8a3222d.
4. **My own stateful invariant suite** (`artifacts/poc/AuditInvariant.t.sol`). A handler drives stake, unstake, claim, IMD deposit, notify, time warp up to 60 days, external burns, `matchBurn` and funder `reclaim` across 4 actors. All 4 invariants hold over 128 runs × 64 depth (8,192 calls):
   - `svoSolvent`: `totalStaked == Σ ghost principal` and `SVO.balanceOf(staking) ≥ totalStaked + matchRemaining()`
   - `imdSolvent`: `IMD.balanceOf(staking) ≥ rewardsReserved ≥ undistributed + streamRemaining + Σ pendingRewards`
   - `imdConservation`: `totalClaimed + IMD.balanceOf(staking) == Σ deposited`, and `totalNotified == totalClaimed + rewardsReserved`
   - `matchAccounting`: `matchUsed ≤ matchTotal`, and `matchAvailable()` never reverts
5. **My own fork tests** (`artifacts/poc/AuditFork.t.sol`, 3 tests, all pass on chain 4663). They exercise the real IMD at `0x5F7Bb59365ce557C26dbcAa4EE9d39A4b95B7127`.
6. **On-chain reads** of IMD via `cast` (chain 4663):
   - `name` "Identity.md", `symbol` "IMD", `decimals` 18, `sharedDecimals` 6
   - `transfersEnabled` true
   - `owner` `0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7`, which has **no code** (an EOA)
   - EIP-1967 implementation slot is empty (not an EIP-1967 proxy)
   - The selector set includes LayerZero OFT functions (`send`, `quoteSend`, `setPeer`, `lzReceive`) and `setBlocked(address,bool)` / `blocked(address)`, `enableTransfers()`, `setV4Config(address,address,bool)`, `updateName/Symbol`, `setMsgInspector`, `setPreCrime`
   - The refuel Safe `0xEb57…697C` is a 2-of-3 Safe (`getThreshold()` = 2)
7. Manual line-by-line review of the in-scope files.

Below, every finding marks what is **Fact** (observed in code, tests or chain), what is **Inference** (my reasoning from facts) and what is **Uncertain / open**.

---

## 3. System overview (fact, from code)

`SvoStaking` combines three features in one contract with no owner, no pause and no upgrade path:

- **Staking SVO for IMD rewards.** This is a Synthetix-style `rewardPerToken` accumulator (`PRECISION = 1e18`). The contract does not pull IMD from anywhere. The refuel Safe transfers IMD to the contract, and anyone calls `notify()` (`SvoStaking.sol:126-145`). `notify()` takes `added = balance − rewardsReserved` and streams `added + leftover + undistributed` over `REWARD_PERIOD = 7 days`. The integer-division remainder goes back into `undistributed` (line 141). While a stream is running, `notify()` reverts unless `added ≥ leftover/10` and `added > 0` (line 137). Emission that falls while `totalStaked == 0` is added to `undistributed` in `_updateGlobal` (line 252).
- **Burn-match pool.** The `funder` calls `fund(amount)` once. The pool vests linearly over 365 days (`matchAvailable`, line 205). Anyone can call `matchBurn()` (lines 162, 185-196). It burns from the pool as much SVO as has reached `DEAD` since the last snapshot, capped at the vested amount, and moves `burnSnapshot` forward by `2 × matched` so the pool does not match its own burn. After 365 days the funder may `reclaim()` once (lines 171-182). Burns that are still waiting get matched first.
- **Access tier.** `hasAccess(a)` requires `staked ≥ 1,000,000 SVO` and `now ≥ stakedSince + 1 day`. Every `stake()` resets `stakedSince`.

`SovrnToken` is a plain ERC-20 with no hooks and a fixed supply. Burning means transferring to `DEAD`, which increments `totalBurned` (`SovrnToken.sol:43-47`). `Guard` is a single-slot reentrancy lock (`Interfaces.sol`).

Ways value can leave the contract (fact, exhaustive by inspection):

- SVO: `unstake` (principal, to `msg.sender`), `_match` (to `DEAD`), `reclaim` (to `funder`)
- IMD: `claim` (to `msg.sender`)

There is no sweep, rescue or admin path.

---

## 4. Detailed review of the questions in the brief

### 4.1 `rewardsReserved` versus the real balance

**Facts.**
- `rewardsReserved` only rises in `notify()`, where it is set to the observed balance (line 131). It only falls in `claim()`, by exactly the amount transferred (line 112).
- `notify()` treats any balance above `rewardsReserved` as new reward. This means fee-on-transfer *into* the contract is handled correctly.
- My invariants show `balance ≥ rewardsReserved ≥ (all liabilities)` and the exact identity `totalNotified == totalClaimed + rewardsReserved` over 8,192 random calls with a standard ERC-20.
- On the real IMD fork, the contract balance went up by exactly the amount sent, and down by exactly the amount `claim()` paid (`test_noTransferFeeBothSides`). So, for the paths I tested, real IMD charges no transfer fee in either direction.

**Inference.**
- The only ways `balance < rewardsReserved` can happen are outside this contract: a negative rebase, an IMD owner action that changes balances, or a fee charged to the sender on outgoing transfers. I saw none of these in IMD's selector set, but I could not read IMD's source (see "Uncertain").
- If it did happen, the last claimers' `claim()` would revert with `TransferFailed` (a "last one out" shortfall). Later Safe deposits would silently fill the gap first, because `notify()` only counts balance above `rewardsReserved`.
- Stakers' SVO principal would not be affected.

**Uncertain.**
- IMD's verified source was not fetched; the explorer is behind a Cloudflare challenge. The unresolved selectors `0x059c9548(uint256)`, `0x4478d7ba`, `0x547ef3d3` and `0x84e4b73a` (all currently returning 0) and `setV4Config` might add transfer conditions. I did not establish what they do.

### 4.2 Rounding and dust

**Facts.**
1. `notify()` streams exactly `rewardRate × 7 days`. The division remainder goes to `undistributed` and is streamed later (line 141). This dust is not lost.
2. `_updateGlobal` truncates `emitted × 1e18 / totalStaked` (line 253). Per global update, stakers lose less than `totalStaked / 1e18` wei of emission. For SVO (1e27 total supply) that is at most about 1e9 wei = 1e-9 IMD. This matches the claim in STAKING.md.
3. `pendingRewards` truncates per account (line 239), losing less than 1 wei per account per update.
4. Lost wei from (2) and (3) stay inside `rewardsReserved` and are **never re-streamed**. Only the `notify` remainder goes to `undistributed`, and there is no sweep. PoC `test_F2`: with about 3e26 SVO staked and one 1-IMD stream, after a full claim `rewardsReserved` was 133,345,689 wei. Only 105,145 wei of that was `undistributed`. The other 133,240,544 wei is permanently locked dust from a single update.
5. Every rounding step favors the contract. My invariants never found a liability above `rewardsReserved`, so `rewardsReserved -= reward` in `claim()` cannot underflow through rounding.

**Overflow check (inference).**
- `staked × (rpt − paid)` is bounded by `emitted × 1e18`, because `rpt` grows by `emitted × 1e18 / totalStaked` and `totalStaked ≥ staked`. Even an IMD supply far above today's 5.49e22 cannot reach 2^256.
- A 1-wei staker makes `rewardPerTokenStored` grow by `emitted × 1e18` per update. That is still about 1e45 per stream, far from overflow.

See I-1 and I-2 for how much this matters.

### 4.3 Undistributed rewards

**Facts.**
- Emission is added to `undistributed` only inside `_updateGlobal`, which runs on any stake, unstake, claim or notify while `totalStaked == 0`.
- `stake()` calls `_update` *before* raising `totalStaked` (lines 89-92). The empty interval is therefore credited to `undistributed`, and the new staker gets none of it. A late staker cannot take emission from a period when nothing was staked.
- `undistributed` is only streamed again by `notify()`.
- PoC `test_edge_noStakerThenFirstStaker`: a 700-IMD stream started with nobody staked; a staker joined after 3 days. They received about 400 IMD for the 4 days staked. 300 IMD rolled into `undistributed` and was paid out in full by the next `notify()`.
- PoC `test_edge_lastStakerLeaves`: the last staker leaves on day 2 and keeps about 200 IMD; about 500 IMD rolls over and is not lost.

**Inference.** The only drawback is timing. While a stream is running, rolled-over IMD cannot be restarted until the stream ends, or until someone adds new IMD of at least a tenth of the remainder (I-3).

### 4.4 Edge cases: first staker, last staker, no stakers

- **No stakers, `notify()` called.** Allowed (fact). The whole stream goes to `undistributed` and waits for the next valid `notify()`. Calling `notify()` repeatedly with no stakers just re-rolls the stream; nothing is lost.
- **First staker of any size takes the whole rate** while alone (fact; the project documents this). Even 1 wei works. This is not an inflation or donation attack: there are no shares, and rewards are per second, so a just-in-time stake around `notify()` earns nothing extra.
- **Last staker leaves.** Covered in 4.3 (fact, PoC).
- **`notify()` with nothing new.** Reverts with `InvalidAmount`, both during a stream and when `total < REWARD_PERIOD` wei (fact; project tests and PoC).
- **Before any stream.** `_updateGlobal` sets `lastUpdate = block.timestamp` when `periodFinish == 0` (line 255). `_emitted()` returns 0 (fact).
- **Burn-match edge cases** (fact, project tests and my invariants):
  - Burns before `fund()` are excluded (line 157).
  - After `reclaim()`, `matchTotal == matchUsed` and `matchAvailable()` returns 0 without underflow, because `elapsed` is capped at the duration.
  - `reclaim()` with nothing left returns 0 and still closes the pool.
- **Access tier.** Only `msg.sender` can stake for itself, so nobody can reset another account's `stakedSince` (fact). Rotating the same SVO across accounts once a day is documented by the project and remains possible.

### 4.5 Theft, lock-up and griefing of staked SVO and earned IMD

- **Theft of staked SVO.** None found (fact plus invariant). The pool can only send `≤ matchTotal − matchUsed` (lines 189, 178), and `unstake` is bounded by `staked[msg.sender]`.
- **Lock-up of staked SVO.**
  - `unstake` makes no external call except `SVO.transfer`, and `_update` calls nothing external (fact). A frozen, paused or blocklisting IMD cannot block it.
  - A project test and my fork test with the real IMD's `setBlocked(staking, true)` confirm this (fact).
  - SVO is immutable and has no hooks.
- **Theft of earned IMD.** None found. `claim` follows checks-effects-interactions and holds the reentrancy lock (fact).
- **Lock-up of earned IMD.**
  - The IMD owner can freeze claims (L-3).
  - A blocked staker cannot claim to another address, because `claim` has no recipient argument. The fork test shows a claim to a blocked staker reverts. That staker's IMD then stays reserved until they are unblocked (fact). Other stakers are unaffected.
- **Griefing.**
  - The stream can be stretched (L-5).
  - Anyone can trigger truncation for free (I-1).
  - A burn just before `reclaim` hurts the funder (I-4).
  - A pool-versus-pool loop is possible if a second pool exists (L-2).

---

## 5. Findings

### L-1. `DeployStaking.fund()` trusts the target contract it is given

**Location.** `script/DeployStaking.s.sol:49-66`

**Facts.**
- `fund()` reads `STAKING_CONTRACT` from the environment.
- It takes `token()` and `funder()` from that address with no other check.
- It checks only that the address has code and that `matchStart() == 0`.
- It then runs `svo.approve(staking, amount)` and `staking.fund(amount)` from the funder wallet. The default amount is 100,000,000 SVO.

**PoC.** `test_F5_fundScriptTrustsStakingContract` deploys a `FakeStaking` that returns the real SVO as `token()` and the broadcaster as `funder()`. Its `fund()` calls `transferFrom` to a thief. The script runs to completion, and the thief receives 100,000,000 SVO.

**Impact / likelihood (inference).**
- Impact: total loss of the founder allocation.
- Likelihood: low. It needs a wrong or phished `STAKING_CONTRACT` value, such as an address copied from a malicious page or a typo that lands on an attacker's contract.
- The deploy and fund steps are deliberately separate, so a human copies the address between them. That is exactly where this kind of mistake happens.

**Recommendation.** In `fund()`:
- require `address(staking).codehash` to equal the expected runtime code hash of `SvoStaking` (constructor arguments are immutables, so compare after `run()` and record the hash, or check `type(SvoStaking).runtimeCode` with the immutables masked);
- require `staking.rewardToken() == IMD`;
- require `address(staking.token()) == vm.envAddress("SVO_TOKEN")`;
- require `block.chainid == 4663`.

Alternatively, have `run()` write the deployed address to a file and have `fund()` read it from there.

### L-2. Two burn-match pools on the same SVO feed each other

**Location.** `SvoStaking.sol:185-196`. The function relies on `token.totalBurned()`, which counts every transfer to `DEAD` by anyone, including another matcher.

**Facts.**
- Each pool excludes only *its own* burns, by advancing `burnSnapshot` by `2 × matched`.
- A second funded `SvoStaking` on the same SVO (or any other contract that burns SVO in response to `totalBurned`) sees the first pool's match burns as external burns, and the reverse.

**PoC.** `test_F6_twoPoolsMatchEachOther` funds two pools with 100M SVO each and waits a year. A single external burn of **1 SVO** followed by 10 rounds of permissionless `matchBurn()` on both pools burns **39 SVO** from the pools. Each extra round burns more. The only limits are gas and the vested amounts.

**Impact (inference).**
- If the project ever has two funded matchers live at once, anyone can drain both vested pools to `DEAD` for gas only. Examples: a re-deploy while the old pool still holds SVO, or a second matcher for another feature.
- An attacker who funds their *own* pool gets only 1:1 leverage: every SVO their pool burns costs them one SVO. That is no worse than the documented burn-before-reclaim case.
- With a single pool the problem does not exist.
- `LifeForceVault.burn()` (out of scope) also burns SVO to `DEAD` (`LifeForceVault.sol:88`), and those burns are matched. This looks intended, but it is not stated in STAKING.md.

**Recommendation.**
- Document "never fund more than one matcher on the same SVO".
- Alternatively, keep an allowlist of addresses whose burns are ignored, or match only burns made through a dedicated burn entry point.

### L-3. IMD owner (a single EOA) can freeze every claim

**Facts (chain 4663).**
- IMD `owner()` is `0x047F…54B7`, which has no code.
- IMD has `setBlocked(address,bool)`.
- Fork test `test_ownerBlocklistFreezesClaimNotPrincipal`: after the owner blocks the staking contract, `claim()` reverts with `TransferFailed`, while `unstake` still returns full principal. `balanceOf` keeps working.
- STAKING.md mentions that "a misbehaving IMD (blocklist, pause) can block `claim`". It does not say that the blocklist exists today and is controlled by one EOA.

**Impact (inference).**
- All accrued and future IMD rewards can be frozen at the discretion of one key, or of whoever compromises it.
- Principal is safe.
- I did not test whether a blocked staking contract can still *receive* IMD from the Safe.

**Recommendation.**
- State the dependency explicitly in STAKING.md and in the app.
- Optionally add a `claimTo(address)` so that a staker whose own address is blocked can still move rewards. Beware that this weakens a deliberate IMD compliance control; that choice is the project's.

### L-4. Constructor does not forbid `rewardToken == token`

**Location.** `SvoStaking.sol:78-83`

**Fact.** If IMD and SVO were the same address, `_rewardBalance()` would include staked principal and the match pool. `notify()` would then stream them as rewards.

**PoC.** `test_F4` streams Alice's 100M staked SVO to Bob and Alice. Alice's later `unstake` of her full principal reverts.

**Likelihood (inference).** Very low. `DeployStaking.run()` hardcodes `IMD` and checks that `SVO_TOKEN` has symbol "SVO" and 1B supply, so the deploy script cannot produce this configuration. The risk applies only to hand-made deployments.

**Recommendation.** Add `if (rewardToken_ == address(token_)) revert Unauthorized();` to the constructor.

### L-5. A running stream can be restarted over a new 7 days for 10% of what is left

**Location.** `SvoStaking.sol:134-143`

**Fact.**
- Any `notify()` with `added ≥ leftover/10` resets `periodFinish` to `now + 7 days` and spreads the whole remainder over the new week.
- PoC `test_F3`: with 1,000 IMD left and 1 day to go, a donor adds 100 IMD.
  - The rate falls from 0.01157 to 0.00182 IMD/s, about 6.4 times slower.
  - A 10% staker who planned to leave at the original end receives 615.7 IMD instead of 700. The remainder is deferred, not lost.

**Inference.**
- The 10% rule (an audit fix in commit c86905c) stops *free* stretching, but stretching is still cheap for a whale. A 90% staker gets back about 90% of the donation, so the net cost is about 10 IMD here.
- The damage is to the time value of rewards, not their total. No funds are lost.

**Recommendation.** If this matters:
- extend by `max(remaining time, added × REWARD_PERIOD / total)`, or
- add new IMD at the current period end without resetting it, or
- require `added ≥ leftover` before a reset is allowed.

### L-6. Deploy script: weak token identity, and no chain check in `fund()`

**Facts.**
- `run()` accepts any contract whose `symbol()` is "SVO" and `totalSupply()` is 1e27 (`DeployStaking.s.sol:30-33`). A look-alike token passes this check.
- `fund()` has no `block.chainid` check, unlike `run()`.
- `STAKING_FUNDER` defaults to the broadcaster. The address is permanent, and the script only logs it.
- The SVO address is not yet fixed anywhere in the repository. `launch-attestation.json` says "no deployment".

**Recommendation.**
- Once SVO is deployed, pin its address, or compare its runtime code hash with the attested build.
- Add the chain check to `fund()`.
- Consider requiring `STAKING_FUNDER` to be set explicitly, with no default.

### I-1. Truncation of `rewardPerTokenStored` can be triggered for free

**Facts.**
- `claim()` with nothing earned returns 0 but still runs `_updateGlobal`. Any account can therefore force a truncation step at the cost of gas.
- `test_F1`: 6e26 SVO staked, a 1-IMD weekly stream, an update every 120 seconds for a week. Stakers lose **2.51e12 wei = 2.5e-6 IMD (2.5 ppm)**. The no-spam control lost 4.0e8 wei.
- `test_F1b`: at the minimum allowed rate (1 wei/s, a 604,800-wei stream) with 3e26 staked and an update every minute, stakers receive **0**. All 604,800 wei stay reserved forever.

**Inference.**
- With an 18-decimal IMD this is economically negligible. It only becomes material if IMD is worth enough that a few nano-IMD per update matter, or if `REWARD_PERIOD` and the minimum stream are tiny.
- The loss formula assumes 18 decimals. IMD reports 18 (fact), and a fork test confirmed it.

**Recommendation.** Optional:
- carry the truncation remainder (`emitted × 1e18 − Δrpt × totalStaked`) into `undistributed`, or
- use a higher `PRECISION` (1e36 is safe given the bounds in 4.2).

### I-2. Dust in `rewardsReserved` is permanently stranded; the STAKING.md bound is per event

**Fact.** See 4.2(4). STAKING.md says "Rounding dust (below a millionth of a token) stays in the contract".

**Inference.**
- The bound holds per update.
- In total, dust accumulates without limit with the number of updates. I-1 shows 2.5e-6 IMD in one week of 2-minute updates on one stream.
- It is still economically trivial.

**Recommendation.** Reword the documentation, or route the dust into `undistributed` (see I-1).

### I-3. Rolled-over emission and small deposits wait while a stream runs

**Facts.**
- `test_edge_undistributedWaitsDuringStream`: `notify()` reverts during a stream even when a large `undistributed` is waiting.
- A Safe deposit below `leftover/10` waits up to 7 days. This is documented.
- If nobody stakes for most of a stream, that IMD is not paid until a later `notify()`. Anyone can call `notify()` after `periodFinish`.

**Recommendation.** None needed. Consider letting `undistributed` count toward the 10% threshold, or allowing a restart when `undistributed ≥ leftover/10`.

### I-4. A burn just before `reclaim()` reduces the funder's refund

**Fact.** `test_F7`: a 100M SVO burn by a holder before `reclaim()` makes the pool burn its whole 100M, and `reclaim()` returns 0. STAKING.md documents this as accepted.

**Inference.** The attacker pays 1:1, so this is an economic choice, not a vulnerability.

### I-5. Minor observations

Facts unless marked otherwise:

- `RewardAdded(added, streamed, …)` emits `total` as "streamed". The amount actually streamed is `rewardRate × REWARD_PERIOD`; the remainder is re-rolled. Off-chain indexers may overcount by the remainder.
- The public `undistributed` getter (and `streamRemaining`) are stale until the next state-changing call while `totalStaked == 0`. Emission since `lastUpdate` is not yet included.
- `fund(amount)` requires `amount ≥ 365 days` (31,536,000 wei). This is harmless; it guarantees non-zero vesting per second.
- `matchAvailable` floors `matchTotal × elapsed / DURATION`. This is safe: `matchTotal ≤ 1e27`, so no overflow, and the full pool is available at the end.
- If the funder loses its key or Safe, the unvested and unmatched pool can never be reclaimed. It stays matchable forever, so nothing is lost, it just never returns.
- SVO sent by plain transfer, and tokens other than IMD, are stranded. This is documented.
- The `Guard` lock is shared by all external functions, so cross-function reentrancy through an IMD callback is blocked. IMD is a LayerZero OFT with no ERC-777-style hooks in its selector set (inference).
- Test gap (fact): the project's `testFuzz_contractStaysSolvent` covers two stakers and two deposits. It does not cover `reclaim` interacting with staking, multiple streams with `totalStaked` reaching 0 in between, or more than one matcher. My invariant suite covers the first two.

---

## 6. Properties that hold

These are facts, backed by tests or invariants as noted:

1. Staked SVO can only leave through its owner's `unstake`. Pool outflows are bounded by `matchTotal − matchUsed`. (Invariant `svoSolvent`, 8,192 calls.)
2. `unstake` succeeds whatever state IMD is in. (Project test with a broken IMD, plus a fork test with the real IMD blocklist.)
3. IMD is conserved: `totalClaimed + balance == deposits`, and `totalNotified == totalClaimed + rewardsReserved`. (Invariant `imdConservation`.)
4. `rewardsReserved` covers everything owed. (Invariant `imdSolvent`.)
5. Burn-match never matches its own burns or pre-funding burns, and never goes past the vested amount. (Project tests plus invariant.)
6. There are no privileged roles other than `funder`, whose powers are `fund` (once) and `reclaim` (once, after 365 days).

---

## 7. Open questions for the project

1. What do IMD's unresolved functions (`0x059c9548(uint256)`, `setV4Config`) do? Can they ever change balances or impose a transfer fee? Is IMD's source verified on the Robinhood Chain explorer?
2. Can a blocked address still *receive* IMD? If the staking contract were blocked, would Safe deposits fail or silently succeed?
3. Will any other contract that matches burns via `totalBurned` ever be deployed alongside this one (L-2)?
4. Who controls IMD's owner EOA, and is there a plan to move it to a multisig or timelock?
5. Is matching `LifeForceVault.burn()` volume from the founder pool intended?

---

## 8. Limits of this review

- This was a single-reviewer, time-boxed review of about 340 in-scope lines, produced by an AI model. The PoCs and invariants raise confidence but do not prove correctness. No formal verification was done.
- IMD was assessed from bytecode selectors, on-chain reads and fork behavior only, not from source code.
- Out-of-scope contracts (`LifeForceVault`, `SovrnHook`, launch scripts) were read only where they affect burns or IMD flows.
- Fork results reflect chain state at about block 85.07M on 2026-10-10. IMD's owner can change IMD's configuration after that.
- The verifier for this deliverable checks file paths and bytes only. It does not certify these findings. An independent human audit is recommended before significant value is placed in the contract.

## Appendix A: Reproducing

```bash
git clone https://github.com/SovrnOne/sovrn-contracts && cd sovrn-contracts && git checkout 8a3222d
forge build && forge test --match-contract "SvoStaking|DeployStaking"          # 24 pass
mkdir -p test/audit && cp <artifacts>/poc/*.sol test/audit/
forge test --match-path "test/audit/*" -vv                                       # PoCs + invariants
FORK_4663_RPC=https://rpc.mainnet.chain.robinhood.com \
  forge test --match-contract "StakingForkTest|AuditForkTest" -vv                 # real IMD
```

Key PoC outputs (from my run):

| Test | Output |
|---|---|
| `test_F1_truncationLossFromFrequentUpdates` | rate 1,653,439,153,439 wei/s; streamed 999,999,999,999,907,200; owed 999,997,488,000,000,000; lost 2,511,999,907,200 wei |
| `test_F1_control_noSpam` | lost 399,907,200 wei |
| `test_F2_dustNeverReturnsToStream` | rewardsReserved 133,345,689; undistributed 105,145; balance 133,345,689 |
| `test_F3_tenPercentDonorStretchesStream` | left ≈ 1,000 IMD; rate 11,574,074,074,074,074 → 1,818,783,068,783,068 wei/s; 10% staker at the original finish: 615.71 IMD (700 without the stretch) |
| `test_F6_twoPoolsMatchEachOther` | 39 SVO burned from pools after a 1 SVO external burn and 10 rounds |
| Fork `test_ownerBlocklistFreezesClaimNotPrincipal` | `claim` reverts `TransferFailed`; `unstake` returns full principal; a later `notify` reverted with `InvalidAmount` only because nothing new had arrived (trace shows `balanceOf` still works for a blocked account) |