bcnmy / biconomy-client-sdk Goto Github PK

Ideal flow:

    // In Backend
    let value = ethers.utils.parseEther('0.000000001')
    let tx = {
        to: "0x48C6F6b6828145E051aAf66dFaA3798450176473",
        data: "0x",
        value: value
    }

    let feeQuotes = await smartAccount.prepareRefundTransaction({transaction: tx})
    transaction = await smartAccount.createRefundTransaction({transaction: tx, feeQuote: feeQuotes[0]})
    
    let web3js_payload = await smartAccount.createWeb3JSPayload(transaction)
    .
    .
    .
    // Send web3js_payload to frontend
    .
    .
    .
    // In Frontend
    // sign and send transaction using web3.js
    let receipt = await web3.eth.sendTransaction(web3js_payload)

Describe the bug
SmartAccount.sendTransactionBatch fails Error: Call Gas Limit Estimation Failed with transactions that require a manual gas limit set. Oddly, the same transactions succeed when using multiple SmartAccount.sendTransaction requests with identical dto data and ordering.

Versions

• "@biconomy/smart-account": "^2.0.2",

Additional context
Possibly caused by peer package account-abstraction not passing a gasLimit array to SmartAccountAPI.createSignedUserOp: https://github.com/bcnmy/biconomy-client-sdk/blob/737634190a689b9dde77105aa717fc8ee3136223/packages/account-abstraction/src/ERC4337EthersSigner.ts#L198C33-L198C72

Description
The current implementation of the new SDK requires supplying API keys on the client-side using environment variables, especially in Next.js. This approach poses potential security risks since the keys are bundled with the JavaScript code during production, making them accessible to users.

Suggestions
I propose migrating the following processes to the server-side to enhance security and prevent exposure of sensitive information:

Bundler Migration: Move the bundler logic to the server-side to avoid exposing API keys to the client.

Paymaster Migration: Transfer the paymaster functionality to the server-side to ensure the secure handling of payment-related tasks.

Smart Account Creation on Server-Side: Implement smart account creation on the server-side to prevent the need for sending the JsonRpcSigner to the backend, which can introduce security vulnerabilities.

Current Limitations
At present, we encounter the following limitations:

JsonRpcSigner: The JsonRpcSigner cannot and should not be sent to the backend. As a result, creating the smart account does not work in this manner.

API Key Access: Even if we pass the paymaster and bundler from the server to the frontend, the API keys can still be accessed, posing a security risk.

Community Collaboration
I urge the community to come together and brainstorm novel solutions to address these security concerns and improve the overall safety and privacy of the SDK implementation.

Let's collaborate to find a more secure approach that ensures the confidentiality of sensitive data and mitigates potential risks associated with the current client-side handling of API keys.

Thank you for your attention to this matter. Your contributions and ideas are highly appreciated. Together, we can make the SDK safer and more robust.

Describe the bug

The app starts failing after write
import SmartAccount from "@biconomy/smart-account"

[TypeError: Class extends value undefined is not a constructor or null]

To Reproduce
Steps to reproduce the behavior:

1. Go to https://github.com/bcnmy/biconomy-sdk-starter-kit
2. Check js/src/App.js or typescript/src/App.tsx
3. import SmartAccount and create an instance new SmartAccount(provider, options)
4. yarn start
5. Front end fails to load with above error

at ./node_modules/messaging-sdk/node_modules/ws/lib/receiver.js (receiver.js:27:1)
    at options.factory (react refresh:6:1)
    at __webpack_require__ (bootstrap:24:1)
    at fn (hot module replacement:62:1)
    at ./node_modules/messaging-sdk/node_modules/ws/lib/websocket.js (websocket.js:15:1)
    at options.factory (react refresh:6:1)
    at __webpack_require__ (bootstrap:24:1)
    at fn (hot module replacement:62:1)
    at ./node_modules/messaging-sdk/node_modules/ws/index.js (index.js:3:1)
    at options.factory (react refresh:6:1)

Expected behavior
Smart Account should get initialised properly

Screenshots
attached above

Desktop (please complete the following information):

• OS: [e.g. iOS] macos monterey
• Browser [e.g. chrome, safari] chrome
• Version [e.g. 22]

node v16.14.2

Additional context
Import fails for js file

In client-sdk provider.getFeeData() function is called to populate maxFeePerGas and maxPriorityFeePerGas for any userOp created in client-sdk. The fee values returned by getFeeData are either null or low as compared to on chain network fee. This can be sorted by switching from provider to an external api that send's accurate data. Following are the requirements for external endpoint for fetching fee values.

Url: BASE_URL/gas-prices/chainid
Type: GET
params: chainid

Response

{
code: 200,
message: 'SUCCESS',
data: {
gasPrice: 10,
maxFeePerGas: 12,
maxPriorityFeePerGas: 2
}
}

im trying to send an txn to using .sendTransaction() for a crosschain swap using LIFI(got txn data like this), im getting a typerror.

const tx = {
data: "0x83f319170000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000022000000000000000000000000000000000000000000000000000000000000008c089ce941ffab1ae94b6fcb4446f11411dbd230d918ccc4b3949dd1b275287b172000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c2132d05d31c914a87c6611c10748aeb04b58e8f00000000000000000000000020b59ee457f3013cc2e556993f961803aabd682100000000000000000000000000000000000000000000000000000000000f34d70000000000000000000000000000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006616d61726f6b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000086c6966692d6170690000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000039e3e49c99834c9573c9fc7ff5a4b226cd7b0e630000000000000000000000006d310348d5c12009854dfcf72e0df9027e8cb4f40000000000000000000000002791bca1f2de4661ed88a30c99a7a9449aa84174000000000000000000000000c2132d05d31c914a87c6611c10748aeb04b58e8f00000000000000000000000000000000000000000000000000000000000f424000000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000544301a37200000000000000000000000002791bca1f2de4661ed88a30c99a7a9449aa84174000000000000000000000000c2132d05d31c914a87c6611c10748aeb04b58e8f00000000000000000000000000000000000000000000000000000000000f424000000000000000000000000000000000000000000000000000000000000f34d7000000000000000000000000000000000000000000000000000000000000016000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000002600000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000030000000000000000000000000000000000000000000000000000000000000004e00000000000000000000000000000000000000000000000000000000065d3696600000000000000000000000000000000000000000000000000000000000000030000000000000000000000006c30be15d88462b788dea7c6a860a2ccaf7b2670000000000000000000000000e373df144a70bccc10190f97bede647d1ed6cfc80000000000000000000000003037e79fce8817a6f21196d8d93c80f53abb926700000000000000000000000000000000000000000000000000000000000000030000000000000000000000001093ced81987bf532c2b7907b2a8525cd0c172950000000000000000000000008929d3fea77398f64448c85015633c2d6472fb29000000000000000000000000445fe580ef8d70ff569ab36e80c647af338db35100000000000000000000000000000000000000000000000000000000000000040000000000000000000000001093ced81987bf532c2b7907b2a8525cd0c172950000000000000000000000008929d3fea77398f64448c85015633c2d6472fb290000000000000000000000003037e79fce8817a6f21196d8d93c80f53abb926700000000000000000000000039e3e49c99834c9573c9fc7ff5a4b226cd7b0e630000000000000000000000000000000000000000000000000000000000000003000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000271000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008f3cf7ad23cd3cadbd9735aff958023239c6a063000000000000000000000000c2132d05d31c914a87c6611c10748aeb04b58e8f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e000000000000000000000000020b59ee457f3013cc2e556993f961803aabd68210000000000000000000000000000000000000000000000000007a7a9f9f91645000000000000000000000000000000000000000000000000000000000000003200000000000000000000000020b59ee457f3013cc2e556993f961803aabd68210000000000000000000000000000000000000000000000000000000000676e6f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  to: "0x1231DEB6f5749EF6cE6943a275A1D3E7486F4EaE",
};

const OP = await smartWallet.sendTransaction(tx, {
  paymasterServiceData: {
    mode: PaymasterMode.SPONSORED,
  },
});

const { transactionHash } = await OP.waitForTxHash();
console.log("transactionHash", transactionHash);

i have checked the api key + bundler url configs, any idea of what might be going wrong here?

here's the full error

 5 |     return padBytes(hexOrBytes, { dir, size });
 6 | }
 7 | export function padHex(hex_, { dir, size = 32 } = {}) {
 8 |     if (size === null)
 9 |         return hex_;
10 |     const hex = hex_.replace('0x', '');
                     ^
TypeError: hex_.replace is not a function. (In 'hex_.replace("0x", "")', 'hex_.replace' is undefined)
      at padHex (/Users/abheektripathy/Documents/code/avail/nexus-cli/node_modules/viem/_esm/utils/data/pad.js:10:17)
      at encodeBytes (/Users/abheektripathy/Documents/code/avail/nexus-cli/node_modules/viem/_esm/utils/abi/encodeAbiParameters.js:142:22)
      at prepareParams (/Users/abheektripathy/Documents/code/avail/nexus-cli/node_modules/viem/_esm/utils/abi/encodeAbiParameters.js:31:29)
      at encodeAbiParameters (/Users/abheektripathy/Documents/code/avail/nexus-cli/node_modules/viem/_esm/utils/abi/encodeAbiParameters.js:19:28)
      at encodeFunctionData (/Users/abheektripathy/Documents/code/avail/nexus-cli/node_modules/viem/_esm/utils/abi/encodeFunctionData.js:26:11)
      at encodeExecute (/Users/abheektripathy/Documents/code/avail/nexus-cli/node_modules/@biconomy/account/dist/esm/BiconomySmartAccountV2.js:1:7192)
      at /Users/abheektripathy/Documents/code/avail/nexus-cli/node_modules/@biconomy/account/dist/esm/BiconomySmartAccountV2.js:1:12812
      at processTicksAndRejections (:61:77)
      

Problem You're Facing

After sending a userOp, I want to wait for N confirmations on the blockchain.
Right now, using userOpResponse.wait(999) returns a Promise which resolves right after the transaction is included in a block, without waiting for any additional confirmation.

Proposed Solution

The UserOpResponse.wait function already takes as argument the number of desired confirmations.
That function should simply be fixed to correctly take into account this value.

Alternatives Considered

A possible workaround is to use waitForTxHash and wait for the desired number of confirmations for that transaction using another library (e.g. ethers).

Use Cases

Waiting for a given number of confirmations can help prevent issues with blockchain forks/reorgs.

Additional Info

I'm willing to provide a fix and will open a PR which closes this issue.

Describe the bug
The React demo App using biconomy SDK does not start

I am using below in my package.json
"start": "react-scripts start"

To Reproduce
Steps to reproduce the behavior:

1. Import below packages in react app

   "@biconomy/core-types": "0.0.2",
   "@biconomy/relayer": "0.0.2",
   "@biconomy/smart-account": "0.0.2",
   "@biconomy/transactions": "0.0.2",
   "@biconomy/web3-auth": "0.0.2",

2. Start the App

Expected behavior
Should be able to run in the browser with sdk and it's dependencies

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS] Macos monterey
• Browser [e.g. chrome, safari] chrome
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

What I suspect is that because the Biconomy SDK is using @biconomy/messaging-sdk and @TorusLabs has dependencies that rely on core node modules such as aqmplib, stream, zlib, therefore it does not work on client side. webpack 5 does not have these polyfills by default.
I am also gettng below for path, fs, tls

Module not found: Error: Can't resolve 'path' in '/Users/chirag/work/biconomy/scw-playground/sdk-demo/node_modules/node-gyp-build'

The TypeScript definition for getPaymasterAndData only takes one argument, but the actual function takes two.

To get it to work I have to do:

const { paymasterAndData } = await (
  account.paymaster.getPaymasterAndData as (
    op: Partial<UserOperation>,
    service: SponsorUserOperationDto,
  ) => Promise<PaymasterAndDataResponse>
)(partialUserOp, paymasterServiceData)

There is no way of specifying gas limit on transactions when the wallet is not deployed.

sendTransaction and sendTransactionBatch ignore the gasLimit set in the transaction when the wallet is not deployed.
Following the callpath
createSignedUserOp -> createUnsignedUserOp -> encodeUserOpCallDataAndGasLimit

it seems that encodeUserOpCallDataAndGasLimit ignores gasLimit set in the detailsForUserOp and sets 600000 as default callGasLimit.

On top of this sendTransactionBatch ignores any gasLimit set on the transaction and doesn't send it down the call path as mentioned in #199.

Describe the bug
When building my library with bundled biconomy sdk I get the following error:
node_modules/@biconomy/core-types/dist/src/AccountAbstractionTypes.d.ts:1:52 - error TS2307: Cannot find module 'Types' or its corresponding type declarations.

To Reproduce
Steps to reproduce the behavior:

1. Install @biconomy/smart-account
2. Build typescript lib with tsc
3. See error

Expected behavior
Successful build

Desktop:

• OS: Linux Mint 20.3 Cinnamon

Additional context
It seems that the error is caused by a wrong import in the file AccountAbstractionTypes.d.ts.
Currently the import is:
import { FallbackApiResponse, UserOperation } from 'Types';

It should be as follows:
import { FallbackApiResponse, UserOperation } from './Types';

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Describe the bug

When using token paymaster, after calling biconomyAccount.buildTokenPaymasterUserOp callGasLimit is coming negative value in the retuned op.

I think the problem arises when you make a call to estimateUseropGas with non-zero values of maxFeePerGas and maxPriorityFeePerGas, in this case bundler will use provided values (instead of defaults)

To Reproduce
Steps to reproduce the behavior:

1. Go to https://github.com/bcnmy/sdk-examples/tree/master/backend-node
2. Add Arbitrum Goerli config in config.json (get paymasterUrl by registering on the dashboard and use bundler public url : https://bundler.biconomy.io/api/v2/42161/A5CBjLqSc.0dcbc53e-anPe-44c7-b22d-21071345f76a
3. yarn run smartAccount mint --mode=TOKEN
4. there would be error log saying callGasLimit should be string of number. In the logs (by enabling export BICONOMY_SDK_DEBUG=true) callGasLiit goes negative value

Expected behavior
Should be correctly able to recalculate callGasLimit.

Screenshots
will be added if required

Desktop (please complete the following information):
v18.16.0
[email protected]
biconomy SDK : packages version 3.0.0-alpha.0

Additional context
NA

Describe the bug
The @biconomy/web3-auth does not work with next.js.
Importing the social login gives error with the styles

To Reproduce
Steps to reproduce the behavior:

1. Import the socialLogin
2. It is not working with nextjs

Expected behavior
It should work properly

Screenshots