Summary: Valence Protocol is best understood as a cross-chain execution environment for pre-structured multi-party programs rather than as a bridge, vault, or solver marketplace. Its docs describe a system where developers configure programs out of accounts, libraries, subroutines, and authorizations across multiple domains, then route execution through per-domain Authorization and Processor contracts, optional cross-domain connectors, and an emerging ZK coprocessor path for verifiable offchain computation. The reusable mechanism insight is that Valence shifts practical authority into whoever defines program structure, subroutine permissions, connector choices, and processor behavior before execution starts, rather than into a live solver market picking routes on the fly.
What it does:
Lets builders configure cross-chain DeFi workflows as Valence Programs rather than writing bespoke contracts for every multi-domain operation
Represents a program as accounts and libraries deployed across one or more domains, with executable subroutines that call specific library functions
Uses an Authorization contract as the user entry point and policy hub for deciding who may trigger which subroutines and under what constraints
Uses a Processor contract to execute authorized message batches, with queued permissionless ticking on CosmWasm and immediate execution in the currently implemented EVM lite processor
Supports cross-domain routing through connectors such as Polytone for CosmWasm environments and Hyperlane mailboxes for EVM environments
Adds an optional ZK coprocessor model where guest programs perform offchain computation and submit proofs back to onchain Valence contracts
Key claims:
The introduction says Valence is a unified development environment for building trust-minimized cross-chain DeFi applications and emphasizes that many programs can be deployed from configuration files without writing new application logic, which is the clearest reason to treat it as an execution environment rather than a single app
The programs overview says Valence supports both on-chain execution and off-chain execution via a ZK coprocessor, which matters because the protocol is explicitly trying to separate workflow definition from where computation occurs
The programs-and-authorizations docs define a Valence program as an arrangement of accounts and libraries across multiple domains, with subroutines limited to one execution domain at a time, showing that the protocol decomposes cross-chain workflows into bounded per-domain execution units rather than one omnichain transaction model
The authorization model supports open access, permissioned access, start/end times, expiration, enable-disable flags, and parameter constraints, which means the core control surface is predeclared permission structure rather than discretionary operator behavior during execution
The Authorization contract is described as the authority and message-routing hub, while the Processor executes the resulting message batches, making the protocol’s operational center a policy-plus-execution split rather than a generic router
The docs distinguish between CosmWasm TokenFactory-based per-label permission tokens and EVM address-plus-function allowlists, which is useful because Valence is not enforcing one universal cross-chain permission primitive; it adapts authority to each target environment
The connectors docs say cross-domain programs currently rely on Polytone for CosmWasm↔CosmWasm routing and Hyperlane for EVM routing, so interoperability trust is partly inherited from connector choice and relayer assumptions rather than abstracted away
The ZK overview says guest programs can run offchain on a dedicated coprocessor and return succinct proofs for onchain verification, showing that Valence also wants to be a verifiable offchain-compute environment, not only a message router
The GitHub README says the project is no longer under active development but that parts of the toolchain have stabilized for cross-chain liquidity deployment and multi-party agreements, which matters for corpus use: it remains analytically interesting as a design pattern even if it is not presently the most active ecosystem front end
Whitepaper: No standalone Valence whitepaper surfaced in this pass. The clearest current sources were the official documentation set and repository materials collected in ../whitepapers/valence-protocol-primary-sources-2026-05-08.md.