Closed paouvrard closed 2 years ago
+1 to the new proposal.
Where are we using connectorAddress
and connectorAbi
, if they are optional how are we using it if not passed?
Environment variables defined by the frontend. But on 2nd thought I think we shouldn't add those arguments here because transfer finalization still relies on them and so they would still need to be defined in process.env.
btw, shouldn't we put each field of options
as optional, rather than the whole object? i.e
options?: {
symbol?: string,
decimals?: number,
sender?: string,
recipient?: string,
provider?: ethers.providers.Web3Provider,
connectorAddress?: string, // erc20Locker | etherCustodian | auroraEvm | erc20Factory | nativeNearLocker
connectorAbi?: string
}
Implementation: https://github.com/aurora-is-near/rainbow-bridge-client/pull/58
Aurora and Rainbow bridge connectors currently implement different APIs for creating transfers.
naturalErc20.sendToNear({ erc20Address, amount, sender, recipient })
https://github.com/aurora-is-near/rainbow-bridge-client/blob/39ae822e0d72da8a66a68cce7c65afdc044b759b/packages/nep141-erc20/src/natural-erc20/sendToNear/index.js#L185symbol
anddecimals
on-chain. But in most cases the caller of the library will already know this metadata as it is used to display token balances to the user. So this metadata could be optional arguments.amount
input is a decimal string ("2.3"). It would be safer to accept ethers.BigNumber or a big number string with decimals as a separate argumentsender
could be optional and default to the connected wallet address.naturalErc20.sendToAurora({ amount, token })
https://github.com/aurora-is-near/rainbow-bridge-client/blob/152b0755d550998adf3533e1dc1f4c0e5f3892c2/packages/aurora-erc20/src/natural-erc20/sendToAurora/index.js#L181token.symbol
andtoken.decimal
could be optional and queried on-chain if necessary.Proposed API:
cc @mfornet