NAN 003: A Smoother EVM for Sai, Passkey Signing, and Zero Gas with v2.11.0
Posted by Unique on 2026-02-11. Release: v2.11.0. Prior mainnet upgrade: v2.9.0.
Summary
- More accurate EVM transaction results: explorers and wallets should no longer label some successful EVM transactions as "failed" due to a Cosmos SDK gas-meter edge case.
- Expanded "Zero Gas" onboarding: governance can allowlist specific contracts that anyone can call with zero gas balance, as long as the call sends no value (
value == 0). - Passkeys for smart accounts (developer foundation): contracts, SDK, and bundler tooling for ERC-4337-style flows secured by P-256 passkey signatures.
- Cleaner precompile gas behavior: more predictable gas reporting and safer out-of-gas handling (no node crashes from certain meter panics).
- Consensus safety improvements: removed nondeterministic map iteration in consensus-critical paths to reduce apphash mismatch risk.
- Security patch: upgraded CometBFT to a patched release for CSA-2026-001 (Tachyon).
Before we go deeper: quick definitions
If you already know these, skip ahead.
Gas Gas is the "execution fee" you pay to run a transaction on the EVM. Most chains require you to hold some native token to pay it. That's a major onboarding hurdle for new users.
Transaction success vs failure (revert) A transaction can be included in a block and still "fail" at execution time. In the EVM, that usually means the contract reverted. You still pay gas for attempted execution.
Receipt A receipt is the chain's record of what happened when the transaction was executed. It exists whether the transaction succeeded or failed. The receipt includes a status flag (success or failure), gas used, and logs.
Precompiles Precompiles are built-in functions exposed at special addresses. They are often used for cryptography and system-level features, and they need to report gas correctly so tools can estimate costs and traces make sense.
CometBFT CometBFT is the consensus engine used underneath Nibiru (responsible for block production and finality). Bugs here can become network-level risks.
1) Fix: EVM transactions no longer "look failed" when they succeeded
What users were seeing
Sometimes a transaction would execute successfully in the EVM, but explorers or receipts would show it as failed. That breaks trust instantly because users do not care why it happened. They only see "failed" and assume funds or actions did not go through.
What was happening under the hood
Nibiru runs EVM execution inside a Cosmos SDK application framework. In certain edge cases, the Cosmos SDK gas meter could throw an error late in processing, after the EVM already produced a successful result. That late error could incorrectly flip the final reported status.
What changed in v2.11.0
The chain now treats the EVM execution result as the ground truth for the success status. If a Cosmos SDK gas-meter issue happens after a successful EVM execution, it will be logged, but it will not rewrite history and label the transaction as failed.
Why this matters
- Fewer false "failures"
- Cleaner support and debugging
- A more credible EVM surface for apps and users
2) Expanded "Zero Gas" calls, with context and guardrails
The problem this addresses
On most chains, a new user has to do this before they can do anything:
- get the native token
- fund the wallet
- then finally interact with the app
That sequence kills onboarding. People bounce before they ever try the product.
What "Zero Gas" means on Nibiru
Nibiru supports a controlled "gasless" path for specific contract calls. In plain language:
If governance approves a contract as "always zero gas," then any user can call that contract even if their wallet has no gas token, as long as the call sends no value (value == 0).
So users can perform certain onboarding actions without first acquiring gas.
What changed in this release
v2.11.0 broadens the "gasless" capability via a governance allowlist of contracts called:
ZeroGasActors.always_zero_gas_contracts
Once a contract is on that list:
- any sender can call it
- the sender can have no gas balance
- the call must send zero value
- normal safety checks still apply (this is not a bypass for everything)
Why this matters
- Apps can build "first action" onboarding flows that feel normal
- Teams can limit gasless privileges to specific contracts and functions by design
- Governance retains control, which reduces abuse risk
3) Passkeys and smart accounts (ERC-4337 style), explained simply
The problem this addresses
Seed phrases and private keys are a major UX wall. Passkeys are the opposite: they are familiar, secure, and built into modern devices.
What shipped in v2.11.0
This release ships developer building blocks for passkey-secured smart accounts using P-256 signatures, in an ERC-4337-style flow:
- a passkey-secured smart account contract (
PasskeyAccount) - a factory to deploy accounts (
PasskeyAccountFactory) - a TypeScript SDK for creating "UserOperations"
- bundler tooling for submitting those operations end-to-end
What this means today
This is primarily an integrator foundation: apps can begin prototyping passkey onboarding now. End-user experiences will appear as wallets and apps integrate these flows.
Why this matters
It is a practical step toward "log in with your device" UX, while keeping a smart-account model that can support richer security policies over time.
4) Precompiles: more predictable gas, cleaner failures
Two improvements that make developer tooling and node behavior better:
- Gas accounting is cleaner for dynamic precompiles, so tracing and estimation behave more like developers expect.
- Out-of-gas panics are recovered into normal execution errors instead of crashing the node in certain bounded-meter cases.
Why this matters:
- fewer confusing debugging sessions
- better reliability under load
- better UX for apps that depend on precompiles
5) Consensus determinism: removing "random order" behavior
Go maps do not iterate in a consistent order. If code relies on map iteration order in a consensus-critical path, different nodes can process the same data in different orders, producing different results. That can lead to apphash mismatches, which is one of the worst classes of operational issues because it looks like "the chain disagrees with itself."
This release removes nondeterministic map iteration in places like:
- oracle processing paths
- EVM state commit paths
Why this matters:
- fewer rare, intermittent consensus issues
- more stability on long-running nodes
6) Security patch: CometBFT CSA-2026-001 (Tachyon)
v2.11.0 upgrades CometBFT to a patched version for a critical consensus-level advisory. If you run a validator or operate infrastructure that depends on correct block timing assumptions, treat this upgrade as high priority.
Key Takeaways
- Transaction status should be less confusing and more accurate.
- More apps can onboard you without making you buy gas first.
- Onboarding flows do not start need to start with "go buy the gas token."
- Users can prototype passkey smart accounts with a real contracts + SDK + bundler stack.
- Precompile and gas-meter handling should behave more cleanly under load.