Call for production routing edge cases: stellar-address-kit spec

[codeZe-us]

Hey all, I maintain stellar-address-kit, a deposit routing correctness library for Stellar with implementations in TypeScript, Go, and Dart that all pass the same conformance vectors.

The project treats spec/vectors.json as the source of truth; every routing scenario the library handles correctly is pinned as a test vector, and every language implementation has to pass every vector. As I extend the spec to cover C-address and Soroban Smart Account routing cases, I'd like to make sure the vector set covers edge cases that have actually hit exchanges, wallets, and deposit-processing services in production.

Contributions I'm especially looking for:

• M-address destinations with simultaneously-set memos (which should win, what should warn)
• Payments originating from Soroban contracts where sender attribution is ambiguous
• Non-canonical address encodings or memo formats you've seen cause misrouting (zero-padded IDs, casing, whitespace)
• SEP-29 memo-required scenarios where the destination has the flag set but no memo is present
• Anything else where your team has written custom code to handle a routing ambiguity the SDKs don't address

Contribution template:

{
  "description": "Short summary of the edge case and why it matters",
  "input": {
    "destination": "G... or M... address",
    "memoType": "none | id | text | hash | return",
    "memoValue": "memo value as string, or empty if memoType is none",
    "sourceAccount": "optional, only needed for contract-sender scenarios"
  },
  "expected": {
    "destinationBaseAccount": "G... address the payment should credit",
    "routingId": "string-encoded uint64 or null",
    "routingSource": "muxed | memo | none",
    "warnings": ["warning-code-1", "warning-code-2"]
  }
}

Example, contract sender with muxed destination:

{
  "description": "Muxed destination receiving payment from a Soroban contract. Routing succeeds via muxed ID, but sender being a contract means no classic account attribution is possible.",
  "input": {
    "destination": "MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAAAPEC2O",
    "memoType": "none",
    "memoValue": "",
    "sourceAccount": "CA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAA"
  },
  "expected": {
    "destinationBaseAccount": "GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGX2K45KHTF",
    "routingId": "1234",
    "routingSource": "muxed",
    "warnings": ["contract-sender"]
  }
}

What happens after you post:

1. I'll review the case against SEP-23 (muxed accounts) and SEP-29 (memo-required) and confirm the expected behavior.
2. Valid cases get merged into spec/vectors.json with attribution to the contributor.
3. The TypeScript, Go, and Dart implementations get patch releases once all pass the new vector.

Repo: https://github.com/Boxkit-Labs/stellar-address-kit
Spec file: https://github.com/Boxkit-Labs/stellar-address-kit/blob/main/spec/vectors.json

If you've been bitten by a routing edge case in production and wrote custom code to handle it, that's exactly the kind of vector I want to capture. Drop it below or open an issue on the repo.