This guide covers the deployment of the Lodestar Service Registry. For detailed instructions on the Agents credit scoring contract, see contract/agents/DEPLOY.md.
- Rust toolchain (stable)
- Stellar CLI
curl -fsSL https://raw.githubusercontent.com/stellar/stellar-cli/main/install.sh | shOr via cargo (slower but also works):
cargo install --locked stellar-clirustup target add wasm32-unknown-unknownstellar keys generate deployer --network testnet
stellar keys fund deployer --network testnet# Service registry
cd contract
stellar contract build
# Agent credit scoring
cd agents
stellar contract buildThe compiled WASM files will be at:
contract/target/wasm32-unknown-unknown/release/lodestar_registry.wasmcontract/agents/target/wasm32v1-none/release/lodestar_agents.wasm
The registry is wired to the agents contract at deploy time (next step), so the agents contract must exist first. See contract/agents/DEPLOY.md for full details on the agents contract.
stellar contract deploy \
--wasm contract/agents/target/wasm32v1-none/release/lodestar_agents.wasm \
--source deployer \
--network testnet \
-- --admin <ADMIN_ADDRESS>Copy the printed agent contract ID — referred to below as <AGENTS_CONTRACT_ID>.
Pass the agents contract ID as the registry's constructor argument. This is
the only place reputation-voting authorization is configured: the agents address
is fixed at deployment and can never be changed or hijacked by a later caller, so
there is no separate (front-runnable) init step.
stellar contract deploy \
--wasm contract/target/wasm32-unknown-unknown/release/lodestar_registry.wasm \
--source deployer \
--network testnet \
-- --agents_contract <AGENTS_CONTRACT_ID>Copy the printed registry contract ID — referred to below as <CONTRACT_ID>.
Record the deployment in contract/deployments.json so the team has a
shared source of truth:
# Compute the WASM hash (also printed by `stellar contract install`)
sha256sum contract/target/wasm32-unknown-unknown/release/lodestar_registry.wasm
# Update deployments.json with the new values:
# - contractId: the printed contract ID
# - wasmHash: the sha256sum output
# - deployer: your deployer public key
# - deploymentLedger: the ledger number printed during deploy
# - deployedAt: ISO timestamp (date -u +"%Y-%m-%dT%H:%M:%SZ")The file is checked into version control so every contributor points at the same deployment and can independently verify the WASM hash on-chain.
The agents contract verifies service providers against the registry, so link it back (one-time):
stellar contract invoke \
--id <AGENTS_CONTRACT_ID> \
--source deployer \
--network testnet \
-- init --registry_contract <CONTRACT_ID>Copy both contract IDs into your .env files:
# backend/.env
CONTRACT_ID=<registry contract id>
AGENTS_CONTRACT_ID=<agent contract id>
# frontend/.env.local
NEXT_PUBLIC_CONTRACT_ID=<registry contract id>
NEXT_PUBLIC_AGENT_CONTRACT_ID=<agent contract id>The hosted backend casts reputation votes as a registered demo agent — by
default its own server key (SERVER_STELLAR_ADDRESS), which npm run seed-agents
registers as an agent. Set NEXT_PUBLIC_DEMO_AGENT_ADDRESS (frontend) to that
address. To let other pre-funded demo agents vote, add their secrets to
DEMO_VOTER_SECRETS (backend).
cd backend
npm install
SEEDING_MODE=true node scripts/seed.jsThis pre-populates the registry with demo services.
Generate three funded testnet keypairs for richer seed data:
stellar keys generate new-agent --network testnet
stellar keys fund new-agent --network testnet
stellar keys generate established-agent --network testnet
stellar keys fund established-agent --network testnet
stellar keys generate trusted-agent --network testnet
stellar keys fund trusted-agent --network testnetAdd their secrets to backend/.env:
DEMO_AGENT_1_SECRET=<new-agent secret>
DEMO_AGENT_2_SECRET=<established-agent secret>
DEMO_AGENT_3_SECRET=<trusted-agent secret>If omitted, the seed script generates ephemeral random keypairs.
cd backend && npm run seed-agentsThis registers three demo agents (NewAgent ~110, EstablishedAgent ~600, TrustedAgent ~1000) and builds their payment histories on-chain.
The register_service function enforces the following field limits on-chain:
| Field | Min | Max | Notes |
|---|---|---|---|
name |
3 | 64 | |
description |
10 | 256 | |
endpoint |
— | 256 | |
category |
1 | 32 |
Submissions exceeding these limits are rejected with a typed assertion error.
The same limits are enforced client-side in the RegisterForm and server-side
by the POST /api/registry/prepare-register route.
- Network: Stellar Testnet
- RPC URL: https://soroban-testnet.stellar.org
- Network Passphrase:
Test SDF Network ; September 2015 - Explorer: https://stellar.expert/explorer/testnet