[Daveeee-tech]

closes #222

Summary

Fixes the hard-coded native XLM Stellar Asset Contract (SAC) addresses, which were each shifted one network along. Adds a test that checks them against the SDK's own derivation so this can't regress silently.

Problem

DEFAULT_XLM_SAC_MAINNET and DEFAULT_XLM_SAC_TESTNET in src/indexer.ts, and KNOWN_SAC_IDS in src/indexer/sac-detect.ts, did not match Asset.native().contractId(...):

Network	Previously held	Correct value (SDK derivation)
Mainnet	testnet SAC (CDLZFC3S…)	CAS3J7GYLGXMF6TDJBBYYSE3HQ6BBSMLNUQ34T6TZMYMW2EVH34XOWMA
Testnet	standalone SAC (CDMLFMKM…)	CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC

All three are valid StrKey contract IDs, so nothing flagged the error. Only the derivation was wrong.

Impact

• Mainnet: with SAC_CONTRACT_IDS unset, resolveSacContractIds() falls back to a contract that doesn't exist on mainnet. getEvents returns nothing forever, and the service looks healthy while the table stays empty.
• Testnet: the fallback points at the standalone SAC, with the same silent-empty failure. Working deployments only avoided this by setting SAC_CONTRACT_IDS explicitly.
• sac-detect.ts: real mainnet XLM transfers missed KNOWN_SAC_IDS and took the slow RPC path. Testnet XLM hit the set through the entry labelled "mainnet", so it was right for the wrong reason.

Changes

• src/indexer.ts: corrected DEFAULT_XLM_SAC_MAINNET and DEFAULT_XLM_SAC_TESTNET.
• src/indexer/sac-detect.ts: corrected the two values in KNOWN_SAC_IDS.
• .env.example:
  • corrected both native SAC fallbacks and the testnet / mainnet fallback comment
  • corrected the "Known mainnet SAC addresses" block and the SAC_CONTRACT_IDS_TESTNET / SAC_CONTRACT_IDS_MAINNET examples
  • corrected the mainnet USDC example to CCW67TSZV3SSS2HXMBQ5JFGCKJNXKZM7UQUWUZPUTHXSTZLEO7SJMI75, which is what new Asset('USDC', 'GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN').contractId(Networks.PUBLIC) produces (the issuer key was already correct)
• Tests: added a test asserting each constant against Asset.native().contractId(Networks.PUBLIC | Networks.TESTNET) instead of against a literal.

it("matches the SDK's own derivation", () => {
  expect(DEFAULT_XLM_SAC_MAINNET).toBe(Asset.native().contractId(Networks.PUBLIC));
  expect(DEFAULT_XLM_SAC_TESTNET).toBe(Asset.native().contractId(Networks.TESTNET));
});

Background

The wrong value originated in #166, which quoted CDLZFC3SY… as the mainnet SAC and carried into docs/DEPLOY_MAINNET.md via #211. The doc was corrected on merge, but the code was not.

Acceptance criteria

• DEFAULT_XLM_SAC_MAINNET / DEFAULT_XLM_SAC_TESTNET equal the SDK derivation for Networks.PUBLIC / Networks.TESTNET
• KNOWN_SAC_IDS holds the same two corrected values
• .env.example corrected (both native fallbacks, known-mainnet-SAC block, USDC example)
• Test asserts each constant against Asset.native().contractId(...)

Notes for reviewers

• Deployments that already set SAC_CONTRACT_IDS explicitly are unaffected.
• Deployments relying on the old defaults were indexing nothing, so after upgrading they will start picking up native XLM events from the network they actually target.

[drips-wave]

@Daveeee-tech Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Miracle656]

This is a live production bug and the fix is correct. Merging.

I checked the constants against the SDK rather than taking the diff at face value, and main has them wrong in both slots:

$ node -e "const {Asset,Networks}=require('@stellar/stellar-sdk');
  console.log('mainnet:', Asset.native().contractId(Networks.PUBLIC));
  console.log('testnet:', Asset.native().contractId(Networks.TESTNET))"

mainnet native SAC: CAS3J7GYLGXMF6TDJBBYYSE3HQ6BBSMLNUQ34T6TZMYMW2EVH34XOWMA
testnet native SAC: CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC

On main:

export const DEFAULT_XLM_SAC_MAINNET = "CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC";  // this is TESTNET's
export const DEFAULT_XLM_SAC_TESTNET = "CDMLFMKMMD7MWZP3FKUBZPVHTUEDLSX4BYGYKH4GCESXYHS3IHQ4EIG4";  // this is neither

So the mainnet indexer has been watching testnet's native XLM contract, and the testnet indexer a contract that is not native XLM on either network. Native XLM transfers on mainnet were not being indexed at all, and nothing failed loudly — the indexer ran, found no events for a contract nobody uses, and reported itself healthy. That is the worst failure shape available: silent, and indistinguishable from "no activity".

Your values are the derived ones, in the right slots.

And the test is what stops it coming back:

expect(DEFAULT_XLM_SAC_MAINNET).toBe(Asset.native().contractId(Networks.PUBLIC));
expect(DEFAULT_XLM_SAC_TESTNET).toBe(Asset.native().contractId(Networks.TESTNET));

Deriving the expectation from the SDK rather than pasting a second copy of the literal is the whole point. A test that asserts the constant equals itself would have passed happily against the wrong value for as long as this bug has existed. Removing the duplicated literal from sacDetect.test.ts and importing the real export closes the other copy.

On CI: Typecheck & build is red because this branch predates #250, which fixed main's OpenAPI coverage failure. Merged current main locally and re-ran: openapiCoverage, sacDetect, multiNetworkIndexer — 42 passed, tsc --noEmit clean. Integration tests fails identically on main (Postgres read path, since at least 10-16) and is not yours.

Someone should check whether anything downstream cached results from the wrong mainnet SAC.