Chain parameters

Network

Parameter	Value
Network	Frost
Chain ID	8141 (0x1fcd)
RPC	https://rpc.frostfi.net
Explorer	https://explorer.frostfi.net
Faucet	https://faucet.frostfi.net
Currency	Frost (FROST), 18 decimals
Block cadence	Load-driven: about one block per second at ordinary load, several per second under load, one empty heartbeat block per 1,200 blockless commits when idle — see Consensus
Block gas limit	60,000,000
Priority fee	Always 0 — the chain is fee-blind

EVM

Frost activates every Ethereum fork at genesis, up to and including Osaka. There is no historical fork schedule to reason about: from block 0, the EVM is at its current feature level, with shanghaiTime, cancunTime, pragueTime and osakaTime all zero.

One Frost-native fork exists, also active from genesis:

Fork	Activation	Effect
Frost	genesis	Witness segregation — activates the strippedTransactionsRoot header field.

The practical consequence is that all Osaka-level opcodes and precompiles are available, including the BLS12-381 set and P256VERIFY. See Precompiled contracts.

Transaction types

Type	Name	Status
0x00	Legacy	Supported
0x01	EIP-2930 access list	Supported
0x02	EIP-1559	Supported
0x03	EIP-4844 blob	Not accepted — refused at submission and skipped by block builders; blob sidecars have no data-availability path through Frost consensus
0x04	EIP-7702 set code	Supported — Prague is active at genesis
0x06	EIP-8141 frame transaction	Frost’s post-quantum path

An EIP-7702 delegation is authorised by a secp256k1 signature, so it does not make an EOA quantum-safe. It is available because Frost runs the standard fork set, not because it is a post-quantum path.

See Transaction type 0x06.

Post-quantum verifier gas

Consensus-critical

These prices are inputs to block gas accounting. A network where some nodes compile one value and some another does not degrade — it splits. They can only change on a fresh chain.

Precompile	Address	Gas	Input size
VERIFY_MLDSA65	0x14	16,000	5,293 B
VERIFY_MLDSA44	0x15	10,500	3,764 B

Both are priced at ecrecover throughput parity on validator-class hardware. See Pricing the verifiers.

ML-DSA encoding sizes

Parameter set	Public key	Signature
ML-DSA-44	1,312 B	2,420 B
ML-DSA-65	1,952 B	3,309 B

Standard FIPS 204 encodings. The message is always 32 bytes.

Frame transaction limits

Also consensus-critical — these are enforced on the block-processing path, not merely at admission.

Parameter	Value	Meaning
MAX_FRAMES	64	Maximum frames per transaction.
MAX_SIGNATURES	128	Maximum signature entries per transaction.
MAX_ARBITRARY_MSG_SIGNATURE_SIZE	4,096 B	Per-entry cap on non-elidable (permanent) witnesses.
MAX_ELIDABLE_SIGNATURE_SIZE	16,384 B	Per-entry cap on the elidable witness channel.
MAX_ELIDABLE_TOTAL_SIZE	16,384 B	Per-transaction cap on elidable witnesses.
FRAME_TX_PERMANENT_SIG_BYTE_GAS	40	Surcharge per permanent witness byte, on top of EIP-7623 calldata gas.

Admission budgets

These are not consensus rules. They bound work at the submission gate, and a node running a different value disagrees about what to accept into a mempool, never about what a block means.

Parameter	Value	Meaning
MAX_VERIFY_GAS	100,000	Gas budget for the VERIFY-frame prefix during validation simulation.

Gas accounting for frame transactions

  15,000                       intrinsic
+    475 × frame count
+ calldata gas                 EIP-7623, including signature bytes
+ per-signature verification   2,800 secp256k1 · 6,700 P256 · 0 ARBITRARY
+ permanent-witness surcharge  40 per byte, non-elidable witnesses only
+ Σ frame gas limits

The transaction-level gas_limit is a signed field: it is covered by the sig-hash, validity requires it to be at least the computed total, the payer is charged it up front, and unused gas is refunded.

Each frame’s own gas_limit also funds the frame-entry access charge: before a frame dispatches, the resolved target’s EIP-2929 account access — 2,600 gas cold, 100 warm — is debited from that frame’s gas, and the target is warm from then on (a reverting frame un-warms it). A frame whose limit cannot cover the charge halts at entry with all of its gas consumed.

Account derivation

Parameter	Value
CREATE2 factory	0x4e59b44847b379578588920cA78FbF26c0B4956C
Salt domain	frost/account/v1
Code ID — fixed ML-DSA-44	0x01
Code ID — fixed ML-DSA-65	0x02
Code ID — rotatable v2	0x03
Code ID — slim hash-commit v3	0x04
Nonce after materialising (v2)	3

salt    = keccak256("frost/account/v1" ‖ ACCOUNT_CODE_ID ‖ uint64_le(index))
address = keccak256(0xff ‖ factory ‖ salt ‖ keccak256(initcode))[12:]

See Account contracts.

Consensus

Parameter	Value
Protocol	Mysticeti V2 (DAG-based BFT), with per-transaction voting switched off — V1 blocks and pass-through finalization
Committee	4 validators, static (no reconfiguration)
Block signature scheme	FN-DSA-512 on the live network; ML-DSA-65 at genesis (see below)
Checkpoint root schemes	ML-DSA-65 and SLH-DSA-SHA2-192s — both must verify
Transport key exchange	X25519MLKEM768, offered as the only group
Transport identity	ML-DSA-65 raw public keys (RFC 7250)

Block keys are scheme-tagged and rotating, so the block signature scheme is a property of the current key schedule rather than of the chain definition. frost-node keygen mints an ML-DSA-65 genesis block key; validators then rotate to a compact FN-DSA-512 successor as an ordinary per-validator rotation. The live network completed that rollout, so blocks you fetch today carry FN-DSA-512 signatures while a freshly generated key does not.

FN-DSA-512 is a pre-standard scheme — Falcon as it stands before FIPS 206 — and carries its own draft scheme ID, distinct from the FIPS 206 identifier it will eventually get. Being scheme-tagged is what makes that safe: the ID names the exact encoding, so a future migration is another rotation rather than a network event.

Chain-wide manifest values

These are fixed when a chain is created and change only on a fresh chain.

Parameter	Value
Checkpoint interval	600 commits
Transaction voting	Disabled — V1 blocks, pass-through finalization
Idle heartbeat	One empty block after 1,200 consecutive blockless commits
Checkpoint-freshness alarm / halt	3 / 10 checkpoint intervals
Block-key validity window	1,000,000 rounds; a validator rotates at 80 % of the window
Block-key rotation scheme	FN-DSA-512 (genesis block keys are ML-DSA-65)

Block cadence follows from these rather than from a fixed slot time: the driver closes a block when consensus time advances past the parent’s timestamp, or sooner when a per-block budget fills, and the idle heartbeat keeps checkpoints, pruning anchors and key rotation advancing while nothing is being sent.

See Consensus and blocks and Two-tier consensus keys.

Verifying these values

Anything network-level can be checked directly against the chain:

curl -s https://rpc.frostfi.net -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s https://rpc.frostfi.net -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_maxPriorityFeePerGas","params":[]}'

The consensus-critical constants on this page are checked in CI against the chain definition, so a value that drifts fails the documentation build rather than quietly misleading you.