-
Notifications
You must be signed in to change notification settings - Fork 12
NEAR chain adapter #17
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
Conversation
| private readonly contract: ChainSignatureContract | ||
| private readonly networkId: 'mainnet' | 'testnet' | ||
|
|
||
| constructor(args: { rpcUrl: string; networkId: 'mainnet' | 'testnet'; contract: ChainSignatureContract }) { |
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.
In all the other chains we take the provider directly, I would suggest to do the same (as providers might need API Keys)
| const res = (await this.provider.query<any>(`account/${address}`, '')) as any | ||
| return { balance: BigInt(res.amount), decimals: 24 } | ||
| } catch (e) { | ||
| if (this.isAccountDoesNotExistError(e)) { |
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 feel that this library in particular should not handle the isAccountDoesNotExistError, since by nature chainsig.js only handles getting signatures
Otherwise, the chains acts in one way for NEAR, and in a totally different for the other chains
Here we could either return 0 on error (which would make sense) or raise the error further app
| async deriveAddressAndPublicKey(predecessor: string, path: string): Promise<{ address: string; publicKey: string }> { | ||
| const derivedKey = await this.contract.getDerivedPublicKey({ path, predecessor, IsEd25519: true }) | ||
| const pk = NearPublicKey.fromString(derivedKey as string) | ||
| const derivedAccountId = `${path}.${predecessor}` |
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 look weird to me, since I would have expected the derived account to be:
- either an
implicit account - either
${predecessor}(always returnpredecessorindifferent to thepath)
feat(near): add NEAR adapter; consolidate to @near-js v2; update examples
Examples needed to be changed: