What you’ll do
By the end of this tutorial you will have:- chosen the correct operator localnet mode for your environment
- locked the fixed runtime contracts that must not drift during the run
- checked the shared dependencies that a first operator-backed baseline expects
- recorded the readiness signals that should be green before deeper operator work
Before you start
- Use this lesson when you are preparing an operator-backed localnet workflow rather than a trader or public API integration flow.
- Keep For Node Operators open if you still need the public boundary map.
- Treat Operator & Restricted APIs as boundary context, not as the node-setup procedure.
Step 1: Choose the right localnet mode
Pick one mode and keep its URLs consistent all the way through the run.| Mode | Use it when | Core URL shape |
|---|---|---|
localnet.loopback | you are running a local validation flow with chain and deployment-service on loopback | http://127.0.0.1:8545 and http://127.0.0.1:4040 |
localnet.compose | you are following CI-parity or shared Compose-network execution | http://ethereum:8545 and http://deployment-service:4040 |
host | you are only diagnosing a host environment, not running the canonical shared baseline | diagnostic only |
Step 2: Lock the fixed runtime contracts
Confirm the contracts below before you treat any later failure as an operator bug.| Contract | Expected value or rule |
|---|---|
APP_CONFIG | /opt/dexlabs |
| deployment metadata path | ${APP_CONFIG}/ethereum/addresses.json |
| deployment metadata writer | deployment-service is the single writer |
| operator REST API | http://127.0.0.1:8080 for the standard localnet baseline |
| KYC REST API | http://127.0.0.1:8090 for the standard localnet baseline |
| report baseline | REPORT_TYPE=SELF for the standard localnet validation path |
Step 3: Check the shared dependencies
Make sure the first-run dependencies are available before you continue.| Dependency | Why it matters |
|---|---|
| chain + deployment-service | provide the deploy/reset baseline and deployment metadata |
| Postgres | backs operator and KYC state |
| Redis | supports background coordination used by the operator stack |
| PCCS and AESM | required when you are validating an SGX-capable runtime |
| oracle source | must provide the market inputs expected by the baseline |
| KYC mock or release source | must be reachable before KYC-backed flows can validate cleanly |
Step 4: Keep the baseline clean
Use the standard baseline model throughout the first run:- Deploy establishes the clean baseline state.
- Reset returns the environment to that same deployment baseline.
- Release and registration side effects happen after reset, not inside the baseline snapshot.
- If the environment has drifted, reset it before you continue.
Step 5: Record your readiness snapshot
Before you continue to a private runbook or deeper debug task, make sure this snapshot is true:| Signal | Healthy first-run state |
|---|---|
| mode and URLs | ETH_RPC_URL and DEPLOYMENT_SERVICE_URL both match the same localnet mode |
| config root | APP_CONFIG=/opt/dexlabs |
| deployment metadata | addresses.json is present at /opt/dexlabs/ethereum/addresses.json and treated as deployment-service owned |
| node-facing APIs | operator and KYC endpoints answer on the expected localnet ports once started |
| oracle and KYC prerequisites | upstream data and mock/release dependencies respond before deeper workflow steps |
| baseline assumptions | the run still matches the standard localnet expectations rather than an ad-hoc environment |
Next steps
- Use How to Verify Operator Localnet Readiness when you need a targeted readiness check.
- Use Node Operations Reference when you need the fixed mode, contract, and readiness facts in lookup form.
- Use Support Channels when the next step requires a private runbook, restricted escalation path, or non-public operator process.