Summary
🔧 Installing soroban-cli...
cargo install --locked stellar-cli --features opt installs the wrong Rust target for the project. It adds , but the target is the only one Soroban SDK 26.x accepts on stable Rust.
Location
, lines 55–57:
Why it is wrong
The CI workflow explicitly calls this out (see job , lines 100–103):
The Makefile's own target uses correctly, but adds the incompatible target. So a new contributor who follows the README in order —
- 🔧 Installing soroban-cli...
cargo install --locked stellar-cli --features opt — adds
- — sees both targets listed
- 🔨 Building Soroban contract...
cargo build -p orbitchain-core -p orbitchain-campaign -p orbitchain-token-bridge -p orbitchain-common --target wasm32v1-none --release — uses and works
…ends up with a stale, unused target on their system that the README actively misinstructs them to use as the primary build target (, see README § "Building (Manual)"). The same wrong target also leaks into (), suggesting that script is stale and would attempt a build with the incompatible target if anybody ran it directly.
Impact
- Light documentation/install drift. New contributors end up installing a wasm target that the project does not actually use, and the README still shows example commands using it.
- ❌ WASM not found at target/wasm32-unknown-unknown/release/orbitchain_core.wasm — run 'make build-wasm' first references , which is not produced by 🔨 Building Soroban contract...
cargo build -p orbitchain-core -p orbitchain-campaign -p orbitchain-token-bridge -p orbitchain-common --target wasm32v1-none --release. If somebody runs ❌ WASM not found at target/wasm32-unknown-unknown/release/orbitchain_core.wasm — run 'make build-wasm' first after only 🔧 Installing soroban-cli...
cargo install --locked stellar-cli --features opt + 🔨 Building Soroban contract...
cargo build -p orbitchain-core -p orbitchain-campaign -p orbitchain-token-bridge -p orbitchain-common --target wasm32v1-none --release, the script would error out trying to find a wasm under the wrong path.
Fix
- Change line 57 of the to so 🔧 Installing soroban-cli...
cargo install --locked stellar-cli --features opt installs the target that 🔨 Building Soroban contract...
cargo build -p orbitchain-core -p orbitchain-campaign -p orbitchain-token-bridge -p orbitchain-common --target wasm32v1-none --release actually uses.
- Update the README's "Building (Manual)" / "Install Soroban CLI" sections to reference instead of , matching .
- Update ❌ WASM not found at target/wasm32-unknown-unknown/release/orbitchain_core.wasm — run 'make build-wasm' first (and the legacy 🔨 Building contract for network: testnet) to look for the wasm under so its matches what produces.
Severity
[LOW] — non-functional in CI (CI uses the right target directly), but tangible contributor-experience pain and a documentation/install drift that should be cleaned up in one pass.
Summary
🔧 Installing soroban-cli...
cargo install --locked stellar-cli --features opt installs the wrong Rust target for the project. It adds , but the target is the only one Soroban SDK 26.x accepts on stable Rust.
Location
, lines 55–57:
Why it is wrong
The CI workflow explicitly calls this out (see job , lines 100–103):
The Makefile's own target uses correctly, but adds the incompatible target. So a new contributor who follows the README in order —
cargo install --locked stellar-cli --features opt — adds
cargo build -p orbitchain-core -p orbitchain-campaign -p orbitchain-token-bridge -p orbitchain-common --target wasm32v1-none --release — uses and works
…ends up with a stale, unused target on their system that the README actively misinstructs them to use as the primary build target (, see README § "Building (Manual)"). The same wrong target also leaks into (), suggesting that script is stale and would attempt a build with the incompatible target if anybody ran it directly.
Impact
cargo build -p orbitchain-core -p orbitchain-campaign -p orbitchain-token-bridge -p orbitchain-common --target wasm32v1-none --release. If somebody runs ❌ WASM not found at target/wasm32-unknown-unknown/release/orbitchain_core.wasm — run 'make build-wasm' first after only 🔧 Installing soroban-cli...
cargo install --locked stellar-cli --features opt + 🔨 Building Soroban contract...
cargo build -p orbitchain-core -p orbitchain-campaign -p orbitchain-token-bridge -p orbitchain-common --target wasm32v1-none --release, the script would error out trying to find a wasm under the wrong path.
Fix
cargo install --locked stellar-cli --features opt installs the target that 🔨 Building Soroban contract...
cargo build -p orbitchain-core -p orbitchain-campaign -p orbitchain-token-bridge -p orbitchain-common --target wasm32v1-none --release actually uses.
Severity
[LOW] — non-functional in CI (CI uses the right target directly), but tangible contributor-experience pain and a documentation/install drift that should be cleaned up in one pass.