On-chain probe (2026-04-22) confirms two parallel DODOPMM deployments on
Chain 138. Stack A is the live, traded one:
- DODOPMMIntegration (Stack A): 0x86ADA6Ef91A3B450F89f2b751e93B1b7A3218895
- DODOPMMProvider (Stack A): 0x3f729632E9553EBacCdE2e9b4c8F2B285b014F2e
- 8 registered pools, all isKnownPool=true, with traded liquidity
(cUSDT/cUSDC, cUSDT/USDT, cUSDC/USDC, cBTC/cUSDT, cBTC/cUSDC,
WETH/USDC, WETH/USDT, cBTC/cXAUC).
Stack B (DODOPMMIntegration=0x5BDc62f1..., DODOPMMProvider=0x5CAe6Ce1...,
pools 0xff8d3b8f.../0x6fc60D.../0x9f74Be...) is a parallel deployment
with seeded but un-traded pools (10M/10M flat or 0/0). Earlier docs that
cited Stack B as canonical are superseded.
Updates:
- .cursor/rules/chain138-tokens-and-pmm.mdc: replace integration + pool
addresses with Stack A; add provider, cBTC, and full live-pool table.
- docs/11-references/ADDRESS_MATRIX_AND_STATUS.md: re-version to
2026-04-22; show both stacks with status flags; add 5 cBTC/WETH pools;
flip EnhancedSwapRouter row from Not deployed to Pending Phase 3.
- docs/11-references/PMM_DEX_ROUTING_STATUS.md: rewrite executive
summary; refer to Phase 3 LAN deploy command.
No code change. Companion to atomic-swap-dapp PR #4 (frontend
routing-honesty) and the upcoming Phase 3 EnhancedSwapRouter deploy.
Co-Authored-By: Nakamoto, S <defi@defi-oracle.io>
Closes the gap where phoenix-deploy-api/server.js on master is the real
implementation, but the running service on CT 5700 is the older stub
that returns 'Deploy request queued (stub)' for every target.
The new workflow .gitea/workflows/bootstrap-phoenix-deploy-api.yml is
manual-only (workflow_dispatch). When triggered it:
1. Validates the repo layout (phoenix-deploy-api/server.js MUST NOT
contain the stub string).
2. Tars phoenix-deploy-api/ + config/public-sector-program-manifest.json
into a deploy bundle.
3. scp's the bundle to the PVE node that hosts CT 5700 using a
dedicated deploy SSH key (PHOENIX_PVE_SSH_KEY repo secret).
4. pct push / pct exec the bundle into the CT and runs the existing
phoenix-deploy-api/scripts/install-systemd.sh which already drops
/opt/phoenix-deploy-api/, writes the systemd unit, and restarts
the service.
5. Health-checks GET http://<dev-vm>:4001/health (with retry).
6. Posts a non-stub probe: POST /api/deploy with target __bootstrap_probe__
+ the deploy bearer token. Fails the workflow if the response body
still contains 'Deploy request queued (stub)' or any auth-rejection
signal. That gives an unambiguous post-bootstrap health signal in
CI logs without depending on a successful real deploy.
Required new secrets (documented in docs/04-configuration/DEVIN_GITEA_PROXMOX_CICD.md
section 3a):
PHOENIX_PVE_HOST, PHOENIX_PVE_USER (default root), PHOENIX_PVE_SSH_KEY,
PHOENIX_PVE_KNOWN_HOSTS (optional), PHOENIX_DEV_VM_VMID (default 5700),
PHOENIX_DEPLOY_DEV_VM_IP (default 192.168.11.59).
Triggered manually only — bootstrap is sensitive enough that we do NOT
fire on every master push. Once the running service on CT 5700 is
post-stub, the existing deploy job in deploy-to-phoenix.yml will
actually execute scripts/deployment/deploy-atomic-swap-dapp-5801.sh on
each push instead of returning a 202 stub.
Co-Authored-By: Nakamoto, S <defi@defi-oracle.io>
