5. Build and test components
-
Make sure that Docker is installed. If you are using Docker Desktop, make sure it is open and running. If you are using Mac OS, make sure that your Docker app is configured correctly.
-
Make sure that you have already run the following commands from the system setup section.
cargo install cargo-binstallcargo binstall cargo-component warg-cli wkg --locked --no-confirm --force# Configure default registrywkg config --default-registry wa.dev
Build WASI component
Run the following command in your terminal to build your component.
make wasi-build
This command will build any components present in the /components
directory, as well as auto-generate bindings and compile the components to WASM. The output will be placed in the compiled
directory.
You can also use the command below to build your solidity contracts and components in one command:
make build
Testing and debugging
You can use the following command to test the WASM component locally. This command is handy for testing components without having to deploy WAVS.
An ID of 1 is Bitcoin. Nothing will be saved on-chain, just the output of the component is shown.
COIN_MARKET_CAP_ID=1 make wasi-exec
This command runs your component locally in a simulated environment and lets you easily view print
statements for debugging.
COIN_MARKET_CAP_ID
is the ID of the asset to fetch the price for. This input is formatted as a bytes32
string using cast format-bytes32-string
before being passed to the component.
Running this command in the oracle example will run the component, fetch the price of Bitcoin, and print the result. Visit the component walkthrough for more information on logging during testing and production.
Upon successful execution, you should receive a result similar to the following:
resp_data: Ok(PriceFeedData { symbol: "BTC", timestamp: "2025-02-14T01:23:03.963Z", price: 96761.74120116462 })INFO Fuel used:1477653Result (hex encoded):7b2273796d626f6c223a22425443222c2274696d657374616d70223a22323032352d30322d31345430313a32333a30332e3936335a222c227072696365223a39363736312e37343132303131363436327dResult (utf8):{"symbol":"BTC","timestamp":"2025-02-14T01:23:03.963Z","price":96761.74120116462}
In the output above, the INFO Fuel used
value represents the computational power consumed during execution. Similar to how on-chain transactions have a gas limit to cap transaction costs, WAVS enforces a fuel limit to control off-chain computational workload and protect against DoS attacks.
The maximum fuel allocation can be adjusted in the Makefile
to accommodate different processing needs.
Custom triggers
When developing a custom trigger, you will need to update the template code in a few places:
- The trigger contract itself in
src/WavsTrigger.sol
, which defines how triggers are created and emitted on-chain. - The
wasi-exec
command in theMakefile
, which passes input data when testing WAVS components via--input `cast format-bytes32-string $(COIN_MARKET_CAP_ID)`
. This simulates an Ethereum event during local execution. - The
decode_trigger_event
function in/components/eth-price-oracle/src/trigger.rs
, which processes the trigger data and extracts relevant fields liketrigger_id
anddata
. - The
run
function in/components/eth-price-oracle/src/lib.rs
, which calls decode_trigger_event, processes the extracted trigger data, and determines how to handle it. - The trigger script in
/script/Trigger.s.sol
, which calls theaddTrigger
function with thecoinMarketCapID
, used in this template for the oracle example.
Contract interfaces
You can view the code for the Solidity interfaces on the WAVS NPM package site: https://www.npmjs.com/package/@wavs/solidity?activeTab=code