Skip to main content

Contributor Guide

This guide walks you through contributing to ZecKit — from building the CLI locally to testing your changes in a real environment.

What you’ll do​

By the end of this guide, you will:

  • Build ZecKit locally
  • Run your local CLI version (not the published one)
  • Test changes against a real project
  • Debug issues confidently

Clone the repository​

git clone https://github.com/intelliDean/ZecKit
cd ZecKit

Build the CLI locally​

From the repository root:

cargo build --release

Where is the CLI binary?​

After building, the local CLI will be available at:

./target/release/zeckit
Use the local binary

You should use this local binary instead of the globally installed zeckit command.

Run the local CLI​

Instead of running:

zeckit up

Run your local version:

./target/release/zeckit up

Optional: create a shortcut​

alias zeckit-local=./target/release/zeckit

Now you can run:

zeckit-local up

Test against a real project​

Clone the sample project:

git clone https://github.com/Supercoolkayy/zeckit-contributor-sample
cd zeckit-contributor-sample

Run the test script​

./test-local.sh

What this does​

The script will:

  • Detect your local ZecKit build
  • Spin up the devnet
  • Run the example app
  • Execute a full end-to-end transaction
tip

This is the fastest way to validate that your local changes actually work.

Your development workflow​

Here’s the typical contributor loop:

# 1. Make changes in the repo
# (edit your Rust code)

# 2. Rebuild
cargo build --release

# 3. Run locally
./target/release/zeckit up

# 4. Test changes
./target/release/zeckit test

Validate your changes​

Check the system status:

./target/release/zeckit status

Make sure:

  • Devnet is running
  • Faucet has balance
  • Tests are passing

Debugging​

View logs (example)​

docker ps
docker logs zeckit-zebra-miner-1

Reset everything​

./target/release/zeckit down --purge

Common pitfalls​

PitfallSymptomFix
Using the global CLIYour changes “don’t work”Use ./target/release/zeckit ...
Forgetting to rebuildOld behavior persistsRun cargo build --release again
Devnet state driftFlaky tests / weird balancesRun ./target/release/zeckit down --purge

Advanced tip: prefer local build on PATH​

If you want your shell to always use your local build while in the repo:

export PATH="$(pwd)/target/release:$PATH"

Now:

zeckit up

…will use your local build.

success

You now have a complete local development workflow for contributing to ZecKit.