InitializeMultiReleaseEscrowPayload.trustline.address (and the matching REST field on POST /deployer/multi-release) is documented as "Public address establishing permission to accept and use a specific token," which reads as if it could be either the classic issuer or the SAC contract id. It's specifically the classic issuer (a G... address) — passing the SAC contract id (C...) fails with 400 "Issuer is invalid".
Confirmed directly against the real testnet API (dev.api.trustlesswork.com) while integrating Multi-Release into our own product:
trustline: { address: "CBIELTK6YBZJU5UP2WWQEUCYKLPU6AUNZ2BQ4WWFEIE3USCIHMXQDAMA", symbol: "USDC" } (testnet USDC's SAC id) → 400 { "message": "Issuer is invalid" }trustline: { address: "GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5", symbol: "USDC" } (testnet USDC's classic issuer) → deploys correctly, and the escrow record returned afterward echoes back the resolved SAC address in that same field — confirming the API converts issuer → SAC internally, so the caller is expected to supply the issuer, not the SAC.
We picked the SAC address on the first attempt specifically because most other Stellar/Soroban integrations we've built (x402, MPP) take a SAC contract id wherever an asset is configured, so it's an easy default to reach for here without a type-level or docstring signal to correct it.
Not filing a PR — wasn't sure whether the fix belongs in the JSDoc on InitializeSingleReleaseEscrowPayload/InitializeMultiReleaseEscrowPayload (src/..., whichever file backs the payloads doc page), a runtime validation with a clearer error message ("Issuer is invalid" doesn't point at which field, and doesn't hint that a C-address was the actual problem), or both. Happy to send a doc-comment PR if that's the preferred fix — just didn't want to guess at where without a maintainer confirming scope first.
Full end-to-end proof this is understood correctly (not just a one-off guess): ran the whole Multi-Release cycle — deploy, fund, approve, release — with two milestones paying two distinct receivers, all six transactions independently confirmed on Stellar Expert testnet. Happy to share the hashes if useful as a second data point.
InitializeMultiReleaseEscrowPayload.trustline.address(and the matching REST field onPOST /deployer/multi-release) is documented as "Public address establishing permission to accept and use a specific token," which reads as if it could be either the classic issuer or the SAC contract id. It's specifically the classic issuer (aG...address) — passing the SAC contract id (C...) fails with400 "Issuer is invalid".Confirmed directly against the real testnet API (
dev.api.trustlesswork.com) while integrating Multi-Release into our own product:trustline: { address: "CBIELTK6YBZJU5UP2WWQEUCYKLPU6AUNZ2BQ4WWFEIE3USCIHMXQDAMA", symbol: "USDC" }(testnet USDC's SAC id) →400 { "message": "Issuer is invalid" }trustline: { address: "GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5", symbol: "USDC" }(testnet USDC's classic issuer) → deploys correctly, and the escrow record returned afterward echoes back the resolved SAC address in that same field — confirming the API converts issuer → SAC internally, so the caller is expected to supply the issuer, not the SAC.We picked the SAC address on the first attempt specifically because most other Stellar/Soroban integrations we've built (x402, MPP) take a SAC contract id wherever an asset is configured, so it's an easy default to reach for here without a type-level or docstring signal to correct it.
Not filing a PR — wasn't sure whether the fix belongs in the JSDoc on
InitializeSingleReleaseEscrowPayload/InitializeMultiReleaseEscrowPayload(src/..., whichever file backs the payloads doc page), a runtime validation with a clearer error message ("Issuer is invalid" doesn't point at which field, and doesn't hint that a C-address was the actual problem), or both. Happy to send a doc-comment PR if that's the preferred fix — just didn't want to guess at where without a maintainer confirming scope first.Full end-to-end proof this is understood correctly (not just a one-off guess): ran the whole Multi-Release cycle — deploy, fund, approve, release — with two milestones paying two distinct receivers, all six transactions independently confirmed on Stellar Expert testnet. Happy to share the hashes if useful as a second data point.