SYMMIO v0.83 Update — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for SYMMIO v0.83 Update, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 5
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 5 closed, publicly disclosed SYMMIO v0.83 Update reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against SYMMIO v0.83 Update
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
SYMMIO v0.83 Update: PartyA's allocated balance could increase after `deferredLiquidatePartyA` is executed
In SYMMIO's two-step deferred liquidation flow, a PartyA's allocated balance is zeroed during step one (deferredLiquidatePartyA) and is then expected to stay non-positive for step two (deferredSetSymbolsPrice). Because the same wallet may be both a liquidator and a PartyA, liquidation fees earned by that wallet's liquidator role can be credited back into its allocatedBalances between the two steps. When deferredSetSymbolsPrice then runs, the now-positive availableBalance flips the remainingLf computation from 100 to 900, letting the liquidator collect a fee far larger than the amount actually locked as LF. The finding was escalated, validated as Medium by the lead judge, and fixed in protocol-core PR #48.
SYMMIO v0.83 Update: Deferred Liquidation can get stuck at step one of the liquidation process if the nonce increment
SYMMIO v0.8.3 introduced deferred liquidation, which lets a liquidator settle a PartyA based on a historical block's state even if the account is currently solvent. The flaw is that the Muon-signed liquidation request pins PartyA's nonce at the historical block, yet a PartyB can still call `chargeFundingRate` (raising the nonce) between the first and second steps of the multi-stage liquidation. When the signature nonce no longer matches the live nonce, the second step fails and the account stays permanently frozen, locking all assets inside it. The finding was escalated and upheld as a valid unique Medium, and the protocol fixed it by adding a `notLiquidatedPartyA` modifier to `chargeFundingRate`.
SYMMIO v0.83 Update: Suspended bridge transactions cannot be restored
SYMMIO's bridge restore path is permanently bricked because `bridgeLayout.invalidBridgedAmountsPool` is initialized to the zero address and no code path ever sets it. Since `restoreBridgeTransaction` requires that pool to be non-zero before it can deposit the invalid portion of a suspended transaction, every restore attempt reverts unconditionally. Consequently any bridge transaction placed in the SUSPENDED status becomes unrecoverable, stranding assets in the protocol so bridge service providers cannot reclaim funds they already forwarded to users. The protocol acknowledged the finding as a high-severity issue and fixed it by adding an admin-only setter for the pool address.
SYMMIO v0.83 Update: Wrong precision when adding balance within the `restoreBridgeTransaction` function
SYMMIO's bridge restoration flow contains a precision bug: `restoreBridgeTransaction` credits the `invalidBridgedAmountsPool` account balance using the raw token-native difference (`bridgeTransaction.amount - validAmount`) without scaling it to the protocol's 18-decimal internal balance. For a 6-decimal token like USDC, a 5000e6 credit is recorded as if it were 5000e18, so the pool's withdrawal math only permits recovering a negligible fraction of the intended funds. The scenario is triggered by the protocol's own legitimate admin restore action after suspending an anomalous bridging transaction, causing a permanent, irreversible loss of protocol assets. The finding was upheld and fixed by scaling the credited amount to 18 decimals, merged in SYMM-IO/protocol-core PR #45.
SYMMIO v0.83 Update: Collateral can still be allocated to PartyA when the system is paused by exploiting the new internal transfer function
SYMMIO's v0.83 update introduced AccountFacet.internalTransfer, which converts a PartyA's deposited balance into allocated (tradeable) collateral. Unlike the pre-existing allocate and depositAndAllocate entry points, it was not guarded by the whenNotAccountingPaused modifier, so when the protocol activates its global and accounting pauses — either to halt harm from a live bug or to freeze funds during an active attack — a user could still call internalTransfer to keep allocating collateral, defeating the pause's purpose. The finding was acknowledged, fixed in protocol-core PR #47 by adding the missing modifier, and signed off by the Lead Senior Watson. This creates a genuine economic risk because pause mechanisms on derivatives platforms are relied on to stop loss accumulation and ongoing exploits.