Skip to content

review5 evm-mapping-bot integration - #199

Closed
tibfox wants to merge 3 commits into
vsc-eco:developfrom
tibfox:tibfox/review5-with-bot
Closed

review5 evm-mapping-bot integration#199
tibfox wants to merge 3 commits into
vsc-eco:developfrom
tibfox:tibfox/review5-with-bot

Conversation

@tibfox

@tibfox tibfox commented Jun 1, 2026

Copy link
Copy Markdown
Collaborator

Brings cmd/evm-mapping-bot/ onto current develop plus the per-receipt logIndex fix the contract reader requires.

Commits on top of develop@1ddfc681

642371d2 Evm mapping bot (cherry-pick from feature/evm-mapping-bot)
488cd080 EVM mapping bot testnet fixes (same source)
ee606170 W4-A CRIT #C14 — per-receipt logIndex resolver (+ F2 hardening)

Why the CRIT #C14 patch

eth_getLogs returns BLOCK-level logIndex; the deposit-proof contract reader expects PER-RECEIPT index (0..N-1 within the tx's own logs list). The bare bot writes block-level → wrong by accident when a tx has one matching log, broken when a tx emits two Transfer(token → vault) logs (both deposits collide on IsObserved, second is permanently uncreditable).

Adds lookupPerReceiptLogIndex(...) to fetch the receipt, match the SPECIFIC log by its block-level index, and return its per-receipt array position. Reuses upstream's existing rpc.getReceipt/TransferEventSig/hexToUint64 — no new helpers. F2 hardening: rejects non-standard RPCs that omit logIndex (would otherwise silently match block index 0).

Scope / coupling

  • 2 files touched, +77/-9 over the upstream bot.
  • go build ./cmd/evm-mapping-bot/ clean; gofmt clean.
  • No changes outside cmd/evm-mapping-bot/.
  • Companion contract-side fix (CRIT #C14 monitor side) lives in vsc-eco/account-mapping — must ship together.

@tibfox tibfox changed the title Tibfox/review5 with bot review5 evm-mapping-bot integration Jun 1, 2026
@miloridenour
miloridenour force-pushed the develop branch 2 times, most recently from 2928dea to 75c384f Compare June 2, 2026 00:25
lordbutterfly-hive and others added 3 commits June 8, 2026 11:21
…hardening)

The contract's deposit-proof reader expects PER-RECEIPT logIndex (position
within the tx's own Logs list, 0..N-1). The bare upstream bot wrote
eth_getLogs's BLOCK-LEVEL index into the deposit payload — that's correct
only by accident when a tx emits exactly one matching log.

A multi-Transfer-log tx (e.g. one deposit that also triggers a token-side
side-effect Transfer to the same vault) maps both logs to block-level
indices that the contract treats as nonsense per-receipt positions ->
deposit either crashes parsing or credits the wrong sender/amount, and on
the surviving path collides on IsObserved -> permanently uncreditable.

Fix lifted from review5 W4-A CRIT vsc-eco#14 + the wetransfer F2-bot hardening:

- New lookupPerReceiptLogIndex(rpc, txHash, tokenAddr, vaultPaddedTopic,
  blockLogIndex) function. Fetches the receipt, finds the SPECIFIC log
  whose block-level logIndex matches the eth_getLogs entry, returns its
  per-receipt array position. Sanity-checks address/topics so a stale
  receipt or RPC mistake surfaces as an error rather than mis-resolving.
- Caller (the scanBlock ERC-20 deposit emit loop) now calls
  lookupPerReceiptLogIndex and writes the resolved position. Skips the
  deposit with a slog.Warn on lookup failure (will be re-detected on the
  next scan of the same height).
- F2 hardening: a non-standard RPC returning a log with no logIndex is
  rejected explicitly (hexToUint64("")==0 would otherwise silently match
  only block index 0, mis-resolving every multi-log tx).

Reuses upstream's existing rpc.getReceipt + TransferEventSig + hexToUint64
(no new helpers introduced). Build clean: go build ./cmd/evm-mapping-bot/.
@miloridenour
miloridenour force-pushed the tibfox/review5-with-bot branch from ee60617 to 0f4f60e Compare June 8, 2026 18:25
@miloridenour

Copy link
Copy Markdown
Collaborator

incorporated into #154

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants