extract shared cairo-native-syscalls crate

[avi-starkware]

Summary

Extracts the StarknetSyscallHandler trait and its supporting types into a new workspace-local crate, cairo-starknet-syscalls. Both cairo-native and sierra-emu re-export from it, so the two crates' types are now nominally identical — a single handler impl can drive both runtimes without an adapter.

Replaces the bridge approach from #1597 / #1607: with this PR landed, the bridge file isn't necessary, and #1612's Emu arm can call the cairo-native handler directly. Those follow-ups land in subsequent PRs in this stack.

Layout

cairo-starknet-syscalls/
  Cargo.toml      # deps: serde, starknet-types-core
  src/lib.rs      # types + trait

Sibling to test_utils/ at workspace root — fits the repo's existing convention for shared, non-binary, non-debug-tool crates.

What moved

From cairo-native/src/starknet.rs and sierra-emu/src/starknet/* into the new crate:

• Types: U256, BlockInfo, TxInfo, TxV2Info, TxV3Info, ResourceBounds, ExecutionInfo, ExecutionInfoV2, ExecutionInfoV3, Secp256k1Point, Secp256r1Point.
• Trait: StarknetSyscallHandler, including its existing default cheatcode impl.
• Constructors: Secp256k1Point::new / Secp256r1Point::new (pure-data).
• Alias: SyscallResult<T>.

Repr / serde / derive layouts preserved exactly (#[repr(C, align(16))] on U256, Secp256{k1,r1}Point).

What stayed put

• cairo-native: ArrayAbi, Felt252Abi, DummySyscallHandler, the runtime/codegen vtables (handler::StarknetSyscallHandlerCallbacks, cairo_native__vtable_cheatcode, etc.) — all cairo-native-specific.
• sierra-emu: StubSyscallHandler, StubEvent, ContractLogs, and the VM eval logic.

Value-conversion methods

Sierra-emu previously had impl <Type> { fn into_value(self) -> Value, fn from_value(v: Value) -> Self } on each type. Inherent impls can't follow the type into a foreign crate, so these become free functions in a new sierra_emu::starknet::value_conv module:

Before	After
U256::from_value(v)	u256_from_value(v)
u.into_value()	u256_into_value(u)
Secp256k1Point::from_value(v)	secp256k1_point_from_value(v)
info.into_value(felt_ty)	execution_info_into_value(info, felt_ty)
...	(same pattern for each type)

Call sites in sierra-emu/src/vm/starknet.rs and cairo-native/src/metadata/trace_dump.rs updated.

Backwards compatibility

• cairo-native users: backwards-compatible. cairo_native::starknet::U256, …::StarknetSyscallHandler, etc. still resolve via pub use. Existing impls and callers compile unchanged. No semver-breaking change.
• sierra-emu users: breaking — the inherent into_value / from_value methods are gone. Sierra-emu is debug-only and not an externally published API surface; callers in this repo are all updated.
• The 11 per-type files under debug_utils/sierra-emu/src/starknet/* are deleted now that the struct defs live in the shared crate.

Stack

1. align sierra-emu StarknetSyscallHandler trait/types with cairo-native #1610 — align trait/type surfaces ← prerequisite
2. this PR — extract the shared crate
3. add ContractExecutor dispatch enum (Aot + Emu) #1612 — ContractExecutor dispatch enum without the bridge (supersedes add ContractExecutor dispatch enum (Aot + Emu) #1598 / add ContractExecutor dispatch enum (Aot + Emu) #1608)
4. add run_with_libfunc_profile + AotWithProgram variant for ContractExecutor #1613 — run_with_libfunc_profile + AotWithProgram (supersedes add run_with_libfunc_profile + AotWithProgram variant for ContractExecutor #1599 / add run_with_libfunc_profile + AotWithProgram variant for ContractExecutor #1609)

Test plan

• cargo check --workspace --all-features clean
• cargo check -p sierra-emu --all-targets clean
• CI green

---

This change is 

[github-actions]

✅ Code is now correctly formatted.

[orizi]

@orizi reviewed 15 files and all commit messages, and made 4 comments.
Reviewable status: 15 of 21 files reviewed, 4 unresolved discussions (waiting on avi-starkware, TomerStarkware, and Yoni-Starkware).

---

cairo-native-syscalls/Cargo.toml line 2 at r1 (raw file):

[package]
name = "cairo-native-syscalls"

cairo-starknet-syscalls maybe? the native here is completely irrelevant.

---

cairo-native-syscalls/src/lib.rs line 179 at r1 (raw file):

    pub x: U256,
    pub y: U256,
    pub is_infinity: bool,

i still don't understand why is this bool needed.

Code quote:

    pub is_infinity: bool,

---

debug_utils/sierra-emu/src/starknet.rs line 138 at r1 (raw file):

        _remaining_gas: &mut u64,
    ) -> SyscallResult<Vec<Felt>> {
        unimplemented!()

add reasoning in each unimplemented.

Code quote:

        unimplemented!()
    }

    fn get_class_hash_at(
        &mut self,
        _contract_address: Felt,
        _remaining_gas: &mut u64,
    ) -> SyscallResult<Felt> {
        unimplemented!()
    }

    fn meta_tx_v0(
        &mut self,
        _address: Felt,
        _entry_point_selector: Felt,
        _calldata: &[Felt],
        _signature: &[Felt],
        _remaining_gas: &mut u64,
    ) -> SyscallResult<Vec<Felt>> {
        unimplemented!()

---

debug_utils/sierra-emu/src/starknet/value_conv.rs line 12 at r1 (raw file):

use crate::Value;

pub fn u256_into_value(x: U256) -> Value {

doc all fns

[avi-starkware]

cairo-native-syscalls/src/lib.rs line 179 at r1 (raw file):

Previously, orizi wrote…

i still don't understand why is this bool needed.

The is_infinity flag exists on cairo-native's Secp256k1Point (it's part of the published trait surface and the repr(C, align(16)) MLIR ABI). To let cairo-native and sierra-emu share one trait without touching the cairo-native side, the unified struct in cairo-starknet-syscalls keeps the flag.

[avi-starkware]

cairo-native-syscalls/Cargo.toml line 2 at r1 (raw file):

Previously, orizi wrote…

cairo-starknet-syscalls maybe? the native here is completely irrelevant.

I renamed it, but I am not sure cairo-starknet-syscalls is a better name.
This syscall handler is only used by cairo-native (and cairo-native-related crates) because the cairo-vm processes syscalls through the hint processor and has a completely different flow.

So I agree these syscalls have nothing inherently "native" about them, but this trait is only relevant to cairo native (btw when implementing this trait in the sequencer repo, it is aliased NativeSyscallHandler), so it might be clearer to have a cairo-native prefix in its name.

[avi-starkware]

debug_utils/sierra-emu/src/starknet.rs line 138 at r1 (raw file):

Previously, orizi wrote…

add reasoning in each unimplemented.

Done.

[avi-starkware]

debug_utils/sierra-emu/src/starknet/value_conv.rs line 12 at r1 (raw file):

Previously, orizi wrote…

doc all fns

Done.

[orizi]

@orizi partially reviewed 8 files and all commit messages, made 2 comments, and resolved 4 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on TomerStarkware and Yoni-Starkware).

---

cairo-native-syscalls/Cargo.toml line 2 at r1 (raw file):

Previously, avi-starkware (Avi Cohen) wrote…

I renamed it, but I am not sure cairo-starknet-syscalls is a better name.
This syscall handler is only used by cairo-native (and cairo-native-related crates) because the cairo-vm processes syscalls through the hint processor and has a completely different flow.

So I agree these syscalls have nothing inherently "native" about them, but this trait is only relevant to cairo native (btw when implementing this trait in the sequencer repo, it is aliased NativeSyscallHandler), so it might be clearer to have a cairo-native prefix in its name.

you are literally working here to make it work for sierra-emulation - this still has nothing to do with native directly.
doesn't even matter if it is defined within the native workspace, same way that they didn't .
same way you don't call it cairo-native-sierra-emu.