NEAR Protocol lands native P256/passkey cryptography at the runtime level and introduces a Pending Transaction Queue proposal that could reshape transaction ordering for developers.

# --- NEP-635: Verifying a P256 (WebAuthn/Passkey) signature on NEAR ---
# This walkthrough shows how a smart contract can use the new
# P256 host function to verify a passkey-generated signature.

# Step 1: Import the new P256 host function from the NEAR SDK.
# The function is exposed at the runtime level, so SDK bindings
# will surface it as a near_sdk or env-level call.
# (Check near-sdk-rs >= 5.x or near-sdk-js nightly for support.)

use near_sdk::env;

# Step 2: Your contract receives a WebAuthn assertion from the client.
# The client signs a challenge using the device's passkey (P256 key).
# You'll need three things:
#   - message:    the raw authenticator data + client data hash (the signed payload)
#   - signature:  the P256 ECDSA signature (64 bytes, r || s)
#   - public_key: the P256 public key registered at account creation (65 bytes, uncompressed)

#[near(contract_state)]
pub struct PasskeyAccount {
    pub registered_pubkey: Vec<u8>, // 65-byte uncompressed P256 public key
}

#[near]
impl PasskeyAccount {
    /// Verify a passkey signature against the registered public key.
    pub fn verify_passkey(&self, message: Vec<u8>, signature: Vec<u8>) -> bool {
        # Step 3: Call the new host function.
        # env::p256_verify takes (sig, msg, pub_key) and returns a bool.
        # This runs as a native host function — far cheaper in gas than
        # doing P256 arithmetic in WASM.
        let valid = env::p256_verify(&signature, &message, &self.registered_pubkey);

        # Step 4: Act on the result. In production you'd gate a
        # sensitive action (transfer, session key rotation, etc.)
        # behind this check.
        assert!(valid, "Invalid passkey signature");
        near_sdk::log!("Passkey signature verified successfully");
        valid
    }
}

# --- Estimated gas comparison ---
# Before NEP-635 (pure WASM P256 verify): ~120+ TGas
# After  NEP-635 (native host function):  ~10-15 TGas (estimate, benchmark pending)

# --- NEP-611: Pending Transaction Queue (tracking note) ---
# NEP-611 is still a proposal (not yet merged). No new SDK surface yet.
# Developers should watch:
#   https://github.com/near/NEPs/pull/611
# Key things to monitor:
#   - Will pending txns be queryable via RPC? (useful for relayers)
#   - Will ordering guarantees change for same-signer nonces?
#   - Impact on near-lake-indexer and transaction streaming pipelines.
# We'll ship a code walkthrough once the spec stabilizes.