You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not yet ready to start making changes to the Go codebase yet, but alternatives external to our infrastructure include automation platforms like Gelato Web3 Functions (50% gas premium on L2s), Chainlink Automation (50% gas premium on L2s), and OpenZeppelin Actions (no cost, self-funded, requires JS/TS).
The primary counterpoint to this is that these platforms might not be quick to support the Omni EVM, so if we want to send messages into Omni, we will likely need to rely on the internal solution described in the issue. I just wanted to provide additional commentary from the perspective of what I can do personally to tackle this issue. Doing it internally costs less, and gives us more flexibility. It just requires Go knowledge to do.
This PR adds a new role RoleXCaller that will be used to send xmsgs on
differen't networks and source chain/dest chain combinations. We will
create a github action that will periodically send xmsgs and it will use
this account.
issue: #2275
Problem to Solve
Mainnet xchain isn't busy yet. We'd like to get some load on the system.
Proposed Solution
RoleTester
for mainnet, but not fireblocks based, rather GCP.scripts/sendxmsg
-count
,-network
,-role
flagsrole
key from GCPethbackend
for the source chain, add the private key to it.GetPortal(chainID uint64, backend ethbackend.Backend) bindings.OmniPortal
on the xconnectorcount
times:go run github/omni-network/omin/scripts/sendxmsg -count=X -network=mainnet -role="tester"
The text was updated successfully, but these errors were encountered: