ift relay support by dhfang · Pull Request #68 · skip-mev/catalyst

dhfang · 2026-04-23T17:13:37Z

Summary

Adds end-to-end IFT transfer support to Catalyst. Senders can drive MsgIFTTransfer load from cosmos or EVM chains to cosmos or EVM destinations and configure Catalyst to forward transactions to an ibc relayer.

Changes

Extends txfactory to support creation of IFT cosmos or evm transactions. These perform a token a transfer using IBC and should be relayed. Recipient addresses are derived deterministically from the base mnemonic (see ift/accounts/{cosmos,evm}.go).
Extends catalyst to support optionally relaying transactions. The configs allow the operator to specify a relay host and what messages should be passed to the relayer.
For EVM gas estimation, use SuggestGasTipCap from the node rather than a hardcoded 2 gwei default — works on L2s without manual tuning.
Extends cosmos runner to choose a tx send interval based on time instead of just block based. It uses the send_interval config.
Extends stats collection to also track the number of relay failures.

In a future PR, I will extend prometheus metric collection in the runners to capture relaying success/failure and latency.

…ps and gas block limits

Remove the aggregate Err field from SentTx in both cosmos and ethereum chains. Rename SourceErr to BroadcastErr and RelayerErr to PostBroadcastErr to align with the txMode abstraction. Add Failed() and Error() methods that derive overall status from the specific error fields and TxResponse.

…elay config - add MsgIFTTransfer as a case in both ethereum and cosmos TxFactory BuildTxs/CreateMsg, with baseline support for high-throughput runs - replace implicit HandlePostBroadcast with explicit RelayConfig that specifies a relayer URL and which message types should be relayed - remove txMode interface and mode.go from both chains - move relayer config from ift.relayer to top-level relay in spec - use SuggestGasTipCap instead of hardcoded 2 gwei default for EVM gas fee estimation - fix EVM IFT timeout to use Unix seconds instead of nanoseconds

dhfang · 2026-04-23T17:14:45Z

 	}

 	maxGas := params.ConsensusParams.Block.MaxGas
+	if maxGas == -1 {


Our test chain did not have max gas configured causing catalyst to fail on the maxGas check below in lin 196

greptile-apps · 2026-04-23T17:18:10Z

Greptile Summary

This PR adds IFT (Inter-chain Fund Transfer) relay support to both the Cosmos and Ethereum load-test runners: new MsgIFTTransfer message types, recipient address generators, an EVM contract wrapper, and a gRPC client that submits confirmed tx hashes to an external relay service.

P1 – GRPCClient.SubmitTxHash retries synchronously for up to 45 s per call (15 × 3 s); it is invoked inside the per-transaction send goroutines in all three Ethereum runners and in the Cosmos runner, meaning a degraded relayer can stall the entire load-test batch for tens of seconds and corrupt throughput measurements.
P1 – generateEVMAddress uses passphrase "" for index 0 but strconv.Itoa(index) for all others, producing an address set with an off-by-one in the first entry compared with the Cosmos generator and with what callers passing offset=0 would expect.

Confidence Score: 3/5

Not safe to merge as-is: the synchronous relay retry loop can stall load-test execution for up to 45 seconds when the relayer is slow, and the EVM address generator silently produces a wrong first recipient.

Two P1 findings: a blocking retry loop in the hot send path that defeats the purpose of a load test under relay degradation, and an inconsistent EVM passphrase that silently generates the wrong first recipient address. Both need to be addressed before the relay path is trustworthy.

ift/relayer/client.go (blocking retry loop), ift/accounts/evm.go (passphrase inconsistency for index 0)

Important Files Changed

Filename	Overview
ift/relayer/client.go	New gRPC relay client with blocking 15-retry loop (up to 45 s) that can stall load-test send goroutines; also leaks timers and never closes the connection.
ift/accounts/evm.go	EVM recipient generator uses empty passphrase for index 0 but numeric string for all others, producing an inconsistent first address compared with the Cosmos generator.
chains/cosmos/ift/msg.go	Hand-rolled MsgIFTTransfer proto message with embedded gzipped FileDescriptorProto; hardcoded message index [4] is fragile but otherwise correct.
chains/ethereum/ift/contract.go	New EVM IFT transfer contract wrapper; cleanly packs ABI calldata and delegates signing to the wallet layer.
chains/types/ift.go	New IFTConfig type with full validation covering source/destination kind compatibility, required fields, and recipient bounds.
chains/types/spec.go	Adds RelayConfig and IFT/Relay fields to LoadTestSpec with ShouldRelay helper; IFT validation is wired into LoadTestSpec.Validate().
chains/ethereum/runner/runner.go	Adds IFT and relay setup; refactors buildLoad into buildTxsForWallet and tracks tx→MsgType in a sync.Map; gRPC connection is never closed.
chains/cosmos/runner/runner.go	Wires IFT config, relay client, and SendInterval logic into Cosmos runner; relay connection is never explicitly closed.
ift/accounts/generator.go	Generator factory and GenerateRecipients helper; defaults recipient count/offset to NumWallets.
chains/ethereum/wallet/wallet.go	Fixes gas price derivation to fetch tip first then compute feecap, removing the hardcoded 2 gwei default.

Sequence Diagram

sequenceDiagram
    participant Runner as Cosmos/ETH Runner
    participant TxFactory as TxFactory
    participant Chain as Chain Node
    participant RelayClient as GRPCClient (Relayer)

    Runner->>TxFactory: CreateMsg / BuildTxs (MsgIFTTransfer)
    TxFactory-->>Runner: signed tx

    Runner->>Chain: BroadcastTx / SendTransaction
    Chain-->>Runner: TxHash / error

    alt send succeeded
        Runner->>RelayClient: SubmitTxHash(txHash)
        loop up to 15 retries (3s apart)
            RelayClient->>Relayer: gRPC Relay(TxHash, ChainID)
            alt success
                Relayer-->>RelayClient: OK
            else failure
                Note over RelayClient: wait 3s then retry
            end
        end
        RelayClient-->>Runner: nil or error (RelayErr)
    end

    Runner->>Runner: record SentTx{SendTransactionErr, RelayErr}

Comments Outside Diff (1)

chains/cosmos/runner/runner.go, line 502-508 (link)

gRPC relayer connection is never closed

NewGRPCClient opens a *grpc.ClientConn and exposes a Close() method, but neither the Cosmos runner nor the Ethereum runner (chains/ethereum/runner/runner.go) ever calls it. After the load test completes the connection stays open indefinitely, leaking OS file descriptors. Consider wiring Close() into the runner's shutdown path or adding a defer relayerClient.Close() after the runner finishes.

_{Reviews (1): Last reviewed commit: "relayer failures are surfaced as a separ..." | Re-trigger Greptile}

greptile-apps · 2026-04-23T17:18:14Z

+	for attempt := range maxRelayRetries {
+		if attempt > 0 {
+			select {
+			case <-ctx.Done():
+				return ctx.Err()
+			case <-time.After(relayRetryDelay):
+			}
+		}
+
+		callCtx, cancel := context.WithTimeout(ctx, c.timeout)
+		_, err := c.client.Relay(callCtx, &relayerapi.RelayRequest{
+			TxHash:  txHash,
+			ChainId: c.chainID,
+		})
+		cancel()
+
+		if err == nil {
+			return nil
+		}
+		lastErr = err
+	}
+
+	return fmt.Errorf("submit tx hash to relayer after %d attempts: %w", maxRelayRetries, lastErr)


Synchronous retry loop blocks load-test send goroutines

SubmitTxHash is called synchronously inside the transaction-sending goroutines in all three Ethereum runners (block.go, interval.go, persistent.go) and in the Cosmos runner's broadcastAndHandleResponse. Each call can block for up to 15 × 3 s = 45 s when the relayer is slow or down. Because each sending goroutine holds a wg.Done that the outer wg.Wait() waits on, a relayer outage can stall the entire load-test batch for tens of seconds per round, completely skewing throughput measurements.

Consider running the relay submission in a fire-and-forget background goroutine (storing the result separately) or using a channel-based worker pool so that transaction sending is never gated on relay delivery.

This is true, but not something I would consider important to address unless it prevents me from generating sufficient load to stress the relayer. For single chain testing, the relayer does not even get called, so there is no impact there.

dhfang · 2026-04-23T17:22:29Z

 				r.logger.Debug("processing block", zap.Int64("height", block.Height),
 					zap.Time("timestamp", block.Timestamp), zap.Int64("gas_limit", block.GasLimit))

+				if r.spec.SendInterval > 0 && time.Since(lastSendTime) < r.spec.SendInterval {


Time based tx submission interval

dhfang · 2026-04-23T17:23:09Z

-		Err:         nil,
+	}
+
+	if err := r.relayTxHash(ctx, msgType, res.TxHash); err != nil {


This only executes if the operator has relaying configured.

dhfang · 2026-04-23T17:26:21Z

 	wg := sync.WaitGroup{}
 	blockStats := make([]loadtesttypes.BlockStat, endBlock-startBlock+1)
 	receipts := make(map[uint64]gethtypes.Receipts)
+	msgTypeByHash := make(map[common.Hash]loadtesttypes.MsgType, len(sentTxs))


Small refactor to store the msg type by tx hash in a map and look it up when building test stats later instead of inferring based on properties of the tx

dhfang · 2026-04-23T17:48:20Z

-			// gasFeeCap = baseFee * 2 + gasTipCap (reasonable default)
-			baseFee := header.BaseFee
-			if gasTipCap == nil {
-				gasTipCap = big.NewInt(2000000000) // 2 gwei default tip


These hard coded values were not appropriate for the networks I was testing against.

I have no idea if changing these does anything negative to our existing eth tests 🤷

Eric-Warehime · 2026-04-23T21:01:51Z

Should the generated protobuf and whatever client code we need for the relayer eventually be in some separate repo that integrators can import instead of having to generate/define client impls everywhere we're using the relayer?

The client is already importable actually. But I tried just now and the resulting dependency version bumps created some compatibility issues with the CI runner. I'm just going to merge as is for now - if you feel strongly that this should be addressed I'm happy to in another PR.

Eric-Warehime · 2026-04-23T21:42:25Z

-			// gasFeeCap = baseFee * 2 + gasTipCap (reasonable default)
-			baseFee := header.BaseFee
-			if gasTipCap == nil {
-				gasTipCap = big.NewInt(2000000000) // 2 gwei default tip


I have no idea if changing these does anything negative to our existing eth tests 🤷

johnnylarner and others added 13 commits March 13, 2026 11:01

feat(ift): extend catalyst to support IFT messages

62f2a27

feat(ift): add evm -> cosmos and evm -> evm to ift

bf98281

refactor: implement review comments

543ac95

add relayer submission retry logic and some bug fixes around timestam…

e8e6322

…ps and gas block limits

refactor: rename SentTx error fields and clean up evm relay flow

e3d3e83

increase relay timeout

fd35a75

remove unused Failed/Error methods on ethereum SentTx

11bf984

merge main into plat-374/extended-ift-transfer-integration-test

a389c92

fix lint issues

0335731

fix struct tag formatting in ChainConfig

8e4be5b

relayer failures are surfaced as a separate metric in stats

426d986

dhfang requested a review from a team as a code owner April 23, 2026 17:13

dhfang commented Apr 23, 2026

View reviewed changes

greptile-apps Bot reviewed Apr 23, 2026

View reviewed changes

dhfang commented Apr 23, 2026

View reviewed changes

address greptile feedback and fix golines lint

5263ff3

Eric-Warehime approved these changes Apr 23, 2026

View reviewed changes

generate IFT contract ABI via forge/abigen

f510461

dhfang force-pushed the df/ift-relay-support branch from fc8de08 to f510461 Compare April 24, 2026 20:45

dhfang merged commit e6c968f into main Apr 24, 2026
3 checks passed

dhfang deleted the df/ift-relay-support branch April 24, 2026 21:28

Conversation

dhfang commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 3/5

Important Files Changed

Sequence Diagram

Comments Outside Diff (1)

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dhfang Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dhfang Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dhfang commented Apr 23, 2026 •

edited

Loading

greptile-apps Bot commented Apr 23, 2026 •

edited

Loading

dhfang Apr 23, 2026 •

edited

Loading

dhfang Apr 23, 2026 •

edited

Loading