Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor: Gateway functions to get Gateway address dynamically #201

Open
fadeev opened this issue Dec 4, 2024 · 4 comments
Open

Refactor: Gateway functions to get Gateway address dynamically #201

fadeev opened this issue Dec 4, 2024 · 4 comments
Assignees

Comments

@fadeev
Copy link
Member

fadeev commented Dec 4, 2024

Update both functions in packages/client/src and tasks in packages/tasks/src for:

  • evm call
  • evm deposit
  • evm deposit and call
  • zetachain call
  • zetachain withdraw
  • zetachain withdraw and call

Remove gatewayEVM/gatewayZEVM from the argument list. Instead, import the JSON from protocol contract's npm and find gateway address. I don't think we can use getAddress, because the functions in the client/src don't have access to chain labels specified in hardhat config, so the idea is for a function to get chain ID from the signer and find the gateway address based on chain ID.

Make txOptions optional.

Extract common functionality like parsing value array in a separate file to be reused across functions.

Make these functions convenient to use both from Hardhat tasks as well as the frontend, because the next task is to update the UniversalKit with these functions.

@lukema95 lukema95 self-assigned this Dec 5, 2024
@fadeev
Copy link
Member Author

fadeev commented Dec 6, 2024

It's also important to keep in mind that these functions are also used in localnet, which has a gateway address that changes, so it should be possible to pass the gateway address manually.

@fadeev
Copy link
Member Author

fadeev commented Dec 9, 2024

@lukema95 for context, I think the way it works right now is a bit ugly:

    const tx = await client.evmDepositAndCall({
      amount: args.amount,
      erc20: args.erc20,
      gatewayEvm: args.gatewayEvm,
      receiver: args.receiver,
      revertOptions: {
        callOnRevert: args.callOnRevert,
        onRevertGasLimit: args.onRevertGasLimit,
        revertAddress: args.revertAddress,
        revertMessage: args.revertMessage,
      },
      txOptions: {
        gasLimit: args.gasLimit,
        gasPrice: args.gasPrice,
      },
      types: ["address", "bytes", "bool"],
      values: [args.target, args.recipient, JSON.stringify(args.withdraw)],
    });

https://github.com/zeta-chain/example-contracts/blob/08d15c55ffba27dc64bd17aca2a7fe88f6b5e061/examples/swap/tasks/swapFromEVM.ts

I want to get rid of the gateway param, for testnet and mainnet this value is read from protocol contracts, but for localnet that's not the case.

I see two options:

  1. Being able to customize contract addresses from new ZetaChainClient({})
  2. Or keep gateway as param, but make it optional

When localnet starts, it creates a file localnet.json:

{
  "pid": 97125,
  "addresses": [
    {
      "chain": "zetachain",
      "type": "gatewayZEVM",
      "address": "0x5FC8d32690cc91D4c39d9d3abcBD16989F875707"
    },
    {
      "chain": "zetachain",
      "type": "systemContract",
      "address": "0xCf7Ed3AccA5a467e9e704C703E8D87F634fB0Fc9"
    },

Maybe we do something like this:

    const jsonData = JSON.parse(fs.readFileSync("localnet.json", "utf8")); // if hre.network.name === localhost
    const contracts = jsonData?.addresses;
    const client = new ZetaChainClient({ signer, contracts });

If contracts are provided to ZetaChainClient, use those, otherwise, the client should fetch the correct addresses from protocol contracts.

@lukema95
Copy link
Collaborator

lukema95 commented Dec 11, 2024

@lukema95 for context, I think the way it works right now is a bit ugly:

    const tx = await client.evmDepositAndCall({
      amount: args.amount,
      erc20: args.erc20,
      gatewayEvm: args.gatewayEvm,
      receiver: args.receiver,
      revertOptions: {
        callOnRevert: args.callOnRevert,
        onRevertGasLimit: args.onRevertGasLimit,
        revertAddress: args.revertAddress,
        revertMessage: args.revertMessage,
      },
      txOptions: {
        gasLimit: args.gasLimit,
        gasPrice: args.gasPrice,
      },
      types: ["address", "bytes", "bool"],
      values: [args.target, args.recipient, JSON.stringify(args.withdraw)],
    });

https://github.com/zeta-chain/example-contracts/blob/08d15c55ffba27dc64bd17aca2a7fe88f6b5e061/examples/swap/tasks/swapFromEVM.ts

I want to get rid of the gateway param, for testnet and mainnet this value is read from protocol contracts, but for localnet that's not the case.

I see two options:

  1. Being able to customize contract addresses from new ZetaChainClient({})
  2. Or keep gateway as param, but make it optional

When localnet starts, it creates a file localnet.json:

{
  "pid": 97125,
  "addresses": [
    {
      "chain": "zetachain",
      "type": "gatewayZEVM",
      "address": "0x5FC8d32690cc91D4c39d9d3abcBD16989F875707"
    },
    {
      "chain": "zetachain",
      "type": "systemContract",
      "address": "0xCf7Ed3AccA5a467e9e704C703E8D87F634fB0Fc9"
    },

Maybe we do something like this:

    const jsonData = JSON.parse(fs.readFileSync("localnet.json", "utf8")); // if hre.network.name === localhost
    const contracts = jsonData?.addresses;
    const client = new ZetaChainClient({ signer, contracts });

If contracts are provided to ZetaChainClient, use those, otherwise, the client should fetch the correct addresses from protocol contracts.

For functions, we can make the gatewayEvm parameter optional. When the gatewayEvm parameter is missing, we can obtain the corresponding contract address through the network and chain fields of ZetachainClient. What do you think?

@fadeev
Copy link
Member Author

fadeev commented Dec 12, 2024

@lukema95 Eventually, I want to have contracts in the zetachain client constructor, but for now yes, let's start with what you suggested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants