Enhance SUi + aptos indexer

[anhthii]

  ┌────────┬────────────────────────┬────────────────────────────┬───────────────────────┬────────────────────────┐
  │ Chain  │    Native transfers    │      Standard tokens       │ Smart contract tokens │  Event-based parsing   │
  ├────────┼────────────────────────┼────────────────────────────┼───────────────────────┼────────────────────────┤
  │ EVM    │ Yes                    │ Yes (ERC20 logs)           │ Yes                   │ Yes                    │
  ├────────┼────────────────────────┼────────────────────────────┼───────────────────────┼────────────────────────┤
  │ TRON   │ Yes                    │ Yes (TRC20 logs)           │ Yes                   │ Yes                    │
  ├────────┼────────────────────────┼────────────────────────────┼───────────────────────┼────────────────────────┤
  │ TON    │ Yes                    │ Yes (Jetton opcodes)       │ Yes                   │ Yes                    │
  ├────────┼────────────────────────┼────────────────────────────┼───────────────────────┼────────────────────────┤
  │ Cosmos │ Yes                    │ Yes (CW20 wasm events)     │ Yes                   │ Yes                    │
  ├────────┼────────────────────────┼────────────────────────────┼───────────────────────┼────────────────────────┤
  │ Aptos  │ Yes                    │ Partial (4 functions only) │ No                    │ No (events not parsed) │
  ├────────┼────────────────────────┼────────────────────────────┼───────────────────────┼────────────────────────┤
  │ Sui    │ Partial (largest only) │ Partial (largest only)     │ No                    │ No (events ignored)    │
  └────────┴────────────────────────┴────────────────────────────┴───────────────────────┴────────────────────────┘

Aptos — Only handles direct transfer functions, misses event-based tokens

  aptos.go:239-284 only checks the payload function against four hardcoded functions:
  - 0x1::aptos_account::transfer (native APT)
  - 0x1::aptos_account::transfer_coins
  - 0x1::aptos_account::transfer_fungible_assets
  - 0x1::coin::transfer

  What's missing:
  1. No event parsing — The Transaction type in aptos/types.go doesn't even have an Events field. The Aptos API returns events with each transaction, but they're not deserialized.
  2. Custom token transfers via smart contracts — Any token sent through a DEX, multisig, or custom contract (not using these 4 functions) is invisible.
  3. 0x1::coin::deposit / 0x1::coin::withdraw events — The standard way to track all Coin movements on Aptos, regardless of the calling function.
  4. Fungible Asset (FA) events — 0x1::fungible_asset::Deposit / Withdraw for the new FA standard.
  5. Batch transfers — 0x1::aptos_account::batch_transfer, batch_transfer_coins are not handled.

  ---
  Sui — Only picks largest balance change, misses most token transfers

  sui.go:308-385 uses a heuristic: iterates BalanceChanges, skips the sender, and picks the single largest positive balance change.

  What's missing:
  1. All other transfers in a PTB — Sui PTBs (Programmable Transaction Blocks) can move multiple tokens to multiple recipients. Only the largest one is captured.
  2. Events are completely ignored — ExecutedTransaction has both Events (with event_type, json payload) and BalanceChanges available in the protobuf, but only BalanceChanges is used, and only
   partially.
  3. Multi-recipient transfers — If a PTB sends SUI to address A and USDC to address B, only one is captured.
  4. Same-coin splits — If a PTB sends 100 SUI to A and 50 SUI to B, only the 100 SUI to A is captured.

[anhthii]

Aptos — Missed Transfer Scenarios

Current implementation (aptos.go:239-284) only matches 4 payload functions. Anything not using those exact functions is invisible.

Note: DEX swaps are out of scope — we only need to track direct token transfers.

1. Batch transfers

Scenario: User calls 0x1::aptos_account::batch_transfer_coins to send tokens to multiple recipients in one tx.
Impact: Entire transaction is skipped — zero transfers captured.
Mitigation: Add these functions to isAptosTransferFunction, parse the argument arrays (vectors of addresses + amounts).

2. Multisig / governance execution

Scenario: A multisig wallet (e.g. 0x1::multisig_account::execute_transaction) executes a transfer. The outer payload is the multisig function, not a transfer function.
Impact: Transfer is missed.
Mitigation: Event-based parsing — deposit/withdraw events are still emitted inside the multisig execution.

3. Token airdrops via custom contracts

Scenario: A project contract distributes tokens to many addresses via a custom airdrop::distribute function.
Impact: All distributions missed.
Mitigation: Event-based parsing catches the underlying coin movements.

4. Fungible Asset (FA) standard transfers

Scenario: Aptos introduced the Fungible Asset standard (replacing Coin in newer tokens). Transfers happen via 0x1::primary_fungible_store::transfer, 0x1::dispatchable_fungible_asset::transfer, or custom wrapper functions.
Impact: Only 0x1::aptos_account::transfer_fungible_assets is handled. Direct calls to primary_fungible_store::transfer or any wrapper are missed.
Mitigation: Parse 0x1::fungible_asset::Deposit and 0x1::fungible_asset::Withdraw events.

5. Script payloads

Scenario: User submits a Move script (not an entry function) that transfers tokens. tx.Payload.Type is script_payload, not entry_function_payload.
Impact: Skipped at payload type check — entire tx dropped.
Mitigation: Event-based parsing doesn't depend on payload type.

6. Staking reward claims / unlocks

Scenario: User claims staking rewards via 0x1::delegation_pool::withdraw or similar. APT moves to their account.
Impact: Missed.
Mitigation: 0x1::coin::deposit event fires on the recipient.

---

Aptos fix strategy

Stop matching on payload functions. Parse events instead.

Add Events field to aptos.Transaction:

type Transaction struct {
    // ... existing fields ...
    Events []Event `json:"events"`
}

type Event struct {
    GUID           EventGUID `json:"guid"`
    SequenceNumber string    `json:"sequence_number"`
    Type           string    `json:"type"`
    Data           EventData `json:"data"`
}

Then match on event types:

Event type	What it catches
0x1::coin::DepositEvent	All legacy Coin deposits (covers scenarios 1-6)
0x1::coin::WithdrawEvent	All legacy Coin withdrawals
0x1::fungible_asset::Deposit	All FA deposits (scenario 4)
0x1::fungible_asset::Withdraw	All FA withdrawals

Pair deposits + withdrawals from the same tx to reconstruct sender→recipient flows. Use sequence_number as the transfer index.

[anhthii]

Sui — Missed Transfer Scenarios

Current implementation (sui.go:308-385) picks only the single largest positive BalanceChange to a non-sender. Everything else is dropped.

Note: DEX swaps are out of scope — we only need to track direct token transfers.

1. Multi-recipient PTB

Scenario: A PTB sends SUI to address A, USDC to address B, and USDT to address C.
Impact: Only the largest transfer is captured. The other two are dropped.
Mitigation: Iterate ALL BalanceChanges with positive amounts to non-sender addresses. Emit one types.Transaction per balance change.

2. Same-token multi-send

Scenario: A PTB splits 1000 SUI: sends 600 to A and 400 to B.
Impact: Only 600 SUI to A is captured. 400 SUI to B is dropped.
Mitigation: Same as above — each BalanceChange entry is a separate transfer.

3. Sponsored transactions

Scenario: A gas sponsor pays the fee. The sponsor appears as a balance change (negative SUI for gas). The actual transfer's sender may differ from the gas payer.
Impact: t.FromAddress is set from execTx.Transaction.GetSender(). If the sponsor is the sender but not the transferor, the sender filter may incorrectly skip the real recipient's balance change, or attribute the wrong sender.
Mitigation: Use BalanceChanges to determine actual sender (largest negative non-gas change) rather than relying solely on Transaction.Sender.

4. Self-transfers / consolidation

Scenario: User merges coin objects or transfers to themselves. Sender == recipient in BalanceChanges.
Impact: Filtered out by the sender == address check at line 353.
Mitigation: If self-transfers matter, remove or relax the sender filter.

5. Coin minting

Scenario: A protocol mints tokens to a user. There's a positive BalanceChange for the recipient but no corresponding negative change from a sender.
Impact: If the mint recipient happens to be the tx sender, it's filtered out.
Mitigation: Handle the case where sender has no negative balance change for that coin type (mint scenario).

6. Zero-amount or dust transfers

Scenario: A PTB sends small amounts to many addresses (common in airdrops or claim txs).
Impact: These have small BalanceChange amounts and will never be the "largest", so they're always dropped.
Mitigation: Emit all non-zero balance changes.

---

Sui fix strategy

Replace the "pick largest" heuristic with "emit all balance changes".

// For each BalanceChange with positive amount to a non-sender:
for i, bc := range execTx.BalanceChanges {
    // ... build types.Transaction with TransferIndex = i
    txs = append(txs, tx)
}

This single change fixes scenarios 1, 2, and 6. For scenarios 3-5, additionally:

• Remove or relax the sender == address filter (scenario 4)
• Use balance changes to infer real sender rather than Transaction.Sender (scenario 3)

Note: Sui multisig is just a different signature scheme, not a different contract call path. The PTB and BalanceChanges are identical to single-signer txs, so multisig is automatically covered by the fix above.