Open berktec opened 2 months ago
Hey @berktec! Thanks for submitting an issue.
As for the first problem, I see two things that could contribute to the problem:
layerzeroConfig.ts
, you are specifying both address
and contractName
- in general, it is sufficient to specify the contractName
and the address
will be grabbed from a deployment filehardhat-deploy
in your project? Are the deployment files for these contracts present? For this to work I would expect two deployment files, one in deployments/sepolia/GODOFT.json
and another one in deployments/arbitrumSepolia/GODOFT.json
Could you check those two please?
Also I notice you mentioned you are using the lz:oapp:peers:get
to wire the OApp - this command will just check whether the peers have been set, to actually run the wiring you'll need to run lz:oapp:wire
.
Hi @janjakubnanista
Thanks for looking into this: so with 1. I changed to this with no difference in the error
export const sepoliaContract: OmniPointHardhat = {
eid: EndpointId.SEPOLIA_V2_TESTNET,
// contractName: 'GODOFT',
address: '0xDee109faA9a53E6aBD3fE4ca2d1E423E4FC6D019',
}
export const arbSepContract: OmniPointHardhat = {
eid: EndpointId.ARBSEP_V2_TESTNET,
// contractName: 'GODOFT',
address: '0xa96b3749D01A50c4353f66455dBD92a52778C65A',
}
For 2. I did not use the hardhat deploy to deploy the contracts, I opted for a different tool to get them on chain.
and for your note at the bottom, that's true, and if I use either lz:oapp:peers:get
or lz:oapp:wire
I get the same error still
info: [OApp] Checking OApp configuration
error: [OApp] Failed to check OApp configuration: AssertionError [ERR_ASSERTION]: Could not find a deployment for address '0xa96b3749D01A50c4353f66455dBD92a52778C65A' on ARBSEP_V2_TESTNET (arbitrumSepolia)
An unexpected error occurred:
Error: An error occurred while getting the OApp configuration: AssertionError [ERR_ASSERTION]: Could not find a deployment for address '0xa96b3749D01A50c4353f66455dBD92a52778C65A' on ARBSEP_V2_TESTNET (arbitrumSepolia)
Hey @berktec!
Yeah that's the problem. We use hardhat-deploy
to get the contract ABIs, that's why you're seeing the error there.
There are several ways around this, depending on whether you want a quick solution or something more sturdy & possibly sustainable:
Create a fake deployment files for your contracts, the only fields they need to contain are the address
and abi
E.g. put this into deployments/sepolia/GODOFT.json
:
{
"address": "0xDee109faA9a53E6aBD3fE4ca2d1E423E4FC6D019",
"abi": [
/* You'll have to copy the ABI from the solc output /*
]
}
We use something we call an OAppFactory
, a sync/async function (up to the implementor, we'll accept both) that creates an OApp
SDK based on an OmniPoint
(a type that stands for { eid: EndpointId, address: string }
). The SDK needs an ethers.js
Contract
to communicate with the chain. We call a Contract
+ EndpointId
an OmniContract
and a function that creates an OmniContractFactory
.
If you're not using hardhat-deploy
to deploy your contracts, you'll need to provide your own OmniContractFactory
, whose code depends on what tools you used to deploy your contracts or what tools you have at hand to get a contract ABI based on either the deployed name or its address. You can see our implementation here for inspiration but your code will most likely be very different.
// hardhat.config.ts
// These are the additional imports you'll need (you'll probably want to add these to your devDependencies)
import { Contract } from '@ethersproject/contracts'
import type { OmniContractFactory } from '@layerzerolabs/devtools-evm';
import { createConnectedContractFactory } from '@layerzerolabs/devtools-evm-hardhat';
import type { IOApp, OAppOmniGraph, OAppFactory } from '@layerzerolabs/ua-devtools'
import { createOAppFactory } from '@layerzerolabs/ua-devtools-evm'
import { createEndpointV2Factory } from '@layerzerolabs/protocol-devtools-evm'
import {
SUBTASK_LZ_OAPP_CONFIG_LOAD,
SUBTASK_LZ_OAPP_WIRE_CONFIGURE,
type SubtaskConfigureTaskArgs,
type SubtaskLoadConfigTaskArgs,
} from '@layerzerolabs/ua-devtools-evm-hardhat'
// We want to hook into the SUBTASK_LZ_OAPP_WIRE_CONFIGURE subtask
// that compiles the list of transactions that need to be submitted
// by comparing the on-chain information and your config
//
// This is the subtask that needs to know how to talk to the chain (i.e. it needs the SDK)
subtask(
SUBTASK_LZ_OAPP_WIRE_CONFIGURE,
'Configure GOD OFT',
(args: SubtaskConfigureTaskArgs<OAppOmniGraph, IOApp>, hre, runSuper) =>
runSuper({
...args,
// We want to override the sdkFactory and provide our own
//
// See the default implementation here https://github.com/stargate-protocol/stargate-v2/blob/main/packages/ua-devtools-evm/src/oapp/factory.ts
sdkFactory: createOAppFactory(
// We will wrap our contract factory with createConnectedContractFactory to attach providers to it
createConnectedContractFactory(myOFTContractFactory),
// createOAppFactory also requires and EndpointV2 SDK factory
//
// In the default implementation, it is optional and based on the contract factory above
// However, since we made that one only work with our specific OFT (i.e. it would not know where to get the EndpointV2 ABI),
// we need to supply the default one
createEndpointV2Factory(createConnectedContractFactory())
),
})
)
const myOFTContractFactory: OmniContractFactory = async ({ eid, address }) => {
// Here the goal is to grab your OFT's ABI and create an ether.js contract based on it
//
// You can go crazy here, make it very specific to your OFT or very generic
const abi = ...
return new Contract(address, abi)
}
There are a couple of variations to this approach, most notably you can make myOFTContractFactory
fall back to a factory from createContractFactory
from @layerzerolabs/devtools-evm-hardhat
if the address
you passed is not your OFT
contract. In this way, you can drop the createEndpointV2Factory
above.
Hey @berktec!
Small update just to keep you in the loop. We are considering moving from ethers
to viem
and this change will include a change that might reduce the code you need to write for your project.
The ABIs for the standard contracts will be embedded into the project so you'll no longer need to override any factories as such. It will take some time to work it in and, it being a breaking change, will also affect any code you might have written.
Hi there,
Looking to deploy an OFT for multiple chains, but starting on Testnets of course. I have Both OFTs Deployed to Arbitrum-Sepolia and to ETH-Sepolia, and I have been facing two Errors.
Error: An error occurred while getting the OApp configuration: AssertionError [ERR_ASSERTION]: Could not find a deployment for address '0xa96b3749D01A50c4353f66455dBD92a52778C65A' on ARBSEP_V2_TESTNET (arbitrumSepolia)
This error occurs when attempting to run the wiring with this command:
npx hardhat lz:oapp:peers:get --oapp-config layerzero.config.ts
and this HardHat Config
and this layerzeroConfig.ts
Expected behavior I would have expected in the first instance for the Configuration to find the Contract deployed on the Arbitrum Sepolia Network, as clearly the transactions and other infrastructure is functioning properly.
Both of the Contracts are IN-fact deployed and validated on testnets https://sepolia.arbiscan.io/address/0xa96b3749D01A50c4353f66455dBD92a52778C65A https://sepolia.etherscan.io/address/0xDee109faA9a53E6aBD3fE4ca2d1E423E4FC6D019
Screenshots
Environment (please complete the following information):
Additional context Additional Context about the Insane Gas Price issue:
Here is the Task that I created to test the bridging between the two test nets:
The second Problem is when trying to bridge any more than 1-10 tokens the Gas fee quickly jumps from Dust essentially to 10x or more as constituted by this error from hardhat.
In Summary:
What am I missing in terms of configuration here to prevent the wild fluctuation in Gas Prices: and How can I get the Arbitrum Sepolia testnet to recognize the Contracts I have deployed to use these tools effectively