Poseidon Parameter Reference

Poseidon Parameter Reference

Field Modulus • Round Constants

---

Poseidon is the primary hash function used throughout the SnarkSide protocol for:

• Intent hashing

• UTXO commitment generation

• Nullifier derivation

• Circuit-level constraint enforcement

Its algebraic design is optimized for zkSNARK performance, specifically low arithmetic complexity over prime fields and efficient constraint layout within R1CS-based systems like Circom.

This section outlines the exact Poseidon parameterization used in SnarkSide, including the field modulus, round configuration, and constant generation logic.

---

1. Field Modulus

All Poseidon operations in SnarkSide are performed over the BN254 scalar field (a.k.a. alt_bn128), which is the default elliptic curve supported by Ethereum precompiles and Circom.

Prime Field:

p = 21888242871839275222246405745257275088548364400416034343698204186575808495617

This prime defines the finite field 𝔽ₚ over which all arithmetic is executed.

• All elements must be reduced mod p

• All coefficients, constants, and state values remain in 𝔽ₚ

• SNARK-compatible (Groth16, PLONK) across EVM and L2 rollups

---

2. Poseidon Input Arity

Poseidon is configured for different input lengths depending on its use:

Use Case	Arity	Input Width
Intent hash	6	[side, leverage, notional, expiry, margin_commitment, salt]
Vault note commitment	8	[amount, pubkey_x, pubkey_y, direction, price, leverage, expiry, salt]
Nullifier generation	3	[commitment, secret, nonce]

Each configuration uses a dedicated Poseidon instantiation with appropriate rounds and constants.

---

3. Round Configuration

SnarkSide follows the Poseidon v1.0 spec and adapts the id-GMSS21 parameters, with the following round setup for each arity:

Arity	State Size	Full Rounds	Partial Rounds
3	4	8	57
6	7	8	60
8	9	8	63

• Full Rounds: Non-linear S-box applied to all state elements

• Partial Rounds: S-box applied to only the first element, others mixed linearly

Total constraints per round scale with state size.

---

4. S-Box Nonlinearity

Poseidon uses a fixed power S-Box: S(x) = x⁵ mod p

This exponentiation is:

• Efficient in SNARKs (e.g., implemented via 3 multipliers)

• Collision-resistant in small fields

• Compatible with R1CS constraint systems

All full and partial rounds apply the S-Box according to this logic.

---

5. MDS Matrix & Round Constants

The MDS matrix is a deterministic, invertible matrix that mixes the state after each round. It is generated using the "powers of a field generator" method.

Example (7x7 MDS matrix snippet):

[
  [1, 2, 4, 8, 16, 32, 64],
  [2, 3, 5, 9, 17, 33, 65],
  ...
]

The matrix must satisfy:

• Maximal branch number

• Non-singularity

• Efficient SNARK constraint layout

Round Constants

Poseidon's constants are derived via SHAKE-128 seed expansion with domain separation tags:

const poseidonConstants = generateConstants(arity, seed="snarkside-v1.3.4");

Each round includes an additive constant per state element, ensuring input- and structure-independence.

---

6. Implementation Libraries

SnarkSide uses the following libraries for Poseidon hashing:

• Circom: circomlib’s Poseidon templates for in-circuit hashing

• Node.js: circomlibjs Poseidon FFI bindings for JavaScript/TypeScript clients

• Rust: poseidon-rust for relayer-side batch hashing, WASM-compatible

All implementations are tested for consistency via Poseidon vector tests.

---

7. Poseidon Hash Function (Pseudocode)

function poseidon(input[]) {
  state = [0, ..., 0] // length = input.length + 1
  state[0] = input.length
  for (i = 0; i < input.length; i++) {
    state[i+1] = input[i]
  }

  for (r = 0; r < TOTAL_ROUNDS; r++) {
    // Add round constants
    for (i = 0; i < state.length; i++) {
      state[i] += round_constants[r][i]
    }

    // S-box application
    if (r < FULL_ROUNDS || r >= TOTAL_ROUNDS - FULL_ROUNDS) {
      for (i = 0; i < state.length; i++) {
        state[i] = state[i] ** 5 mod p
      }
    } else {
      state[0] = state[0] ** 5 mod p
    }

    // Mix with MDS
    state = MDS * state
  }

  return state[0]
}

---

8. Security Notes

• Poseidon parameters used in SnarkSide are resistant to statistical distinguishers and known collision attacks

• Field modulus aligns with Ethereum EVM precompile support (BN254)

• All intent and vault-level commitments use domain-separated Poseidon instances

• Round constants are versioned and committed to within circuit hashes

---

Conclusion

Poseidon is the cryptographic spine of SnarkSide. Every confidential trade, margin proof, or nullifier derives its integrity from this function. Our parameterization is tuned for EVM compatibility, SNARK efficiency, and ZK constraint minimalism, forming a secure and scalable privacy layer for decentralized perpetuals.