v0.1.6 — stable boundary names + wire-path hardening

thebes-deploy v0.1.6 — stable boundary names + wire-path hardening

Deploy smart contracts to the Thebes substrate from your terminal. This release removes raw validator IPs from every client surface and hardens the wire path for proxy transport.

What's new

• Validators are addressed by stable boundary names. thebes-deploy init now scaffolds validators = ["https://memphis.mercaturaforum.com/deploy-api/v0" … /v3] — the boundary resolves validator addresses server-side, so a validator rehoming never touches your manifest. Existing manifests keep working; swap their validators entries for the boundary URLs to become rehoming-proof.
• Ingress expiry margin. Envelopes are stamped +4min, one minute under the substrate's 5-min max-future window, so a validator whose clock trails yours no longer rejects with EXPIRY_TOO_FAR_FUTURE.
• Transport resilience. Receipt polling rides out transient proxy hiccups (the phase deadline owns giving up — default now 180s, THEBES_DEPLOY_PHASE_DEADLINE_SECS still overrides); submits retry twice on pure transport failures (safe: ingress is keyed by message hash, duplicates dedup); the HTTP client stops reusing stale keepalive sockets a proxy has closed.

Smart routing, sticky chunked installs, the credit-metered path, and the self-signed path are unchanged.

Install

curl -L https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.6-thebes-deploy/install-thebes-deploy.sh | bash

The installer downloads the binary, verifies md5 + sha256, and installs to /usr/local/bin (override with INSTALL_DIR). The binary is a static-pie musl build — no glibc or runtime dependency.

Verification

This exact binary was proven end-to-end against the live cluster before release, through boundary names only: fresh chunked deploy (counter, cid auto-assigned) → two live increment update calls → getCount returned (2 : nat). 94/94 workspace tests pass.

• size: 7505840 bytes
• md5: 8d590ca82e3bd5ebeec8d9f1149c203d
• sha256: a96f32d98bacbeb4e2c7570993ec223ab4c47747387d057e03b7afb338e26a68

— Menese DeFi Team

v0.1.5 — pipelined chunked uploads for large bundles

thebes-deploy v0.1.5 — pipelined chunked uploads

Deploy smart contracts and frontend bundles to the Thebes substrate from your terminal. This release removes the large-bundle wall: uploads no longer wait for one consensus finalization per 16 KiB chunk.

What's new

• Pipelined chunk uploads. Previously every store_chunk waited for its consensus receipt before the next chunk was sent — a 113 MB bundle meant ~7,200 sequential finalizations and multi-hour deploys that timed out at the edge. Chunks are now submitted back-to-back (order-preserving, pinned to one validator) and completion is reconciled against the canister's chunk_progress afterwards, so a deploy costs the submit round-trips plus a single finalization tail.
• Self-healing reconcile. If any chunk fails to land (expired envelope, pool backpressure, replay collision), the uploader reads received_indices and resubmits exactly the missing chunks — chunk storage is index-keyed, so resubmission is idempotent.
• Smarter nonce handling. Replay walk-forward now feeds the learned on-chain high-water mark back into the session's nonce allocator, so long uploads never re-discover it chunk by chunk.
• deploy --upgrade — state-preserving in-place upgrade for an already-installed canister (chunked commit with upgrade dispatch); the canister's cid must be explicit and its state survives.
• --init textual-Candid install arguments — parsed and encoded strictly; a malformed init arg is a hard error, never a silent empty argument.

The wire protocol, chunk sizes, and substrate are unchanged — this is a client-side change only and works against existing networks. The credit-metered path and the self-signed path both benefit.

Install

curl -L https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.5-thebes-deploy/install-thebes-deploy.sh | bash

The installer downloads the binary, verifies md5 + sha256, and installs to /usr/local/bin (override with INSTALL_DIR). The binary is a static-pie musl build — no glibc or runtime dependency.

Verification

• Integration-tested against a mock substrate node, including the failure path: a deliberately dropped chunk stalls progress, the reconcile arm resubmits exactly that chunk, and the upload completes (asserted one-resubmit).
• Full workspace test suite: 94/94 green from the committed source.
• Live large-bundle acceptance runs (100 MB+ game bundles) are in progress with a partner studio; results will be attached to the next release notes.
• size: 7,501,744 bytes
• md5: e6c9e7836086fcd0bda23f2dc92e69b9
• sha256: b7c90d92eeb15835fcda90496016ad9c8df6bd1b1bffd50cf7317f86b277d03f

— Menese DeFi Team

Asset canister v0.1.0 — certified frontend hosting

The asset canister serves a Thebes application's static frontend bundle as
certified on-chain assets, reachable at
https://memphis.mercaturaforum.com/_/raw/<cid>/index.html.

Reference this wasm in your thebes.toml to deploy a frontend:

[canisters.web]
type = "frontend"
cid = "auto"
wasm = "asset_canister.wasm"   # this release asset
bundle = "frontend/dist"       # your built static bundle
health_check_url = "/index.html"

thebes-deploy deploy web installs this wasm to a freshly allocated canister
and uploads your dist/ bundle as certified assets.

Artifact

• asset_canister.wasm — 571124 bytes
• SHA-256: 6b72e4fe96b0439e37e485b0bcbf5ac7ccda3a2fd51e39b3e9aa8f276bd55b77

Verify after download:

sha256sum -c asset_canister.wasm.sha256

v0.1.4 — credit-metered deploy + CLI API keys

thebes-deploy v0.1.4 — credit-metered deploy + CLI API keys

Deploy smart contracts to the Thebes substrate from your terminal. This release adds the credit-metered path: sign in once in the IDE, mint a CLI API key, and ship dapps that are billed against an on-chain credit pool — no canister-controller keys to manage.

What's new

• thebes-deploy login --api-key tbk_… — store the API key minted in the IDE (passkey sign-in → "API key" button). Pins the gateway it talks to.
• thebes-deploy credits — show your credit balance and how many deploys it buys.
• thebes-deploy deploy --metered — build every canister locally, upload the artifacts to the gateway, which charges your credit pool per contract and installs each as controller. The cid is gateway-assigned and written back to your manifest.
• New signup grant: 100,000,000 credits on first register = 5 single deploys (20M each) or 2 project deploys (40M each).

The original self-signed path is unchanged: identity new → setup → init → deploy signs install envelopes with a local identity and uses no credits.

Install

curl -L https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.4-thebes-deploy/install-thebes-deploy.sh | bash

The installer downloads the binary, verifies md5 + sha256, and installs to /usr/local/bin (override with INSTALL_DIR). The binary is a static-pie musl build — no glibc or runtime dependency.

Onboarding (credit-metered)

1. Open the IDE, sign in with a passkey, click API key:
   https://memphis.mercaturaforum.com/_/raw/129525575222700/index.html
2. thebes-deploy login --api-key tbk_…
3. thebes-deploy credits
4. thebes-deploy init then edit thebes.toml
5. thebes-deploy deploy --metered

Full guide: docs/deploying.md in this repo.

Verification

This exact binary was proven end-to-end against the live cluster before release:
register (100M grant) → mint API key → login → deploy --metered (counter, charged 20M, installed) → live inc/get calls → on-chain balance dropped to the expected amount.

• size: 7,436,208 bytes
• md5: bd4dd077ec8a21ef526f70791629e198
• sha256: c6c6f1711f251413a5babab4902d0b5c7280048bd64dd026c4d97a48cd419958

— Menese DeFi Team

v0.1.3 — fix ENOENT on default relative manifest

thebes-deploy v0.1.3

Fix — deploy/build with the default manifest no longer fails with ENOENT.

Running thebes-deploy deploy (or build) in a project directory with the
default relative thebes.toml failed with Error: No such file or directory (os error 2). Path::parent() of a bare relative filename returns an empty
path, not None, so the build step spawned its child process with an empty
working directory. The manifest directory now resolves to . when the parent
is empty or absent. Pinned with regression tests.

This restores the most common first-run flow:

thebes-deploy init
thebes-deploy deploy

Verified on the testnet

This binary deployed and called two contracts end-to-end: a counter
(increment / get → 0→1→2) and a full-stack storefront (products /
placeOrder / myOrders, orders read back from chain state).

Install

curl -L https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.3-thebes-deploy/install-thebes-deploy.sh | bash

See docs/deploying.md for the full walkthrough.

v0.1.2-thebes-deploy — wire format hex + receipt lifecycle vocab

v0.1.2-thebes-deploy — wire format hex + receipt lifecycle vocab

Patch release. The v0.1.0 binary couldn't actually deploy against the
production WAN cluster (forever-binary) because three wire-protocol
mismatches blocked every install. This release closes them. Verified
end-to-end 2026-05-23 against chain_id=2026, 4-validator cluster;
377 KB Motoko wasm → fresh canister in 15 s.

Fixes

1. Byte fields now serialize as hex, not base64. The protocol
crate's base64_bytes helper emitted real base64; the substrate's
matching helper encodes/decodes hex. A wasm_sha256 field arrived as
e.g. "l4yJ..." and the substrate's hex::decode failed at character
'l' → HTTP 422 "Invalid character 'l' at position 0". Now both
sides emit hex. Module name preserved so grep base64_bytes lines up
across the substrate and the deploy tool.

2. cycles_used accepts null. Substrate emits null for
receipts in pending lifecycle; the prior cycles_used: u64 panicked
with invalid type: null, expected u64, surfacing only as a generic
reqwest "error decoding response body". Now Option<u64>.

3. Receipt poll now recognises the substrate's lifecycle vocabulary.
Substrate emits exactly four values — "success" / "error" /
"pending" / "unknown" — but the prior is_terminal() matched
"ok" / "error" / "rejected" / "trapped", so a successful
install never terminated the poll and the deploy hit the 30 s phase
deadline despite the install having actually succeeded. The terminal
set now includes the substrate's real strings; legacy strings retained
as a forward-compat buffer. New is_success() helper for the explicit
check.

Operational improvements

• Per-phase deadline raised to 60 s and env-overridable via
  THEBES_DEPLOY_PHASE_DEADLINE_SECS for slow WAN deploys without a
  recompile.
• Schema-mismatch errors now include the response body instead of
  swallowing it inside reqwest's Transport error — the diagnostic
  tells you exactly which field shape diverged.
• Optional install_start trace via THEBES_DEPLOY_TRACE_MESSAGE_IDS=1
  so an operator chasing a stuck deploy can curl /api/receipt?hash=<id> against any validator and see why.
• New regression test in thebes-deploy-protocol
  (install_start_byte_fields_serialize_as_hex_not_base64) — fails
  loudly if hex-vs-base64 ever regresses.

Verification

metric	value
size	7 164 704 bytes
md5	c3dd9cb32877aab4faa19a94a3f3bf4e
sha256	8f05870416fc0dde3a5af1a0757f438f47841cf63d6bca40602c4d9ad34ebc43
platform	Linux x86_64
tests	14/14 protocol, 12/12 client, 5/5 install

Install

curl -L https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.2-thebes-deploy/install-thebes-deploy.sh | bash

Override INSTALL_DIR to install somewhere other than /usr/local/bin.
The script preserves any prior binary as thebes-deploy.backup.<md5>
so rollback is local.

Upgrade from v0.1.0

No manifest or workflow changes. Re-run thebes-deploy deploy against
your existing thebes.toml. The new error semantics surface real
errors faster (no more 30 s waits on a successful install), and the
new THEBES_DEPLOY_PHASE_DEADLINE_SECS env var lets ops bump the
budget without rebuilding when a WAN cluster is slow.

Authored by Menese DeFi Team.

v0.1.1 — frontend-link deploy summary

v0.1.1-thebes-deploy — frontend-link deploy summary

Successful thebes-deploy deploy now closes with the URLs the
operator can hand to a teammate or open in a browser; one line per
frontend canister; one line per backend canister; the boundary URL
written out in full for frontends, the cid written out for backends.

✓ deploy complete

Frontends — open in a browser:
  portal       cid 174832  https://memphis.mercaturaforum.com/_/raw/174832/index.html
  marketing    cid 192201  https://memphis.mercaturaforum.com/_/raw/192201/index.html

Backends — call via `thebes-deploy call <name> <method>`:
  ledger       cid 110447
  applications cid 138992

No protocol changes; same wire format; same identity model; same
manifest format as v0.1.0.

Binary: thebes-deploy (Linux x86_64)
md5: 1f9d58f00ff8ffe19119bd83fc95beb5
sha256: 2a987ddd12eba9eaeb63926f70de91c25c3d76e5e3113b7c4e6c8c9abfce324d
Size: ~7.1 MB

Install

curl -L https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.1-thebes-deploy/install-thebes-deploy.sh | bash

Installs to /usr/local/bin/thebes-deploy (override with INSTALL_DIR=/path).

Or pull just the binary:

curl -L -o thebes-deploy \
  https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.1-thebes-deploy/thebes-deploy
chmod +x thebes-deploy
md5sum thebes-deploy   # should match 1f9d58f00ff8ffe19119bd83fc95beb5

Source

Source is in the private KYounesMercatura/Thebes-Project repo under
tools/thebes-deploy/; eight crates; no internal substrate
dependency. Reproduction: cargo build --release -p thebes-deploy
on the same Rust toolchain (1.75+) yields a byte-identical binary.

v0.1.0-thebes-deploy — first public release

v0.1.0-thebes-deploy — first public release

The deploy tool for the Thebes substrate. One binary; one manifest;
one command — thebes-deploy deploy — that compiles every smart
contract a project declares, signs the install envelopes, uploads
the frontend bundles, and verifies the result against the cluster's
boundary. The substrate's chunked install protocol, the smart-routed
HTTP client, and the asset-bundle upload pipeline are inside; the
operator does not see them; the operator sees a deploy that either
succeeds or surfaces a clear error pointing at the right page of the
deployment-procedures folder.

Binary: thebes-deploy (Linux x86_64)
md5: 70e88cf8de31be35ef35bc738b925e73
sha256: 32ce9f42772133f5bc3d3a37c315615c7854e59babb952c9c3fedaa6bb482a37
Size: ~7.1 MB

Install

curl -L https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.0-thebes-deploy/install-thebes-deploy.sh | bash

Installs to /usr/local/bin/thebes-deploy (override with INSTALL_DIR=/path).

Or pull just the binary:

curl -L -o thebes-deploy \
  https://github.com/Mercatura-Forum/Thebes-Protocol-/releases/download/v0.1.0-thebes-deploy/thebes-deploy
chmod +x thebes-deploy
md5sum thebes-deploy   # should match 70e88cf8de31be35ef35bc738b925e73

First-time setup

thebes-deploy identity new alice          # generate an ed25519 identity
thebes-deploy setup                       # check moc, mops, cargo, mo:core
thebes-deploy init                        # scaffold thebes.toml in your project

Quick start

After editing the scaffolded thebes.toml to name your canisters:

thebes-deploy deploy                      # build + install + upload + verify
thebes-deploy status                      # cluster + per-validator view
thebes-deploy query <name> <method> --arg '(42 : nat)'
thebes-deploy call  <name> <method> --arg '(42 : nat, "hello")'

What's in this release

Eight crates, ~5,900 LOC of source, ~600 LOC of tests, 82/82 tests
green at release time.

Crate	What
thebes-deploy-manifest	Parses thebes.toml; validates; resolves paths; supports cid = "auto" for random one-time canister-id allocation with write-back.
thebes-deploy-identity	ed25519 seed files at ~/.thebes/identities/<name>.seed (mode 0600); principal derivation byte-for-byte compatible with the substrate.
thebes-deploy-protocol	All ten IngressMessage variants; length-prefixed canonical signing payload; v2 envelope with chain-id binding; sign / verify_outer / message_id; chunked-install upload_id via BLAKE3.
thebes-deploy-client	Smart routing — probes every validator's /api/status; picks the lowest-queue non-laggard; sticky per multi-step operation; submits signed envelopes; polls receipts.
thebes-deploy-install	Three-phase chunked install orchestrator — install_start + install_chunk × N + install_commit against one validator.
thebes-deploy-assets	Frontend bundle uploader — per-file chunked upload through start_chunked_upload + store_chunk + chunk_progress poll + finish_chunks; --prune + --force-replace.
thebes-deploy-build	Motoko via moc; Rust via cargo build --target wasm32-unknown-unknown --release; setup probes the toolchain.
thebes-deploy	The binary; the orchestrator; rotating educational facts during slow phases; doc-section pointers on error.

Subcommands

thebes-deploy init                          scaffold thebes.toml
thebes-deploy identity new <name>           generate ed25519 identity
thebes-deploy identity use <name>           set active
thebes-deploy identity list                 show all + principals
thebes-deploy identity whoami               print active principal
thebes-deploy identity import <name> --seed-hex <HEX>
thebes-deploy setup                         check moc/mops/cargo/mo:core
thebes-deploy build [<name>]                compile canisters
thebes-deploy deploy [<name>]               build + install + upload + verify
thebes-deploy status                        per-validator status table
thebes-deploy verify <name>                 re-run post-deploy checks
thebes-deploy call <name> <method> --arg '<candid-text>'
thebes-deploy query <name> <method> --arg '<candid-text>'

Identity model

Operator identity is local. Each identity is one ed25519 seed file at
~/.thebes/identities/<name>.seed; the file is the 32-byte seed
encoded as 64 hex characters; on Unix the file is mode 0600. The CLI
manages these through thebes-deploy identity new / import / use / list / whoami. Memphis, the substrate's end-user identity layer,
serves a different purpose — WebAuthn-anchored session tokens for
applications running on the chain — and is not in the deploy path.

Canister-id allocation

cid = "auto" in the manifest delegates allocation to the tool. On
first deploy, the CLI generates a random u64 in the 2^32..2^48 range,
probes the cluster to confirm the id is unused, installs, and writes
the chosen literal back into the manifest. Subsequent deploys reuse
the same id. The 281-trillion-id range makes collisions with
manually-chosen low-range cids impossible by construction.

Smart routing

Every operation queries the cluster's /api/status and picks the
validator with the lowest queue depth among non-laggards. Updates
prefer the leader on a tie (the leader's chunks skip a round of peer
gossip); queries prefer non-leaders on a tie (so the leader's
proposal tick is not slowed by query work). Chunked installs stick to
one validator across the three phases — the substrate's install
chunk store is per-validator.

Source

Source is at KYounesMercatura/Thebes-Project (private; under
tools/thebes-deploy/). The release binary is built from the
phase-p-wasm-1/force-checkpoint-on-install branch at the
v0.1.0-thebes-deploy tag.

Reproduction: clone the source, cd tools/thebes-deploy, and run
cargo build --release -p thebes-deploy. The resulting binary
should match this release's md5 byte-for-byte under the same toolchain
(Rust 1.75+).