thecoding.pool.near is now running nearcore v2.14 voting starts nov 4. here's what changes ↓ + gas rebate 30% → 0% (100% burned) + post-quantum signatures go native + storage proof cap on all receipt actions + DelegateV2 removed ↓ --- nearcore 2.14.0 went out yesterday (26th): a protocol upgrade release (protocol version 86 → 88, in two steps) with a database migration on top. the upgrade alone doesn't do anything, though. it's a network-level vote and enough validators need to upgrade for it to apply. if the vote passes, the minority of validators who didn't upgrade go out of sync. + validators start voting for protocol version 87 on wed, nov 4, 00:00 utc + voting for version 88 starts fri, nov 6 + if voting succeeds within an epoch, activation follows ~7-14 hours after that epoch ends (in the next epoch) ‼️ operators: upgrade before nov 4. and start the node read-write once. the database migrates in place (49 → 51) on startup, and a read-only process against an old database refuses to start. i've wrote a few posts and community forum comments on the gas rebate reduction, which is a meaningful tokenomics change to $NEAR this is part of what is shipping in this release. let's take a look into v2.14.0 in more details now ↓ --- 1 → the 30% gas rebate is gone until now, every call to a smart contract required gas and 30% of that gas was paid back to the contract's account. a small protocol reward to whoever deployed it. 70% was burned, reducing the tokens from circulation. with 2.14, that goes to 100% of execution fees burn. zero for the smart contracts reward. + users → nothing changes. same fees, same experience, nothing to do + devs → that revenue stream is gone. the thing is, for most it was already dust (proposal data showed only ~14 contracts clearing 100 NEAR in a month). the real caveat is security: some contracts counted rebates in their storage staking math. these will need to re-check their strategy. i flagged this in a post when the RC came out. + tokenholders → cleaner, simpler tokenomics. more NEAR being burned as the network activity increases. currently, community math puts the extra burn at around 1% of protocol revenue. the real win is simplicity, and retiring a mechanism that doesn't fit NEAR's sharded-contract future. this was HSP-027, ratified on house of stake (i voted FOR it). --- 2 → post-quantum signatures go native this is the one i'm most excited about. and the one getting the least attention. 2.14 adds an ml_dsa_verify host function: contracts can now verify FIPS 204 ML-DSA-65 signatures on-chain. ML-DSA is NIST's post-quantum signature standard. why it matters: quantum computers could break the elliptic-curve signatures behind basically every chain (ed25519, ECDSA). not today. maybe not this decade. but migrating a live blockchain's crypto is slow -- the chains that wait for the emergency to ship a fix will have waited too long. NEAR has built for that since the mainnet launch, making it easier for NEAR accounts to rotate private keys when needed. with nearcore's v2.14.0 NEAR's runtime learns the new format natively (ml_dsa_verify): + signature: 3309 bytes + public key: raw 1952 bytes + returns 1 for valid, 0 for invalid + cost: 540 Ggas base + 11 Mgas per byte -- native speed, not WASM speed and it doesn't come alone: the same release stabilizes universal accounts with a post-quantum-safe derivation. all that while the industry still writes post-quantum thinkpieces. NEAR is already shipping the solutions. live on mainnet and improving. for devs: post-quantum auth for agents and bridges, PQ-signed attestations verified inside contracts, migration paths ready before the threat stops being theoretical. --- 3 → the 4 MB storage proof limit now covers every action context: NEAR runs stateless validation. validators verify chunks using storage proofs (the evidence that the data a receipt touches actually exists) instead of holding full state. before 2.14, the per-receipt proof limit (4 MB) was only enforced on FunctionCall actions. from 2.14, it applies to EVERY action in a receipt, checked after each one. cross the line → the receipt fails right there with the new ReceiptStorageProofSizeExceeded error, and the remaining actions don't run. no more oversized proofs through the back door via other action types. predictable receipt bounds, healthier chunks, one less DoS surface. devs decoding ActionErrorKind: new variant to handle. --- 4 → DelegateV2 is removed DelegateV2 is a meta-transaction action introduced in 2.13.0, now removed. new transactions carrying it are rejected outright with a new error. the why is the interesting part: its inner nonce advanced a gas key of the delegate sender and the SPICE pending transaction queue doesn't track gas key nonces, it only reads the outer transaction's signer. this could quickly become an accounting hole. not anymore. the details: + receipts already in flight across the upgrade still complete + gas keys can no longer sign meta transactions at all + the types stay in the codebase, holding a place for a future version i respect the core team acknowledging that and removing the feature one release after shipping it. bugs need to be fixed regardless of ego. doing it now instead of after mass adoption is exactly what protocol maintenance should look like. also in 2.14: universal accounts (0u) stabilized, early chunk-producer reassignment (dead producers lose slots mid-epoch, not at the boundary), and sha3_256/384/512 host functions (take a look on the release notes for the full list) --- the rebate removal is the right call. it was an interesting economics experiment that doesn't fit where NEAR is going: global contracts, sharded contracts, rebates scattered across thousands of user-owned accounts. small devs losing a small stream is a real cost that some people flagged in governance discussions. people need to understand the tradeoffs. ml_dsa_verify is the sleeper of this release. crypto agility at the protocol level is boring infrastructure that not many people care about... i do. it's the boring kind that decides which projects are still standing in 10 years. NEAR is. the proof limit and the DelegateV2 removal are the least sexy changes and just as important: protocol hygiene and housekeeping. beautiful time to be building on this chain. --- i run a NEAR validator: thecoding.pool.near (stake with me via app.thecoding[.]dev) and also a devops business on thecoding[.]dev, helping builders and teams with technical content, documentation, and user/dev education. visit the website to discover how to start working with me.