CCIP v2.0.0 VersionedVerifierResolver API Reference
VersionedVerifierResolver routes messages to specific Cross-Chain Verifier (CCV) implementations based on version and destination chain.
It determines:
- inbound verifier selection using a version prefix encoded in
verifierResults - outbound verifier selection using the destination chain selector
This enables support for multiple verifier versions and strategies within the same system.
Applications do not call this contract directly.
Usage Boundary
You do not call this contract directly.
- OnRamp and OffRamp components use this resolver to select verifier implementations.
- The owner configures mappings between versions, chains, and verifier contracts.
- You use this contract when supporting multiple verifier implementations or versions.
- You are responsible for ensuring mappings are consistent across chains.
Contract
ccvs/VersionedVerifierResolver.sol
Import
import {VersionedVerifierResolver} from "chainlink-ccip/ccvs/VersionedVerifierResolver.sol";
Inheritance
ICrossChainVerifierResolverITypeAndVersionOwnable2StepMsgSender
External API
getInboundImplementation
function getInboundImplementation(bytes calldata verifierResults) external view returns (address)
Returns the verifier implementation used to validate an inbound message.
- The verifier is selected using a version prefix extracted from
verifierResults.
| Parameter | Type | Description |
|---|---|---|
verifierResults | bytes calldata | Encoded verifier output containing a version prefix. |
Returns:
| Type | Description |
|---|---|
address | Verifier implementation for inbound validation. |
getAllInboundImplementations
function getAllInboundImplementations() external view returns (InboundImplementationArgs[] memory)
Returns all inbound verifier mappings.
getOutboundImplementation
function getOutboundImplementation(
uint64 destChainSelector,
bytes memory extraArgs
) external view returns (address)
Returns the verifier implementation used to construct an outbound message.
- The verifier is selected based on the destination chain selector.
getAllOutboundImplementations
function getAllOutboundImplementations() external view returns (OutboundImplementationArgs[] memory)
Returns all outbound verifier mappings.
applyInboundImplementationUpdates
function applyInboundImplementationUpdates(
InboundImplementationArgs[] calldata implementations
) external onlyOwner
Updates inbound verifier mappings.
applyOutboundImplementationUpdates
function applyOutboundImplementationUpdates(
OutboundImplementationArgs[] calldata implementations
) external onlyOwner
Updates outbound verifier mappings.
getFeeAggregator
function getFeeAggregator() external view returns (address)
Returns the configured fee aggregator.
setFeeAggregator
function setFeeAggregator(address feeAggregator) external onlyOwner
Updates the fee aggregator.
withdrawFeeTokens
function withdrawFeeTokens(address[] calldata feeTokens) external
Withdraws accumulated fees to the configured aggregator.
Events
event InboundImplementationRemoved(bytes4 version)event OutboundImplementationRemoved(uint64 destChainSelector)event InboundImplementationUpdated(bytes4 version, address prevImpl, address newImpl)event OutboundImplementationUpdated(uint64 destChainSelector, address prevImpl, address newImpl)event FeeAggregatorUpdated(address indexed oldFeeAggregator, address indexed newFeeAggregator)
For a cross-contract event index, see Events.
Errors
error InvalidVerifierResultsLength()error InvalidDestChainSelector(uint64 destChainSelector)error InvalidVersion(bytes4 version)
For a cross-contract error index, see Errors.
Notes
- Inbound resolution must map to the same verifier implementation that produced the original verifier results.
- Resolver outputs must be deterministic for a given input.
- Resolver mappings must be consistent across chains to ensure compatible verification behavior.
- Returning an incorrect implementation may result in message validation failure or execution under the wrong security model.
- Version-based routing enables safe upgrades and coexistence of multiple verifier implementations.
Security model
- Owner controls resolver mappings.
- Incorrect configuration may route messages to incompatible verifier implementations.
- Fee withdrawals are routed to the configured aggregator.