[evm,sdk,tesseract,docs]: redeploy testnet EvmHost to align GET ABI with mainnet#1009
Merged
Conversation
66f58c3 to
2f03b23
Compare
royvardhan
approved these changes
Jun 30, 2026
2f03b23 to
e4a83c1
Compare
Wizdave97
approved these changes
Jun 30, 2026
e4a83c1 to
a7ea96c
Compare
…ith mainnet The deployed Gargantua V3 testnet host (0xEB94…311D) ran a pre-`payer` `DispatchGet` ABI (selector 0xd22e3343), while mainnet and `@hyperbridge/core` latest ship the `payer` variant (0x0175539c). GET dispatch from the published SDK therefore failed against testnet (see #1007). The host (+ HostManager) was redeployed to the current ABI, reusing the existing stateless infrastructure; this repoints everything at the new addresses. New testnet deployment (all 8 EVM chains, identical addresses): - TestnetHost: 0x9AA003594d59C62EE17A73A569Fd7B1DbdBd71E1 - HostManager: 0xa7273Cb04E99978CF5c0A935e92EC95F09e9D44a - IntentGatewayV2 (97, 80002): 0x6CF42FA9BecbC5b6a26884964956b113530f7cFA - SolverAccount (97, 80002): 0x07FeC66d967800998060194EaECDd7C66dA4a1B1 HyperFungibleToken test pair redeployed against the new host (their `_host` is a one-shot setter so the old tokens could not be repointed): - WrappedHFT (BSC, WBNB): 0x5ae3C15EFa6FC9D226c108bD3c706F2400Ab7311 - HFT (Polygon Amoy, hBNB): 0x1bd0AB7686710a66255d4EFe4826f43CF2A11a1F Changes: - evm: config.testnet.toml updated with new HOST/HOST_MANAGER/INTENT_GATEWAY_V2/ SOLVER_ACCOUNT. - tesseract: registry.rs host addresses; also fixes the stale Gnosis-Chiado entry (was pointing at an address with no code; now its real host 0x58A4…). Relayer crate bumped to 2.4.7. - sdk: chain.ts host + gateway/solver addresses; DispatchGet gains the `payer` field in the TS type and all ABIs (evmHost, IntentGateway[V2], hyperFungibleToken). hyperFungibleToken.test.ts points at the redeployed token pair. Package bumped to 2.3.0. - indexer: new host + per-chain start blocks. - docs: testnet contract addresses.
a7ea96c to
69e6973
Compare
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.
Why
The deployed Gargantua V3 testnet host (
0xEB94…311D) runs a pre-payerDispatchGetABI (selector0xd22e3343), whereas mainnet and@hyperbridge/core@latestship thepayervariant (0x0175539c). GET dispatch from the published SDK therefore reverts with "unrecognized function selector" against testnet — see #1007.The host isn't behind a proxy, so fixing the ABI requires a redeploy to a new address. This PR redeploys only the host (+ a fresh HostManager, since
setIsmpHostis one-shot), reuses the existing stateless infra (HandlerV2, ConsensusRouter, fee token, CallDispatcher), redeploys IntentGateway/SolverAccount on the gateway chains, and repoints every reference. BandwidthManager is intentionally not redeployed on testnet.New testnet deployment (all 8 EVM chains, deterministic identical addresses)
TestnetHost0x9AA003594d59C62EE17A73A569Fd7B1DbdBd71E1HostManager0xa7273Cb04E99978CF5c0A935e92EC95F09e9D44aIntentGatewayV2(97, 80002)0x6CF42FA9BecbC5b6a26884964956b113530f7cFASolverAccount(97, 80002)0x07FeC66d967800998060194EaECDd7C66dA4a1B1WrappedHFT(BSC, WBNB)0x5ae3C15EFa6FC9D226c108bD3c706F2400Ab7311HyperFungibleToken(Amoy, hBNB)0x1bd0AB7686710a66255d4EFe4826f43CF2A11a1FThe HFT test pair was redeployed against the new host (their
_hostis a one-shot setter, so the old tokens couldn't be repointed) and re-peered both directions.Old host
0xEB94…311Dis retired. Bootstrapped with the live consensus state read from the old Sepolia host. Verified on-chain: new host exposesdispatch GET (payer)0x0175539cand no longer has0xd22e3343.Contents
config.testnet.tomlupdated with the newHOST/HOST_MANAGER/INTENT_GATEWAY_V2/SOLVER_ACCOUNT(host-only redeploy reusing the existing stateless infra).registry.rshost addresses; also fixes the stale Gnosis-Chiado entry (it pointed at0xEB94…, which has no code on Chiado — corrected to its real host0x58A4…). Relayer crate bumped to2.4.7.chain.tshost + gateway/solver;DispatchGetgains thepayerfield in the TS type and all ABIs (evmHost,IntentGateway,IntentGatewayV2,hyperFungibleToken);hyperFungibleToken.test.tspoints at the redeployed token pair. Package bumped to2.3.0.config-testnet.json,config-local.json).Required follow-ups (operational, not in this PR)
host-executive::update_evm_hosts(all 8 → new host) +intents-coprocessor::add_deploymentfor EVM-97/EVM-80002 (new gateway, params host=new, dispatcher=0x2B33…, solverSelection=true, surplus=5000bps, fee=30bps).ismp_hostper chain in the operator config and restart withinitial_height= new deploy block per chain.@hyperbridge/sdk2.3.0 so testnet consumers pick up the new host +payer-GET.Notes