-
Notifications
You must be signed in to change notification settings - Fork 10
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
Add evm function call #270
Conversation
@@ -0,0 +1,92 @@ | |||
// Origal repo: https://github.com/Consensys/Tokens/blob/master/contracts/eip20/EIP20.sol |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so this file is extended version of file from above link? could you add a bit more detail about what has modified/extended and why? (eg. I notice that mint
doesn't exist on above, but added below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't added any explanation because we will never change this file again. It's just a contract implementing the ERC20 interface for testing.
The code here was copy pasted from the URL linked, and the mint function was added so we can distribute the tokens as we want for testing.
I was checking other options to implement this contracts, looks like Open Zeppelin haves a npm package with the implementations for all we need ERC20, ERC721, ERC1155.
But if it's ok I would like to tackle this in another PR, there is too much work here already.
That's the package I'm looking to use: https://www.npmjs.com/package/@openzeppelin/contracts
const isUserAuthenticated = await getAuthState(); | ||
if (isUserAuthenticated !== true) { | ||
onError('You are not authenticated or there has been an indexer failure'); | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it ok to exclude isUserAuthenticated
check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved it to here:
fast-auth-signer/packages/near-fast-auth-signer/src/components/SignMultichain/SignMultichain.tsx
Line 130 in db52750
const isUserAuthenticated = await getAuthState(); |
We need to be authenticated before estimate the gas for the function call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is amazing work. Left few comments. Would prefer to get more reviews from rest of the team
❌ PR inactiveThis PR has been inactive for two weeks. It's now marked as stale. Tip If you think it's a mistake, you can restart the bot with |
packages/near-fast-auth-signer/src/components/SignMultichain/bitcoin/schema.ts
Outdated
Show resolved
Hide resolved
maxFeePerGas: yup.mixed<bigint>().optional(), | ||
maxPriorityFeePerGas: yup.mixed<bigint>().optional(), | ||
gasLimit: yup.mixed<bigint>().optional(), | ||
export const SendEVMMultichainMessageSchema = BaseSendMultichainMessageSchema.shape({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also validate the chainId
like before. Also are we no longer supporting dapps specifying the gas themselves and only fetching when it's not specified?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The chainId it's being validate on the derivationPath.
For the other properties, the type mixed accepts anything, but you are right we should narrow the validation. I will improve it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about EVM chain previously validated here:
chainId: yup.lazy((value) => yup.mixed<bigint>().test(
'is-valid-chainId',
`Invalid chainId value: ${value}`,
(val) => [BigInt(1), BigInt(56), BigInt(97),
// Check if both are present or both are undefined | ||
if ((fee && utxos) || (!fee && !utxos)) { | ||
return true; // Validation succeeds | ||
transaction: yup.object().shape({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should validate that a from
is provided here. As discussed the dapp can choose to be explicit about the from and if it is provided the signer should check that it matches the derivation path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The BTC doesn't accept a from, even if provided it will be ignored, now and before.
The EVM can accept a from and as discussed it will be validated on the multichain-tools, here is the place where the validation occurs: https://github.com/near/multichain-tools/blob/cce661c13a53b8b89dde5f3c82f3aadd1790a0aa/src/chains/EVM/EVM.ts#L156
maxPriorityFeePerGas: yup.mixed<bigint>().optional(), | ||
gasLimit: yup.mixed<bigint>().optional(), | ||
export const SendEVMMultichainMessageSchema = BaseSendMultichainMessageSchema.shape({ | ||
transaction: yup.mixed().required(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it's no longer validated in the base schema, we should make sure that the dev has passed in a to
, value
and optionally a from
here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, it will be fixed when we narrow down the schema
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Great work @Pessina !
This PR includes:
hardhat
for testing purposeObs: The tests for this PR are expected to be flaky as they depend on relayer and ChainSignature contract that fail frequently. The solution would be run those dependencies locally (I can setup this later)