Bug Report
Cairo version: 2.16.1 (scarb 2.16.1)
Current behavior:
Values larger than the BN254 field prime (p = 2188...617) but within the STARK field are accepted without any warning. While these values are technically valid felt252 elements in Cairo's STARK field, applications porting from BN254-based systems (Circom, Noir) could silently get completely different results because the same value represents a different field element in each system.
Expected behavior:
At minimum, documentation should warn about cross-field incompatibility. Optionally, a flag or warning could alert developers when input values exceed common field primes used by other ZK systems.
Steps to reproduce:
- Create a Scarb project with this circuit:
#[executable]
fn main(a: felt252) -> felt252 {
(a * a) + 1
}
- Configure
Scarb.toml:
[package]
name = "test"
version = "0.1.0"
edition = "2024_07"
[dependencies]
cairo_execute = "2.16.1"
[cairo]
enable-gas = false
[[target.executable]]
- Run with a value that exceeds BN254 prime but is valid in STARK field:
# p_bn254 - 1 = 21888242871839275222246405745257275088548364400416034343698204186575808495616
scarb execute --arguments="21888242871839275222246405745257275088548364400416034343698204186575808495616" --print-program-output
# Cairo outputs a value computed in STARK field
# Same value in Circom/Noir (BN254):
# Circom: output = 2 (since p-1 ≡ -1, and (-1)²+1 = 2)
# Noir: output = 2
# Cairo: output = DIFFERENT VALUE (different field arithmetic)
Related code:
#[executable]
fn main(a: felt252) -> felt252 {
(a * a) + 1
}
Other information:
Cross-compiler comparison:
| Input |
Circom (BN254) |
Noir (BN254) |
Cairo (STARK) |
| a = p_bn254 - 1 |
2 |
2 |
Different value |
| a = p_bn254 + 1 |
2 (reduces mod p) |
Rejects |
Different value |
This is not a correctness bug — Cairo's arithmetic is correct for the STARK field. However, the silent acceptance of values that would be invalid or different in BN254-based systems creates a cross-system portability risk. Applications migrating between Circom/Noir and Cairo could silently produce wrong results.
Bug Report
Cairo version: 2.16.1 (scarb 2.16.1)
Current behavior:
Values larger than the BN254 field prime (p = 2188...617) but within the STARK field are accepted without any warning. While these values are technically valid felt252 elements in Cairo's STARK field, applications porting from BN254-based systems (Circom, Noir) could silently get completely different results because the same value represents a different field element in each system.
Expected behavior:
At minimum, documentation should warn about cross-field incompatibility. Optionally, a flag or warning could alert developers when input values exceed common field primes used by other ZK systems.
Steps to reproduce:
Scarb.toml:Related code:
Other information:
Cross-compiler comparison:
This is not a correctness bug — Cairo's arithmetic is correct for the STARK field. However, the silent acceptance of values that would be invalid or different in BN254-based systems creates a cross-system portability risk. Applications migrating between Circom/Noir and Cairo could silently produce wrong results.