Overview

What is WAVS?

Developers building decentralized applications face an impossible choice:

• Run everything on-chain — Prohibitively expensive and slow
• Rely on centralized servers — Defeats the purpose of decentralization
• Build custom infrastructure — Months of scaffolding across separate bridges, oracles, and serverless functions

WAVS (Web Assembly Verifiable Services) is the event-driven framework for distributed architectures that provides a third option: verifiable off-chain compute through a unified framework. Developers define events (on-chain, off-chain, or internal), trigger workflows that execute components via the WAVS Engine, and submit verifiable outputs on-chain. Bridges, oracles, and other third-party server functions become first-class events — handled natively within one framework instead of stitched together across separate systems.

Write logic in languages you already know — Rust, Golang, JavaScript/TypeScript, or Python — compiled to WASM and executed at near-native speed. WAVS separates services from the operators that run them: builders define components, operators execute them off-chain, sign the results, and commit them on-chain. Off-chain compute with on-chain verifiability.

Why WAVS?

Ship faster — Skip the boilerplate and focus on your application. Built-in tooling handles event parsing, signature aggregation, and coordination logic. Components can be added, updated, or modified without coordinating changes across an operator set. Build in languages your team already knows — no new smart contract languages required.

Lower costs — One framework replaces three separate systems. Oracles, bridge integrations, and serverless functions are all first-class events in WAVS, so you're not paying for and maintaining each independently. Your core logic runs in standard languages, so you can hire general-purpose engineers and choose the chain, security model, and deployment shape that fits your budget and roadmap.

No lock-in — Your application logic isn't trapped in one chain, one execution model, or one vendor's roadmap. WAVS is compatible with ZK proofs, TEEs, MPC, and multiple security models (PoA, restaking). Switch chains, security models, or verification methods as your product grows — without rewriting core logic. WAVS is open source with no business license.

Use cases

WAVS supports a wide range of use cases, enabling powerful, verifiable off-chain computation across different domains:

• Decentralized AI: WAVS unlocks decentralized AI that is deterministic and verifiable, enabling trustless decision-making and autonomous governance through DAO-controlled AI agents.
• Oracles: Create and dynamically deploy new oracles as easily as uploading a component to your service to verifiably bring data from any source on-chain.
• Zero Knowledge Proofs: ZK verifiers, ZK Prover Marketplaces, and ZK aggregation layers can be deployed as lightweight WAVS service components, making it simple to build modular and composable proof services.
• Crosschain Bridges: Build secure, decentralized bridges with WAVS. Lock assets on one chain, trigger a verifiable service component, and mint them on another—all with trust-minimized execution.
• Dynamic applications: WAVS combines on-chain and off-chain services to build a cross-chain, decentralized application layer.
• Intelligent protocols: Build protocols that are verifiably aware of on-chain and off-chain events without relying on centralized infrastructure. Compose services and applications to enable complex webs of decentralized transaction flows.
• TEEs: WAVS can be used to build TEEs (Trusted Execution Environments) that run off-chain computations in a secure and verifiable manner, ensuring data integrity and confidentiality.

Building a service

WAVS removes the complexity of building a verifiable application, making it easy to develop and deploy custom services. With built-in infrastructure and developer tooling, WAVS powers a new multichain ecosystem of composable, decentralized, and verifiable applications.

This example will cover a basic verifiable service with three parts: a trigger, a service component, and submission logic.

Defining triggers

Triggers are the actions or events that prompt your service to be run. Currently, WAVS supports triggers from on-chain events from EVM and Cosmos chains, cron schedules, and block intervals for EVM or Cosmos chains. Triggers can be used to pass arbitrary data as the inputs for service components to be run. Operators running a service listen for specific trigger events and run the corresponding service component.

To learn more about triggers, visit the triggers page.

Service components

Service components are the core logic of a verifiable service. They are written in (Rust, Golang, JavaScript/TypeScript, C/C+ or Python)(./handbook/components/component#languages) and compiled to WASM as lightweight WASI components. WAVS provides a base layer of infrastructure, allowing you to focus solely on the logic of your service.

Service components can contain logic for processing input data from triggers. If a trigger passes data, a service component can use that data as input. For example, a simple service component could contain logic for receiving a number as input and returning the square of that number as output.

To learn more about service components, visit the How it works page. Check out the WAVS tutorial to learn how to create a service component.

Submission logic

Along with your component, you'll also need to define how the results of your service are submitted on-chain. With WAVS, you can use an aggregator and submission contract to define this logic.

Run your service

Builders define their service in a service manifest or service.json file with a workflow that includes a trigger, service component, and submission logic. Registered operators will then listen for the triggers specified by your service. Once triggered, operators will run your service off-chain, where data from a trigger is passed to a service component and run in a sandboxed WASI environment. Operators sign the result of the service computation and the verified result can be returned as an on-chain response.

With WAVS, service updates are streamlined: updates to services can be made by builders directly without needing to coordinate with operators. Operators only need to upgrade if there is a change to the WAVS node software itself.

Multichain capability

WAVS is built to be multichain. A service can be triggered by events on one chain, run by operators off-chain, and write verified responses to another chain. This interoperability is what makes WAVS so flexible, creating a decentralized computational layer that can function across multiple chains.

Composability

WAVS is composable by nature, allowing a verifiable service to dynamically run and manage multiple workflows that work together to build flexible and intelligent applications. Workflows include a trigger, service component, and submission logic. To compose services and workflows, the trigger of one workflow can be the submission logic of another workflow. The registry model allows component bytecode to be stored in one location and reused across multiple workflows.

Security

WAVS has a pluggable security layer — you choose the model that fits your application, from a simple permissioned deployment to full cryptoeconomic staking.

• Proof of Authority (PoA) — The simplest option. A contract owner (typically a deployer account, DAO, or multisig) manages the operator set directly, assigning each operator a numeric weight. No staking or external protocol required. The PoA middleware is audited and production-ready, making it a solid default for most services.

• TEEs (Trusted Execution Environments) — Components can run inside hardware-based TEEs such as Intel TDX or AWS Nitro Enclaves. TEEs provide confidential execution and hardware attestation, useful for services that require data privacy or need to prove that a specific binary ran unmodified.

• Restaking — Provides cryptoeconomic security by leveraging staked assets from a restaking protocol. Operators stake and are subject to slashing for misbehavior, aligning economic incentives with correct execution. EigenLayer and Symbiotic are examples of restaking protocols supported by WAVS.

Full-stack decentralization

WAVS enables full-stack decentralization by unifying off-chain computation with on-chain verifiability. The chain layer connects to Ethereum and other chains, while the security layer provides flexible, verifiable operator accountability — via PoA, TEEs, restaking, or a combination. At the app layer, lightweight WAVS powers WASM-based services to process off-chain computations triggered by on-chain events. Operators validate, sign, and commit the results back on-chain, ensuring verifiability and trust-minimized execution. This architecture makes WAVS a scalable, decentralized framework for full-stack applications.

Edit on GitHub