Agent guide for this repository. A copy of this file is emitted as both
AGENTS.md and CLAUDE.md at the repo root.
A generated, read-only mirror. Every file here is synced from
developer-frameworks/examples/ in the
SubzeroLabs/rialo monorepo by the
rialo-examples-release tool; the sync wipes and rewrites the whole tree, so
local commits and pull requests against this repository are lost on the next
sync. Copy scaffolds out of it; land changes in the monorepo. To change an
example, contribute under developer-frameworks/examples/.
The Cargo.toml workspace at the root is generated too: monorepo
workspace = true dependencies have been rewritten to the explicit published
crate versions (the sync's --release-version) so everything builds
standalone. Examples with a rex {} block additionally carry a vendored
wit/rex-component.wit: the Venus macro reads the REX host interface from
that path when building outside the monorepo, and the released crates do not
ship the file. Keep it when copying such an example out as a scaffold.
| Directory | Contents |
|---|---|
venus/ |
Venus workflow PDK examples: programs written inside the rialo! {} macro (http-fetch is the smallest; start there) |
Only examples that build standalone against the published crates are
mirrored. Monorepo examples that depend on unpublished in-repo crates (the
raw-programs/, plugins/, and sol/ families today) are skipped by the
sync and will appear here once their dependencies are published.
# Type-check every example: the same command the release pipeline's
# verify step runs against this repo. Needs only a stock Rust toolchain.
cargo check --workspace
# Produce a deployable PolkaVM blob for one program: build its artifact/
# companion crate. Needs the Rialo toolchain (install via rialoman).
cargo build --manifest-path <example-dir>/artifact/Cargo.tomlNot every Venus example ships an artifact/ crate (e.g. venus/http-fetch
does not; venus/rex-wasm-pipeline does). To deploy
one that doesn't, add the three-file artifact/ crate exactly as the
Fetch web data tutorial
describes; rialo client program deploy-venus expects that layout.
rialo config network switch devnet # RPC: http://devnet.rialo.io:4100
rialo client airdrop --amount 1 # faucet cap: 1 RLO per request; repeat to accumulate
# Deploy a built Venus program from its directory
rialo client program deploy-venus .
# Invoke an initiating function (argument names come from wit/<name>-manifest.json)
rialo client program invoke <PROGRAM_ID> --program-dir . \
--function start --arg workflow_pda_slug=random --arg url=http://example.com
# Follow the workflow across the framework-invoked transactions
rialo client get-workflow-lineage <TX_SIGNATURE> --full-id trueUse freshly generated DevNet keypairs (rialo keytool generate) funded by
airdrop only. Never use mainnet endpoints or production secrets, and never
pass a secret as a plain program argument (arguments are public transaction
data).
Inside rialo! {}, async DSL statements (AFTER, EVERY, ON, SEND,
START) register asynchronous operations executed off-chain by REX nodes;
they are forbidden inside for/while/loop blocks, closures, and async
blocks. To process a list, keep an index in workflow state and have the
handler advance it and re-issue. Functions in the rex {} block run in the
TEE and receive no workflow state; every input is an explicit parameter. The
keyword before a function assigns its role: initiating fn is a client
entry point, handler fn receives async results, control fn steers a
running workflow, terminating fn ends it and gets no instruction.
- Docs site: https://docs.rialo.io/user/latest/. The Venus track under
PDKs → Venus walks through
http-fetch,price-alert,websocket-feed,rex-wasm-pipeline, andrex-wasm-crypto - Single-fetch context: https://docs.rialo.io/user/latest/llms-full.txt
(the whole user book, the Venus DSL reference
usage-guide.md, and the anchor examples'src/lib.rsin one markdown file) - Page index: https://docs.rialo.io/user/latest/llms.txt