Axone deployment workflows with cargo-make, cw-orch, and Abstract. Use when publishing modules, installing them on accounts, running local chain tasks, or inspecting deployments.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Prefer repository tasks over ad hoc deployment commands.
cp .env.example .env
Then set the relevant mnemonic values in .env.
The repository already defines:
LOCAL_MNEMONIC for local developmentTEST_MNEMONIC for testnet deploymentMAIN_MNEMONIC for mainnet deploymentPrimary repository aliases:
localtestnetmainnetaxone-localnetaxone-dendrite-2axone-1Other cw-orch-supported networks may also work when the scripts support them.
Use these tasks for local chain lifecycle:
cargo make chain-initialize
cargo make chain-start
cargo make chain-logs
cargo make chain-stop
cargo make clean-chain
Repository note:
chain-start automatically for local targetsDeploy Abstract core contracts with:
cargo make deploy-abstract local
cargo make deploy-abstract testnet
Inspect the resulting deployment info with:
cargo make deploy-abstract-info local
cargo make deploy-abstract-info testnet
Treat deploy-abstract-info as the normal post-deploy verification step for infrastructure.
Publish a module with:
cargo make deploy-contract axone-gov local
cargo make deploy-contract axone-gov testnet
Repository behavior of deploy-contract:
.wasm files into artifacts/ for cw-orch lookupcargo make deploy-script publish ...Use cargo make release-wasm only when you explicitly need optimized production artifacts and checksums. The normal publish flow uses cargo make wasm when it needs to build.
Install a module on an Abstract account with:
cargo make deploy-install axone-gov local
cargo make deploy-install axone-gov testnet
The repository task also supports additional CLI-style arguments after the contract name. Keep using cargo make deploy-install ... instead of calling the binary directly unless you have a reason to bypass the task wrapper.
Use the repository inspection tasks instead of raw chain commands when possible:
cargo make contract-list
cargo make contract-inspect <code_id>
cargo make contract-query <address> '{"query_msg": {}}'
cargo make contract-execute <address> '{"execute_msg": {}}'
For lower-level chain access:
cargo make chain status
cargo make chain query bank balances <address>
The repository keeps publish and install entrypoints in each contract:
contracts/<name>/src/bin/publish.rs
contracts/<name>/src/bin/install.rs
Use the wrapper task when running them:
cargo make deploy-script publish axone-gov local
cargo make deploy-script install axone-gov local
For a normal local flow:
cargo make deploy-abstract localcargo make deploy-abstract-info localcargo make deploy-contract <contract> localcargo make deploy-install <contract> localcontract-query, contract-inspect, or targeted chain queriesNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Best practices for designing CosmWasm smart contract APIs. Use when defining message types, designing execute/query interfaces, or optimizing API ergonomics.
The English summary is being prepared. Showing the original description.
Guide for writing Rust doc comments that produce accurate generated contract documentation. Use when editing Instantiate/Execute/Query/Response types or any public schema-facing API.
The English summary is being prepared. Showing the original description.
Guide for writing conventional commit messages. Use when committing changes, writing commit messages, or reviewing commit history.
The English summary is being prepared. Showing the original description.
Axone contract structure and Abstract SDK patterns. Use when scaffolding or refactoring contracts, deciding layer boundaries, wiring AppContract entrypoints, or adding module metadata and replies.
The English summary is being prepared. Showing the original description.
Guide for regenerating Axone contract schemas and rendered Markdown docs. Use when contract APIs or metadata change, when checking generated-doc drift, or when preparing documentation commits.
The English summary is being prepared. Showing the original description.
Domain-driven modeling patterns for Axone contracts. Use when introducing domain concepts, encoding invariants, or deciding boundaries between domain, handlers, services, gateways, queries, and state.
The English summary is being prepared. Showing the original description.