Stories by Gear Protocol on Medium

The Cryptography Behind Blockchain Signatures: ed25519, sr25519, and secp256k1 Explained

Gear Protocol — Wed, 01 Apr 2026 17:03:25 GMT

Abstract

Digital signatures are the backbone of blockchain security. Every transaction you send, every block a validator signs, every smart contract interaction — all rely on elliptic-curve cryptography to prove authenticity without revealing private keys. This article breaks down the three most widely used signature algorithms in the blockchain space: ed25519, sr25519, and secp256k1. We cover how they work, where they’re used, and why different chains made different choices. Whether you’re a developer choosing a signature scheme for a new project, or simply curious about the cryptography securing your assets, this guide provides the technical foundation you need.

Introduction

Blockchain developers often work with elliptic-curve cryptography for digital signatures. ed25519, sr25519, and secp256k1 are three prevalent elliptic-curve-based signature algorithms. All three provide roughly 128-bit security and rely on the hardness of the elliptic curve discrete log problem.

In this introduction, we explore their common properties, key differences, typical use cases (especially in blockchains), and the advantages and disadvantages of each. We also touch on advanced capabilities like hierarchical deterministic key derivation (HDKD), threshold signatures, and distributed key generation (DKG) — features increasingly important for modern blockchain applications.

Common Properties

Elliptic Curve Cryptography: All three algorithms are based on elliptic curve mathematics. Their security relies on the difficulty of solving discrete logarithms on elliptic curves. ed25519 and sr25519 use curves based on Curve25519, a twisted Edwards curve known for speed and security. Secp256k1 uses a Koblitz short Weierstrass curve defined by the equation y² = x³ + 7 over a 256-bit prime field (used in Bitcoin).

Key and Signature Sizes: All produce relatively compact keys and signatures. Private keys are 256-bit (32 bytes) in each scheme. Public keys are 256-bit points (32-byte compressed form for ed25519/sr25519, 33-byte compressed for secp256k1). Signatures are approximately 64 bytes in ed25519 and sr25519, and typically 64–72 bytes in secp256k1’s ECDSA.

Deterministic Signatures: ed25519 and sr25519 produce deterministic signatures — the nonce is derived from the message and private key via hashing, removing the need for a new random number per signature. This avoids the pitfalls of ECDSA, where a poor or repeated random nonce can leak the private key.

Performance: All benefit from faster verification and signing compared to traditional RSA. ed25519 and sr25519 often have an edge in performance thanks to Edwards-curve arithmetic. Curve25519-based ed25519 can perform signature verification roughly twice as fast as secp256k1 ECDSA in well-optimized implementations.

ed25519 (EdDSA on Curve25519)

ed25519 is an instance of the EdDSA signature scheme using the Twisted Edwards curve Curve25519. It was designed by Daniel J. Bernstein et al. for high security and high performance.

Design and Security: It has a fully specified deterministic signing procedure, making it robust against poor randomness. It is resilient to certain side-channel attacks because the curve’s structure allows efficient constant-time implementations. ed25519’s parameters were chosen transparently, avoiding suspicion of backdoors.

Performance: ed25519 is very fast on modern hardware. Its verification is especially fast — roughly twice as fast as secp256k1 ECDSA verification — due to the curve’s structure and the ability to batch verify multiple signatures efficiently. For blockchains handling many signatures per block, this efficiency is a big advantage. Solana, for example, chose ed25519 in part for its fast, batchable verification.

Usage: ed25519 is widely used in new blockchain and crypto projects. Cardano uses ed25519 for transaction signatures, Algorand uses ed25519 for its accounts, Solana uses ed25519 exclusively for signatures, and many Tendermint-based chains (Cosmos, etc.) use ed25519 for validator signatures. It’s also popular outside blockchains — OpenSSH adopted ed25519 keys as a modern default.

Limitations: A known limitation is in hierarchical key derivation. The standard ed25519 uses hashing and bit-clamping of the private key, which makes deriving child keys from a parent public key non-trivial. The SLIP-0010 standard for ed25519 HD wallets only supports hardened derivation, meaning you cannot derive a child public key from a parent public key as you can in secp256k1.

sr25519 (Schnorr on Ristretto25519)

sr25519 is a signature scheme derived from ed25519, created for the Polkadot/Substrate ecosystem. It uses the same underlying Curve25519 elliptic curve but implements a Schnorr signature and uses Ristretto point compression for safer operations. Essentially, sr25519 can be thought of as ‘ed25519 upgraded for advanced use-cases.’

Schnorrkel and Ristretto: sr25519 is implemented in the Rust Schnorrkel library using Ristretto, a technique to remove the small cofactor of Curve25519 and work in a prime-order subgroup. By encoding points with Ristretto, sr25519 ensures no weak small-subgroup points ever appear, making protocols like multi-signatures, threshold schemes, and verifiable random functions (VRFs) easier to implement safely.

Security: For basic signing, ed25519 and sr25519 offer equivalent security. Both are Schnorr-like signatures on Curve25519, so there’s no known security difference for single signatures. Polkadot’s developers note that ‘there are no differences in security between ed25519 and sr25519 for simple signatures.’

Blockchain-Friendly Features: sr25519 was explicitly designed with blockchain applications in mind. It supports native HD key derivation (HDKD) and safer multi-signature/aggregation protocols out of the box. The Schnorrkel library provides both hard and soft key derivation, and even public-key derivation, which ed25519 lacked. It also supports multi-signatures via aggregation with MuSig support.

Use Cases: sr25519 is the default key system for Polkadot, Vara, and Substrate-based blockchains. Account keys and consensus keys in these systems often use sr25519 by default. As the Web3 Foundation puts it, ‘sr25519 provides more blockchain-friendly functionality like HDKD and multi-signatures.’

secp256k1 (ECDSA/Schnorr)

secp256k1 refers to the elliptic curve itself — a 256-bit SECG Koblitz curve — and by extension to the signature schemes used with it. In Bitcoin and Ethereum, ECDSA signatures on secp256k1 are the standard. More recently, secp256k1 is also used with Schnorr signatures, as introduced in Bitcoin’s Taproot upgrade.

Curve Characteristics: secp256k1 is a curve of prime order (cofactor = 1), defined over a 256-bit prime field. It was chosen for Bitcoin likely for its performance and because it wasn’t one of the NIST curves. It provides the same 128-bit security level as ed25519.

ECDSA on secp256k1: ECDSA is the classic signing algorithm used. It is not deterministic by default — a random nonce is required for each signature — and it’s somewhat more complex to implement than Schnorr. If the nonce is ever repeated or predictable, the private key can be solved. When implemented with care (using RFC6979 for deterministic nonce and constant-time arithmetic), ECDSA is secure. However, it’s harder to batch-verify ECDSA signatures and it doesn’t support native signature aggregation without complex protocols.

Schnorr on secp256k1: To overcome ECDSA’s limitations, the Bitcoin community adopted Schnorr signatures for secp256k1 (BIP340 in 2021). Schnorr on secp256k1 yields 64-byte signatures similar to ed25519. It’s slightly simpler and more efficient than ECDSA and enables advanced constructions like MuSig, allowing multiple parties to produce one aggregate signature.

Use Cases: secp256k1 (with ECDSA) is the de facto standard in Bitcoin, Ethereum, and many other early cryptocurrencies. Even newer platforms that need Ethereum compatibility support secp256k1 so that keys can be shared between systems. It’s broadly supported in hardware wallets and HSMs.

Summary

All three algorithms provide strong 128-bit security based on elliptic curve cryptography. ed25519 offers excellent performance and widespread adoption across modern blockchains. sr25519 builds on ed25519 with additional blockchain-friendly features like native HD key derivation and safer multi-signature protocols — making it the default choice for Polkadot, Vara, and Substrate ecosystems. secp256k1 remains the standard for Bitcoin and Ethereum compatibility, with Schnorr signatures now available to overcome ECDSA’s limitations.

The choice between them depends on your use case: secp256k1 for Ethereum/Bitcoin compatibility, ed25519 for broad support and performance, and sr25519 for advanced blockchain features and Substrate-based development.

Vara

Gear Protocol

Validator Discovery in Vara.ETH Network

Gear Protocol — Thu, 19 Mar 2026 15:52:37 GMT

This article explains how validator discovery works in the Vara.ETH network in practice: what data it stores, how it queries and publishes identities, and why some checks are strict.

The implementation is heavily inspired by Substrate authority discovery, but is integrated into Gear’s current networking stack. It consists of 3 tightly associated parts.

What Problem It Solves

Currently, there are 2 use cases: tight connections between validators because they are part of consensus, and injected transaction routing to send transactions directly to a validator.

Part One. Identity

A validator identity contains network addresses and the identity creation time. It is signed with both the network key and the validator key.

Keys

The key design is “double signing”: the validator key proves “this validator approved this identity,” while the networking key proves “this peer controls the peer ID/address side.”

This prevents two replay-like classes: a validator cannot point to someone else’s network identity, and a random peer cannot claim “I am validator X.”

Addresses

Network addresses must satisfy the following requirements: they must contain at least 1 address, every address must end with a P2P protocol containing the same peer ID, and duplicate addresses are rejected during decoding.

Creation time

Kademlia is eventually consistent, so stale (old) identities can appear. To avoid trusting whichever identity version arrives first, we compare the creation time in the identity itself and prefer the newest one.

This freshness rule works together with the timer behavior described below.

Part Two. Timers

To keep identities fresh without flooding the network, we use exponential backoff timers with the following parameters: start delay is 2 seconds, so requests are not made when there are no peers in the KAD routing table; factor is 2, a value heuristically selected from Substrate sources; and maximum interval is 10 minutes, after which multiple queries with an exponentially increasing interval should acquire enough identities.

Two timers are used in total. The first is for querying identities, which everybody does for validator identities. The second is for putting validator identity, where only the validator itself should PUT an identity while other peers verify it via the validator list.

Part Three. KAD

We use the good old plain Kademlia (KAD) protocol with some key differences.

Disjoint query paths are enabled to mitigate adversarial routing. Inbound PUT records are always validated to avoid trash records. Peers are inserted into the routing table manually only via discovery services like mDNS, libp2p-identify, or validator discovery to avoid random peers.

Record TTL is 1 hour and the record publishing interval is 15 minutes. We don’t want stale validator records, so these intervals are much lower than the default libp2p ones.

Security and DoS controls

After defining the identity format, refresh timers, and KAD behavior, we apply additional cross-cutting controls: strict decode-time validation for signatures and peer-ID consistency, validator membership check (current/next only), freshness check via monotonic creation-time preference, address count limit (10), query concurrency limit (10), and exponential backoff up to 10 minutes.

Together, these controls keep traffic bounded and reduce the chance of accepting junk identities.

Summary

Validator discovery here is a strict, practical, KAD-backed identity layer. It publishes a validator’s own identity safely, continuously refreshes other identities with bounded concurrency, and accepts only records that are both cryptographically valid and validator-set relevant.

The design is conservative by default and optimized for correctness under evolving validator sets.

Would you like to become part of the community? Explore and join using the social channels below:

Vara

Gear Protocol

The Paradox of Ethereum Decentralization: How New Blocks Are Actually Created

Gear Protocol — Wed, 11 Mar 2026 07:16:56 GMT

Short Article Introduction Summary

Ethereum is currently regarded as a leading example of a decentralized blockchain. However, several structural nuances raise questions about the true extent of its decentralization. This article examines how Ethereum’s present consensus mechanism functions and who effectively controls the block‑production process. We analyze the role of Proposer‑Builder Separation (PBS), the challenges introduced by Maximal Extractable Value (MEV), and explain why — despite nearly one million validators — Ethereum is trending toward centralization at the block‑creation layer.

Ethereum is often described as one of the most decentralized blockchains, and at first glance this appears accurate: as of early December 2025, the network contains nearly one million active validators. However, behind this impressive figure lie structural mechanics that raise legitimate concerns about the real level of decentralization. This article explains the full lifecycle of a transaction — how it moves from broadcast to inclusion in a block — and identifies the entities that truly control this process.

Fundamentals of Proof‑of‑Stake and the Role of Validators

Unlike Bitcoin, which relies on the Proof‑of‑Work consensus mechanism, Ethereum uses Proof‑of‑Stake (PoS). In PoS, network security depends on economic incentives rather than computational resources. Validators lock (stake) the network’s native asset (a minimum of 32 ETH) as collateral, granting them the right to participate in transaction validation and block creation.

Ethereum time is divided into slots (12 seconds) and epochs (32 slots, approximately 6.4 minutes). During each slot, one validator is pseudorandomly selected to propose a new block — the Block Proposer.

The consensus algorithm is designed so that every validator has an equal probability of being selected, which theoretically ensures a high degree of decentralization.

Proposer Authority and the MEV Problem

When a validator is chosen to produce a block, it gains exclusive control over which transactions will be included and in what order. This creates opportunities to extract additional profit, known as Maximal Extractable Value (MEV) — the maximum value obtainable by reordering, inserting, or censoring transactions within a block.

Efficient MEV extraction requires significant computational resources, sophisticated software, and continuous network monitoring. A typical validator running standard software cannot compete with specialized entities that optimize every block for profit maximization.

The Solution: Proposer‑Builder Separation (PBS)

To mitigate this imbalance, the Proposer‑Builder Separation (PBS) model was introduced. Its purpose is to separate the complex task of constructing an optimal block from the simpler task of proposing it to the network.

In this model, new participants — Block Builders — are responsible for assembling candidate blocks. Builders compete to produce the most profitable block, aggregating transactions from users and MEV searchers. They then submit these blocks to an open auction. The validator acting as Block Proposer simply selects the most profitable block offered, signs it, and broadcasts it to the network.

The most widely used implementation of this concept today is MEV‑Boost, adopted by approximately 90% of Ethereum validators.

A New Form of Centralization

While PBS and MEV‑Boost solved fairness issues for validators, they introduced a new and potentially more serious problem: block‑builder centralization. Despite the presence of nearly one million validators, the overwhelming majority of Ethereum blocks are produced by a very small set of builders.

As of early December 2025, only 12 active block builders operate in the network, with three of them dominating over 95% of total block production:

Titan Builder — 50.62%
BuilderNet — 27.79%
Quasar (quasar.win) — 17.10%

Conclusion

As Ethereum’s protocol continues to evolve, it has produced a paradoxical structure. At the validation layer, it remains highly decentralized, supported by hundreds of thousands of independent participants. However, at the critical block‑creation layer, power is concentrated in the hands of only a few specialized entities. A system that appears decentralized on paper increasingly exhibits centralizing tendencies in practice.

Would you like to become part of the community? Explore and join using the social channels below:

Vara

Gear Protocol

From Opaque Bytes to Universal Services: Introducing Sails Header v1

Gear Protocol — Wed, 28 Jan 2026 14:29:27 GMT

Note: The Sails Header specification described below is currently in active development. While the design is finalized, the implementation has not yet landed in the main Sails release. We expect to ship this feature in the near future as part of the next major framework update.

In the actor model architecture of Gear and Vara, communication is king. Programs send messages, and programs reply. However, until now, those messages have essentially been “opaque blobs” of SCALE-encoded bytes. To understand a message, external tools needed the specific Wasm binary, the source code, or a side-channel definition of what the data meant.

We are changing that.

We are introducing the Sails Header v1 — a deterministic, wire-level ABI that lives entirely in userspace. This standard transforms Gear messages from raw byte streams into self-describing, discoverable, and polymorphic service calls.

The “Black Box” Problem

Currently, if an indexer or a block explorer sees a message on the Vara network, it sees a payload. Without the specific metadata for that exact program, the tool cannot distinguish a Token::Transfer from a Game::Attack.

This creates friction:

Fragmented Tooling: Every dApp needs custom frontend logic just to decode its own messages.
Identity Crisis: A wallet doesn’t know if a contract is a Token, a DAO, or a Game until it queries specific state or checks a registry.
Complex Indexing: Data availability is hindered because indexing requires heavy execution context.

The Solution: Sails Header v1

The Sails Header is a compact envelope prepended to the payload. It requires no changes to the Gear node runtime or consensus. It is a strictly opt-in, userspace agreement that creates a universal language for services.

The Anatomy of the Header

The header is a fixed 16-byte prefix (for the base version) that creates a standard “preamble” for every message:

Magic (0x47 0x4D): ASCII for “GM”. This allows parsers to instantly recognize a Sails-compatible message.
Interface ID (64-bit): A deterministic, structural fingerprint of the service being called.
Entry ID (16-bit): Identifies the specific function or event (e.g., Transfer).
Route Index (8-bit): Allows a single program to host multiple instances of a service.
Payload: The standard SCALE-encoded data follows immediately after.

Efficient In-Program Routing

This header doesn’t just help tools outside the blockchain; it radically simplifies the code running inside your contract.

Previously, routing often relied on parsing strings encoded in the payload (e.g., matching a byte string like “VFT.Transfer”). This was costly: it required reading string bytes, allocating memory, and performing string comparisons — all burning gas.

With Sails Header v1, routing becomes a simple integer match:

Read 8 bytes: Compare the interface_id to see which service is being called (e.g., Token vs. Game).
Read 2 bytes: Compare the entry_id to see which function to run.

This creates a O(1) dispatch table. The router simply jumps to the correct function pointer based on two numbers. It is faster, safer, and completely eliminates the risk of string-parsing vulnerabilities or typos.

The Game Changer: Optimistic Service Identification

The most powerful feature of the new header is how it changes the way tools perceive contracts. The Interface ID is not just a routing number; it is a semantic fingerprint.

Because the ID is derived mathematically from the code structure, every program that implements the exact same standard (e.g., FungibleToken, Tamagotchi, DaoVoting) will broadcast the exact same Interface ID.

This enables Optimistic Identification:

“Duck Typing” for Smart Contracts: Off-chain tools don’t need to verify the bytecode to know what a contract is. If a contract sends messages with the FungibleToken Interface ID, a Wallet can “optimistically” assume it is a token.
Instant UI Rendering: When a wallet sees a transaction targeting a known Interface ID, it can instantly render the appropriate UI (e.g., a “Transfer” screen) without waiting to query an on-chain registry or download an ABI file.
Universal Indexing: An indexer can now answer questions like “Show me every NFT transfer on the network” by simply filtering for the specific Interface ID.

The Science of Determinism

We don’t assign random numbers to services. The Interface ID is a structural fingerprint derived from the code itself using the Keccak256 algorithm. It is calculated at compile-time via a process called Structural Reflection.

The computation (PRE_INTERFACE_ID) is a composite hash of three distinct layers:

The Function Layer: We collect every function in the service, sort them lexicographically, and hash their structure.
Strict Typing: We hash the Type (Query vs. Command), Name, Arguments (via ReflectHash), and Return Type.
Result Handling: If a function returns Result, we treat T (success) and E (error) as distinct structural components, ensuring that error handling is part of the interface contract.
Wrapper Transparency: Protocol wrappers like CommandReply are stripped away, so the ID focuses on business logic, not transport artifacts.
The Event Layer: If the service emits events, the structure of the Event Enum is hashed. This ensures that if you add a new event type, the Interface ID changes, signalling a protocol update to listeners.
The Inheritance Layer (Base Services): Sails supports service inheritance. If your service extends BaseServiceA, we take its pre-computed Interface ID and mix it into the derived service’s hash. This creates a Chain of Trust: A service’s ID mathematically proves that it implements the specific versions of the base services it claims to extend.

The final ID is simply the first 8 bytes of this composite hash: INTERFACE_ID = Keccak256(Functions || Events || BaseServices)[0..8]

Zero-Cost Runtime

For Rust developers, this complexity is handled at compile-time.

build.rs parses the service definition and computes the hashes.
The compiler embeds these IDs as constants.
At runtime, the program simply writes a static 16-byte array.

There is zero runtime gas cost for hashing.

The Path Forward

The Sails Header v1 is designed to be future-proof. It includes versioning and support for extensions (like correlation IDs) without breaking the core protocol.

By adopting Sails and this header standard, we aren’t just writing smart contracts; we are building a composable, transparent, and robust web of services. We are moving from a world of isolated programs to a unified ecosystem where services announce their identity simply by speaking.

KEY TECHNICAL SPECS

By Vadim Smirnov @ukint-vs

Would you like to become part of the community? Explore and join using the social channels below:

Vara

Gear Protocol

TLS Tool: The Modern Internet and Ways To Protect Information

Gear Protocol — Tue, 13 Jan 2026 04:25:42 GMT

The modern internet stands on a few pillars: DNS, TCP/IP, and, of course, TLS/HTTPS — a cryptographic protocol that provides privacy and authenticity for connections between browsers, mobile clients, APIs, and millions of services worldwide. Today, TLS is the foundation of trust across the entire network infrastructure.

In parallel with the development of the internet, blockchains are evolving too. They are turning from simple distributed ledgers into full execution environments and replacements for server-side logic. With the rise of Web3, a fundamental challenge appears: how do we connect the deterministic world of the blockchain with the external world of HTTPS resources without breaking integrity and cryptographic security?

The TLS-Tool project (https://github.com/gear-tech/tls-tool/) from the Gear ecosystem is one possible solution to this problem. It provides a Rust toolkit for working with TLS records and certificates, and, most importantly, makes it possible to verify TLS inside a WASM contract.

What’s the problem?

Blockchains are traditionally isolated: a smart contract can’t simply execute an HTTPS request. That’s good — determinism, security, repeatable computation. But it also makes it impossible to:

• fetch data from exchange APIs

• check the state of external services

• integrate with OAuth / Web2 authorization

• use HTTPS as part of the trust model

Most networks try to solve this with an oracle approach, but that again leads to the need to trust external services.

Gear takes a different path: the contract itself can verify the authenticity of a TLS session by validating the certificate chain, signatures, and handshake materials inside WASM.

What in TLS provides security?

TLS is a protocol that proves two things:

1. Server authenticity: it truly controls the private key corresponding to the domain certificate.

2. Correctness of the encrypted channel: both sides derived the same encryption keys, and no one could have inserted themselves into the process (no MITM).

HTTPS = HTTP over TLS.

The whole point of HTTPS boils down to:

the client verifies → certificate + signatures + handshake, and then uses the encrypted channel.

What exactly does TLS verify, and what does that mean cryptographically?

Certificate chain validation (X.509 chain validation):

1. Correct certificate formats (ASN.1 / DER).

2. Correct signature on each certificate over the next one.

3. Domain matching: CN / SAN contains exactly the domain the client requested.

4. Validity period checks.

5. Checks for allowed key algorithms and KeyUsage.

This work is needed to prove:

The server presented a key that the trusted root infrastructure recognized as the key for example.com

Verification of the ServerHello + ServerParameters signature (CertificateVerify):

In TLS 1.3 the server signs the entire handshake transcript with its private key.

This exact point guarantees:

The server really controls the private key for example.com, and did not simply send someone else’s certificate.

Verified:

1. The signature algorithm matches the certificate.

2. The signature is computed over the transcript hash (which includes ClientHello).

3. The correct scheme is used (typically ECDSA P-256 / RSA-PSS).

4. The public key from the certificate correctly verifies the signature.

This check is critical:

Without it, TLS turns into a simple exchange of certificates that are easy to spoof.

Key agreement verification (ECDHE key exchange):

TLS 1.3 uses ephemeral Diffie–Hellman (typically X25519 or P-256).

Verified:

1. The server sent a valid ephemeral public key.

2. The client correctly computes the shared secret.

3. Traffic key derivation uses the exact transcript.

4. Any mismatch in fields → an attacker is trying to insert themselves.

Result:

An attacker cannot substitute encryption keys without also substituting the content.

Finished-signature verification (HMAC over transcript):

The last and most important check in TLS 1.3:

The server sends a Finished message, which is:

HMAC(server_handshake_traffic_secret, transcript_hash)

If even a single bit in the handshake was forged, Finished won’t match.

This makes TLS cryptographically atomic:

Either the entire handshake is authentic, or no part of it can be trusted.

What do the parts of TLS-tool do?

Off-chain collection of TLS artifacts (crate tls_gatherer)

The off-chain agent performs:

1. A normal TLS handshake to, for example, https://example.com

2. Captures all critical data:

• certificates

• the server’s ephemeral public key

• ServerHello

• CertificateVerify signature

• Finished

• transcript hash

3. Packs everything into serializable structures.

4. Sends them to the Gear contract.

Key point:

The agent does not interpret the results. It does not tell the contract: “trust this site.

It only passes raw TLS records.

On-chain verification of TLS artifacts (crate wasm_tls_verifier)

A Gear smart contract that performs a full independent audit of a TLS 1.3 session inside WASM, using only raw cryptographic data, in strict compliance with RFC 8446.

1. Recomputes HKDF chains on its own

2. Recomputes the transcript hash on its own

3. Verifies Finished on its own

4. Derives AEAD keys and IVs on its own

5. Decrypts traffic on its own while verifying AEAD tags

The contract does not trust the external agent by even one byte.

If verification passes, then:

• the server → proved control of the domain’s private key

• the handshake → was not modified

• the HTTP → is authentic and unmodified

• AEAD → confirmed integrity and authenticity of the traffic

Thanks to Finished + AEAD:

No one can change the contents of HTTPS traffic, even with full control over the off-chain agent.

Tools for simple integration (crates watcher and app)

Watcher is a simple library that uses gclient and provides a high-level interface for interacting with the verifying contract.

App is an application that provides a command-line interface for interacting with the contract, for example:

app verify — url https://example.com — contract-id

How exactly are TLS records verified by the smart contract?

The contract has several stages of processing and verifying TLS records inside WASM:

• fully reconstructs and verifies a TLS 1.3 session

• decodes and decrypts the HTTP request/response

• returns a report on the cryptographic correctness of the session

1. What are Artifact and Report

Artifact contains:

• all TLS records from the client (client_records)

• all TLS records from the server (server_records)

• keylog (NSS keylog) with traffic secrets (handshake + application)

• connection meta-information (TlsInfo): cipher suite, SNI, certificate chain, etc.

Report contains:

• finished: FinishedReport — verification flags for Finished messages

• certs: CertsReport — result of certificate chain validation and CertificateVerify

• close: CloseReport — whether close_notify was seen from both sides

• client: Vec — decrypted HTTP request

• server: Vec — decrypted HTTP response

2. Checking that required keys are present

Extracted from keylog:

• CLIENT_HANDSHAKE_TRAFFIC_SECRET

• SERVER_HANDSHAKE_TRAFFIC_SECRET

• CLIENT_TRAFFIC_SECRET_0

• SERVER_TRAFFIC_SECRET_0

Without them there is no point in continuing — we won’t be able to decrypt messages or verify Finished.

3. Initializing AEAD states for traffic secrets

Supported cipher suites:

• TLS_AES_256_GCM_SHA384

• TLS_AES_128_GCM_SHA256

• TLS_CHACHA20_POLY1305_SHA256

For each:

1. HKDF-Expand-Label is performed via derive_aead_key_and_iv;

2. a TrafficSecretState is created:

• hash_algorithm (SHA-256 or SHA-384)

• the specific AEAD (Aes128Gcm, Aes256Gcm, ChaCha20Poly1305)

• base IV

• sequence number counter

This is the minimal piece of a TLS 1.3 implementation: exactly what is needed to decrypt records.

4. Decrypting application data (HTTP)

The extract_application_data function does:

• for all TlsRecord with content_type == ApplicationData:

• parses the header (5 bytes)

• decrypts via AEAD (decrypt_record):

• nonce = base_iv XOR sequence_number

• AAD = record_header

• parses the inner type (InnerPlaintext): content_type + content

• if inner.content_type = APPLICATION_DATA — collects the payload (HTTP)

Its result:

ApplicationDataResult {
    data: Vec, // clean HTTP
    close_notify_received: bool // whether alert close_notify was received
}

This function is called twice:

• for artifact.client_records with the client app secret → HTTP request

• for artifact.server_records with the server app secret → HTTP response

5. Extracting handshake messages

The extract_handshake_messages function does the following:

• from client records:

• Handshake (content_type=Handshake) → cleartext (ClientHello in TLS 1.3)

• ApplicationData with inner.content_type=Handshake → encrypted handshake messages → client_encrypted

• from server records:

• similarly: ServerHello in cleartext, everything else in server_encrypted

This is exactly the raw stream of handshake messages as seen by a TLS implementation.

6. Building the handshake transcript

let mut handshake_transcript = Vec::new();


handshake_transcript.extend_from_slice(&handshake_streams.client_cleartext);
handshake_transcript.extend_from_slice(&handshake_streams.server_cleartext);
handshake_transcript.extend_from_slice(&handshake_streams.client_encrypted);
handshake_transcript.extend_from_slice(&handshake_streams.server_encrypted);

Then it is partially “unwound” while iterating through server_handshake_messages in order to record:

• transcript_length_before_certificate_verify

• transcript_length_before_server_finished

7. Parsing server handshake and extracting CertificateVerify/Finished

let server_handshake_messages =
    parse_handshake_messages(&handshake_streams.server_encrypted);


let mut server_certificate_verify_body: Option> = None;
let mut transcript_length_before_certificate_verify: usize = 0;
let mut server_finished_verify_data: Option> = None;
let mut transcript_length_before_server_finished: usize = 0;


for message in server_handshake_messages {
    if message.message_type == 15 {
        // CertificateVerify
        transcript_length_before_certificate_verify = handshake_transcript.len();
        server_certificate_verify_body = Some(message.full_message[4..].to_vec());
        handshake_transcript.extend_from_slice(&message.full_message);
    } else if message.message_type == 20 {
        // Finished
        transcript_length_before_server_finished = handshake_transcript.len();
        server_finished_verify_data = Some(message.full_message[4..].to_vec());
        break;
    } else {
        handshake_transcript.extend_from_slice(&message.full_message);
    }
}

Message types:

• 11 — Certificate

• 15 — CertificateVerify

• 20 — Finished

What matters here:

• before CertificateVerify, we fix the transcript length (before CV)

• before Finished — separately (before Finished)

8. Verifying server Finished

The verify_finished_message function follows RFC 8446 strictly:

1. computes transcript_hash = Hash(transcript) (SHA-256 or SHA-384)

2. derives finished_key via tls13_hkdf_expand_label(…, “finished”, …)

3. checks HMAC(finished_key, transcript_hash) == verify_data

If everything is OK → server_finished_ok = true

9. Adding Server Finished to the transcript and verifying client Finished

After successful server Finished verification:

• the reconstructed Finished is added to the transcript as a full handshake message (type=20 + length + data)

• client_encrypted is parsed the same way, client Finished is searched for and verified using the same verify_finished_message, but with client_handshake_traffic_secret

10. Verifying the certificate chain

The validate_certificate_chain function:

Uses:

• webpki::EndEntityCert

• rustls_pki_types::CertificateDer

• webpki_roots::TLS_SERVER_ROOTS — Mozilla root store

Steps:

1. parse the leaf (the first certificate in the chain);

2. EndEntityCert::verify_is_valid_tls_server_cert with:

• TLS_SERVER_ROOTS root set

• intermediate certificates

• UnixTime (current block/call time)

3. verify DNS:

• ServerName::try_from(hostname) from SNI

• verify_is_valid_for_subject_name

Returns:

• chain_valid — whether the chain is valid up to a trusted root

• dns_name_valid — whether the domain matches

11. Verifying CertificateVerify

The validate_certificate_verify_signature function

Does:

1. parses certificate_verify_body:

• 2 bytes: SignatureScheme (0x0403, 0x0503, 0x0804, …)

• 2 bytes: signature length

• then: the signature itself

2. builds Transcript-Hash for transcript_before_certificate_verify

3. forms “signed content” per RFC

4. extracts the public key from the leaf

5. selects the algorithm by signature_scheme

6. calls end_entity.verify_signature(verification_algorithm, &signed_content, signature)

Success → cert_verify_valid = true

12. Building the final report

At the very end:

Report {
    finished: FinishedReport {
        server_finished_ok,
        client_finished_ok,
    },
    certs: CertsReport {
        chain_valid,
        cert_verify_valid: true/false,
        dns_name_valid,
    },
    close: CloseReport {
        server_close_notify: server_result.close_notify_received,
        client_close_notify: client_result.close_notify_received,
    },
    client: client_result.data,
    server: server_result.data,
}

This Report is exactly what is emitted from the contract outward. It allows determining which checks were passed during the audit process and drawing a conclusion about the authenticity of the TLS records.

Would you like to become part of the community? Explore and join using the social channels below:

Vara

Gear Protocol

HOW-TO: Stable Substrate Runtime. Part 1

Gear Protocol — Tue, 06 Jan 2026 14:24:40 GMT

This is the first article in a series about achieving stable substrate runtime through test techniques we used for the Gear protocol. These techniques have shown great results, i.e., we have caught some tricky bugs with them. In this article, we will discuss, in general, grey-box testing and how we have used it in our node-loader tool.

Are We Sure Everything’s Rock Solid?

While developing Gear protocol, we applied many common — or rather, mandatory and obvious — methods of testing our code. We had:

Unit testing

Both individual crates and the extrinsics of our pallets.

2. Integration testing

Testing Gear protocol itself against a blockchain node instance. In other words, we tested our extrinsics as the available API of the blockchain node itself by spinning up a node on CI and sending transactions to it.
Testing dependencies for the protocol. What I mean here is that we tested our expectations of how other crates (our dependencies) work. For example, we even have tests verifying that the layer between a Gear program and the WASM executor for Gear programs always returns expected values at the required pointers.
Yes, this was a pretty low-level and system-level test:
https://github.com/gear-tech/gear/blob/ec53e0ae2fab661b1da720ee1c842215dc4594dc/pallets/gear/src/benchmarking/tests/syscalls_integrity.rs

Is this enough? When you’re developing a system for decentralized value (money) transfer, especially while preparing for the first mainnet release, you should be 99.999% confident that your project won’t be the one updating the “Days without blockchain project exploit” counter. Otherwise, you can kiss goodbye to that lambo to an engaged and growing community.

The situation was further heated by the fact that our runtime was quite large, complex, and wasn’t all about user-accessible extrinsics as the main state transition mechanism. Extrinsics merely create certain input data (in our case — placing messages in a queue), which are then processed by an inherent transaction. And the latter, during its execution, creates a deep and difficult-to-fully-grasp chain of state transitions.

Black Box Testing to the Rescue

You can approach this complex and branching state transition logic in different ways: through positive and negative tests. Well, with positive tests, everything seems clear: you have certain features, and you verify that using them results in expected storage states.

As for negative tests, in short, it’s about hitting error branches and handling them correctly. But have you covered all cases? Is your project’s architecture and code design really so successful, are components properly decomposed and correctly abstracted, that you’ve managed to handle all input data cases in your code?

There’s something that gives you a bit more confidence in answering the questions posed above. Your tests need to… go dark.

What I mean is, you should start applying black box testing techniques, which assume you either know absolutely nothing about the executable target or know very little about it. This is testing that emulates how users interact with your product, especially those who use it “incorrectly.” You know what I’m talking about…

In short, you generate almost completely random input and execute it, then watch how the system behaves, what outputs it produces, whether it crashes. This really gives you more confidence in product stability through greater confidence in negative tests, because there’s always a utility running that conducts those very negative tests. Especially if you introduce such testing as early as possible.

Note: We introduced this long before the mainnet release and continue using it to this day.

How to Start Black Box Testing for a Substrate Runtime Blockchain?

Choose Your Approach

Initially, we decided to use black box testing for the entire product. That is, we planned to spin up a working Substrate node with a runtime supporting Gear protocol and bombard it with a large number of nearly random transactions.

As will be described later, this isn’t the only black box testing approach we applied.

Obviously, the Substrate outer node part would reject any input garbage, and a working node on the mainnet would generally block a spammer. So the input data (transactions) shouldn’t be completely random. We need to at least hit our main extrinsics:

upload_program for creating Gear programs from an attached WASM blob:
https://github.com/gear-tech/gear/blob/81a0ddf84a3d493b1c0a5ac843be1320793b607f/pallets/gear/src/lib.rs#L1359
send_message for sending a message to an actor:
https://github.com/gear-tech/gear/blob/81a0ddf84a3d493b1c0a5ac843be1320793b607f/pallets/gear/src/lib.rs#L1476
send_reply for sending a reply to a received message:
https://github.com/gear-tech/gear/blob/81a0ddf84a3d493b1c0a5ac843be1320793b607f/pallets/gear/src/lib.rs#L1513

Users and programs in Gear protocol are actors that can perform nearly the same set of actions. Just as users can use the extrinsics mentioned above, Gear protocol defines for Gear programs their methods of communication (sending messages and creating other programs) and executing messages in the context of their code.

So, to properly organize testing, we need to generate as input… Gear programs and messages?

2. Forming Input for Grey Box Testing

The testing takes on a grey box character because we need to teach our test system slightly more knowledge about the final product to make testing more effective.

Not an easy task. We need a WASM blob that is also a Gear program, meaning it meets certain requirements for this WASM (no start section, presence of certain exports, etc.).

Initially, we used an approach with mutation of ready-made templates. wasm-mutate helped us with this. That is, we created some subset of programs that would be mutated according to rules we defined: https://crates.io/crates/wasm-mutate

However, later we discovered this gem — wasm-smith. This crate allows generating WASM from random data, and this generation is configurable through many different parameters. With the wasm-smith config, we defined the number of generated functions, maximum number of instructions, absence of memory-grow instructions, and much more: https://crates.io/crates/wasm-smith

We then used such a generated program as a template. Based on random data, we inserted syscall invocations (host functions that allow reading or writing to the blockchain runtime supporting Gear protocol, more details here: https://docs.rs/gstd/1.9.1/gstd/) into the generated functions in this WASM template, defining random argument values for them.

3. Randomization and Determinism

Since we learned to generate random valid programs, we faced the next task — making the test-utility deterministic. We needed determinism because if we found a program that could break something on the node, we’d need to easily reproduce it.

For program generation, we used a seeded generator. The seed itself was logged, which allowed us to reproduce the test-utility’s work with high precision — it could simply be run again with the same input.

Moreover, this generator in turn produced new seeds, which were also logged. These new seeds were used to generate input data for the extrinsic: the program and payload.

Thus, this approach allowed us to reproduce not only the test-utility’s work from its very beginning but also a specific transaction and even a specific program. This was especially useful when we found bugs using this test-utility.

4. Final Solution

In the end, we created a node-loader, which worked according to the following algorithm:
https://github.com/gear-tech/gear/blob/92eef3b8f5ecfa2fefe8adfa98d3c2518731b5bd/utils/node-loader/src/main.rs#L23

Accepted input parameters via CLI. These parameters were the node address, number of parallel workers, and initial seed (optional).
Instantiated a client to the node and a generator of input data for extrinsics. The generator, as should be clear by now, used the previously described Gear program generator.
Sent extrinsics and waited for block updates with corresponding events.

Obviously, if no response came from the node within a certain period, this signaled that the node had crashed.

So, Is This Effective?

You bet! Trophies found:

Not benchmarked random syscall with large inputs, which caused constantly having block timeout.
Memory out of bounds panic on instantiation:
https://github.com/gear-tech/gear/pull/2197
Gasful and gasless messages order affected runtime storage and led to panic in runtime:
https://github.com/gear-tech/gear/pull/2211
Panic after init message failure:
https://github.com/gear-tech/gear/pull/1967
Event depositing from reservation:
https://github.com/gear-tech/gear/pull/1833

Limitations of Our Implementation

1. Coverage

Although this solution allowed us to find quite a few bugs, this approach has an obvious downside. The thing is, with this approach you can quite effectively test code written something like this:

Rust example:

fn function(random: u32) {
    some_function(random);
    some_function(random + 1);
}

fn some_function(param: u32) {
    if param > 42 {
        panic!("")
    }
    
    if param < 24 {
        panic!("")
    }
}

But we write much more complex code where the number of branches is simply enormous. And similarly to how we had to teach the generator something more about our runtime to increase test efficiency by ensuring most cases at least pass the outer node checks and upper layers of extrinsic logic, we also feel the need to have slightly smarter input data that could trigger execution of more branches, as well as deeper branches.

That is, we need grey box testing that leads to maximum coverage in depth and breadth.

2. Off-Target Load

It was mentioned earlier that the goal was to conduct negative testing of Gear protocol. However, Gear protocol is not Substrate. In fact, for testing purposes, we don’t need the latter. We need to somehow abstract away from the Substrate outer node part and everything else. We wanted to focus more on runtime state transitions. For this, we needed to somehow test the runtime while using the same extrinsics as input.

What’s Next?

We arrived at a new solution. We started using fuzz testing techniques and created a fuzzer for the runtime. But I’ll tell you about that in part two.

Stay tuned for the next installment, where we dive into how we built a proper fuzzer that gets us a good coverage of our runtime logic.

Would you like to become part of the Gear community?

Make sure to join the Gear x Vara Discord or Telegram!

Or send an email to hello@gear-tech.io

Fractured But Whole: Can Ethereum’s Fragmentation Challenge Be Solved?

Gear Protocol — Wed, 20 Aug 2025 09:20:27 GMT

“Maze of isolated chains, highlighting that even simple operations such as token swaps often require cumbersome bridging processes and multiple transactions across networks. Consequently, users frequently experience friction, confusion, and increased exposure to potential errors”

Hart Lambur, Co-Founder of Risk Labs

Ethereum has always faced the daunting challenge of scalability. L2 solutions emerged as Ethereum’s primary strategy to tackle scalability challenges, dramatically boosting network capacity and significantly reducing transaction fees. According to Ethereum Foundation reports, L2 rollups have scaled Ethereum’s transaction throughput nearly 17 times, decreasing fees from upwards of $50 per swap to mere cents. This shift has enabled rapid growth and the influx of millions of new users and applications into the Ethereum ecosystem.

However, the very success of Layer 2 solutions has inadvertently introduced a significant new challenge: fragmentation.

As of early 2025, there are over 100 Layer 2 blockchains listed on L2beat, with new chains launching approximately every 19 days according to Gemini’s institutional insights report. Users are now navigating an increasingly complex landscape where assets and liquidity are fragmented across numerous isolated networks.

Developers face their own set of hurdles, forced to manage multiple L2 deployments and bridging infrastructures. Developers who commit to a single L2 risk isolating their applications from users and capital residing on other networks. The resulting complexity stifles innovation and raises barriers to entry for new projects.

«Justin Bons from Cyber Capital highlights a critical issue: “Millions of dollars lost due to vulnerabilities in bridges between networks highlight severe security concerns in Ethereum’s Layer 2 infrastructure.”»

Social coordination adds yet another dimension to the problem. L2 ecosystems such as Arbitrum’s Orbit chains, Optimism’s Superchain, and Polygon’s Aggregation Layer are often built on proprietary stacks with asynchronous sequencing. This modular design leads to further fragmentation of global state, exacerbating issues of interoperability and slowing collective progress due to divergent visions and incompatible standards.

Is There a Way Out?

Ethereum’s fragmented maze of disparate L2 chains has not gone unnoticed. In response, both core developers and community — led initiatives have been exploring a range of solutions aimed at bringing coherence back to the ecosystem. Broadly, these approaches fall into two key categories:

The Modular Landscape: Is This the Fix?

The concept of modular blockchains involves separating core functions — execution, data availability, and settlement — into distinct layers. Execution occurs on rollups, data is posted to Ethereum L1 for availability, and finality is guaranteed by Ethereum’s consensus. This architecture allows each layer to specialize, scaling Ethereum without changing its foundational protocol.

Projects like Arbitrum Orbit allow developers to launch custom L3 chains on Arbitrum’s stack. Optimism’s Superchain envisions a network of interoperable rollups using shared governance and standards. Polygon’s Aggregation Layer coordinates zero — knowledge rollups under a unified interface. Starkware explores recursive scaling with its “fractal” approach, layering L3s on top of L2s for additional flexibility.

Yet modularity doesn’t fully resolve fragmentation. Liquidity, user activity, and developer efforts remain dispersed. Each modular ecosystem tends to form its own silo. Asynchronous sequencing leads to inconsistent states, complicating real-time interoperability. Bridging assets or messages across rollups often still requires trust-minimized bridges, involving cost, latency, and risk.

Standards, Standards and More Standards

Another approach is standardization, intended to organize Ethereum’s expanding L2 ecosystem. One notable initiative is ERC-7683, introducing an intents-based architecture. Users simply express their intent — like swapping tokens on one chain using funds from another — while relayer networks handle complex execution behind the scenes.

Standards simplify interactions significantly (on user side), yet they don’t address fragmentation at its root. Each L2 maintains its own state, sequencer, and stack. Even with a shared interface, liquidity and developer ecosystems remain separate. Social coordination remains a barrier, requiring sustained alignment across competing ecosystems.

Critics warn about potential risks: “Intent-based execution models, like ERC-7683, can introduce centralization risks as relayers often become dominant market actors. This can lead to concentrated power and resources in the hands of a few participants.”

From Fragmentation to Coherence: Gear.exe

While mainstream approaches revolve around spinning up additional chains or stitching them together via interoperability layers, Gear.exe offers a genuinely different path — one that rethinks horizontal scalability from the ground up.

Gear.exe is a computational environment existing natively alongside Ethereum’s Layer 1. Rather than creating separate networks or isolated economic zones, Gear.exe extends Ethereum’s own computational capabilities, running WebAssembly-based smart contracts directly within Ethereum’s economic and security guarantees.

«Nikolay Volf, founder of Gear Technologies, summarizes: “Gear operates as a computational module that can seamlessly integrate into any blockchain environment, eliminating fragmentation and significantly enhancing user experience.”»

Notably, Gear.exe does not introduce new tokens or isolated pools of liquidity. Instead, it utilizes Ethereum’s native asset, ETH, thereby maintaining unified liquidity and asset interoperability. Because Gear.exe operates at Ethereum’s core layer and relies on Ethereum finality, composability is preserved naturally. This design ensures full compatibility with existing Ethereum contracts and applications, minimizing the need for additional integration.

Technical and Social Advantages

Compared to modular blockchains or cross-chain aggregators, Gear.exe sidesteps the complexity of coordinating different technological stacks and bridging solutions. By embedding itself directly within Ethereum’s infrastructure, Gear.exe offers developers a unified toolset and streamlined deployment. This approach reduces complexity, accelerates development, and offers a practical path toward a more cohesive and scalable Ethereum ecosystem, free from fragmentation.

Ethereum Meets IoT: Off-Chain Automation with Gear.exe’s Compute Layer

Gear Protocol — Thu, 12 Jun 2025 16:22:19 GMT

What happens when blockchain’s determinism meets the unpredictability of the physical world? That’s the puzzle developers face when connecting IoT devices to Ethereum. On one side, you have smart contracts that expect finality, consensus, and onchain proofs. On the other hand, temperature sensors, smart valves, or motion detectors that stream data every few seconds, if not milliseconds.

Submitting every reading to Ethereum just to validate a threshold breach? That’s a fast track to high gas fees and sluggish performance. But even if you could afford to capture all that data, there’s another hurdle: making sense of it. Validating whether a reading is anomalous, triggering automation based on conditions, or coordinating responses across devices requires complex processing that Ethereum isn’t designed to handle natively.

Gear.exe offers a streamlined solution to both challenges.

First, it keeps raw, high-volume sensor data off-chain, avoiding Ethereum’s bandwidth and cost limitations. Then, using an off-chain compute layer built on WebAssembly (WASM), Gear.exe handles the heavy lifting, like data validation, anomaly detection, and automated decision-making, in a decentralized and verifiable way. Only the final results, such as confirmed events or actionable insights, are posted onchain where smart contracts can react.

Why Off-Chain Logic for IoT Makes Sense

Let’s start with the obvious: IoT devices aren’t built for L1 latency or gas economics. A temperature sensor in a vaccine shipment doesn’t care about block times. If the cargo gets too warm, it needs to send an alert now, not in 12 seconds. And not at $4 per transaction.

Developers have tried to solve this with centralized gateways or permissioned edge networks, but those reintroduce trust assumptions. The real goal is to keep the logic decentralized while scaling responsiveness.

Gear.exe’s compute layer bridges this divide. It lets you move real-time processing off-chain while preserving Ethereum as the ultimate source of truth. In other words: let the IoT sensors talk to Ethereum, but don’t force them to speak Solidity every time they blink.

How It Works: Wasm on Gear.exe

The Gear.exe network consists of Executor nodes that process WASM modules in a decentralized environment. These modules are uploaded to Gear.exe and executed there.

Once deployed, any Ethereum smart contract can offload complex or repetitive logic to these WASM modules. For IoT, this might include:

Automatically turning heating or cooling systems on or off based on room temperature.
Switching lights on when motion is detected, and off when no one is present.
Sending mobile alerts if smoke, gas, or an unusual sound is detected in a home or office.

Executors pick up the computation task, run the logic, and return the result. Outputs are cryptographically signed and passed to the Sequencer, which posts results back to Ethereum. For use cases that demand sub-second responsiveness, like reacting to real-time sensor input, a pre-confirmation mechanism allows applications to act on the result immediately, even before full confirmation or finality on Ethereum. Once finalized, the Mirror Contract updates its state, making the result accessible to any dApp that needs it.

Because Gear.exe allocates up to 2 GB of memory per program and supports multi‑threaded execution, you can run sophisticated logic without being constrained by Ethereum’s gas or memory limits.

So, What Happens When Your Sensor Speaks?

Sensor Gateway → Mirror Contract: Your IoT gateway bundles a batch of readings into a transaction that calls the Mirror Contract’s request function.
Event Detection by Executors: Executors monitor Ethereum for those request events. Once spotted, they fetch the corresponding WASM code from Gear.exe’s network and run it against the payload.
Off‑Chain Computation: Within milliseconds, the WASM logic validates each reading, dropping out‑of‑range values, running anomaly scores, and determining if an automation trigger fires.
Sequencer Aggregation: Executors sign their outputs, forwarding them to the Sequencer, which batches results to reduce on‑chain calls and covers the associated gas fees.
Instant Pre-Confirmation for dApps: The Sequencer emits a signed pre-confirmation of the result before final settlement. dApps can consume this off-chain signal and react immediately, which is ideal for automation that can’t afford to wait for Ethereum’s finality.
Router Contract → Mirror Contract: The Router Contract ingests the batch, updates the Mirror Contract’s state, and emits an event signalling completion. Now, your dApp or another contract can read the validated results, such as temperature breach detected, directly on Ethereum.

Explore the whitepaper for comprehensive insights and technical details on Gear.exe’s architecture and capabilities.

Mirror Contracts: Your Off‑Chain On‑Ramp

Mirror Contracts are more than just convenience wrappers. They allow Ethereum to maintain visibility and control over off-chain execution without needing custom bridges or centralized middleware.

Each Mirror Contract emits request events and receives result events. This two-way messaging system allows off-chain logic to stay verifiable, trackable, and auditable, while keeping on-chain interaction lean and gas-efficient.

Developers also benefit from working with familiar tools. Mirror Contracts are standard Solidity contracts that integrate cleanly with MetaMask, Hardhat, and indexing services.

Grounding the Concept: Supply Chain Automation

Consider a logistics company transporting perishable goods. Containers are equipped with IoT sensors that monitor temperature and humidity. If the temperature rises above a certain threshold, the shipment is compromised.

A typical Web3 approach might try to log every reading on-chain. That’s unworkable.

With Gear.exe:

The sensor gateway pushes readings to a Mirror Contract every minute.
A WASM module on Gear.exe validates the data off-chain. It might average the last five readings, apply anomaly filters, and check if the breach is sustained.
If a breach is confirmed, the result is returned on-chain.
The Ethereum smart contract then unlocks an insurance payout or triggers a refund.

Only the breach event and its validated proof make it to Ethereum. The rest stays off-chain, where it belongs.

So What Makes Gear.exe the Right Fit?

Gear.exe delivers noticeable improvements in both cost and speed. Off-chain compute handles the heavy lifting, reducing transaction costs by moving expensive operations off Ethereum. Executors process tasks in parallel threads, enabling near-instant response times for critical triggers — ideal for applications that can’t wait on block finality.

This performance doesn’t come at the expense of trust. Executors are peer-selected through a restaking model, eliminating centralized control. Developers work with familiar tools: Rust for writing WASM logic, Solidity for smart contracts, and the same Ethereum interfaces they already know.

Gear.exe allows developers to build smarter Ethereum dApps that don’t choke on sensor input or outsource logic to centralized APIs. For IoT builders, that’s the missing puzzle piece: decentralized automation that actually performs like the systems they’re trying to replace.

Gear.exe Testnet is around the corner — please reach out to hello@gear-tech.io if you are interested in building the next wave of highly performant blockchain Dapps.

Join Vara Network and Start Building

Vara Network is a stand-alone layer-1 decentralized network built and running on top of Gear Protocol. Created by Gear Foundation, Vara aims to be a performant and scalable network for developers to build market-leading decentralized applications.

Whether you’re looking to build a new project or bring existing applications to the blockchain, Vara Network’s unique architecture offers benefits — including deep scalability and unparalleled composability — making It the ideal platform for developers looking to build the next generation of dApps.

Would you like to become part of the community? Explore and join using the social channels below:

Vara

Gear Protocol

Technical Updates: Gear Release 1.8.1 | May 2025 Recap

Gear Protocol — Thu, 29 May 2025 14:57:33 GMT

Gear Release 1.8.1 — A New Era of Reply Logic, Error Semantics & Economic Security

This post presents a combined overview of Gear releases v1.8.0 and v1.8.1 — two important updates that introduce critical protocol-level improvements and runtime refinements. Together, they signal a clear shift toward stronger execution guarantees, developer-friendly debugging, and tightened economic boundaries.

Note: Whether you’re building dApps, writing runtime logic, or integrating with Gear infrastructure — this release cycle matters.

TL;DR — What Changed and Why It Matters

The Gear protocol is evolving with tighter invariants, more robust error semantics, and stronger economic deterrents. This release brings:

A fundamental shift in how value is returned through error messages
Major upgrades to error reply codes and panic behavior
A substantial gas/weight price increase to deter network abuse
Runtime and userspace improvements for more stable and efficient development

Key Highlights

1. Protocol Invariant Change: Value Now Only Flows Through Messages (#4634)

Previously, any error would auto-return the value to the source silently. Not anymore.

From now on:

All value transfers must happen via messages, including error replies.
If the original message doesn’t expect a reply and the program fails — the value is retained by the destination program.
In handle_reply, you can now reliably track how much value was returned, ensuring transparent and traceable logic.

💡 This strengthens control and predictability in smart contract execution.

2. gr_panic Now Accepts Arbitrary Bytes (#4583)

The gr_panic syscall is now fully flexible:

Payload can contain any bytes, not just formatted strings.
This makes binary protocols and low-level debugging easier.
No more userspace hacks to encode complex errors.

3. Programs That Exit Now Always Reply (#4620)

If a program exits without manually sending a reply, an auto-generated reply is sent to honor the protocol invariant.

This guarantees:

Every repliable message always gets a reply
Client logic becomes more robust and predictable

4. Error Reply Codes Refactored and Made Self-Descriptive (#4589)

Error reply behavior has been updated to remove the soft requirement for string-formatted payloads.

Now:

UserspacePanic: contains raw byte payload
ProgramExited: includes inheritor ActorId
All other codes: payloads are empty — rely on the code alone

💡 Clarified and more flexible handling of payloads, making integration cleaner and less error-prone.

5. System GearBank Address Changed (#4588)

The GearBank account now uses Substrate-native PalletId derivation, changing its address to modlpy/gbank.

This makes it:

Recognizable to tools and explorers
Easier to integrate in governance and economic flows

6. Gas and Weight Cost Increased 100x (#4585)

To reduce attack surface and discourage abuse:

Gas/weight cost raised from 6 units to 100
Governance deposits increased
Spamming the network now comes with real cost

7. Builtins Now Lock Existential Deposit (#4633)

Built-in programs now behave like regular ones in terms of existential deposit logic:

Value is locked from the treasury
Ensures unified behavior and compatibility during migrations

Other Notable Updates

New WASM target: wasm32v1-none (#4407)
gmeta crate fully removed (#4347)
gtest and gsdk can now query inheritors of exited programs (#4616, #4622)
Replaced parity-wasm with custom WASM parser for long-term support (#4494)
Improved memory allocation and runtime election thresholds (#4473, #4428)
Added basic transport fees and governance tracks to gear-eth-bridge (#4590, #4527)

Would you like to become part of the community? Explore and join using the social channels below:

Vara

Gear Protocol

Technical Updates: Treasury & New Rust Edition | March 2025 Recap

Gear Protocol — Mon, 07 Apr 2025 21:12:05 GMT

March brought continued progress across the Gear Protocol, ecosystem tools, and its libraries — focusing on optimization, stability, and improvements to our economic model.

Developers made 33 contributions across the main repositories this month, with 26 commits on the Gear Protocol repository and 7 commits on the Sails repository. Network activity remained strong, with 113,326 active accounts and 487 new accounts added.

Key changes:

Treasury Redirection: 100% of transaction fees now go straight to the “Treasury”, strengthening funding for continued protocol improvements.

Rust Edition 2024: Upgraded to the latest Rust edition, enabling the use of modern language features.

Core Refactor: a minor internal optimization replaces full initialization allocations with a simple boolean flag, reducing memory usage and speeding up initialization.

BLAKE3 Update: library has been updated to the latest version, providing improved performance for hashing operations.

Join Vara Network and Start Building

Would you like to become part of the community? Explore and join using the social channels below:

Vara

Website | X | Discord | Telegram

Gear Protocol

Website | X | Discord | Telegram