Closed brewmaster012 closed 1 year ago
@aldapp7 to send ZETA from zEVM to other chains, what is a good design to do this?
Create a contract that the fungible module monitors (via hooks, like the Withdrawal(
) event of ZRC20), and have the user send ZETA (zEVM) to that contract to withdraw?
I think the design should be:
Add cmd special command to send ZETA form ZetaChain to other EVM chains with params: chainTarget, receiver, etc. After command is called:
@btroo, bring you here because this affects UX
would it be possible to have a Connector
on ZetaChain that is functionally the same as on other chains? (so for a dev, sending ZETA from ETH -> ZetaChain feels the same as sending ZETA from ZetaChain -> ETH)
would it be possible to have a
Connector
on ZetaChain that is functionally the same as on other chains? (so for a dev, sending ZETA from ETH -> ZetaChain feels the same as sending ZETA from ZetaChain -> ETH)
that'll be very convenient, and a major feature. However my gut feeling is that this Connector on zEVM will connect the two disparate systems--message passing and the zeta omnichain smart contracts--and their interactions and how people can use/abuse them need to be investigated further.
But maybe an idea to move forward with regard to moving ZETA=>X is to indeed deploy a connector contract, but restrict the functionality to only move ZETA but not message.
Another alternative is to have a modified weth contract (wzeta) that has a burn/send function.
A simple contract can be used for sending ZETA from zetachain zEVM to other connected chains:
// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.7;
contract Warpspace {
event ZetaSent(address indexed to, uint256 toChainID, uint256 amount);
function sendZeta(address to, uint256 toChainID) payable public {
emit ZetaSent(to, toChainID, msg.value);
}
}
The event can be processed by the ethermint Hook (PostProcess) mechanism that we used for the Withdrawal() event of ZRC20 contract. Note that the balance of ZETA of this Warpspace contract needs to be burned (from the bank module) during the post processing.
@aldapp7 does this look good to you?
@brewmaster012 we don't have minting for Zeta on ETH https://github.com/zeta-chain/zeta-node/blob/develop/contracts/evm/zeta_eth.sol and I suppose after receiving ZetaSent we should burn and also generate OutboundTx to corresponding chain with target as contract with Zeta mint https://github.com/zeta-chain/zeta-node/blob/develop/contracts/evm/zeta_noneth.sol, for non-ETH chains it has it.
@aldapp7 to mint zeta on external chains, we can go through their respective connector, which can mint (non-eth) or transfer already locked (eth).
would it be possible to have a
Connector
on ZetaChain that is functionally the same as on other chains? (so for a dev, sending ZETA from ETH -> ZetaChain feels the same as sending ZETA from ZetaChain -> ETH)that'll be very convenient, and a major feature. However my gut feeling is that this Connector on zEVM will connect the two disparate systems--message passing and the zeta omnichain smart contracts--and their interactions and how people can use/abuse them need to be investigated further.
But maybe an idea to move forward with regard to moving ZETA=>X is to indeed deploy a connector contract, but restrict the functionality to only move ZETA but not message.
Another alternative is to have a modified weth contract (wzeta) that has a burn/send function.
i think having a connector that just sends ZETA and not messages might be better devX-wise! versus the burn/send WZETA contract, especially if we can assume that adding in messaging is feasible down the road (3-6months?)
ZETA from zEVM -> other chains with limited ConnectorZEVM contract in #404
To send ZETA from external chain to zetachain, one can use the Connector contract: example:
Connector.send( [7001, "0x6dA30bFA65E85a16b05bCE3846339ed2BC746316", 90000, [], "8000000000000000000", [] ])
7001
being the chain id of zEVM. The message must be empty as there is no connector contract on zEVM yet to execute arbitrary contract calls.The zetaclients should observe this, and the inbound tx voter logic should recognize that the ZETA token is to be sent to zEVM, and should mint ZETA.