Wayfinder: New Position token holding source

[3esmit]

Question

How should the AMM app discover the selectable token holdings for Issue 30 from current main?

Answer should identify:

• which wallet/indexer/backend data source lists token holding accounts, token definition IDs, balances, and public/private status
• how selected wallet account maps to token holdings
• what minimal token display data is available now, and what must be deferred
• how to exclude non-fungible/non-token/native accounts
• how equal-token and duplicate-pair prevention should be represented before PDA derivation

[3esmit]

Resolved grilling input: selectable assets come from public fungible token holdings owned by the active account only. Do not aggregate across wallet accounts. If current wallet/indexer surfaces only raw account IDs without active-account ownership links, identify the missing source in this ticket.

[3esmit]

Research conclusion for holding discovery:

• Current main wallet list is not an asset list. AccountModel mirrors list_accounts() as wallet account id + public/private flag, then fetches native balance. It does not expose token definitions, token holding ownership, or owner->asset links.
• TokenHolding::Fungible stores definition_id + balance, but no owner. Ownership cannot be recovered from decoded holding data alone.
• Current ATA program gives the owner mapping: derive holding id from (ata_program_id, token_program_id, owner_account_id, token_definition_id), then fetch that public account and decode it.
• AMM NewDefinition / AddLiquidity still require concrete user holding accounts as signers. Submit cannot pass the owner account directly to AMM.
• Equal definitions must be blocked before pool PDA derivation; non-fungible holdings, token definition accounts, metadata accounts, private holdings, and native accounts must not be selectable.

Recommended first implementation:

1. Take the active account from shared/external wallet state.
2. Take token definitions from a per-network allowlist until an indexer/asset API exists.
3. For each configured definition, fetch and require a fungible token definition owned by the configured token program.
4. Derive the active account ATA with the configured ATA + token program ids.
5. Fetch that public account, require a fungible TokenHolding for that definition, and expose it as one selectable asset.
6. Backend returns holdingId, ownerAccountId, definitionId, token program id, display name/symbol, raw/display balance, and inferred decimals.

If the app must not carry token-definition config, #218 has a missing dependency: an external wallet/indexer API must provide the active account's public fungible holdings. Current main does not provide that source.

[3esmit]

Resolved in PR #210 by commit 7f88fd0. New Position now discovers public, directly signable fungible Token Holding accounts from the external wallet inventory; validates token definitions against the TokenProgram read from AMM Config; chooses the highest-balance holding with the lowest-ID tie break; and allows quote simulation without a holding. ATA support remains explicitly deferred.