Skip to main content

Build, Deploy, and Test

Install and Start a Devnet​

Install the LDK and developer tools, then start a single-node local devnet with Docker Compose — see Quick Start for full details:

curl ldk.lyquor.dev -L | bash   # installs shaker, ladle, the Rust/Foundry toolchains, and the LDK under ~/.shakenup

# requires Docker Engine and Docker Compose v2
docker compose -f ~/.shakenup/ldk/docker/single/docker-compose.yaml up -d

The node serves its API at http://localhost:10087/api, a WebSocket at ws://localhost:10087/ws, and the dashboard at http://localhost:10087/lyquor/. For a 4-node topology, use docker/multi/docker-compose.yaml instead.

Build and Deploy​

Deploy a Lyquid with shaker. The example Lyquids ship inside the LDK under ~/.shakenup/ldk/lyquid-examples/:

shaker deploy ~/.shakenup/ldk/lyquid-examples/hello/Cargo.toml --debug

If the constructor takes ABI parameters, encode and pass them with --input:

shaker deploy ~/.shakenup/ldk/lyquid-examples/hello/Cargo.toml \
  --input $(cast abi-encode "constructor(string)" "Hello, World!")

The deploy output includes:

  • deployment status (created or updated)
  • Lyquid ID
  • EVM contract address

Start a brand-new project from the template:

cargo generate --git https://github.com/lyquor-labs/ldk.git lyquid-template --name <lyquid_name>

Stream console output from a running Lyquid:

shaker console <LYQUID_ID>

The node's web dashboard at http://localhost:10087/lyquor/ lists all deployed Lyquids together with their current contract addresses — useful if you lose track of an ID or its address.

Updating Deployed Code​

shaker deploy creates a new Lyquid by default — a fresh LyquidID and EVM contract. To replace the code of an existing Lyquid in place, pass its ID with --update:

shaker deploy path/to/Cargo.toml --update <LYQUID_ID>

The constructor runs atomically once per deploy and per code update; supply its input with --input in either case. Persistent state follows the memory model: network state is versioned by LyquidNumber, and instance state persists on each hosting node.

Packaging​

A Lyquid pack includes:

  • the Lyquid WASM layer
  • EVM deployment bytecode
  • optional EVM auxiliary bytecode
  • optional static assets
  • metadata
  • a digest over the OCI manifest

Static assets are collected from the Lyquid project's assets/ directory and packaged as one best-effort reproducible application/vnd.lyquor.lyquid.assets.v1.tar+xz layer with the assetType=assets annotation. Asset serving failures are usually packaging or image availability issues if the Lyquid API endpoint works but static asset paths return 404.

Inspect the metadata embedded in a built pack or raw WASM binary with:

shaker inspect path/to/pack-or-wasm

Testing and Debugging​

Testing​

Keep application logic in ordinary Rust functions so you can unit-test it with the standard toolchain without the runtime:

cargo test

For end-to-end behavior, deploy to a local devnet and interact with the Lyquid. The tutorial, ERC20 example, and BasicSwap example all walk through deploy-and-interact flows you can adapt as integration checks.

Debugging​

Use Lyquid console output for application-level traces:

lyquid::println!("transfer {} from {} to {}", amount, from, to);

View it with shaker console <LYQUID_ID>.

For node logs, follow the node container. Raise verbosity by setting LYQUOR_LOG in the Compose file's environment (e.g. LYQUOR_LOG=debug):

docker compose -f ~/.shakenup/ldk/docker/single/docker-compose.yaml logs -f node

When debugging hosted Lyquid sites, distinguish routing from packaging:

  • if /lyquid/api or /lyquid/statusz works, host routing is alive
  • if /index.html fails, inspect asset packaging and image availability first
  • use the web dashboard at http://localhost:10087/lyquor/ to confirm hosting state