OpenZeppelin’s Starknet audit: 9 issues closed, 0 critical/high, 2 moderate, 4 low, improved logging, type adjustment, bounds checking, eliminated notary panic, and clarified configuration and documentation. Very timely considering STRK has increased by 52% over the past week.
Details about Starknet itself
Lombard connects BTC staking and DeFi liquidity via Babylon. Users deposit BTC and Lombard stakes it through Babylon, minting LBTC 1:1 on the network of their choice. In Starknet, this liquid LBTC exists natively. Ledger creates tokens and creates accounts, and notaryd reads Starknet events and confirms operations. Users use LBTC in Starknet applications. To exit, users initiate an unstake on Starknet, write LBTC, and receive BTC on the Bitcoin network. There is no transfer of LBTC from Starknet to other networks. Starknet is not EVM compatible, so integration requires dedicated event handling, strict type coordination and bounds checking, and idempotent off-chain steps. As such, these Starknet-specific aspects formed the core of the audit modification.
Medium. Incompatible scriptPubKey length for P2WPKH in Starknet event decoder. The hard minimum of 31 bytes excludes correct assembly of 22 bytes of P2WPKH. The team adapted the decoding to better handle types smaller than 31 bytes. This eliminates false positives on validation and redemption failures.
Medium. An integer overflow can occur on 32-bit platforms when casting uint32→int in GetUnstake. This fix enforces safe target type boundaries and removes architectural dependencies, reducing the risk of negative indexes and panics in edge cases.
low. ABI type mismatch: u128 field amount_after_fee was decoded as uint64. Casting to a compatible type or explicit range validation removes silent truncation and incorrect downstream logic.
low. Possible slice out-of-bounds panic when handling pendingBytesLength in DecodeUnstakeOnchainMsgFromStarknetEvent. Length and upper bound checks were added to mitigate edge cases and protect the decoder from adversarial input.
low. Risk of truncation when casting pendingBytesLength→int in event decoder. Maximum checks and pendingBytes array length adjustments were introduced to prevent negative offsets and panics.
Notes. Starknet’s unreliable or missing logging issues in runNotaryd have been aligned to common patterns with other networks. This is expected to simplify operational monitoring and debugging.
Notes. Introductory comment for NewStarknetSepoliaLChainId has been corrected. This function returns SN_SEPOLIA instead of SN_MAIN. This promises to eliminate discrepancies between documentation and actual behavior.
Notes. Uninitialized StarknetConfigs maps in DefaultNotaryConfig are now explicitly initialized. This will hopefully prevent nil-map panics and ensure that Starknet’s default configuration is present.
In operation. Enhanced error handling in notarized configuration override and shutdown. Processes now signal override failures more clearly and shut down cleanly. This is expected to improve observability and reliability.
Where does the assumption of trust remain?
It is still important that the system relies on the Starknet event log to confirm actions. These logs are not part of Ethereum’s L1 state commitment and arrive via RPC. Therefore, the client infrastructure must:
- Built-in protection against log tampering and delay by RPC providers. Without this, off-chain components may accept incorrect redemptions/de-staking and release assets prematurely.
- Consider potential changes to log format, Starknet OS, and Cairo VM. This requires a strict parser and backwards compatibility.
- Don’t rely on a notary for payload deduplication. Consumers and smart contracts must guarantee no double deposits or double mints, and unstaking (one BTC transfer per unique request).
All of this is expected to make transparent bounds checking, idempotency, and explicit event source validation an integral part of the operational profile.
What is the conclusion?
Collectively, these are truly high-quality changes that reduce the blast radius of failures, improve code portability across environments, and simplify incident response. At the same time, the architectural risks associated with Starknet logs and RPC trust remain a matter of operational discipline. Addressing these requires idempotent protocols, deterministic parsers, limits on the number of checks, and clear rules for validators to return or absorb invalid objects.
Therefore, further reliability will largely depend on operational rigor when processing Starknet logs and maintaining idempotency at the on-chain/off-chain boundary. Stay tuned for the latest updates and opportunities in the new economy, crypto industry, and blockchain development.