Repository navigation
feat: multi-topic aptos sui, getLogs.typeAndVersions - #357
Merged
Merged
Conversation
andrevmatos
requested review from
a team,
PabloMansanet and
aelmanaa
as code owners
August 15, 2026 02:59
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
π andrevmatos, thanks for creating this pull request! To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team. Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks! |
Coverage Report |
- Aptos, Sui: receive support for multiple topics/event handlers in LogFilter.topics/getLogs - getLogs LogFilter receives a new option `typesAndVersions`, which can be an array of strings or regexes, calls `typeAndVersion` on the `log.address`, and match against given set, yielding logs only if matching
allows e.g. passing a set of topics/handlers to a set of addresses, and getting the relevant from each
The later gets exactly (no more `precision` uncertainty interval) the first block at or after a given timestamp, which is the precise `startBlock` to get anything that happened at or after that point in time
andrevmatos
force-pushed
the
feat/multi-topic-aptos-sui
branch
from
August 15, 2026 03:41
0477fce to
89fe92b
Compare
The dest-side loop was nested inside itself: an inner `for (const offRamp of destOffRamps)` shadowed the outer binding and re-iterated every candidate, calling getOnRampsForOffRamp again without the surrounding try/catch β so a single offRamp with no valid source chain config propagated out of discovery instead of being skipped. Flatten it back to one loop, and compare ramp addresses through a helper which ignores formatting differences (Sui/Aptos `::module` suffixes, hex padding, case) so a match isn't missed on non-EVM lanes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sui has no usable on-chain ramp registry. `ccip_router::RouterState` maps dest chain selectors to onramps but is left unconfigured on the public deployments (both testnet router packages have an empty `on_ramp_package_ids`), and it is not reachable from the ccip package anyway; `CCIPObjectRef.package_ids` only tracks the ccip package's own versions; and neither ramp's state references the other. The one thing both ramps agree on is the ccip package, which each reports from `get_ccip_package_id`. So use it as the anchor, for two things: Discovery. Ramps are recovered from transactions which can only belong to one deployment, newest first, each naming its ramp in `<pkg>::<module>::*` events and PTB calls: `ccip::onramp_state_helper` calls for the onramp (every `ccip_send` builds its `TokenTransferParams` there, so this matches sends and nothing else), and the deployment's `CCIPObjectRef` as an input object for the offramp. This needs no ownership, publish or upgrade history, so it works on RPCs which prune them β where the previous path could not enumerate anything. The deployer-ownership scan stays as a last resort, but is no longer primary: shared testnet deployer keys own hundreds of objects across unrelated deployments (150 OwnerCaps / 35 offramp packages on sui-testnet), so it costs a page-walk plus a probe per candidate, and finds nothing once ownership moves to MCMS. It is also cheaper now β a small `*Pointer`-type lookup per package instead of a full module ABI fetch, and it stops at the first ccip match. Router handle. The ccip state object is what both ramps report as `router`, and every router-taking API accepts it (or a ramp, or a bare package id, resolved through `resolveCcipStateAddress`). That makes the address printed for one direction usable as `--router` for the other, which is what the EVM lanes already do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both configs returned a handful of ad-hoc fields. Report what the contracts actually expose, mirroring the EVM shape and the field names the base OnRampConfig/OffRampConfig interfaces ask subclasses for. Fields come from the ramps' state objects directly β one `getObject` returns the whole struct, and a `VecMap` field brings all its entries with it β which also replaces the hand-rolled BCS offset parsing that read the offramp's source chain config through a devInspect view call. onRamp: chainSelector, feeQuoter/rmnRemote/nonceManager/tokenAdminRegistry, feeAggregator, allowlistAdmin, owner, allowlistEnabled, allowedSenders, destRouter, sequenceNumber, expectedNextSequenceNumber, feeQuoterConfig, rmnRemoteConfig. offRamp: the same ccip modules plus permissionlessExecutionThresholdSeconds, latestPriceSequenceNumber, owner, isEnabled, minSeqNr, isRmnVerificationDisabled, rmnRemoteConfig. Three things worth noting about the mapping: - rmn_remote/nonce_manager/token_admin_registry/fee_quoter are not separate contracts. The ramps' `create_static_config`/`create_dynamic_config` hardcode `@ccip` for all four, since each is a module of the ccip package, so they are reported as `<ccipPkg>::<module>` and cost no RPC. - the onramp's per-dest `router` is the *remote* chain's router, so it is reported as `destRouter`; `router` stays this deployment's handle. - there is no `getARM()` to unwrap into a separate `rmn` as on EVM β Sui has no RMNProxy, so `ccip::rmn_remote` is itself the RMN (chainlink-sui's own relayer tests note the Move function does not exist). What EVM reaches through that indirection is reported as `rmnRemoteConfig` instead: the versioned config and the curse state. An unconfigured source chain now raises CCIPSourceChainUnsupportedError instead of reporting zeroes, which the contract's own getter returns as a default. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
discoverOffRamp matches the onRamp it was asked about against the onRamp each candidate dest offRamp accepts, with `===`. That only holds if both sides are formatted the same way, and they were not: the parameter is normalized with decodeOnRampAddress (which appends `::onramp` for Sui/Aptos package addresses), while four of the five getOffRampConfig implementations decoded their stored onRamp with plain decodeAddress β Solana even shadowed the canonical helper with a local of the same name that called decodeAddress. For an EVM source the two are identical, which is why this stayed hidden. It bites when the source is Sui or Aptos and the dest is any non-EVM chain: the dest reports a bare package id, the parameter carries `::onramp`, and a lane which exists fails to resolve. Fix it where the addresses are produced, so every family returns the canonical form and the comparison stays a plain equality. Also report the (destOnRamp, offRamp, accepts) triplets considered in CCIPOffRampNotFoundError. When a lane is half-wired β the dest's offRamp pairs with a different source onRamp than the one asked about, as happens with an abandoned deployment β that pairing is the whole answer, and it was previously only visible with debug logging enabled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
aelmanaa
previously approved these changes
Aug 18, 2026
bukata-sa
approved these changes
Aug 18, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
LogFiltergets atypeAndVersionsoption, as an array of types or regexes to match logs contracts before emittingtopicsin a singlegetLogs, and interleave them; Aptos also can ignore if address doesn't have some topicUSDCTokenPoolProxy v2in EVM properly handlecctpV2Pooland output some more details inget-supported-tokensConfigSet)getLogs, break the list and re-joinget-supported-tokens/ tokenPool methodslane/offRamp discovery optimized and fixedgetFeeandsendMessage,sendsui->* now workingmanual-execgetExecutionReceipts(send --wait)