Smart Contract Analysis Statement

Contract Analysis

The SCADABridge contract implements a trustless 1:1 wrapper between OmniBridge wSCADA and native SCADA on Ethereum, using a mint-and-burn model. Users deposit wSCADA to mint SCADA (unwrap), or burn SCADA to withdraw wSCADA (wrap). The contract is intentionally minimal - 45 nSLOC, no owner, no admin, no upgrade path. The contract is deployed and immutable; the team has acknowledged the finding below. Residual concern is summarized as follows:

• unwrap mints SCADA based on the requested amount, not on the actual wSCADA balance delta after safeTransferFrom. Under the current OmniBridge wSCADA implementation (a non-fee-on-transfer PermittableToken) this is benign and the documented 1:1 invariant holds. The residual exposure is conditional on a future OmniBridge governance action that upgrades the wSCADA proxy to introduce fee-on-transfer or deflationary semantics; if that ever happens, every subsequent unwrap silently over-mints SCADA, drift compounds across all future unwraps, and the bridge has no on-chain remediation because it is intentionally immutable. Operational mitigation is continuous monitoring of the documented invariant 'wscada.balanceOf(bridge) is approximately scada.totalSupply() minus the 1,000,000 deployment seed' and a frontend-pause if drift is detected. The balance-delta hardening is recommended for any future redeployment.

Ownership Privileges

There is no owner. The contract does not inherit Ownable, has no admin function, no parameter setter, no pause mechanism, and no upgrade path. All three contract references (scada, wscada, scadaManager) are stored as immutable. The privileged surface is therefore extremely narrow:

• The SCADAManager (set immutably at deployment) is the only address authorized to call burnCollateral, which destroys wSCADA collateral in lockstep with SCADA burns from the supplyBlock cycle
• burnCollateral is capped at the bridge's actual wSCADA balance, so it can never burn more collateral than is available
• That is the entire privileged surface - no other address has any administrative power over this contract
• No party (including the deployer) can change the wSCADA address, the SCADA address, or the SCADAManager address
• No party can mint or burn SCADA outside the user-driven wrap/unwrap flow
• No party can pause the bridge or block specific addresses
• No party can upgrade the contract or migrate its collateral
• No party can reverse a wrap or unwrap once it has settled

Security Features

The contract implements several positive security features:

• Fully immutable construction - no Ownable, no upgrade path, no admin functions, no proxy. The contract is permanently frozen at the bytecode that was deployed.
• ReentrancyGuard on every state-mutating function (unwrap, wrap, burnCollateral).
• Mint-and-burn model with capped collateral burns - the bridge can never burn more wSCADA than it actually holds, and the 1:1 collateralization invariant was verified by both symbolic analysis and stateful fuzzing.
• SafeERC20 used for all wSCADA movements, and the wrap path burns SCADA before releasing wSCADA so the user cannot receive collateral without surrendering an equal amount of SCADA first.

Note - This Audit report consists of a security analysis of the SCADABridge smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the SCADABridge team. Other contracts associated with the project were audited separately by our team. We recommend investors do their own research before investing.