Symbiotic Relay — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Symbiotic Relay, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Symbiotic Relay 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, Access control, 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 Symbiotic Relay
- Access control findings disclosed against Symbiotic Relay
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Symbiotic Relay: BlsBn254 is not available in certain chains due to hardcoded gas limit
Symbiotic Relay's BLS BN254 signature verification library hardcodes a 120,000-gas limit for the EcPairing precompile call, matching the EIP-1108 cost for k=2. On chains like ZKsync Era whose precompiles were updated (the May 2025 v28 upgrade charges 80,000 per pair, i.e. 160,000 for k=2), the staticcall always exhausts the provided gas, so BN254.safePairing returns failure and every BlsBn254 signature is rejected. Since the gas limit is not adjustable by an administrator, the BLS signing path becomes permanently unusable on affected deployments. This is a self-inflicted denial of service rather than a fund-loss bug, and the protocol team fixed it by making the precompile gas cost configurable.
Symbiotic Relay: `autoDeployedVault` mapping is not updated after `unregisterOperatorVault`
Symbiotic Relay's OpNetVaultAutoDeploy extension keeps a per-operator `_autoDeployedVault` mapping recording which vault was auto-created when an operator registered. The base module's `unregisterOperatorVault` only removes the vault from `_operatorVaults` and `_allOperatorVaults`, and because the extension never overrides the unregister path to hook back into its own mapping, `_autoDeployedVault[operator]` is left pointing at a now-unregistered address. Once that stale non-zero pointer is set, `_registerOperatorImpl` believes the operator already has a vault and refuses to auto-deploy a fresh one, so the operator loses access to the old vault without ever getting a replacement, and any `getAutoDeployedVault` query surfaces an incorrect address. The issue was acknowledged as a medium by the team and fixed by overriding the unregister path to clear the mapping, mirroring the existing `_registerOperatorImpl` override.
Symbiotic Relay: Enabling the whitelist can grant a malicious operator a temporary whitelisted status
Symbiotic Relay's OperatorsWhitelist extension contains a governance flaw where removing an operator requires that operator to already hold whitelisted status. Because the unwhitelist call reverts for non-whitelisted operators, a malicious operator who registers the moment whitelist mode is enabled is stuck in a state where the owner must first grant the whitelist role (then revoke it) to expel them. This forces the owner to temporarily bestow whitelisted privileges on an actor they sought to exclude, and the exposure worsens when the owner is a timelock-gated Network. The team fixed it by allowing an operator to be unwhitelisted even when not currently whitelisted, provided whitelist mode is on.