SAC contract ID derivation mismatch for XSTROOP asset — wrong contract called on transfer *known credit_alphanum12 conversion issue?* #138
Description
Your issue will be reviewed by a maintainer and labeled for further action.
To complete your request, follow the bot-actions to report this on the support E-mail box and follow the outlined steps. Alternatively, you can report this issue on the official web page to an agent for assistance.
@lumenbro
Issue Description
Maybe this is a known credit_alphanum12 issue, but just wanted to confirm, this is the analysis of the issue:
When attempting to send XSTROOP:GARPXWTVB4QAGDZDCKV7ERN5GJTTMBSLOGPQPHYRVLYOW24CFB2SWCR5 to a contract address via xBull, the transaction simulation fails with:
HostError: Error(Storage, MissingValue) "trying to get non-existing value for contract instance"
The error log shows xBull is calling contract: CB4UZBIHB7PSLEVDIYESRJSBZHNC65QRXEUXBOZJLJOQBHH5V5TQLTY7
However, the correct deterministic SAC contract ID for this asset on mainnet is: CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP
On-Chain Protocol-Level Proof
Horizon API independently confirms the correct contract ID for this asset:
GET https://horizon.stellar.org/assets?asset_code=XSTROOP&asset_issuer=GARPXWTVB4QAGDZDCKV7ERN5GJTTMBSLOGPQPHYRVLYOW24 CFB2SWCR5
Response (relevant fields): { "asset_type": "credit_alphanum12", "asset_code": "XSTROOP", "asset_issuer": "GARPXWTVB4QAGDZDCKV7ERN5GJTTMBSLOGPQPHYRVLYOW24CFB2SWCR5", "contract_id": "CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP" }
Soroban RPC confirms the contract is a native SAC:
The contract at CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP has executable type contractExecutableStellarAsset, confirming it is a protocol-native Stellar Asset Contract — not a WASM deployment. It was created in ledger 61083118.
The contract xBull is calling does not exist:
stellar contract invoke --id CB4UZBIHB7PSLEVDIYESRJSBZHNC65QRXEUXBOZJLJOQBHH5V5TQLTY7 --network mainnet -- name ❌ error: Contract not found
SDK Verification
Both the Rust SDK (Stellar CLI) and JS SDK @stellar/stellar-sdk v14.4 agree with Horizon:
$ stellar contract id asset --asset XSTROOP:GARPXWTVB4QAGDZDCKV7ERN5GJTTMBSLOGPQPHYRVLYOW24CFB2SWCR5 --network mainnet CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP
const { Asset, Networks } = require('@stellar/stellar-sdk'); const asset = new Asset('XSTROOP', 'GARPXWTVB4QAGDZDCKV7ERN5GJTTMBSLOGPQPHYRVLYOW24CFB2SWCR5'); console.log(asset.contractId(Networks.PUBLIC)); // CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP
The deployed SAC is fully functional — name(), symbol(), and decimals() all return correct values.
Summary Source: Horizon API (contract_id field) SAC Contract ID: CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP Exists?: ✅ Yes ──────────────────────────────────────── Source: Soroban RPC (ledger entry) SAC Contract ID: CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP Exists?: ✅ Yes (contractExecutableStellarAsset) ──────────────────────────────────────── Source: Stellar CLI (Rust SDK) SAC Contract ID: CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP Exists?: ✅ Yes ──────────────────────────────────────── Source: JS SDK v14.4 SAC Contract ID: CB4ICKWTNMZGY2VZGB6HQZK3OC5VLKE2TZHOVSM3VGPPNE5CPKZ2JWPP Exists?: ✅ Yes ──────────────────────────────────────── Source: xBull SAC Contract ID: CB4UZBIHB7PSLEVDIYESRJSBZHNC65QRXEUXBOZJLJOQBHH5V5TQLTY7 Exists?: ❌ Does not exist Asset details:
- Code: XSTROOP (7 chars → credit_alphanum12)
- Issuer: GARPXWTVB4QAGDZDCKV7ERN5GJTTMBSLOGPQPHYRVLYOW24CFB2SWCR5
- Network: Public (mainnet)
- Deploy tx: 37270c281e514c6c863f82fccd7287a21001183c3947193ffa92d8ad5ecf82cf
Possible causes:
- An outdated version of @stellar/stellar-sdk bundled in xBull with a bug in Asset.contractId()
- The asset id being stored/parsed incorrectly in xBull's internal format (the split('') in sdkAssetFromAssetId)
- Incorrect networkPassphrase being passed to .contractId()
Environment:
- xBull Wallet (web app)
- Mainnet / Public network