chore: exchange integration checklist#3427
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…st-depositwithdrawal
…st-depositwithdrawal
|
|
||
| | # | Scenario | Expected result | | ||
| | ---- | ------------------------------------------------------------------------ | -------------------------------------------- | | ||
| | TV-1 | Native **ETH** transfer to a platform deposit address, `status` `0x1` | Credit **ETH** equal to `value / 1e18` | |
There was a problem hiding this comment.
Should this mirror the other references? 10^decimals vs. value / 1e18
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
|
||
| ## Step 4: Confirm finality before crediting | ||
|
|
||
| Run an asynchronous loop that calls `eth_getBlockByNumber("finalized", false)` and reads `result.number` as the finalized height. For each entry in the `READY` list whose block height is at or below the finalized height, credit the mapped user the recorded amount and coin. |
There was a problem hiding this comment.
Re-verify that the block is still canonical before crediting — comparing block height alone isn't enough
This step credits any READY entry whose block height is at or below the finalized height, but a matching height doesn't prove the block we originally scanned is still canonical. Deposits are recorded while scanning latest (which this doc itself notes is "not yet final"); if that block is reorged out before finalization, comparing only the block number will still credit the stale record captured from the now-orphaned block.
Suggest storing the block hash in the READY entry, and — once the finalized height reaches the deposit's height — re-fetching the canonical block (or the transaction receipt) at that height and confirming the hash/tx still match before crediting.
| ArbOS upgrades can change the details this logic depends on, so confirm versions against the [ArbOS releases overview](/run-arbitrum-node/arbos-releases/01-overview.mdx) and the [Nitro releases page](https://github.com/OffchainLabs/nitro/releases) before each integration cycle. Three things can change across an upgrade and affect your indexer: | ||
|
|
||
| - **Tracer output** — the structure or completeness of `debug_traceBlockByHash` call frames. | ||
| - **Gas accounting** — how `gasUsed` is computed and how the parent-chain data fee is represented (for example, the dynamic pricing introduced around ArbOS 60). |
There was a problem hiding this comment.
| - **Gas accounting** — how `gasUsed` is computed and how the parent-chain data fee is represented (for example, the dynamic pricing introduced around ArbOS 60). | |
| - **Gas accounting** — how `gasUsed` is computed and how the parent-chain data fee is represented. |
The arbos 60's dynamic pricing won't affect poster fee
3 participants
Thank you for contributing to our docs!
Please fill out the form below to ensure your doc gets quickly approved and merged.
Description
Document type
Checklist
yarn startoryarn buildAdditional Notes