- Expand defillama-chain138-touchpoints.json with server/dimension status and form links
- Add DEFILLAMA_CHAIN138_SUBMISSION_CHECKLIST.md (forms + PR notes + API blockers)
- Link checklist from CHAIN138_DEFILLAMA_ECOSYSTEM_MAP.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Updates ADDRESS_MATRIX_AND_STATUS.md and PMM_DEX_ROUTING_STATUS.md to reflect:
- EnhancedSwapRouter is deployed at 0xE6Cc7643ae2A4C720A28D8263BC4972905d7DE0f
on Chain 138 (2026-04-22, EVM Paris). Wired immutables: UniV3, Dodoex
(Stack-A 0x86ADA6Ef...), Balancer, 1inch; Curve disabled. dodoLiquidityProvider
set to Stack-A 0x3f72963....
- 11 DODO pools registered bidirectionally in dodoPoolAddresses[tokenA][tokenB]:
8 at deploy + 3 cBTC pools (cBTC/cUSDT, cBTC/cUSDC, cBTC/cXAUC) added
Phase 3j 2026-04-22 via setDodoPoolAddress(...).
- Multi-provider DEX routing capability summary updated from "No (router not
deployed)" to "Partial — DODO Stack-A path live; UniV3/Balancer/1inch slots
wired but inactive (no native pools / no pool ids)."
- Liquidity Engine and DEX routing status rows updated to reflect the partial
activation state. Balancer pool ids per-pair via setBalancerPoolId(...) and
native UniV3/1inch pools on Chain 138 remain follow-ups.
Stacks on top of PR #17 (Stack-A canonicalization).
Co-Authored-By: Nakamoto, S <defi@defi-oracle.io>
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>
