Starknet Specialized Scanner

Specialized security scanner for Starknet Cairo contracts. Extends the general Cairo Scanner with Starknet-specific patterns: account abstraction, contract upgrades via replace_class, component architecture, and the L1-L2 messaging bridge.

Why a Separate Starknet Scanner?

While the Cairo Scanner covers language-level patterns (felt arithmetic, Sierra safety), Starknet-specific features create unique attack surfaces:

Detection Capabilities

Starknet Account Abstraction

Every account on Starknet is a smart contract. This means custom validation logic:

#[starknet::contract(account)]
mod MyAccount {
    // REQUIRED: Validates transaction signature
    // If this returns successfully, the tx is considered valid
    #[external(v0)]
    fn __validate__(
        ref self: ContractState,
        calls: Array<Call>
    ) -> felt252 {
        // CRITICAL: Must verify the transaction signature
        // If this blindly returns VALIDATED, anyone can submit txs as this account
        let tx_hash = get_tx_info().unbox().transaction_hash;
        let signature = get_tx_info().unbox().signature;
        
        // Verify signature against stored public key
        assert(check_ecdsa_signature(tx_hash, self.public_key.read(), *signature.at(0), *signature.at(1)), 'invalid sig');
        
        starknet::VALIDATED
    }
    
    // REQUIRED: Executes the validated transaction
    #[external(v0)]
    fn __execute__(
        ref self: ContractState,
        calls: Array<Call>
    ) -> Array<Span<felt252>> {
        // Execute each call
        // Typically a loop over calls with call_contract_syscall
    }
}

Account Security Checklist

• __validate__ verifies transaction hash signature
• __validate__ uses stored public key (not hardcoded)
• Signature cannot be replayed (nonce handled by protocol)
• chain_id included in signature verification (cross-chain replay)
• Key rotation mechanism exists and is secure
• Multicall execution handles failures correctly (atomicity)

Contract Upgrade via replace_class_syscall

Starknet contracts can upgrade their logic using replace_class_syscall:

use starknet::replace_class_syscall;
use starknet::ClassHash;

#[external(v0)]
fn upgrade(ref self: ContractState, new_class_hash: ClassHash) {
    // CRITICAL: WHO can call this?
    self.ownable.assert_only_owner();
    
    // Replace the contract's class (logic) with new implementation
    replace_class_syscall(new_class_hash).unwrap();
    
    // Emit upgrade event
    self.emit(Upgraded { new_class_hash });
}

Upgrade Security

• replace_class_syscall protected by access control (owner, governance)
• Upgrade delay (timelock) implemented for critical contracts
• Storage layout documented and verified compatible across versions
• Upgrade event emitted

Component Architecture

Starknet components are reusable modules (similar to Solidity libraries with storage):

// Using OpenZeppelin components
#[starknet::contract]
mod MyContract {
    use openzeppelin::access::ownable::OwnableComponent;
    use openzeppelin::token::erc20::ERC20Component;
    
    component!(path: OwnableComponent, storage: ownable, event: OwnableEvent);
    component!(path: ERC20Component, storage: erc20, event: ERC20Event);
    
    #[storage]
    struct Storage {
        #[substorage(v0)]
        ownable: OwnableComponent::Storage,
        #[substorage(v0)]
        erc20: ERC20Component::Storage,
        // Custom storage
        my_value: felt252,
    }
}

Component Security

• All components initialized in constructor
• #[substorage(v0)] used correctly (automatic storage isolation)
• No manual storage access that could collide with component storage
• Component versions compatible with each other

L1-L2 Messaging

Starknet communicates with Ethereum L1 via asynchronous messaging:

L1-L2 Security Checklist

• L2 handler validates L1 sender (from_address in L1Handler)
• L1 handler validates L2 sender (message origin)
• Messages consumed exactly once (replay protection)
• Message format matches between L1 and L2 contracts
• Stuck message handling (cancellation mechanism exists)
• Fee handling on L1→L2 messages correct

Resources

• Starknet Patterns

Workflows

• Starknet Audit

See Also

• Cairo Scanner for Cairo language patterns
• Chain Guide: Starknet for chain context

Error Code Reference

Starknet-specific error codes and system errors encountered during audits.

Starknet OS / Sequencer Errors

Account Abstraction Errors

Starknet Contract Errors (OpenZeppelin Cairo)

L1↔L2 Messaging Errors

Troubleshooting