SorobanClientService.getContract(contractId?: string) resolves the contract to call as contractId || this.stellar.escrowContractId — i.e. it will only ever target something other than the escrow contract if a caller explicitly passes { contractId: ... } in invoke()'s third argument.
Every single call site in src/escrow/escrow.service.ts — fund(), release(), splitRelease(), releasePartial(), refund() — calls this.soroban.invoke(method, args) with no third argument at all. This is true regardless of whether the escrow being operated on backs a bountyId, a milestoneId, or a maintenancePoolId.
The practical effect: AppConfig.stellar.maintenancePoolContractId (and MAINTENANCE_POOL_CONTRACT_ID in .env.example, documented there as "Optional separate contract for the maintenance pool; falls back to ESCROW_CONTRACT_ID") is never read by any code path that actually submits a transaction. Once ESCROW_CONTRACT_ID is configured for production use, every fund/release/refund call — bounty, milestone, or maintenance pool — is submitted to the single escrow contract, never to a distinct maintenance-pool (or, per the sibling mergefi-contracts repo's actual three-contract design, milestones) deployment.
EscrowService already knows which parent type it's serving (escrow.bountyId/escrow.milestoneId/escrow.maintenancePoolId are read in exactly this order at several call sites, e.g. fund()'s referenceId selection). Threading that same discriminant through to soroban.invoke(method, args, { contractId: ... }), selecting this.stellar.escrowContractId / this.stellar.maintenancePoolContractId accordingly, would make the already-configured maintenancePoolContractId actually take effect.
SorobanClientService.getContract(contractId?: string)resolves the contract to call ascontractId || this.stellar.escrowContractId— i.e. it will only ever target something other than the escrow contract if a caller explicitly passes{ contractId: ... }ininvoke()'s third argument.Every single call site in
src/escrow/escrow.service.ts—fund(),release(),splitRelease(),releasePartial(),refund()— callsthis.soroban.invoke(method, args)with no third argument at all. This is true regardless of whether the escrow being operated on backs abountyId, amilestoneId, or amaintenancePoolId.The practical effect:
AppConfig.stellar.maintenancePoolContractId(andMAINTENANCE_POOL_CONTRACT_IDin.env.example, documented there as "Optional separate contract for the maintenance pool; falls back to ESCROW_CONTRACT_ID") is never read by any code path that actually submits a transaction. OnceESCROW_CONTRACT_IDis configured for production use, every fund/release/refund call — bounty, milestone, or maintenance pool — is submitted to the single escrow contract, never to a distinct maintenance-pool (or, per the siblingmergefi-contractsrepo's actual three-contract design, milestones) deployment.EscrowServicealready knows which parent type it's serving (escrow.bountyId/escrow.milestoneId/escrow.maintenancePoolIdare read in exactly this order at several call sites, e.g.fund()'sreferenceIdselection). Threading that same discriminant through tosoroban.invoke(method, args, { contractId: ... }), selectingthis.stellar.escrowContractId/this.stellar.maintenancePoolContractIdaccordingly, would make the already-configuredmaintenancePoolContractIdactually take effect.