Conversation
Add depositFromEvent()/fillFromEvent() to convert typed FundsDeposited/FilledRelay event data directly to SDK Deposit/Fill types, replacing the unwrapEventData<T> claim-and-convert chains in findDeposit, findFillEvent and getDeposit/FillEventsFromSignature. This fixes three bugs the generic claims hid: the signature helpers converted addresses with chain IDs read from fields that do not exist on the event (originChainId on FundsDeposited, destinationChainId on FilledRelay), yielding RawAddress instead of the native address types, and the fill helper never converted relayer/updatedRecipient at all. Retire the remaining legacy decode remnants (parseEventData, unwrap's number[] and fillType-variant branches, isUint8Array/isByteArray); the differential validation script now freezes the legacy pipeline verbatim as its reference and is committed at last. Verified equivalent against 111 mainnet transactions plus a synthetic RequestedSlowFill.
Decodes recent mainnet SvmSpoke events through both the legacy pipeline (Anchor BorshEventCoder + parseEventData + the retired unwrap semantics, frozen here) and the current codama path, comparing consumer-visible output. Previously referenced by the decode PR but never committed.
| destinationChainId, | ||
| depositId: BigNumber.from(data.depositId), | ||
| depositor: toAddressType(data.depositor, originChainId), | ||
| recipient: toAddressType(data.recipient, destinationChainId), |
There was a problem hiding this comment.
Codama decodes every event Pubkey as Solana base58, but toAddressType(..., CHAIN_IDs.TRON) treats non-hex input as native TRON Base58Check. For a valid SVM→TRON deposit, data.recipient is the Solana-base58 encoding of the zero-padded TVM bytes (for example 1111111111113KCdB5mQUd99fY7YzEp79PEQi1ST), so this line throws Invalid address provided; I reproduced that directly through depositFromEvent. The same issue affects outputToken/exclusiveRelayer, plus fill fields when the origin or repayment chain is TRON. The legacy path worked because unwrapEventData hexlified the event Pubkey before chain-specific typing. Please normalize these event addresses to raw bytes/hex first and add TVM deposit/fill coverage.
Sent from Reinis Martinsons's Codex CLI Agent using gpt-5.6-sol 🤖
2 participants
Add depositFromEvent()/fillFromEvent() to convert typed
FundsDeposited/FilledRelay event data directly to SDK Deposit/Fill
types, replacing the unwrapEventData claim-and-convert chains in
findDeposit, findFillEvent and getDeposit/FillEventsFromSignature. This
fixes three bugs the generic claims hid: the signature helpers converted
addresses with chain IDs read from fields that do not exist on the event
(originChainId on FundsDeposited, destinationChainId on FilledRelay),
yielding RawAddress instead of the native address types, and the fill
helper never converted relayer/updatedRecipient at all. Retire the
legacy unwrap remnants (the number[] byte-array heuristic, the fillType
variant-object branch, isUint8Array); parseEventData stays, since the
generic Anchor path (non-bundled IDLs) still decodes through it. The
differential validation script (committed in the decode PR) keeps the
retired unwrap semantics frozen verbatim as its legacy reference.