CODE_COLOR: CODE_YELLOW_TESTNET
RELEASE_VERSION: 2.13.0-rc.1
PROTOCOL_UPGRADE: TRUE
DATABASE_UPGRADE: TRUE
SECURITY_UPGRADE: FALSE

Protocol Changes

• Opt-in strict nonce mode for transactions. A transaction may opt in to require its nonce be exactly the previous nonce for that access key plus one; such transactions are rejected when the nonce repeats or skips a value. Transactions that do not opt in keep the existing monotonic nonce behavior. (#15361, #15402)
• Stabilized the FIPS 204 ML-DSA-65 post-quantum signature scheme as a third transaction-signature and access-key scheme alongside ed25519 and secp256k1. Public keys are stored on-trie as a 32-byte SHA3-256 hash rather than the full 1952 bytes, and ML-DSA-65 signature verification is charged an extra 100 Ggas at transaction conversion to cover its higher verification cost. (#15731)
• Ensure delegate action returns the correct error consistently. (#15458)
• Fix action_delete_account not accounting for the global contract identifier when checking the account deletion storage limit. For accounts using a global contract, the check overcounted storage usage by the identifier size (32 bytes, or the account id length for GlobalByAccount), so they were slightly harder to delete. (#15752)
• Fix a bug in receiver verification for a DeterministicStateInitAction inside a DelegateAction that made it impossible to create deterministic accounts through meta transactions. (#15812)
• Stabilized gas keys (NEP-611): a new access key type that carries a pre-funded NEAR balance and up to 1,024 independent nonce sequences. Transactions signed with a gas key pay gas costs from the key's balance rather than the signer's account balance. (#15183)
• Added a new DelegateV2 meta-transaction action that lets gas keys (NEP-611) sign relayed (meta) transactions. Unlike the existing Delegate action, whose nonce is the signing access key's plain nonce, DelegateV2 carries a TransactionNonce that selects either the access key's nonce or one of a gas key's parallel nonce sequences by index. The signed payload is versioned so future variants can be added without a new action type. (#15904, #15905, #15906)
• Stabilized the promise_yield_create_with_id and promise_yield_resume_with_yield_id host functions, which let a contract supply its own deterministic 32-byte yield ID when creating a yield/resume promise instead of storing the runtime-generated data_id in state. This avoids the storage cost of tracking yields, enabling use cases such as in-contract mempools. (#15602)
• Increased the cost of creating new accounts from ~0.0008 NEAR to ~0.007 NEAR (NEP-642), paid in gas. The gas will now be purchased at a higher price than before (at least min_gas_purchase_price = 0.001 NEAR/TGas) to cover the cost of creating new accounts. Gas will still be burned at the same price as before (usually min_gas_price = 0.0001 NEAR/TGas) and the price difference will be refunded, so the total cost of a transaction will stay the same. However the balance required to start a transaction will be 10x higher than before, as the price at which gas is purchased will be 10x higher than before. For any operation which creates an account, the protocol will deduct ~0.007 NEAR from the gas refund to cover the cost of creating an account.
• Meta transactions with gas key support via Action::DelegateV2. (#15183)
• Extend the existing sticky chunk-producer-to-shard assignment to resharding boundaries. Previously stickiness was keyed by ShardIndex, which is unstable across a shard layout change; switch to keying by ShardId, and when a shard splits distribute the parent's chunk producers across its child shards using greedy stake-balanced bin-packing. Reduces unnecessary state sync after resharding.
• Skip transactions whose hash already appeared earlier in the same chunk. A transaction hash is also its outcome id, and outcomes are committed (via the chunk outcome root) keyed by that id.
• Recompute block_ordinal and epoch_sync_data_hash against local chain state when validating received block headers.
• Emit ExecutionMetadata::V4 from chunk producers. V4 carries a per-action Vec<AccountContract>: one entry per action in the receipt, recording the contract attached to the receiver account immediately before that action ran. Captured for every action kind (not just FunctionCall), so consumers can see what code an account had even on receipts that did not invoke a contract. AccountContract::None is emitted when the account has no contract deployed, when it did not exist (e.g. the CreateAccount slot that materialized it), or for unexecuted trailing slots after a mid-receipt failure. Order matches the receipt's actions vector. (#15822)
• Authenticate ContractCodeResponse messages with a chunk-producer signature, matching the signed-message pattern already used by ChunkContractAccesses and ContractCodeRequest.
• Stabilized continuous epoch sync: epoch sync proofs are maintained incrementally at each epoch boundary, and block headers are garbage-collected on non-archival nodes. Enabling this feature performs a DB migration (48 → 49) to store the compressed proof. (#15476)
• Stabilized dynamic resharding: shards are now split automatically at epoch boundaries based on runtime state size, without requiring a protocol upgrade to ship a new hard-coded shard layout. (#15823)
• Clamp the gas admission check used when forwarding buffered receipts under congestion control to allowed_shard_outgoing_gas, so a receipt whose gas exceeds the per-shard outgoing budget can still be forwarded when the shard is in the "allowed" set. (#15924)

Non-protocol Changes

• EXPERIMENTAL_receipt_to_tx accepts optional block_height, shard_id, window hint params. On a column miss with a hint set, the handler scans execution outcomes around the hint. Best-effort: long emit-to-execute delays may return UnknownReceipt instead of a terminal tx. Resharding boundaries are handled. New node-config knobs: receipt_to_tx_max_hint_window (default 20), receipt_to_tx_max_hop_distance (default 20), receipt_to_tx_max_outcomes_per_request (default 20_000). Operators serving cold-archival queries should consider raising these.
• Added pagination to EXPERIMENTAL_view_state and the view_state query. The request takes after_key_base64 and limit, and the response returns last_key to fetch the following page. (#15743)

Protocol upgrade voting

This release upgrades the protocol version from 84 to 85.
Voting for protocol version 84 will start on Tuesday June 30th 00:00 UTC.
To continue participating in consensus, you need to upgrade your node before this time.

If voting succeeds in one epoch, the protocol upgrade to version 85 is expected to happen 7-14 hours after the voting epoch ends.