OpenZeppelin Brings Smart Contract Security Standards to Starknet and Sui

The change covers deployment targets previously outside OpenZeppelin's core EVM footprint. For engineers shipping contracts on non-EVM runtimes, this widens the menu of reusable, audited primitives—and shifts where invariants must be re-validated.

What the expansion actually changes

Until now, OpenZeppelin's reference implementations targeted Solidity and the EVM. Starknet uses Cairo with a STARK-proven execution model. Sui runs Move with an object-centric state model. Both differ from the EVM in storage layout, call semantics, and upgrade patterns. Standards ported without adaptation transfer syntax, not invariants.

Specific divergences that matter:

• Storage. EVM uses key-value mapping against 256-bit slots. Cairo's storage tree composes writes into a Merkle structure. Move's object model enforces ownership at the type level. A slot-indexing pattern from Solidity does not carry over.
• Calls. EVM's message-call frame includes reentrancy-flag handling. Cairo's contract-to-contract calls pass through a different interface. Reentrancy vectors shift in shape, not in presence.
• Determinism. Both Starknet and Sui are deterministic at the contract level, but ordering and event emission can differ. Off-chain consumers expecting EVM log schemas need re-validation.

The audit side is the more consequential move. Code review built around EVM-specific failure modes—reentrancy via external calls, gas-griefing loops, storage collisions across proxy slots—does not transfer verbatim. A library label is not a security guarantee.

The AI-enabled Continuous Security Program adds an automated scanning layer. Scope and trigger conditions are not specified in the available reporting. Treat it as supplementary signal, not as authorization to skip manual review on critical invariants.

Broader signal

This is one of several audit-centric moves in the same window. SlowMist, per Coinfomania coverage dated July 27, launched a specialized RWA audit service focused on compliance governance and ownership verification. A Bitcoin Foundation write-up dated July 30 notes institutional capital moving away from speculative AI tokens toward infrastructure, tokenized real-world assets, and stablecoin rails. Capital is also reallocating elsewhere: biotech venture capital is rebounding as pharma shifts toward strategic acquisitions. Infrastructure draws money across sectors.

Verify before you import

• Storage access. Cairo requires explicit reads and writes against its storage tree. Move enforces stricter type and ownership rules. Cross-reference against each VM's documented semantics before the import.
• Upgrade mechanics. EVM proxy patterns do not map cleanly to Cairo or Sui. Verify the upgrade entry point, admin powers, timelock presence, and whether the migration is deterministic.
• Event schema. Indexers built for EVM logs may misclassify Cairo or Sui events. Re-check downstream consumers.
• Reentrancy model. EVM reentrancy via external calls has analogs in both runtimes but with different code paths. A pattern flagged clean on EVM is not automatically clean elsewhere.
• Audit report scope. Confirm whether the audit covers the ported version or only the original EVM implementation. Two libraries with the same name and different guarantee profiles are not interchangeable.