diff --git a/docusaurus.config.js b/docusaurus.config.js index 8a909543..0eb0af97 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -49,9 +49,6 @@ const config = { }, "3.0": { label: "SDK V3", - }, - "1.0": { - label: "SDK V2", } }, }, diff --git a/versioned_docs/version-1.0/additional-content/_category_.json b/versioned_docs/version-1.0/additional-content/_category_.json deleted file mode 100644 index b9808e4c..00000000 --- a/versioned_docs/version-1.0/additional-content/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Additional Content", - "position": 7, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/additional-content/account-abstraction.md b/versioned_docs/version-1.0/additional-content/account-abstraction.md deleted file mode 100644 index 7512f69c..00000000 --- a/versioned_docs/version-1.0/additional-content/account-abstraction.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Account Abstraction - -Account abstraction provides users the ability to use accounts at a higher level with less knowledge of the processes going on underneath. Like using a Gmail account without knowing how it functions. - -## Type of Accounts - -Currently, there are two types of wallets on Ethereum, one is EOA (externally owned account) and the other is a smart contract wallet. To initiate a transaction on Ethereum a trigger must come from something outside the blockchain, and hence transactions can only be executed via externally owned accounts. - -1. **EOAs**. Every EOA is associated with a public and a private key. A public key is used to indicate the address of an account and a private key is used to sign transactions. The private key signature is proof that the transaction is valid and has in fact been initiated by its associated public key address. - The problem with EOAs is that accounts are tightly coupled with signatures, to own a particular wallet address, you need to have its associated private keys and this functionality is hardcoded in the EVM. This creates a few problems as losing a key means losing your account. - -2. **Smart Contract Accounts**. There is one solution that saves the day - Smart Contract Accounts. Unlike EOAs, the account and signer are not coupled here. The accounts are defined by the contract code and the transaction-validating functionality has been abstracted away from the accounts. Smart contract accounts can have their own logic to define what a valid transaction is. - To use better UX features like multisig, social recovery, and social signing schemes - you need to use smart contract accounts as EOAs can not provide those functionalities. - In summary, account abstraction removes the need to remember seed phrases. It decouples the account and its transaction validation functionality. Account abstraction gives users a self-custodial account that can be customized to suit their needs. - -With account abstraction, there is an overall UX improvement that will be reflected across the domains of DeFi, GameFi, DAOs, and much more. - -## ERC-4337: Account Abstraction Via Entry Point Contract - -The following section gives a brief technical breakdown of ERC 4337. The ERC logic replicates the functionality of the current transaction mempool in a higher-level mempool which takes in smart contract wallet calls. - -There are four main components to ERC 4337: UserOperation, EntryPoint, Sender Contract, Paymaster, and Bundler. - -There is also an Aggregator which is a helper contract trusted by wallets to validate an aggregated signature. It is part of a newer addition to the EIP and has not yet been included in the explanation below. - -**UserOperations**: These are transaction objects created to execute transactions on behalf of the user. The execution happens after confirmation from the Sender Contract. These operations are generated by the Dapp. - -**EntryPoint**: The EntryPoint contract handles the execution and verification of the transaction operations passed to it. The global EntryPoint contract takes in the bundled transactions from respective Bundlers and goes through each user operation to run a verification and execution loop. - -**Bundlers**: A bundler takes in UserOperations from the mempool, and bundles them together to send them to the EntryPoint contract for execution. - -**Sender Contract**: These are user wallet accounts in the form of a smart contract. - -**Paymaster**: These are optional contracts that can pay gas for a transaction on behalf of the user. Instead of relying on their wallet, users can get their transaction fees sponsored by a paymaster. - -## Verification loop - -The contract goes through each user operation and calls a 'validation function' in the Sender Contract. The Sender Contract runs this function to verify the signature of the UserOperation and to compensate the bundler for bundling these transactions. - -## Execution loop - -Sends the `callData` in each UserOperation to the Sender Contract. The wallets run an execution operation to execute the transaction(s) that are specified in the operation. The Sender Contract is then refunded with the gas left after the execution of the operation. - -## Bundlers - -Bundlers are required to relay bundled UserOperations from various sources to the EntryPoint contract and then to the network. A Bundler performs the following functions: - -- Picks UserOperations from the high-level UserOperation mempool (which is not the same as the regular transaction mempool). -- Bundles the transactions into one large transaction. -- Routes them to the EntryPoint contract. -- Informs inclusion of the said bundle in the next block that is to be broadcasted to the network. - -## Sender Contract - -There are basically two functionalities that a Sender Contract is expected to perform: - -- It is expected to verify the operation’s signature and pay the fee if the wallet considers the operation valid. -- Wallet contract is expected to have an execute function that parses the callData as a series of one or more calls that the wallet should make. - -## Paymaster - -A paymaster contract is an optional feature that allows application developers to cover gas costs for their user’s operation, allow users to pay fees with EIP-20 tokens, and many other use cases. A paymaster must stake ETH with the EntryPoint contract, which is enough to pay for the UserOperation. - -A paymaster is required to perform two functions: - -- It is expected to validate a UserOperation by showing its willingness to pay for the operation. -- It is required to have custom logic for fee payment which gets called during the execution loop. diff --git a/versioned_docs/version-1.0/additional-content/gas-txn-fee.md b/versioned_docs/version-1.0/additional-content/gas-txn-fee.md deleted file mode 100644 index 93eb55b0..00000000 --- a/versioned_docs/version-1.0/additional-content/gas-txn-fee.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Gas & Transaction Fees - -Using the smart contract wallet, transaction fees can be abstracted away from users. This allows users to pay the transaction fees in multiple currencies or even have their fees paid by a third party like the dApp itself. In addition, users don't have to worry about gas limits or gas price since our relayer system automatically retries transactions to ensure prompt execution. - -## Transaction Fee Payment Options - -Currently, users can pay their gas fees with the following currencies: - -- ETH / MATIC / BNB (native tokens of a particular chain) -- USDT -- USDC -- DAI - -Users are shown a fixed fee at the time of transaction confirmation, which is used to reimburse the relayers that will execute the transaction. This fee will not increase even if the transaction is repriced by the relayer. This is a cost the relayers will bear and hence will optimize for. - -> The following Endpoint can be consumed to fetch gas fees for different currencies and for different networks -> -> https://sdk-relayer.prod.biconomy.io/api/v1/relay/feeOptions?chainId=5 - -Later, the option of paying gas in your project's eco-system token will be available. - -## How to Pay Transaction Fees for Your Users - -It is possible for third parties to [sponsor the transaction fees](https://docs.biconomy.io/build-with-biconomy-sdk/gasless-transactions) of their users in a non-custodial way. You can do this using a paymaster. diff --git a/versioned_docs/version-1.0/additional-content/partners.md b/versioned_docs/version-1.0/additional-content/partners.md deleted file mode 100644 index dfc06131..00000000 --- a/versioned_docs/version-1.0/additional-content/partners.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -sidebar_position: 4 ---- - -# Preferred Partners - -> A list of partners that we recommend to work with. - -## Developer Studios - -### Lazer Technologies - -[Lazer](https://www.lazertechnologies.com/) is a 70-person engineering and design studio. We partner with top VCs like Sequoia, A16Z, and Paradigm, among others, to help their portfolio companies build high-quality products fast. Some of the projects we’ve worked on include Dapper Labs, 100 Thieves, Goldfinch, Abacus, Stardust, SudoSwap, and Fan Controlled Football, among many others. - -Complete list of customers [here](https://www.lazertechnologies.com/clients). - -Service offerings [here](https://www.notion.so/lazertechnologies/Lazer-Engineering-Design-2bc78238b24e4f2c9239ceb0e6c70199). - -Design portfolio [here](https://www.lazertechnologies.com/design). - -Point of contact: [telegram](https://t.me/cryptoangelgc), angel@lazertechnologies.com. - -## RPC Services - -### Alchemy Node Service - -Alchemy's node infrastructure is designed to provide developers with reliable and scalable access to blockchain data. Alchemy is used by over 100,000 developers and powers over $1 trillion in monthly transactions. Visit https://www.alchemy.com/homepage. diff --git a/versioned_docs/version-1.0/additional-content/scw.md b/versioned_docs/version-1.0/additional-content/scw.md deleted file mode 100644 index f231336b..00000000 --- a/versioned_docs/version-1.0/additional-content/scw.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Smart Contract Wallets - -A smart contract wallet is an Ethereum wallet managed by a smart contract instead of a private key. In this paradigm, the object holding your tokens (the account) is decoupled from the object authorized to move these tokens (the signer). - -Ethereum platform supports two types of accounts: - -- Externally owned accounts (EOAs) like Metamask, which can be accessed using a private key or seed phrase with just limited functionality. -- Smart Contract Accounts require a smart contract with a deployed arbitrary logic for providing functionalities like multi-sig transactions, daily transfer limit, emergency account freezing, and secure account recovery. - -The recent standardized proposal [EIP-4337 for Account Abstraction](https://eips.ethereum.org/EIPS/eip-4337) presents the standard for creating smart contract wallets. This simplifies the creation and operations of SCWs on Ethereum, and offers a rich user chainless experience. The smart contract wallets created by using Biconomy's SDK are compliant with this EIP. Thus, with account abstraction and SCWs coming together, users will be able to pay gas fees in ERC-20 Tokens and accept meta transactions. - -SCWs can enable the following features: - -- Allowing Multi-signature authorization - More than one user to approve the transaction for improved security. -- Setting daily transaction amount limit - Setting up a transaction amount limit for reducing the chances of the occurrence of expensive user transaction errors or manipulation done by hackers. -- Batching transactions - Batched transactions allow users of the wallet to perform multiple transactions in one single on-chain transaction - -Most Ethereum wallets manage EOA accounts and, therefore, have limited functionality. Smart wallets, however, take advantage of Contract Account functionality—they manage funds via coded instructions that establish who can access them, under what conditions, and more. - -Thanks to the versatility of smart contracts, in addition to breaking user reliance on private keys, smart wallets offer advantageous new features and provide a seamless user experience similar to traditional Web2 apps. diff --git a/versioned_docs/version-1.0/architecture/_category_.json b/versioned_docs/version-1.0/architecture/_category_.json deleted file mode 100644 index aa1ba421..00000000 --- a/versioned_docs/version-1.0/architecture/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Architecture", - "position": 6, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/architecture/backend-service.md b/versioned_docs/version-1.0/architecture/backend-service.md deleted file mode 100644 index d15905c8..00000000 --- a/versioned_docs/version-1.0/architecture/backend-service.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Backend Service - -> SDK relies on a backend client for gas estimation endpoints, configurations, indexer communication etc. - -The backend Service is there to support client SDK and provides APIs to perform tasks that are not effectively done on the client side. - -For example, it provides APIs to fetch token balances of smart accounts, APIs to do gas estimation for certain operations, etc. - -The main services of the Backend node are described below. - -![Arch-3](img/arch-3.png) diff --git a/versioned_docs/version-1.0/architecture/client-sdk.md b/versioned_docs/version-1.0/architecture/client-sdk.md deleted file mode 100644 index a391c167..00000000 --- a/versioned_docs/version-1.0/architecture/client-sdk.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Client SDK - -> client SDK overview - -Biconomy SDK is a collection of packages shipped as a mono repo. You can use one module, several modules, or the entire stack. - -Core packages and their dependencies are described below. - -- Smart Account -- Node client -- Core types -- Account abstraction -- Relayer -- Transactions -- web3-auth -- Gas estimator (WIP) - -![Arch-2](img/arch-2.jpeg) diff --git a/versioned_docs/version-1.0/architecture/img/arch-1.png b/versioned_docs/version-1.0/architecture/img/arch-1.png deleted file mode 100644 index fb107c92..00000000 Binary files a/versioned_docs/version-1.0/architecture/img/arch-1.png and /dev/null differ diff --git a/versioned_docs/version-1.0/architecture/img/arch-2.jpeg b/versioned_docs/version-1.0/architecture/img/arch-2.jpeg deleted file mode 100644 index 17660f4f..00000000 Binary files a/versioned_docs/version-1.0/architecture/img/arch-2.jpeg and /dev/null differ diff --git a/versioned_docs/version-1.0/architecture/img/arch-3.png b/versioned_docs/version-1.0/architecture/img/arch-3.png deleted file mode 100644 index 5fbae1ce..00000000 Binary files a/versioned_docs/version-1.0/architecture/img/arch-3.png and /dev/null differ diff --git a/versioned_docs/version-1.0/architecture/img/arch-4.png b/versioned_docs/version-1.0/architecture/img/arch-4.png deleted file mode 100644 index 4a22502d..00000000 Binary files a/versioned_docs/version-1.0/architecture/img/arch-4.png and /dev/null differ diff --git a/versioned_docs/version-1.0/architecture/overvierw.md b/versioned_docs/version-1.0/architecture/overvierw.md deleted file mode 100644 index a2d91dd3..00000000 --- a/versioned_docs/version-1.0/architecture/overvierw.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -> Bird's eye view of Biconomy SDK - -There are multiple different unique modules that power the Biconomy Architecture. - -- Widget UI (WIP) -- Client SDK -- Backend Service -- Indexer Node -- Relayer Service Node - -![Arch-1](img/arch-1.png) diff --git a/versioned_docs/version-1.0/architecture/realyer-node-service.md b/versioned_docs/version-1.0/architecture/realyer-node-service.md deleted file mode 100644 index 22595cf3..00000000 --- a/versioned_docs/version-1.0/architecture/realyer-node-service.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -sidebar_position: 4 ---- - -# Relayer Node Service - -Relayer Node Service is responsible for signing valid transactions, paying their gas fees, and sending them to the network. - -Biconomy Relayers allows you to send transactions and takes care of transaction signing, nonce management, gas pricing estimation, and resubmissions. This way you don’t need to worry about monitoring transactions to ensure they get mined. - -Each Relayer is essentially an EOA. Biconomy's relayer infrastructure composes of multiple such EOAs on each chain. Every relayer has an inbuilt auto-scaling functionality. Thus in cases of a high load of transactions, the relayer infra can auto-spin up additional relayers to handle this. - -## Architecture - -The Relayer Node Service is divided into the following main components. - -- **Common**: Has all the services that would be shared by every entity of the project. These include database, caching, gas price service, network service, logger, etc. -- **Server**: Has all the routes along with validations of request bodies and simulation check middleware. -- **Relayer**: Contains the core logic of relayer management and transaction handling. This part also takes care of transaction resubmission and notifying the client regarding the state of a transaction. - -![Arch-4](img/arch-4.png) - -## Detailed Service Overview - -Below you will find a detailed explanation for every service that is there in the relayer node. - -### Common - -- **Cache**: Connects to Redis and has functions to interact with the cache layer -- **Constants**: All Abis, constant values go into this -- **Gas Price**: Includes the gas price manager and services that are responsible for scheduling gas price schedulers, fetching gas prices & getting bumped up gas prices for resubmitted transactions. Both regular gasPrice and EIP 1559 gasPrices are available. -- **Health Check APIs**: These APIs are built in to check if servers are up and running for the relayer node -- **Interfaces**: Contains all the common interfaces that are required throughout the project. -- **Logger**: A module that is responsible for logging across the project. -- **Maps**: Certain maps that are to be maintained and used go in here. -- **Network Service**: The network service is the most important service as it is responsible to get data from the blockchain, sending transactions, and getting gas prices. All the interactions with the blockchain happen via this service. -- **Queue Manager**: RabbitMq queues are used to manage transactions as messages for various services to push and consume. There are queues for every chain id and transaction type. And also some common queues for transaction handling and retry transaction handling. -- **Relay Service**: This service is responsible to relay transactions to the relayer side from the server side. It basically pushes to respective queues based on chain id and transaction type. -- **Scheduler**: Schedulers are used to have cron jobs for services that require actions to be triggered at regular intervals. -- **Service Manager**: This is the main service setup manager where all the instances of various services are created and all instance mappings are exported from. It is also responsible for creating database and cache instances and creating their connections. -- **Simulation Service**: To check if a transaction would succeed on-chain we simulate transactions beforehand. It is also used to calculate gas used in a transaction to be used as gasLimit. -- **Token Price Service**: For users to pay back the relayers in ERC 20 tokens, we need the prices for those tokens in comparison to the native token price. Token Price Service does just this and gets prices through Coin Market Cap API. -- **Types**: Type definitions that are to be used across various services go in here. -- **Utils**: Contains utility functions. - -### Server - -- **Relay**: Endpoint for relaying transactions. -- **Fee Options**: Endpoint for getting fee options. - -### Relayer - -- **Account**: An account can be a relayer address or the main funding account. -- **Consumer**: Consumers are actors that are responsible for consuming data from the queue and acting upon it, be it starting transaction processing or alerting the socket server. -- **Nonce manager**: Manages the nonces of various relayer addresses and main accounts by using cache and network service. -- **Relayer Manager**: One of the core components that takes care of creating relayers, funding them, maintaining relayer mappings and various relayer queues, and fetching the next active relayer from the relayer queue. -- **Relayer Queue**: A simple queue that has a list of relayers sorted basis on some pre-defined logic. Be it who has the maximum balance or least pending count. -- **Retry Transaction Service**: In case a transaction is not mined for a set time, the transaction is resubmitted again to the network by the same relayer and same nonce but at a bumped-up gas price. -- **Transaction Listener**: Once a transaction is sent on the chain, the state of the transaction is monitored by the transaction listener. It pushes to the retry transaction queue, and at the same time listens for transactions confirmed or failed on the chain and then saves the data in the database. -- **Transaction Publisher**: The transaction publisher is just an interface for the publishing queue of the transaction queue. -- **Transaction Service**: This service is responsible for creating the raw transaction by fetching gas prices, then using the network service to broadcast the transaction and notifies the transaction listener to monitor a particular transaction. diff --git a/versioned_docs/version-1.0/biconomy-contracts/Contracts/_category_.json b/versioned_docs/version-1.0/biconomy-contracts/Contracts/_category_.json deleted file mode 100644 index c4276108..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/Contracts/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Contracts", - "position": 4, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/biconomy-contracts/Contracts/common_contracts.md b/versioned_docs/version-1.0/biconomy-contracts/Contracts/common_contracts.md deleted file mode 100644 index c6a0aa48..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/Contracts/common_contracts.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -sidebar_position: 5 ---- - -# Common Contracts - -Smart contracts that extend Smart Account functionality - -**_Module Manager_** - -(https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/base/ModuleManager.sol) - -Module Manager allows to enable and disable modules. -Module Manager is also in charge of executing transactions coming from Modules on behalf of the Smart Account. - -#### What are modules? - -Modules add additional functionalities to the Smart Accounts. They are smart contracts that implement the Smart Account’s functionality while separating module logic from the core contract. Depending on the use case, modules could for instance allow the execution of transactions without requiring a signature confirmation. - -Modules can allow for Multisig access control, alternative signing schemes, such as passkeys, Social recovery, etc. - -**_FallbackManager_** - -(https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/base/FallbackManager.sol) - -A contract that manages fallback calls made to the Smart Account - -Fallback calls are handled by a `handler` contract that is stored at `FALLBACK_HANDLER_STORAGE_SLOT.` - -Fallback calls are not delegated to the `handler` so they can not directly change Smart Account storage. diff --git a/versioned_docs/version-1.0/biconomy-contracts/Contracts/helpers.md b/versioned_docs/version-1.0/biconomy-contracts/Contracts/helpers.md deleted file mode 100644 index 9097ecc1..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/Contracts/helpers.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -sidebar_position: 7 ---- - -# Helpers - -Set of helper contracts used by the Smart Account - -**_Multisend_** - -**MultiSend.sol** - -Allows to batch multiple transactions into one and reverts all if one fails. Relayer -> Smart Wallet - > MultiSend -> Dapp contract / contracts - -(https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/libs/MultiSend.sol) - -**MultiSendCallOnly.sol** - -MultiSend functionality but reverts if a transaction tries to do `delegatecall`. - -(https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/libs/MultiSendCallOnly.sol) - -**_Executor_** - -Executor.sol contract is a helper contract that is used by a [Module Manager](https://www.notion.so/Biconomy-Contracts-only-for-docs-purpose-138e3e989ecc42619a532f2045a89b48?pvs=21). It makes `calls` and `delegatecalls` to Dapp contracts on behalf of Smart Account Modules. - -(https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/base/Executor.sol) - -**_SecuredTokenTransfer_** - -A Secured Token Transfer contract is used to transfer ERC20 tokens from Smart Account to the Refund Receiver whenever the user pays gas from their assets. - -(https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/common/SecuredTokenTransfer.sol) diff --git a/versioned_docs/version-1.0/biconomy-contracts/Contracts/overview.md b/versioned_docs/version-1.0/biconomy-contracts/Contracts/overview.md deleted file mode 100644 index 4bf2b92b..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/Contracts/overview.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -Welcome to the Contracts section, where you'll find explanations and deep dives into the core contracts that power Biconomy's Smart Accounts. These contracts are at the heart of the magic that happens under the hood! - -All Biconomy Smart Accounts are proxies that delegate calls to a common implementation contract. - -The address of the implementation that is used by the proxy is stored in a storage slot with a location that matches the proxy address. - -The core contracts related to Smart Accounts are: - -1. **BaseSmartAccount.sol:** This abstract contract implements the `IAccount` Interface. - -2. **SmartAccountFactory.sol:** This contract is responsible for deploying smart wallets using `CREATE2` and `CREATE`. It has a method to compute the counterfactual address of the Smart Account before deploying. - -3. **SmartAccount.sol:** This contract inherits from `BaseSmartAccount.sol` and implements all the required functionality. It supports Account Abstraction (EIP-4337) flow and simple forward flow (Gnosis Safe style). - -4. **ModuleManager.sol:** This Gnosis Safe style module manager allows the activation and deactivation of modules and handles the transactions sent by modules. - -5. **DefaultCallbackHandler.sol:** This contract manages hooks to react to receiving tokens. diff --git a/versioned_docs/version-1.0/biconomy-contracts/Contracts/paymaster_contract.md b/versioned_docs/version-1.0/biconomy-contracts/Contracts/paymaster_contract.md deleted file mode 100644 index f1ef5d3f..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/Contracts/paymaster_contract.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -sidebar_position: 6 ---- - -# Paymaster Contract - -Manages gas payment on behalf of users - -A paymaster is a special contract in [Account Abstraction Flow](https://github.com/eth-infinitism/account-abstraction/blob/develop/eip/assets/eip-4337/image2.png) that acts like a Gas tank. **Paymasters** can sponsor transactions for other users. - -This feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with EIP-20 tokens, and many other use cases. When the paymaster is not equal to the zero address, the entry point implements a different [flow](https://github.com/eth-infinitism/account-abstraction/blob/develop/eip/assets/eip-4337/image2.png). - -## **_Types of Paymasters_** - -**_TokenPaymaster_** - -A Token-based paymaster. Each request is paid for by the caller in ERC20 tokens. - -**_VerifyingPaymaster_** - -Paymaster uses an external service to decide whether to pay for the UserOp. The paymaster trusts an external signer to sign the transaction. The calling user must pass the UserOp to that external signer first, which performs whatever off-chain verification before signing the UserOp. - -💡 The wallet owner still signs the user operation. - -- the paymaster signs to agree to PAY for GAS. -- the wallet signs to prove identity and wallet ownership. - -**_DepositPaymaster_** - -A token-based paymaster that accepts token deposits. The deposit is only a safeguard: the user pays with his token balance. A bundler can whitelist this type of Paymaster. - -💡 Biconomy currently supports VerifyingPaymaster through Paymasters-As-A-Service Dashboard. This is a Singleton Paymaster which implements the IPaymaster interface and manages gas tank accounting using depositor's paymasterIds. - -**_Biconomy Verifying Singleton Paymaster_** - -Derives from a Base Abstract Contract called [BasePaymaster](https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/paymasters/BasePaymaster.sol) which implements the IPaymaster interface mentioned below. - -**[scw-contracts/VerifyingSingletonPaymaster.sol at master · bcnmy/scw-contracts**GitHub](https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/paymasters/verifying/singleton/VerifyingSingletonPaymaster.sol) diff --git a/versioned_docs/version-1.0/biconomy-contracts/Contracts/proxy.md b/versioned_docs/version-1.0/biconomy-contracts/Contracts/proxy.md deleted file mode 100644 index 07bd9daf..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/Contracts/proxy.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -sidebar_position: 4 ---- - -# Proxy - -Smart Account Itself -(https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/Proxy.sol) - -It is a basic proxy that delegates all calls to a fixed implementation address. - -The implementation address is stored in the slot defined by the Proxy's address and is set at the Proxy deployment. - -It can be changed by calling `setImplementation` method. diff --git a/versioned_docs/version-1.0/biconomy-contracts/Contracts/smartaccount.md b/versioned_docs/version-1.0/biconomy-contracts/Contracts/smartaccount.md deleted file mode 100644 index 08ef8425..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/Contracts/smartaccount.md +++ /dev/null @@ -1,255 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Smart Account Contract - -Heart of the Biconomy SDK AA Eco-system - -This is the actual implementation of the Smart Account. - -It acts as a Singleton as it is deployed only once and all the actual user Smart Accounts are deployed as Proxies, which send delegatecalls to the Singleton Implementation. - -It inherits from theBaseSmartAccount.sol contract, that defines the EIP-4337 specified IAccount interface. It also implements function definitions, that are specified in the BaseAccount.sol - -You'll find the description of the most important functions and design choices below. - -### Constructor - -```javascript -constructor(IEntryPoint anEntryPoint) { - _self = address(this); - // By setting the owner it is not possible to call init anymore, - // so we create an account with fixed non-zero owner. - // This is an unusable account, perfect for the singleton - owner = address(0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE); - if (address(anEntryPoint) == address(0)) - revert EntryPointCannotBeZero(); - _entryPoint = anEntryPoint; - _chainId = block.chainid; - } -``` - -- \_self, chainId, and \_entryPoint are immutable storage variables. They are the cheapest to use, that's why we decided to store chainId instead of calling for it dynamically. -- Entry Point address is stored in the \_entryPoint variable and is immutable. That means every time there's a new Entry Point deployed, it will be required for Smart Accounts to upgrade to a new implementation that works with the new EP. Actually, introducing a new EP will be more like deploying the new hardfork, so it won't happen often. -- The owner is set not as address(0) but as some random address because ECDSA signature verification algorithm can return address(0) as a signer for some of the invalid signatures. - -1. **_init()_** - -Is the method for initializing the Smart Account proxy with initial states. It sets the owner address, and the fallback handler address. It also initiates the \_setupModules procedure. - -```javascript -function init(address _owner, address _handler) external virtual override { -if (owner != address(0)) revert AlreadyInitialized(address(this)); -if (_owner == address(0)) revert OwnerCannotBeZero(); -owner = _owner; -_setFallbackHandler(_handler); -_setupModules(address(0), bytes("")); - -} -``` - -2. **_handlePayment()_** - -Private method to be used to transfer ERC20 tokens from Smart Account to the refund receiver. Is used to perform gas payment with ERC20 tokens. - -```javascript -function handlePayment( -uint256 gasUsed, -uint256 baseGas, -uint256 gasPrice, -uint256 tokenGasPriceFactor, -address gasToken, -address payable refundReceiver -) private returns (uint256 payment) -``` - -#### Parametres - -| Name | Type | Description | -| ------------------- | ------- | -------------------------------------------------------------------------------------------------------- | -| gasUsed | uint256 | gas units to be accounted for fee calculation (passed on from main transactional method execTransaction) | -| baseGas | uint256 | gas units to be accounted for other actions | -| gasPrice | uint256 | gasPrice or tokenGasPrice | -| tokenGasPriceFactor | uint256 | indicates decimals of fee token | -| gasToken | address | address of the gas token (0x for native) | -| refundReceiver | address | refund receiver | - -#### Return Values - -| Name | Type | Description | -| ------- | ------- | ----------------------- | -| Payment | uint256 | gas token refund amount | - -There's also handlePaymentRevert function that always reverts with the gas amount that was spent to execute the potential refund. It is used to estimate gas usage of the refund procedure itself without actually sending the refund. - -3. **_execTransaction_S6W()_** - This is the main method to dispatch transactions from the Smart account to dApp's contracts using the owner's signature. Operates with the Safe (previously Gnosis Safe) style transactions with optional repayment in native tokens or ERC20 tokens. - -The name is optimized to make the function signature start with zeros, in order for it to be at the beginning of the routing table and allow for cheaper public calls. - -For consistency, there's also an execTransaction() function that just calls the execTransaction_S6W. - -```javascript -function execTransaction_S6W( - Transaction memory _tx, - FeeRefund memory refundInfo, - bytes memory signatures - ) public payable virtual nonReentrant returns (bool success) -``` - -#### Parameters - -```Javascript -struct Transaction { - address to; - uint256 value; - bytes data; - Enum.Operation operation; // call or delegate call - uint256 targetTxGas; // gasLimit for internal transaction - } - -struct FeeRefund { - uint256 baseGas; - uint256 gasPrice; //gasPrice or tokenGasPrice - uint256 tokenGasPriceFactor; - address gasToken; - address payable refundReceiver; - } -``` - -| Name | Type | Description | -| ---------- | ----------- | -------------------------------------------- | -| \_tx | Transaction | Smart Account transaction as described above | -| refundInfo | FeeRefund | as described above | -| signatures | bytes | required owner signature | - -#### Returns Success or Failure bool and Emits Following Events - -```javascript -event ExecutionFailure(address to, uint256 value, bytes data, Enum.Operation operation, uint256 txGas); -event ExecutionSuccess(address to, uint256 value, bytes data, Enum.Operation operation, uint256 txGas) -``` - -4. **_setOwner()_** - -Allows to rotate signing kets. Definition below: - -```javascript -function setOwner(address _newOwner) external mixedAuth -modifier mixedAuth { - require(msg.sender == owner || msg.sender == address(this),"Only owner or self"); - _; - } -``` - -mixedAuth is onlyOwner OR self (allows transaction from social recovery module via Guardians!) -modifier mixedAuth - -5. **_updateImplementation()_** - -Allows to update the implementation when called from a Proxy via delegatecall. New implementation must be a smart contract. - -```javascript -function updateImplementation(address _implementation) public virtual mixedAuth -``` - -6. **_checkSignatures()_** - -Checks whether the signature provided is valid for the provided data hash. Revert otherwise. - -Works with several types of signatures, such as: contract signatures, eth_sign derived signatures and regular ECDSA signatures. Used by the execTransaction() in a non-EIP-4337 flow. - -```javascript -function checkSignatures( - bytes32 dataHash, - bytes memory signatures - ) public view virtual -``` - -7. **_requiredTxGas()_** - -Allows to estimate a transaction. This method is only meant for estimation purpose, therefore the call will always revert and encode the result in the revert data. Biconomy SDK backend has the API to estimate gas using above method - -```javascript -function requiredTxGas( - address to, - uint256 value, - bytes calldata data, - Enum.Operation operation - ) external returns (uint256) -``` - -8. **_executeCall(), executeBatchCall()_** - -And their optimized names implementations: `executeBatchCall_4by` and `executeCall_s1m`. - -Are called by an Entry Point in a EIP-4337 flow to execute arbitrary transactions on behalf of the Smart Account. - -9. **_validateUserOp()_** - -Located in BaseSmartAccount.sol -Implements IAccount interface by EIP-4337. - -```javascript -function validateUserOp( - UserOperation calldata userOp, - bytes32 userOpHash, - uint256 missingAccountFunds - ) external virtual override returns (uint256 validationData) { - if (msg.sender != address(entryPoint())) - revert CallerIsNotAnEntryPoint(msg.sender); - validationData = _validateSignature(userOp, userOpHash); - if (userOp.initCode.length == 0) { - _validateAndUpdateNonce(userOp); - } - _payPrefund(missingAccountFunds); - } -``` - -10. **_\_validateSignature()_** - -Implements the template method of BaseAccount and validates the user's signature for a given operation. - -If the `calldata` field in the `UserOp` encodes the call to this Smart Account module, we pass the signature verification flow to the Module's `validateSignature` method. This design allows for alternative signing schemes, such as `secp256r1` (passkeys) and others. - -```javascript -function _validateSignature( - UserOperation calldata userOp, - bytes32 userOpHash - ) internal virtual override returns (uint256 validationData) { - // below changes need formal verification. - bytes calldata userOpData = userOp.callData; - if (userOpData.length > 0) { - bytes4 methodSig = bytes4(userOpData[:4]); - // If method to be called is executeCall then only check for module transaction - if (methodSig == this.executeCall.selector) { - (address _to, uint _amount, bytes memory _data) = abi.decode( - userOpData[4:], - (address, uint, bytes) - ); - if (address(modules[_to]) != address(0)) - return IModule(_to).validateSignature(userOp, userOpHash); - } - } - bytes32 hash = userOpHash.toEthSignedMessageHash(); - if (owner != hash.recover(userOp.signature)) - return SIG_VALIDATION_FAILED; - return 0; - } -``` - -11. **_isValidSignature()_** - -This function allows for signature verification according to [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271). - -This method can be called by off-chain entities to verify if the contract recognizes the provided signature as valid or not. That allows for a seamless login experience with signed messages like the one by OpenSea to be available for Smart Accounts as well. - -If there's an active module for this Smart Account that has got signature verification flow passed to, `_dataHash` and \*\*`_signature` will be passed to its `isValidSignature` method. This allows for alternative signing schemes not only in course of EIP-4337 `userOps` executions but for all kinds of Smart Account interactions with various dApps. - -```javascript -function isValidSignature( - bytes32 _dataHash, - bytes memory _signature - ) -``` diff --git a/versioned_docs/version-1.0/biconomy-contracts/Contracts/smartaccountfactory.md b/versioned_docs/version-1.0/biconomy-contracts/Contracts/smartaccountfactory.md deleted file mode 100644 index ccfeb808..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/Contracts/smartaccountfactory.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Smart Account Factory Contract - -Factory for deploying Smart Accounts as Proxies - -(https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/SmartAccountFactory.sol) - -It is a Factory contract that is responsible for deploying Smart Accounts using `CREATE2` and CREATE opcodes. - -It deploys Smart Accounts as proxies pointing to `basicImplementation` that is immutable for this factory. - -This allows keeping the same address for the same Smart Account `owner` on various chains via `CREATE2`. - -The Smart Account is initialized directly after its deployment with owner and callback handler info. - -**_getAddressForCounterFactualAccount()_** - -Returns an address for the Smart Account when it will be deployed by this factory with the same `_owner` and `_index` values. `_index` serves as a salt to be able to deploy several Smart Accounts for the same user from this factory. - -```javascript -function getAddressForCounterFactualAccount( - address _owner, - uint256 _index - ) external view returns (address _account) -``` - -**_deployCounterFactualAccount()_** - -Deploys Smart Account with `CREATE2` and returns its address. - -```javascript -function deployCounterFactualAccount( - address _owner, - uint256 _index - ) public returns (address proxy) -``` - -**_deployAccount()_** - -Deploys account using `CREATE` (thus it deploys with a random address, rather than a counterfactual). - -```javascript -function deployAccount(address _owner) public returns (address proxy) -``` diff --git a/versioned_docs/version-1.0/biconomy-contracts/_category_.json b/versioned_docs/version-1.0/biconomy-contracts/_category_.json deleted file mode 100644 index 107e68c4..00000000 --- a/versioned_docs/version-1.0/biconomy-contracts/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Biconomy Contracts", - "position": 8, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/build-w-bico/_category_.json b/versioned_docs/version-1.0/build-w-bico/_category_.json deleted file mode 100644 index 639cc9ca..00000000 --- a/versioned_docs/version-1.0/build-w-bico/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Build with Biconomy SDK", - "position": 3, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/build-w-bico/batch-txn.md b/versioned_docs/version-1.0/build-w-bico/batch-txn.md deleted file mode 100644 index 161449cd..00000000 --- a/versioned_docs/version-1.0/build-w-bico/batch-txn.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -sidebar_position: 4 ---- - -# Batch Transactions - -Evolving from simple externally owned accounts (EOAs) to contract-based accounts enables a lot of advantages and features. One such feature that is only available for smart contract-based accounts is batched transactions. Batched transactions allow users of the wallet to perform multiple transactions in one single on-chain transaction. - -There are a number of advantages to batching many transactions into a single transaction. - -One advantage is that of efficiency — batched transactions save both in cost and time. Each transaction on Ethereum costs 21,000 gas as a base fee. Provide your users with incremental gas savings by enabling batches of transactions at once. - -Additionally, a user can save time and experience less friction when attempting to send sequential transactions. - -If you wish to skip the explanation of how batched transactions work via BiconomySDK, you can directly navigate to Enable Batch Transactions within your dApp. - -## Flow Explained - -![batch-1](img/batch-1.png) - -Batched transactions also allow for an enhanced user experience. An obvious example is removing the need to call both approve and transferFrom on an ERC20 token in two separate transactions. This leads to dApp developers designing their dApps with a more familiar web 2.0 feel — no need to explain the intricacies of the blockchain and perform all required steps in a single button. - -There is no need to modify existing contracts in order to be able to access batched transactions. Smart Contract Wallet calls the MultiSendCall contract (with delegatecall) by preparing the call data on execTransaction or execFromEntryPoint methods, where to address is multiSend's address and data is a batch of transactions encoded as bytes. - -When implementing this, one must consider a potential failed transaction. A well-designed implementation will check for the return status of the call and fail the entire batched transaction if any of the calls fail. With this implementation, the transaction would fail atomically (all or nothing) and save users from unintended consequences, such as approved tokens that go unspent. - -Transaction batching also helps mitigate MEV in case you are doing high-volume DeFi trades. This helps avoid the transaction being front-run for extracting value. - -In order to enable this flow, please check out our Guide to Enabling Batched Transactions (React). diff --git a/versioned_docs/version-1.0/build-w-bico/fiat.md b/versioned_docs/version-1.0/build-w-bico/fiat.md deleted file mode 100644 index 2a1ab57a..00000000 --- a/versioned_docs/version-1.0/build-w-bico/fiat.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Fiat On-Ramp & Off-Ramp - -## Seamless Fiat On-Ramp & Off-Ramp Integration - -We've partnered with leading fiat On-Ramp & Off-Ramp service providers, to offer a seamless integration of fiat-to-crypto and crypto-to-fiat transactions. With their developer integration toolkits, users can now buy or sell crypto directly within any app, website, or web plugin. -By leveraging these providers, users can avoid the hassle of multiple separate transactions and the complexity of on/off-ramping for different assets. It streamlines the process and provides a convenient experience for handling their crypto holdings. Please note that KYB (Know Your Business) requirements may apply separately when working with the on-ramp provider to ensure compliance with regulations. - -## Our preferred onramp partners - -| Fiat Onramp | Otlier factor | Quick Guides | Supported Currencies | API Integration | KYC Required | -| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------- | --------------- | :----------- | -| Ramp Network | global coverage on/off-ramp, most payment methods & currencies, best Ux with Native integration, lowest user fees, high conversion rates | [Technical Docs](https://docs.ramp.network/), [Off-ramp Demo Video](https://www.youtube.com/watch?v=KSXgmRpl_Pg) | [List](https://support.ramp.network/en/articles/471-supported-fiat-currencies) | Yes | Yes | -| Transak | Best rates globally, **native integration** for all products with Biconomy SDK | [Demo UI](https://transak-biconomy.netlify.app/), [Demo Video](https://www.loom.com/share/90d1473db6cd44879a24c3407bf39789), [Technical Docs](https://docs.biconomy.io/guides/enable-fiat-on-ramp-and-off-ramp) | [List](https://docs.transak.com/docs/fiat-currency-country-payment-method-coverage-plus-fees-and-limits) | Yes | Yes | -| Poko | Best for games, Onramp Aggregator, Strong and wide support for Alternative Payment Methods (APMs) | [Demo Video](https://www.loom.com/share/f3eac5212cb443ed8f9f5e849ccd9287), [Technical Docs](https://pokoapp.gitbook.io/documentation/other-resources/how-to-get-onboarded) | [List](https://docs.pokoapp.xyz/onramp-aggregator/country-and-payment-method-coverage) | Yes | Yes | - -If you wish to skip explaining how fiat on-ramp or off-ramp works, you can directly navigate to Enable Fiat On-Ramp & Off-Ramp with Transak. - -## User Flow - -### On-Ramp Flow - -The user is redirected to the buy crypto page, where they go through the following steps: - -1. The user places an order in their preferred fiat for their chosen crypto and selects a payment method. -2. If this is the user's first time buying through the service provider, the user goes through the provider's KYC process. -3. The service provider takes a fiat payment from the user. -4. The service provider converts the fiat to crypto and sends it to the user's smart contract wallet. -5. The user now has the crypto they need to use your dApp. - -### Off-Ramp Flow - -After integrating with the Off-Ramp service, a user must follow several steps to liquidate their crypto holdings: - -1. First-time users need to go through a simple one-time KYC process. -2. After this, users can complete the crypto payment from their smart contract wallet whenever they want to liquidate their crypto holdings. -3. Behind the scenes, the service provider reconciles the crypto payment made by the user and transfers the equivalent fiat in the chosen currency to the user's bank account, all within a few minutes. - -**If your bank does not support Instant bank transfers, it may take 24-48 hours. For some cryptocurrencies, the minimum buy amount may be greater due to the minimum withdrawal limit of partner exchanges.** diff --git a/versioned_docs/version-1.0/build-w-bico/gasless-txn.md b/versioned_docs/version-1.0/build-w-bico/gasless-txn.md deleted file mode 100644 index b709a525..00000000 --- a/versioned_docs/version-1.0/build-w-bico/gasless-txn.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Gasless Transactions - -Users must possess chain native tokens to interact with a dApp on any chain. For example, anyone who wants to send an Ethereum transaction needs to have Ether pay for its gas fees. This forces new users to purchase these crypto tokens before they can start using a dApp. This is a major hurdle in user onboarding which can be mitigated by enabling gas sponsorship within your dApp. - -In the Biconomy SDK, gasless transactions happen in a non-custodial manner via [Account Abstraction](https://coinmarketcap.com/alexandria/glossary/account-abstraction). In this mechanism, there is a Paymaster contract that acts like a 'Gas Tank'. All you need to do is deposit funds into the Paymaster & whitelist your dApp contracts to enable gas abstraction within your dApp. - -If you wish to skip the explanation of how gasless transactions work via BiconomySDK, you can directly navigate to: - -1. Register dApp On Dashboard & Deposit Gas -2. Enable Gasless Transactions using Biconomy SDK (React) - -## Flow Explained - -![GT-1](img/gt-1.png) - -In this case, dApp is sponsoring the transaction gas fee using gasless transaction using the concept of paymasters as mentioned in [EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) (Account Abstraction). - -EIP-4337 proposal introduces a higher-layer pseudo-transaction object called a `UserOperation`. Users send UserOperation objects into a separate mempool. A special class of actors called _bundlers_ (either miners, or users that can send transactions to miners through a bundle marketplace) package up a set of these objects into a transaction making a `handleOps` call to a special contract, and that transaction then gets included in a block. - -- **UserOperation** - a structure that describes a transaction to be sent on behalf of a user. - - Like a transaction, it contains “sender”, “to”, “calldata”, “maxFeePerGas”, “maxPriorityFee”, “signature”, “nonce” - - Unlike transactions, it contains several other fields - - Also, the “nonce” and “signature” field's usage is not defined by the protocol, but by each account implementation -- **Sender** - the account contract sending a user operation. -- **EntryPoint** - a singleton contract to execute bundles of UserOperations. - -Users send `UserOperation` objects to **bundlers** (in this case, Biconomy's relayers act as bundlers). Bundlers pick `UserOperation` and create **bundle transactions**. A bundle transaction packages up multiple `UserOperation` objects into a single `handleOps` call to a pre-published global **Entry Point contract.** - -**Paymasters** are contracts that can be used by dApps to sponsor gas fees for users. For enabling gasless you can use the pre-deployed `BiconomyVerifyingPaymaster`. It is pre-configured and ready to use. You will only have to deposit tokens which will be used for gas sponsorship. This amount in case it hasn't been used can be withdrawn by the dApp at any point. - -Here how the transaction flow looks like: - -- The user initiates a transaction and provides their signature via Biconomy SDK. -- The signature is sent to a Relayer(Bundler), which then posts the transaction on-chain via an Entry Point contract. Entry Point does signature verification and uses paymaster to recover the gas fee from dApp’s deposit (Paymaster is essentially dApp’s on-chain Gas Tank). - -The paymaster scheme allows a contract to passively pay on users’ behalf under arbitrary conditions. You can specify these conditions - calls to certain or all methods of a contract can be whitelisted on the dashboard. - -You can start by Registering your dApp on the Dashboard. Here you will also be able to fund the gas tank & whitelist contracts. Then you can Enable Gasless Transactions using Biconomy SDK (React). - -## Supported Chains - -- Ethereum Mainnet -- Polygon Mainnet -- BSC Mainnet -- Polygon ZkEvm Mainnet -- Arbitrum One Mainnet -- Arbitrum Nova Mainnet -- Goerli Testnet -- Polygon Testnet -- BSC Testnet -- Polygon ZkEVM Testnet -- Arbitrum Goerli Testnet - -:::info -If you wish to enable gasless transactions within your dApp for only EOAs & in a custodial way, please check out our guide to [Enable Gasless via Meta-Transactions.](https://docs-gasless.biconomy.io/products/enable-gasless-transactions) -::: diff --git a/versioned_docs/version-1.0/build-w-bico/img/batch-1.png b/versioned_docs/version-1.0/build-w-bico/img/batch-1.png deleted file mode 100644 index 74561c5e..00000000 Binary files a/versioned_docs/version-1.0/build-w-bico/img/batch-1.png and /dev/null differ diff --git a/versioned_docs/version-1.0/build-w-bico/img/gt-1.png b/versioned_docs/version-1.0/build-w-bico/img/gt-1.png deleted file mode 100644 index 44102b26..00000000 Binary files a/versioned_docs/version-1.0/build-w-bico/img/gt-1.png and /dev/null differ diff --git a/versioned_docs/version-1.0/build-w-bico/img/particle-1.png b/versioned_docs/version-1.0/build-w-bico/img/particle-1.png deleted file mode 100644 index b15ad6a3..00000000 Binary files a/versioned_docs/version-1.0/build-w-bico/img/particle-1.png and /dev/null differ diff --git a/versioned_docs/version-1.0/build-w-bico/img/web3-1.png b/versioned_docs/version-1.0/build-w-bico/img/web3-1.png deleted file mode 100644 index eb088ded..00000000 Binary files a/versioned_docs/version-1.0/build-w-bico/img/web3-1.png and /dev/null differ diff --git a/versioned_docs/version-1.0/build-w-bico/img/web3-2.png b/versioned_docs/version-1.0/build-w-bico/img/web3-2.png deleted file mode 100644 index e4d80a27..00000000 Binary files a/versioned_docs/version-1.0/build-w-bico/img/web3-2.png and /dev/null differ diff --git a/versioned_docs/version-1.0/build-w-bico/social-login/_category_.json b/versioned_docs/version-1.0/build-w-bico/social-login/_category_.json deleted file mode 100644 index 814ad313..00000000 --- a/versioned_docs/version-1.0/build-w-bico/social-login/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Social Login", - "position": 1, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/build-w-bico/social-login/overview.md b/versioned_docs/version-1.0/build-w-bico/social-login/overview.md deleted file mode 100644 index dade8ec7..00000000 --- a/versioned_docs/version-1.0/build-w-bico/social-login/overview.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -Web3 applications often necessitate a Web3 wallet for authentication or login. However, this requirement can pose a barrier to new users who are unfamiliar with wallets. Therefore, the integration of traditional social sign-in with Web3 login can significantly enhance user onboarding and experience. - -We collaborate with Web3 authentication providers like Web3Auth and Particle Network to offer social login via our SDK. Our non-custodial social login flow greatly improves user experience and onboarding. Users always maintain control over ownership and access to their cryptographic key pair. If you have an existing user base, it's easy to plug in and use. No migration is necessary. - -## Social Logins in General - -Social logins have become a popular method for user authentication due to their convenience and ease of use. They allow users to authenticate themselves using their existing social media accounts, eliminating the need to remember another username and password. This not only simplifies the login process but also speeds up the registration process, as users don't need to fill out a registration form. - -In the context of Web3 applications, social logins can be used to generate a unique private key for each user. This private key can then be used to sign transactions, allowing users to interact with the blockchain without needing to understand the complexities of managing a blockchain wallet. - -## Flow Explained - -Users can log in to your dApp either via social login or by connecting their external wallet. In social login, they may sign in via Google, Facebook, or email. A unique private key is generated for each user via the Web3 authentication provider. Using this key, users can sign transactions without wallet pop-ups or context switching. As long as the email is the same, the same account will be generated for all social accounts. - -:::note -**Please Note**: We do not store any private keys. -::: - -## Modular SDK - -Our SDK is designed to be highly modular and versatile. It can be easily integrated with any social login provider, giving you the flexibility to choose the provider that best suits your needs. However, we recommend using either Particle Network or Web3Auth, as these providers offer robust and secure solutions for Web3 authentication. By using our SDK, you can leverage the benefits of social logins to provide a seamless and user-friendly experience for your users. diff --git a/versioned_docs/version-1.0/build-w-bico/social-login/particle-auth.md b/versioned_docs/version-1.0/build-w-bico/social-login/particle-auth.md deleted file mode 100644 index 8f5ffcc5..00000000 --- a/versioned_docs/version-1.0/build-w-bico/social-login/particle-auth.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Using Particle Auth - -## What is Particle Auth？ - -Particle Auth is a simple self-custodial auth infra for Web3 apps and wallets. We support mobile number and email login, providing users with a simple operating experience. Their login account is then associated with a blockchain wallet, which is secured with a "Threshold Signatures vault". - - - -## Why Particle Auth? - -Particle Auth is committed to helping Web2 users enter the Web3 world easily with their most familiar login methods. - -Users can log in to your dApp through **Google, Apple ID, Facebook, Twitter, and other social methods**, and can also log in with an **Email / Mobile number** without a password. - -After the user successfully logs in, Particle Auth will automatically create a crypto wallet without a private key. The security is guaranteed by **MPC (Multi-Party Computing) - based threshold signatures,** which is ahead of other technologies. - -![Particle-1](../img/particle-1.png) - -In order to enable this flow, please check out our guide to enable Particle Auth within your dApp. - -## Demo Videos - -1. [Social Login & Batch Swap & USDC Pay Gas](https://www.loom.com/share/fef39d36b0e44354a603010c8f987f7c) -2. [Gasless Send NFT](https://www.loom.com/share/599f85f5339346acb82b7ee5a5325a74) -3. [Turn MetaMask to AA Wallet - Batch Swap & USDT Pay Gas](https://www.loom.com/share/16c46ef473264b4683798783d9c16b3c) -4. [Buy NFT from OpenSea](https://www.loom.com/share/3ff3db497c244e5e99db2b1448a86d16) - -## FAQs related to Particle Auth and Key Management - -Please refer to the Web3 Auth Key Management docs to know more about the inner workings of Torus Network: - -https://docs.particle.network/developers/faq diff --git a/versioned_docs/version-1.0/build-w-bico/social-login/web3-auth.md b/versioned_docs/version-1.0/build-w-bico/social-login/web3-auth.md deleted file mode 100644 index 5f639615..00000000 --- a/versioned_docs/version-1.0/build-w-bico/social-login/web3-auth.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Using Web3Auth (Torus) - -Web3Auth is an innovative, pluggable authentication infrastructure designed for Web3 wallets and applications. It significantly simplifies user onboarding by providing familiar experiences and supporting a wide range of login methods. Whether your users are mainstream or crypto-native, Web3Auth can get them onboarded in under a minute. - -## How Does Web3Auth Work? - -Web3Auth supports all social logins, web & mobile native platforms, wallets, and other key management methods. It generates a standard cryptographic key specific to the user and application, ensuring secure and personalized access. - -Here's a step-by-step breakdown of the Web3Auth flow: - -1. **User Initiation**: The user starts the process and is redirected to the Web3Auth portal (app.openlogin.com). -2. **Initial Login Process**: The Web3Auth portal handles the initial login process. -3. **Authentication with OAuth Provider**: The user is redirected to their chosen login/OAuth provider and completes the authentication process. -4. **Key Reconstruction**: The user is redirected back to the Web3Auth portal, which handles the reconstruction of the user’s key. -5. **Successful Authentication**: Once the user is successfully authenticated, they are redirected back to the application, equipped with a derived key specific to the application/wallet. - -![Web3 Auth-1](../img/web3-1.png) - -## Key Management Infrastructure - -Web3Auth introduces a multi-factor account-like approach to key management. Users leverage OAuth logins, devices, and other factors to manage their key pairs. The private key is mathematically divided into parts (the "shares"), which can only reconstruct the key when a sufficient number of shares are combined. Each share individually reveals no information about the private key. - -Here's an example setup with three shares: - -1. **Device Share**: Stored on the user's device. The implementation is device and system-specific. For instance, on mobile devices, the share could be stored in device storage secured via biometrics. -2. **OAuth Login Share**: Managed by a login service via node operators. This share is further split amongst a network of nodes and retrieved via conventional authentication flows. -3. **Backup/2FA Share**: Acts as a recovery share. It's an extra share kept by the user, possibly on a separate device, downloaded, or based on user input with enough entropy (e.g., password, security questions, hardware device, etc.). - -![Web3-2](../img/web3-2.png) - -Similar to existing 2FA systems, a user must prove ownership of at least 2 out of 3 shares to retrieve their original private key and use it to sign transactions. - -To enable this flow, please check out our guide to Enable Social Logins within your dApp. - -## Demos - -1. [Integrating Web3Auth with Biconomy AA SDK by Nader Dabit (DeveloperDAO)](https://www.youtube.com/watch?v=qBPoVs66CxE) - -## For FAQs related to Web3Auth and Key Management - -Please refer to the Web3Auth Key Management docs to learn more about the inner workings of the system: [Web3Auth Key Management](https://web3auth.io/docs/overview/key-management/) diff --git a/versioned_docs/version-1.0/faq.md b/versioned_docs/version-1.0/faq.md deleted file mode 100644 index bdfd9d61..00000000 --- a/versioned_docs/version-1.0/faq.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -sidebar_position: 10 ---- - -# Frequently Asked Questions - -**Q. Will the SC Wallet (Smart Account) creation add extra steps for users before interacting with the dApp?** - -Wallet addresses are counterfactual in nature. Thus SCW address can be generated without actually deploying the smart contract on-chain and can be shown immediately. The smart contract is deployed along with sending the first user's transaction. - -

- -**Q. Who is in control of the wallet?** - -The owner of the wallet is the only signatory to authorize transactions. No transactions of value can be done via the Smart Account without the owner’s signature. Modules added by the owner are in control of the wallet within their defined specific logic. - -

- -**Q. What will the SCW integration look like on dApp’s front end? How much effort will apps need to put to integrate?** - -Besides the WalletConnect method, Biconomy SDK will provide a customizable widget that makes interactions for end users easy and in place. - -

- -**Q. What does wallet creation cost?** - -All wallets are copies of the implementation contract with their own states and are created as proxies. That means Smart Account creation consumes only a small amount of gas thus it is cheap. The actual cost varies depending on the chain. - -

- -**Q. Which ERC20 Tokens are supported as payments?** - -Biconomy relayers will initially support payments in stablecoins. In the future, dApps can also participate in a relayer network and collect fees in tokens of their choice. diff --git a/versioned_docs/version-1.0/guides/_category_.json b/versioned_docs/version-1.0/guides/_category_.json deleted file mode 100644 index 72a8c3ff..00000000 --- a/versioned_docs/version-1.0/guides/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Guides", - "position": 4, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/guides/bico-particle.md b/versioned_docs/version-1.0/guides/bico-particle.md deleted file mode 100644 index 12d6dfb0..00000000 --- a/versioned_docs/version-1.0/guides/bico-particle.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -sidebar_position: 5 ---- - -# Biconomy + Particle Auth - -> Make transactions using @biconomy/particle-auth - -Particle Auth provides MPC (Multi-Party Computation)-based threshold signatures. This integration provides the auth module with the smart-account package combined. - -## Code example - -- https://github.com/bcnmy/sdk-examples/tree/master/react-vite-particle-auth -- https://docs.particle.network/developers/account-abstraction/web-sdk -- https://github.com/Particle-Network/particle-web-demo - -## Installation - -Install and import the package from the Biconomy SDK - -```bash -yarn add @biconomy/particle-auth -// or -npm install @biconomy/particle-auth -``` - -Can initiate the social login using the code snippet shared below. - -:::info -You will need to get the particle keys from the Particle Dashboard. -::: - -```js -import { - ParticleAuthModule, - ParticleProvider, - BiconomyAccountModule, -} from "@biconomy/particle-auth"; - -const particle = new ParticleAuthModule.ParticleNetwork({ - projectId: "", // get it from particle dashboard - clientKey: "", // get it from particle dashboard - appId: "", // get it from particle dashboard - chainName: "Ethereum", //optional: current chain name, default Ethereum. - chainId: 5, //optional: current chain id, default 1. - wallet: { - //optional: by default, the wallet entry is displayed in the bottom right corner of the webpage. - displayWalletEntry: true, //show wallet entry when connect particle. - defaultWalletEntryPosition: ParticleAuthModule.WalletEntryPosition.BR, //wallet entry position - uiMode: "dark", //optional: light or dark, if not set, the default is the same as web auth. - supportChains: [ - { id: 1, name: "Ethereum" }, - { id: 5, name: "Ethereum Goerli" }, - ], // optional: web wallet support chains. - customStyle: {}, //optional: custom wallet style - }, -}); -``` - -Now can trigger the social login using - -````js -const connect = async () => { - try { - const userInfo = await particle.auth.login(); - console.log("Logged in user:", userInfo); - const particleProvider = new ParticleProvider(particle.auth); - const ethersProvider = new ethers.providers.Web3Provider( - particleProvider, - "any" - ); - const accounts = await ethersProvider.listAccounts(); - console.log("Logged in user:", accounts[0]); - } catch (error) { - console.error(error); - } -};``` - -To create Biconomy smartAccount transactions. - -:::info -To sponsor transactions you will need to generate the dapp api key from the [Biconomy dashboard.](https://dashboard.biconomy.io/) -::: - -```js -const getSmartAccount = async () => { - if (particle.auth === undefined) return; - const particleProvider = new ParticleProvider(particle.auth); - const wallet = new BiconomyAccountModule.SmartAccount(particleProvider, { - projectId: "", // get it from particle dashboard - clientKey: "", // get it from particle dashboard - appId: "", // get it from particle dashboard - networkConfig: [ - { - dappAPIKey: "", // get it from biconomy dashboard - chainId: 5, - }, - ], - }); - // AA address - const address = await wallet.getAddress(); - setScwAddress(address); - setSmartAccount(wallet); - // EOA address - const address = await smartAccount.getOwner(); - // load account more info. - const accountInfo = await smartAccount.getAccount(); -}; - -const doAATX = async () => { - const nftInterface = new ethers.utils.Interface([ - "function safeMint(address _to)", - ]); - const data = nftInterface.encodeFunctionData("safeMint", [scwAddress]); - const nftAddress = "0xdd526eba63ef200ed95f0f0fb8993fe3e20a23d0"; // test nft contract for goerli and mumbai - const tx = { - to: nftAddress, - data: data, - value: 0, - }; - const wrapProvider = new BiconomyAccountModule.BiconomyWrapProvider( - smartAccount, - BiconomyAccountModule.SendTransactionMode.Gasless - ); - const provider = new ethers.providers.Web3Provider(wrapProvider, "any"); - const signer = provider.getSigner(); - const txResponse = await signer.sendTransaction(tx); - console.log("Tx Response", txResponse); - const txReciept = await txResponse.wait(); - console.log("Tx hash", txReciept.transactionHash); -}; -```` - -DONE! You just sent a gasless transaction with social login. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/dashboard.md b/versioned_docs/version-1.0/guides/dashboard.md deleted file mode 100644 index 025cf7ed..00000000 --- a/versioned_docs/version-1.0/guides/dashboard.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Biconomy Dashboard - -The Biconomy Dashboard enables organisations and developers to leverage Account Abstraction stack in their projects. You can configure your project to pay gas fees for your users through Paymasters, add conditions for gas sponsorship. By registering your paymaster for any of the supported chains, you can begin simplifying the Web3 experience for your users. - -The instructions below will walk you through the following: - -1. Creating an account on the Biconomy Dashboard -2. Registering your paymaster on the dashboard -3. Setting up a Gas Tank -4. Whitelisting your contracts and methods - -**In order to use the Biconomy SDK in your project, it is important to complete all four steps mentioned above.** - -## Let’s Get Started - -### Create an Account or Login to the Biconomy Dashboard - -- Register your account on the dashboard here: https://dashboard.biconomy.io -- Once registered, you will see the dashboard homepage, as shown in the figure below: - ![Dash-1](img/dash-1.png) - -### Register your Paymaster on the Dashboard - -- On the top right of the homepage, you will see a button labeled **Register new Paymaster**. Clicking that will open the registration modal pictured below. - ![Dash-2](img/dash-2.png) - -- Create a **name** for your Paymaster and select a **chain** as shown in the figure below, and click **Add new Paymaster** once completed. -- Now that you have registered your Paymaster, you will be redirected to the Paymaster main page. -- On the Paymaster main page, you can see your Paymaster **API key**, **chain** your Paymaster is connected to, and a **set up gas tank** button, as shown below. - ![Dash-3](img/dash-3.png) - -### Setting up a Gas Tank - -Gas Tank is another term for Paymaster. We have created a Singleton Verifying Paymaster for you, so you don't need to deploy a new Paymaster. We handle its stake on the EntryPoint contract, so you don't have to worry about these things. Check out the [code here](https://github.com/bcnmy/scw-contracts/blob/master/contracts/smart-contract-wallet/paymasters/verifying/singleton/VerifyingSingletonPaymaster.sol). - -To enable gas-free transactions in your dPaymasterApp, **Gas Tanks** must be utilised. The Dashboard enables you to create your own Gas Tank, fund it, and withdraw gas as needed in a secure and non-custodial manner. Gas Tanks should be thought of as separate from Paymaster; they are a deposit and withdrawal location for gas that can be used in multiple Paymaster to cover gas fees. The conditions for sponsoring the gas are linked to your Paymaster. - -### Steps to set up your Gas Tank - -- Once you click on **setup gas tank**, you will see a connect wallet button. Setting up a gas tank requires you to have a decentralised wallet with some native tokens balance on the chain your Paymaster is registered on. -- Once you click on **connect wallet**, you will see different wallets that can be connected to top up your gas tanks as seen below. - ![Dash-4](img/dash-4.png) - -- Once your wallet is connected. you will see your connected **wallet address**. -- Note: Please be aware that the address you used to connect during these steps is the only address that will have the ability to withdraw funds from this gas tank in the future. -- Check off the **I Understand** icon and click **Set up gas tank**. You will be asked to sign a message from your wallet. As you are only **signing**, this is not a blockchain transaction. - ![Dash-5](img/dash-5.png) - -- Now that your gas tank is setup successfully you will be redirected to the **Deposit** flow. -- The current state of your Gas Tank should look like the image below. - ![Dash-6](img/dash-6.png) - -### Deposit Gas - -- Your Paymaster currently has an active Gas Tank, but it needs to be topped up in order to sponsor gasless transactions. -- You will need to ensure that you have Native tokens of your selected chain in the gas tank. -- Enter the desired funds you wish to deposit in the **Deposit amount** input field and press **Deposit** button as pictured below. After hitting the deposit button this will trigger a transaction in your connected wallet. - ![Dash-7](img/dash-7.png) - -- Once your transaction confirms on-chain, you will be able to see it in the **transaction** section, and your gas tank balance will be updated with your deposit amount. - ![Dash-8](img/dash-8.png) - -### Withdrawing Gas - -After depositing funds you may want to withdraw any remaining funds in the future.:::info -Please note that only the initial wallet you used to sign and connect to this gas tank can make withdrawals. -::: - -Make sure to connect with the same wallet that you have used during the setup of the gas tank. - -- Once you click withdraw tab you will see the following screen as shown below. - ![Dash-9](img/dash-9.png) -- You can enter a specific amount to withdraw in the **Withdraw amount** input field, or you can choose a percentage of funds to withdraw. -- After clicking "withdraw," you will need to sign the transaction from your wallet. Once the transaction is confirmed on the chain, the funds will be transferred to your wallet. -- Once the transaction is confirmed on-chain, you will see the following screen displaying the on-chain transaction details. - ![Dash-10](img/dash-10.png) - -## Whitelisting your contract and methods - -Whitelisting contracts in the Biconomy dashboard provides a security layer that gives the Paymaster owner more control over transaction sponsorship. Even if the Paymaster is sponsoring user transactions, users will not be able to execute any arbitrary transactions and have them sponsored by the gas tank. Transactions can only be sponsored for contracts that the Paymaster owner has whitelisted. If the Paymaster owner hasn't whitelisted any contract, then only native token transfer transactions can be sponsored. - -### Steps to Whitelist your Contract - -- Once you click on your Paymaster, you will see the **Add smart contract** button under the contracts tab, as shown below - ![Dash-11](img/dash-11.png) -- The modal pictured below will appear after clicking the **Add smart contract** button. -- Now add the name of the smart contract. It is not necessary to use the original contract name, any name can be used. -- Next, you are required to enter the contract address that you wish to whitelist. If the contract is verified, the system will automatically populate the ABI in the corresponding field. If it is not verified you can manually paste in your ABI. -- Now, you can select the methods you want to whitelist for this specific contract and press **Add Smart Contract** button. Only these selected contract methods can be sponsored by the gas tank. -- In the example pictured below, we have whitelisted the USDC contract and only selected the transfer function call to be sponsored by the gas tank. - ![Dash-12](img/dash-12.png) - -After completing the whitelisting process, your whitelisted contract details will be displayed under the "Contracts" tab. You will be able to edit, delete, activate, or deactivate any of the whitelisted contracts using the controls located under each contract, as shown in the figure below. -![Dash-13](img/dash-13.png) - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/enable-fiat.md b/versioned_docs/version-1.0/guides/enable-fiat.md deleted file mode 100644 index 8808d032..00000000 --- a/versioned_docs/version-1.0/guides/enable-fiat.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -sidebar_position: 6 ---- - -# Enable Fiat On-Ramp & Off-Ramp - -BiconomySDK's Transak library is made for developers who just want on-ramp and off-ramp solutions and don't want to go through with all steps to integrate the SDK. - -It is a typescript wrapper on `transak.js` SDK which abstracts a few steps for the developers and users. - -## Steps to Enable Fiat On-Ramp & Off-Ramp - -- Import the `@biconomy-sdk/transak` package into your project. - -```js -import Transak from "@biconomy/transak"; -``` - -- Initialize the project without going to any dashboard - -```js -// init the widget -const transak = new Transak("STAGING"); -transak.init(); -``` - -- If you are using Fiat On Ramp then you can directly pass in the email like so: - -```js -import Transak from "@biconomy/transak"; - -// use this info for transak package -const transak = new Transak("STAGING", { - walletAddress: userAddress, - userData: { - firstName: userInfo?.name || "", - email: userInfo?.email || "", - }, -}); -transak.init(); -``` - -- On `transak.init()` Transak widget opens and users can buy on-ramp. - ![Fiat-1](img/fiat-1.png) - -## Code Examples - -- https://github.com/bcnmy/sdk-demo -- https://github.com/bcnmy/hyphen-ui/tree/demo-sdk - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/img/dash-1.png b/versioned_docs/version-1.0/guides/img/dash-1.png deleted file mode 100644 index 0804670d..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-1.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-10.png b/versioned_docs/version-1.0/guides/img/dash-10.png deleted file mode 100644 index f89a75e1..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-10.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-11.png b/versioned_docs/version-1.0/guides/img/dash-11.png deleted file mode 100644 index 660d3313..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-11.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-12.png b/versioned_docs/version-1.0/guides/img/dash-12.png deleted file mode 100644 index 0675ee1c..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-12.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-13.png b/versioned_docs/version-1.0/guides/img/dash-13.png deleted file mode 100644 index 3eaf1d5a..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-13.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-2.png b/versioned_docs/version-1.0/guides/img/dash-2.png deleted file mode 100644 index e4a400a4..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-2.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-3.png b/versioned_docs/version-1.0/guides/img/dash-3.png deleted file mode 100644 index fba9679b..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-3.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-4.png b/versioned_docs/version-1.0/guides/img/dash-4.png deleted file mode 100644 index ee9d970c..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-4.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-5.png b/versioned_docs/version-1.0/guides/img/dash-5.png deleted file mode 100644 index af05ddd3..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-5.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-6.png b/versioned_docs/version-1.0/guides/img/dash-6.png deleted file mode 100644 index ad5e1769..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-6.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-7.png b/versioned_docs/version-1.0/guides/img/dash-7.png deleted file mode 100644 index 45c2cc0c..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-7.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-8.png b/versioned_docs/version-1.0/guides/img/dash-8.png deleted file mode 100644 index 836bf4fc..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-8.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/dash-9.png b/versioned_docs/version-1.0/guides/img/dash-9.png deleted file mode 100644 index 5f211c76..00000000 Binary files a/versioned_docs/version-1.0/guides/img/dash-9.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/img/fiat-1.png b/versioned_docs/version-1.0/guides/img/fiat-1.png deleted file mode 100644 index 1e291c40..00000000 Binary files a/versioned_docs/version-1.0/guides/img/fiat-1.png and /dev/null differ diff --git a/versioned_docs/version-1.0/guides/next/_category_.json b/versioned_docs/version-1.0/guides/next/_category_.json deleted file mode 100644 index f5ebb815..00000000 --- a/versioned_docs/version-1.0/guides/next/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Next.js", - "position": 3, - "link": { - "type": "generated-index", - "description": "In order to integrate our SDK into your Next.js projects you can go through the snippets and code recaps to integrate the features of our SDK. In the following sections we talk about:" - } -} diff --git a/versioned_docs/version-1.0/guides/next/code-examples/_category_.json b/versioned_docs/version-1.0/guides/next/code-examples/_category_.json deleted file mode 100644 index 5c52fbdc..00000000 --- a/versioned_docs/version-1.0/guides/next/code-examples/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Code Examples", - "position": 4, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/guides/next/code-examples/gasless-code-example.md b/versioned_docs/version-1.0/guides/next/code-examples/gasless-code-example.md deleted file mode 100644 index 3bb33c38..00000000 --- a/versioned_docs/version-1.0/guides/next/code-examples/gasless-code-example.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Gasless Code Example - -## Send Single Gasless Transaction With Social Login - -```js -import SocialLogin from "@biconomy/web3-auth"; -import { ChainId } from "@biconomy/core-types"; -import SmartAccount from "@biconomy/smart-account"; - -const socialLoginSDK = new SocialLogin(); -const signature = await socialLoginSDK.whitelistUrl('https://yourdomain.com'); -await socialLoginSDK.init({ - whitelistUrls: { - 'https://yourdomain.com': signature, - } -}); - -socialLoginSDK.showWallet(); - -if (!socialLoginSDK?.provider) return; -const provider = new ethers.providers.Web3Provider( - socialLoginSDK.provider, -); -const walletProvider = new ethers.providers.Web3Provider(provider); -const accounts = await provider.listAccounts(); - -// Initialize the Smart Account -// All values are optional except networkConfig only in the case of gasless dappAPIKey is required -let options = { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ChainId.GOERLI, ChainId.POLYGON_MAINNET, ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - }, - { - chainId: ChainId.POLYGON_MAINNET, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - } - ] -} - -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); - -const erc20Interface = new ethers.utils.Interface([ - 'function transfer(address _to, uint256 _value)' -]) -// Encode an ERC-20 token transfer to recipient of the specified amount -const data = erc20Interface.encodeFunctionData( - 'transfer', [recipientAddress, amount] -) -const tx = { - to: usdcAddress, - data -} - -// Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransaction({ transaction: tx1 }); -console.log('userOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx hash', txReciept.transactionHash); - -// DONE! You just sent a forward transaction -``` - -## Send Batched Gasless Transactions With Social Login - -```js -import SocialLogin from "@biconomy/web3-auth"; -import { ChainId } from "@biconomy/core-types"; -import SmartAccount from "@biconomy/smart-account"; - -const socialLoginSDK = new SocialLogin(); -const signature = await socialLoginSDK.whitelistUrl('https://yourdomain.com'); -await socialLoginSDK.init({ - whitelistUrls: { - 'https://yourdomain.com': signature, - } -}); - -socialLoginSDK.showWallet(); - -if (!socialLoginSDK?.provider) return; -const provider = new ethers.providers.Web3Provider( - socialLoginSDK.provider, -); -const walletProvider = new ethers.providers.Web3Provider(provider); -const accounts = await provider.listAccounts(); - -// Initialize the Smart Account -// All values are optional except networkConfig only in the case of gasless dappAPIKey is required -let options = { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ChainId.GOERLI, ChainId.POLYGON_MAINNET, ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - }, - { - chainId: ChainId.POLYGON_MAINNET, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - } - ] -} - - -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); - -// One needs to prepare the transaction data -// Here we will be transferring ERC 20 tokens from the Smart Contract Wallet to an address -const erc20Interface = new ethers.utils.Interface(ERC_20_ABI) - -// Encode an ERC-20 token approval to spenderAddress of the specified amount -const approvalEncodedData = erc20Interface.encodeFunctionData( - 'approve', [spenderAddress, amount] -) -// Encode an ERC-20 token transferFrom from an address of the specified amount -const transferFromEncodedData = erc20Interface.encodeFunctionData( - 'transferFrom', [from, receipientAddress, amount] -) -const txs = []; -// You need to create transaction objects of the following interface -const tx1 = { - to: usdcAddress, // destination smart contract address - data: approvalEncodedData -} -txs.push(tx1); -const tx2 = { - to: usdcAddress, - data: transferFromEncodedData -}; -txs.push(tx2); - -// Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransactionBatch({ transactions: txs }); -console.log('UserOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx Hash', txReciept.transactionHash); -// DONE! You just sent a batched gasless transaction -``` - -:::caution -For common errors check [this](https://docs.biconomy.io/references/common-errors). -::: - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth -- https://github.com/bcnmy/sdk-demo -- https://github.com/bcnmy/hyphen-ui/tree/demo-sdk - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/next/gasless-txn/_category_.json b/versioned_docs/version-1.0/guides/next/gasless-txn/_category_.json deleted file mode 100644 index e446e1d9..00000000 --- a/versioned_docs/version-1.0/guides/next/gasless-txn/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Gasless Transactions", - "position": 3, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/guides/next/gasless-txn/batch-txn.md b/versioned_docs/version-1.0/guides/next/gasless-txn/batch-txn.md deleted file mode 100644 index 6f18ab31..00000000 --- a/versioned_docs/version-1.0/guides/next/gasless-txn/batch-txn.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Gasless Batched Transaction - -One needs to prepare the transaction data. Here we will be transferring ERC 20 tokens from the Smart Contract Wallet to an address - -```js -const erc20Interface = new ethers.utils.Interface(ERC_20_ABI) - -// Encode an ERC-20 token approval to spenderAddress of the specified amount -const approvalEncodedData = erc20Interface.encodeFunctionData( - 'approve', [spenderAddress, amount] -) - -// Encode an ERC-20 token transferFrom from an address of the specified amount -const transferFromEncodedData = erc20Interface.encodeFunctionData( - 'transferFrom', [from, receipientAddress, amount] -) - -const txs = []; - -// You need to create transaction objects of the following interface -const tx1 = { - to: usdcAddress, // destination smart contract address - data: approvalEncodedData -} - -txs.push(tx1); - -const tx2 = { - to: usdcAddress, - data: transferFromEncodedData -}; - -txs.push(tx2); - -// Optional: Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransactionBatch({ transactions: txs }); -console.log('UserOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx Hash', txReciept.transactionHash); -// DONE! You just sent a batched gasless transaction -``` - -:::caution -For common errors check [this](https://docs.biconomy.io/references/common-errors). -::: - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth -- https://github.com/bcnmy/sdk-demo -- https://github.com/bcnmy/hyphen-ui/tree/demo-sdk - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/next/gasless-txn/overview.md b/versioned_docs/version-1.0/guides/next/gasless-txn/overview.md deleted file mode 100644 index 1f792e94..00000000 --- a/versioned_docs/version-1.0/guides/next/gasless-txn/overview.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -Smart Account instance has been created and initialized. - -:::info -Smart account address that SDK spins up are counterfactual in nature and remains the same address on all EVM chains. You can securely transfer funds to this counterfactual address using a transfer from a Centralised exchange or via Fiat on-ramps. -::: - -These smart accounts are only deployed when users initiate a first transaction. Optionally as a Dapp you can just deploy the wallets and sponsor gas for it. Please check the below flows. - -## Wallet Deployment flow - -:::info -"Wallet deployment only" is supported using only gasless transactions where gas is sponsored via dApps using Paymasters (Gas Tanks). Users do not need to hold any assets to pay fees for this deployment. -::: - -Initialize Smart Account with appropriate config as mentioned here in the gasless section. - -```js -// Assuming smart account has already been initialised - -const tx = await smartAccount.deployWalletUsingPaymaster(); -``` - -:::note -Note: above deploy wallet uses createSenderIfNeeded() from the Entry point which merely calls the Wallet Factory contract for deployment. One can also plug in a local relayer to make this transaction directly on wallet factory. -::: - -## Wallet Deployment batched with a transaction - -Any gasless or user paid transaction will check whether the wallet is deployed or not. If the wallet is not deployed, the SDK will batch the wallet deployment with the intended transaction/batch transactions. This behaviour is handled within the SDK itself & would require no changes in your code to enable this. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/next/gasless-txn/single-txn.md b/versioned_docs/version-1.0/guides/next/gasless-txn/single-txn.md deleted file mode 100644 index ab817e07..00000000 --- a/versioned_docs/version-1.0/guides/next/gasless-txn/single-txn.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Gasless Single Transaction - -Once the Smart Account has been setup and initialised, one can start sending gasless transactions in the following way: - -```js - -// One needs to prepare the transaction data -// Here we will be transferring ERC 20 tokens from the Smart Contract Wallet to an address -const erc20Interface = new ethers.utils.Interface([ - 'function transfer(address _to, uint256 _value)' -]) - -// Encode an ERC-20 token transfer to recipientAddress of the specified amount -const encodedData = erc20Interface.encodeFunctionData( - 'transfer', [recipientAddress, amount] -) - -// You need to create transaction objects of the following interface -const tx = { - to: usdcAddress, // destination smart contract address - data: encodedData -} - -// Optional: Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransaction({ transaction: tx1 }); -console.log('userOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx hash', txReciept.transactionHash); - -// DONE! You just sent a gasless transaction -``` - -:::caution -For common errors check [this](https://docs.biconomy.io/references/common-errors). -::: - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth -- https://github.com/bcnmy/sdk-demo -- https://github.com/bcnmy/hyphen-ui/tree/demo-sdk - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/next/smart-account-login.md b/versioned_docs/version-1.0/guides/next/smart-account-login.md deleted file mode 100644 index f2927f01..00000000 --- a/versioned_docs/version-1.0/guides/next/smart-account-login.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Setting Up Smart Account with Social Login - -Next, you will need to connect the provider to the Biconomy Smart Account package. To install the smart account run the following command: - -```bash -yarn add @biconomy/smart-account -// or -npm install @biconomy/smart-account -``` - -:::info -**You'll need a dApp API key to create Smart Accounts for your users.** -You can register your dApp and get an API key for it from the **Biconomy Dashboard.** - -If you have problems with using the Dashboard and configuring your dApp and Gas Tank, feel free to get in touch with us for spinning up personal test keys and gas tanks on other test networks. -::: - -## Initialize Smart Account - -```js -import { ChainId } from "@biconomy/core-types"; -import SmartAccount from "@biconomy/smart-account"; - -// Initialize the Smart Account -// All values are optional except networkConfig only in the case of gasless dappAPIKey is required -let options = { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ChainId.GOERLI, ChainId.POLYGON_MAINNET, ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - }, - { - chainId: ChainId.POLYGON_MAINNET, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - } - ] -} - -// this provider is from the social login which we created in previous setup -let smartAccount = new SmartAccount(provider, options); -smartAccount = await smartAccount.init(); -``` - -Now using the SDK you can do: - -- Make Gasless Transactions. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/next/social-login.md b/versioned_docs/version-1.0/guides/next/social-login.md deleted file mode 100644 index c91ae7f3..00000000 --- a/versioned_docs/version-1.0/guides/next/social-login.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Setting Up Social Login - -Social Login is a pluggable auth infrastructure built on Web3Auth for dApp developers who want to integrate social login without hassle. Developers don't have to create clients or go to any dashboard to whitelist URLs. - -## Steps To Enable Social Login - -- Install and import the web3-auth package from the Biconomy SDK - -```bash -yarn add @biconomy/web3-auth -// or -npm install @biconomy/web3-auth -``` - -```js -import SocialLogin from "@biconomy/web3-auth"; -import "@biconomy/web3-auth/dist/src/style.css"; -``` - -:::info -By installing this package you might get an error like -"Module not found: Error: Can't resolve 'crypto'." -These are polyfills errors that can be resolved by configuring the webpack properly. As mentioned [here](https://github.com/bcnmy/biconomy-client-sdk/issues/87#issuecomment-1329798362). -::: - -:::info -If you're using a biconomy/web3-auth package version below 0.0.4 then you don't need to import the CSS in the project root. -::: - -### SocialLogin Module Functions - -If you check the SocialLogin class you will find different methods which we've got to help you integrate social login - -1. `init()` - is required after initializing. It makes important calls and makes the web3auth ready for you. -2. `showWallet()` - it will show the widget in your UI. -3. `hideWallet()` - it will hide the wallet widget from the UI. -4. `logout()` - Logs out of the wallet, also clears the cache. -5. `getUserInfo()` - This method returns the object of email, name, profileImage, and idToken. -6. `whitelistUrl()` - If you are deploying your site, you must whitelist your deployment URL. It returns signatures that you can pass to init functions. You can also pass the array of URLs to signatures. The signature in init is not required for localhost. - -Initialize the social login SDK - -```js -// create an instance of SocialLogin -const socialLogin = new SocialLogin(); -// init social login SDK, all params are optional -await socialLogin.init(); - -// pops up the UI widget -socialLogin.showWallet(); -``` - -For whitelisting your domain, please use the following code snippet. When deploying on prod it is required to whitelist your domain. In init, you can pass the domain and signature. - -```js -// get signature that corresponds to your website domains -const signature1 = await socialLogin.whitelistUrl("https://yourdomain1.com"); -const signature2 = await socialLogin.whitelistUrl("https://yourdomain2.com"); -// pass the signatures, you can pass one or many signatures you want to whitelist -await socialLogin.init({ - whitelistUrls: { - "https://yourdomain1.com": signature1, - "https://yourdomain2.com": signature2, - }, -}); -``` - -- Access to web3Auth provider after the wallet is connected - -```js -if (!socialLogin?.provider) return; -// create a provider from the social login provider that -// will be used by the smart account package of the Biconomy SDK -const provider = new ethers.providers.Web3Provider(socialLogin.provider); -// get a list of accounts available with the provider -const accounts = await provider.listAccounts(); -console.log("EOA address", accounts); -``` - -As the SocialLogin SDK is trying to access the DOM this might give error for document not found by next.js. - -We need to wrap this file inside next/dynamic from next.js. Move all the logic in to new component and import it like this. [Here is all the files.](https://github.com/bcnmy/sdk-examples/tree/master/nextjs-biconomy-web3Auth) - -```js -import dynamic from "next/dynamic"; -import { Suspense } from "react"; - -const Index = () => { - const SocialLoginDynamic = dynamic( - () => import("../components/scw").then((res) => res.default), - { - ssr: false, - }, - ); - - return ( -
- Loading...
}> - - - - ); -}; - -export default Index; -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/node/_category_.json b/versioned_docs/version-1.0/guides/node/_category_.json deleted file mode 100644 index 1d60bb10..00000000 --- a/versioned_docs/version-1.0/guides/node/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Node.js", - "position": 4, - "link": { - "type": "generated-index", - "description": "To start integrating SDK in your Node.js environment you can go through the snippets and code recaps to integrate the features of our SDK. In the following sections we talk about:" - } -} diff --git a/versioned_docs/version-1.0/guides/node/code-example/_category_.json b/versioned_docs/version-1.0/guides/node/code-example/_category_.json deleted file mode 100644 index 8f5165db..00000000 --- a/versioned_docs/version-1.0/guides/node/code-example/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Code Examples", - "position": 3, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/guides/node/code-example/gasless-code-example.md b/versioned_docs/version-1.0/guides/node/code-example/gasless-code-example.md deleted file mode 100644 index e6068392..00000000 --- a/versioned_docs/version-1.0/guides/node/code-example/gasless-code-example.md +++ /dev/null @@ -1,173 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Gasless Transactions Code Example - -## Send Single Gasless Transaction - -```js -const { ethers } = require("ethers"); -const HDWalletProvider = require("@truffle/hdwallet-provider"); -const SmartAccount = require("@biconomy/smart-account").default; -const { ChainId } = require("@biconomy/core-types"); - -const config = { - privateKey: "0x0000000000000000000000000000000000000000000000000000000000000000", - rpcUrl: "https://rpc-mumbai.maticvigil.com", - dappAPIKey: "", -} - -async function main() { - let provider = new HDWalletProvider(config.privateKey, config.rpcUrl); - const walletProvider = new ethers.providers.Web3Provider(provider); - // create SmartAccount instance - const wallet = new SmartAccount(walletProvider, { - debug: false, - activeNetworkId: ChainId.POLYGON_MUMBAI, - supportedNetworksIds: [ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - dappAPIKey: config.dappAPIKey, - } - ] - }); - const smartAccount = await wallet.init(); - - // transfer ERC-20 tokens to recipient - const erc20Interface = new ethers.utils.Interface([ - 'function transfer(address _to, uint256 _value)' - ]) - // Encode an ERC-20 token transfer to recipient of the specified amount - const recipientAddress = '0x0000000000000000000000000000000000000000' - const amount = ethers.BigNumber.from("1000000") - const usdcAddress = '0xdA5289fCAAF71d52a80A254da614a192b693e977' - const data = erc20Interface.encodeFunctionData( - 'transfer', [recipientAddress, amount] - ) - const tx = { - to: usdcAddress, - data - } - - // Transaction events subscription - smartAccount.on('txHashGenerated', (response) => { - console.log('txHashGenerated event received via emitter', response); - }); - smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); - }); - smartAccount.on('txMined', (response) => { - console.log('txMined event received via emitter', response); - }); - smartAccount.on('error', (response) => { - console.log('error event received via emitter', response); - }); - - // Sending gasless transaction - const txResponse = await smartAccount.sendTransaction({ transaction: tx }); - console.log('userOp hash', txResponse.hash); - // If you do not subscribe to listener, one can also get the receipt like shown below - const txReciept = await txResponse.wait(); - console.log('Tx hash', txReciept.transactionHash); -} - -main().catch((error) => { - console.error(error); -}); -``` - -## Send Batched Gasless Transactions - -```js -const { ethers } = require("ethers"); -const HDWalletProvider = require("@truffle/hdwallet-provider"); -const SmartAccount = require("@biconomy/smart-account").default; -const { ChainId } = require("@biconomy/core-types"); - -const config = { - privateKey: - "0x0000000000000000000000000000000000000000000000000000000000000000", - rpcUrl: "https://rpc-mumbai.maticvigil.com", - dappAPIKey: "", -}; - -async function main() { - let provider = new HDWalletProvider(config.privateKey, config.rpcUrl); - const walletProvider = new ethers.providers.Web3Provider(provider); - // create SmartAccount instance - const wallet = new SmartAccount(walletProvider, { - debug: false, - activeNetworkId: ChainId.POLYGON_MUMBAI, - supportedNetworksIds: [ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - dappAPIKey: config.dappAPIKey, - }, - ], - }); - const smartAccount = await wallet.init(); - - // transfer ERC-20 tokens to recipient - const erc20Interface = new ethers.utils.Interface(ERC_20_ABI); - - // Encode an ERC-20 token approval to spenderAddress of the specified amount - const approvalEncodedData = erc20Interface.encodeFunctionData("approve", [ - spenderAddress, - amount, - ]); - // Encode an ERC-20 token transferFrom from an address of the specified amount - const transferFromEncodedData = erc20Interface.encodeFunctionData( - "transferFrom", - [from, receipientAddress, amount], - ); - - const txs = []; - // You need to create transaction objects of the following interface - const tx1 = { - to: usdcAddress, // destination smart contract address - data: approvalEncodedData, - }; - txs.push(tx1); - const tx2 = { - to: usdcAddress, - data: transferFromEncodedData, - }; - txs.push(tx2); - - // Transaction events subscription - smartAccount.on("txHashGenerated", (response) => { - console.log("txHashGenerated event received via emitter", response); - }); - smartAccount.on("txMined", (response) => { - console.log("txMined event received via emitter", response); - }); - smartAccount.on("error", (response) => { - console.log("error event received via emitter", response); - }); - - // Sending gasless transaction - const txResponse = await smartAccount.sendTransactionBatch({ - transactions: txs, - }); - console.log("UserOp hash", txResponse.hash); - // If you do not subscribe to listener, one can also get the receipt like shown below - const txReciept = await txResponse.wait(); - console.log("Tx Hash", txReciept.transactionHash); - // DONE! You just sent a batched gasless transaction -} - -main().catch((error) => { - console.error(error); -}); -``` - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/backend-node - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/node/gasless-txn/_category_.json b/versioned_docs/version-1.0/guides/node/gasless-txn/_category_.json deleted file mode 100644 index 343ee7b4..00000000 --- a/versioned_docs/version-1.0/guides/node/gasless-txn/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Gasless Transactions", - "position": 2, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/guides/node/gasless-txn/batch-txn.md b/versioned_docs/version-1.0/guides/node/gasless-txn/batch-txn.md deleted file mode 100644 index 43c52680..00000000 --- a/versioned_docs/version-1.0/guides/node/gasless-txn/batch-txn.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Gasless Batched Transaction - -One needs to prepare the transaction data. Here we will be transferring ERC 20 tokens from the Smart Contract Wallet to an address - -```js -const erc20Interface = new ethers.utils.Interface(ERC_20_ABI) - -// Encode an ERC-20 token approval to spenderAddress of the specified amount -const approvalEncodedData = erc20Interface.encodeFunctionData( - 'approve', [spenderAddress, amount] -) - -// Encode an ERC-20 token transferFrom from an address of the specified amount -const transferFromEncodedData = erc20Interface.encodeFunctionData( - 'transferFrom', [from, receipientAddress, amount] -) - -const txs = []; - -// You need to create transaction objects of the following interface -const tx1 = { - to: usdcAddress, // destination smart contract address - data: approvalEncodedData -} - -txs.push(tx1); - -const tx2 = { - to: usdcAddress, - data: transferFromEncodedData -}; - -txs.push(tx2); - -// Optional: Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransactionBatch({ transactions: txs }); -console.log('UserOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx Hash', txReciept.transactionHash); -// DONE! You just sent a batched gasless transaction -``` - -:::caution -For common errors check [this](https://docs.biconomy.io/references/common-errors). -::: - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/backend-node - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/node/gasless-txn/overview.md b/versioned_docs/version-1.0/guides/node/gasless-txn/overview.md deleted file mode 100644 index 1f792e94..00000000 --- a/versioned_docs/version-1.0/guides/node/gasless-txn/overview.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -Smart Account instance has been created and initialized. - -:::info -Smart account address that SDK spins up are counterfactual in nature and remains the same address on all EVM chains. You can securely transfer funds to this counterfactual address using a transfer from a Centralised exchange or via Fiat on-ramps. -::: - -These smart accounts are only deployed when users initiate a first transaction. Optionally as a Dapp you can just deploy the wallets and sponsor gas for it. Please check the below flows. - -## Wallet Deployment flow - -:::info -"Wallet deployment only" is supported using only gasless transactions where gas is sponsored via dApps using Paymasters (Gas Tanks). Users do not need to hold any assets to pay fees for this deployment. -::: - -Initialize Smart Account with appropriate config as mentioned here in the gasless section. - -```js -// Assuming smart account has already been initialised - -const tx = await smartAccount.deployWalletUsingPaymaster(); -``` - -:::note -Note: above deploy wallet uses createSenderIfNeeded() from the Entry point which merely calls the Wallet Factory contract for deployment. One can also plug in a local relayer to make this transaction directly on wallet factory. -::: - -## Wallet Deployment batched with a transaction - -Any gasless or user paid transaction will check whether the wallet is deployed or not. If the wallet is not deployed, the SDK will batch the wallet deployment with the intended transaction/batch transactions. This behaviour is handled within the SDK itself & would require no changes in your code to enable this. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/node/gasless-txn/single-txn.md b/versioned_docs/version-1.0/guides/node/gasless-txn/single-txn.md deleted file mode 100644 index 265da2ca..00000000 --- a/versioned_docs/version-1.0/guides/node/gasless-txn/single-txn.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Gasless Single Transaction - -Once the Smart Account has been setup and initialised, one can start sending gasless transactions in the following way: - -```js - -// One needs to prepare the transaction data -// Here we will be transferring ERC 20 tokens from the Smart Contract Wallet to an address -const erc20Interface = new ethers.utils.Interface([ - 'function transfer(address _to, uint256 _value)' -]) - -// Encode an ERC-20 token transfer to recipientAddress of the specified amount -const encodedData = erc20Interface.encodeFunctionData( - 'transfer', [recipientAddress, amount] -) - -// You need to create transaction objects of the following interface -const tx = { - to: usdcAddress, // destination smart contract address - data: encodedData -} - -// Optional: Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransaction({ transaction: tx1 }); -console.log('userOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx hash', txReciept.transactionHash); - -// DONE! You just sent a gasless transaction -``` - -:::caution -For common errors check [this](https://docs.biconomy.io/references/common-errors). -::: - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/backend-node - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/node/setup-smart-account.md b/versioned_docs/version-1.0/guides/node/setup-smart-account.md deleted file mode 100644 index 9292dc2e..00000000 --- a/versioned_docs/version-1.0/guides/node/setup-smart-account.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Setting Up Smart Account - -The very first step is to set up your smart account and attach a provider to it. You will need to pass the provider into the Biconomy Smart Account package. To install the smart account run the following command: - -```bash -yarn add @biconomy/smart-account -// or -npm install @biconomy/smart-account -``` - -:::note -The dashboard is not live yet and will be launching soon. Meanwhile, to enable Gasless transactions please reach out to us. -::: - -:::info -**You'll need a dApp API key to create Smart Accounts for your users.** -You can register your dApp and get an API key for it from the **Biconomy Dashboard.** - -If you have problems with using the Dashboard and configuring your dApp and Gas Tank, feel free to get in touch with us for spinning up personal test keys and gas tanks on other test networks. -::: - -## Steps to Enable Gasless Transactions - -```js -const { ethers } = require("ethers"); -const HDWalletProvider = require("@truffle/hdwallet-provider"); -const { ChainId } = require("@biconomy/core-types"); -const SmartAccount = require("@biconomy/smart-account").default; - -const privateKey = ""; -const rpcUrl = ""; - -async function main() { - let provider = new HDWalletProvider(privateKey, rpcUrl); - const walletProvider = new ethers.providers.Web3Provider(provider); - // get EOA address from wallet provider - const eoa = await walletProvider.getSigner().getAddress(); - console.log(`EOA address: ${eoa}`); - - // get SmartAccount address from wallet provider - const wallet = new SmartAccount(walletProvider, { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ - ChainId.GOERLI, - ChainId.POLYGON_MAINNET, - ChainId.POLYGON_MUMBAI, - ], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: "", - providerUrl: "", - }, - { - chainId: ChainId.POLYGON_MAINNET, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: "", - providerUrl: "", - }, - ], - }); - const smartAccount = await wallet.init(); - const address = await smartAccount.getSmartAccountState(); - console.log(`SmartAccount address: ${address.address}`); - process.exit(0); -} - -main().catch((error) => { - console.error(error); - process.exit(1); -}); -``` - -Now using the SDK you can do: - -- Gasless Transactions in which dapp sponsors the gas. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/react/_category_.json b/versioned_docs/version-1.0/guides/react/_category_.json deleted file mode 100644 index 588bb735..00000000 --- a/versioned_docs/version-1.0/guides/react/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "React.js", - "position": 2, - "link": { - "type": "generated-index", - "description": "In order to integrate our SDK into your React.js projects you can go through the snippets and code recaps to integrate the features of our SDK. In the following sections we talk about:" - } -} diff --git a/versioned_docs/version-1.0/guides/react/code-examples/_category_.json b/versioned_docs/version-1.0/guides/react/code-examples/_category_.json deleted file mode 100644 index 5c52fbdc..00000000 --- a/versioned_docs/version-1.0/guides/react/code-examples/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Code Examples", - "position": 4, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/guides/react/code-examples/gasless-code-example.md b/versioned_docs/version-1.0/guides/react/code-examples/gasless-code-example.md deleted file mode 100644 index 3bb33c38..00000000 --- a/versioned_docs/version-1.0/guides/react/code-examples/gasless-code-example.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Gasless Code Example - -## Send Single Gasless Transaction With Social Login - -```js -import SocialLogin from "@biconomy/web3-auth"; -import { ChainId } from "@biconomy/core-types"; -import SmartAccount from "@biconomy/smart-account"; - -const socialLoginSDK = new SocialLogin(); -const signature = await socialLoginSDK.whitelistUrl('https://yourdomain.com'); -await socialLoginSDK.init({ - whitelistUrls: { - 'https://yourdomain.com': signature, - } -}); - -socialLoginSDK.showWallet(); - -if (!socialLoginSDK?.provider) return; -const provider = new ethers.providers.Web3Provider( - socialLoginSDK.provider, -); -const walletProvider = new ethers.providers.Web3Provider(provider); -const accounts = await provider.listAccounts(); - -// Initialize the Smart Account -// All values are optional except networkConfig only in the case of gasless dappAPIKey is required -let options = { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ChainId.GOERLI, ChainId.POLYGON_MAINNET, ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - }, - { - chainId: ChainId.POLYGON_MAINNET, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - } - ] -} - -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); - -const erc20Interface = new ethers.utils.Interface([ - 'function transfer(address _to, uint256 _value)' -]) -// Encode an ERC-20 token transfer to recipient of the specified amount -const data = erc20Interface.encodeFunctionData( - 'transfer', [recipientAddress, amount] -) -const tx = { - to: usdcAddress, - data -} - -// Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransaction({ transaction: tx1 }); -console.log('userOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx hash', txReciept.transactionHash); - -// DONE! You just sent a forward transaction -``` - -## Send Batched Gasless Transactions With Social Login - -```js -import SocialLogin from "@biconomy/web3-auth"; -import { ChainId } from "@biconomy/core-types"; -import SmartAccount from "@biconomy/smart-account"; - -const socialLoginSDK = new SocialLogin(); -const signature = await socialLoginSDK.whitelistUrl('https://yourdomain.com'); -await socialLoginSDK.init({ - whitelistUrls: { - 'https://yourdomain.com': signature, - } -}); - -socialLoginSDK.showWallet(); - -if (!socialLoginSDK?.provider) return; -const provider = new ethers.providers.Web3Provider( - socialLoginSDK.provider, -); -const walletProvider = new ethers.providers.Web3Provider(provider); -const accounts = await provider.listAccounts(); - -// Initialize the Smart Account -// All values are optional except networkConfig only in the case of gasless dappAPIKey is required -let options = { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ChainId.GOERLI, ChainId.POLYGON_MAINNET, ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - }, - { - chainId: ChainId.POLYGON_MAINNET, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - } - ] -} - - -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); - -// One needs to prepare the transaction data -// Here we will be transferring ERC 20 tokens from the Smart Contract Wallet to an address -const erc20Interface = new ethers.utils.Interface(ERC_20_ABI) - -// Encode an ERC-20 token approval to spenderAddress of the specified amount -const approvalEncodedData = erc20Interface.encodeFunctionData( - 'approve', [spenderAddress, amount] -) -// Encode an ERC-20 token transferFrom from an address of the specified amount -const transferFromEncodedData = erc20Interface.encodeFunctionData( - 'transferFrom', [from, receipientAddress, amount] -) -const txs = []; -// You need to create transaction objects of the following interface -const tx1 = { - to: usdcAddress, // destination smart contract address - data: approvalEncodedData -} -txs.push(tx1); -const tx2 = { - to: usdcAddress, - data: transferFromEncodedData -}; -txs.push(tx2); - -// Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransactionBatch({ transactions: txs }); -console.log('UserOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx Hash', txReciept.transactionHash); -// DONE! You just sent a batched gasless transaction -``` - -:::caution -For common errors check [this](https://docs.biconomy.io/references/common-errors). -::: - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth -- https://github.com/bcnmy/sdk-demo -- https://github.com/bcnmy/hyphen-ui/tree/demo-sdk - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/react/gasless-txn/_category_.json b/versioned_docs/version-1.0/guides/react/gasless-txn/_category_.json deleted file mode 100644 index e446e1d9..00000000 --- a/versioned_docs/version-1.0/guides/react/gasless-txn/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Gasless Transactions", - "position": 3, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/guides/react/gasless-txn/batch-txn.md b/versioned_docs/version-1.0/guides/react/gasless-txn/batch-txn.md deleted file mode 100644 index 6f18ab31..00000000 --- a/versioned_docs/version-1.0/guides/react/gasless-txn/batch-txn.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Gasless Batched Transaction - -One needs to prepare the transaction data. Here we will be transferring ERC 20 tokens from the Smart Contract Wallet to an address - -```js -const erc20Interface = new ethers.utils.Interface(ERC_20_ABI) - -// Encode an ERC-20 token approval to spenderAddress of the specified amount -const approvalEncodedData = erc20Interface.encodeFunctionData( - 'approve', [spenderAddress, amount] -) - -// Encode an ERC-20 token transferFrom from an address of the specified amount -const transferFromEncodedData = erc20Interface.encodeFunctionData( - 'transferFrom', [from, receipientAddress, amount] -) - -const txs = []; - -// You need to create transaction objects of the following interface -const tx1 = { - to: usdcAddress, // destination smart contract address - data: approvalEncodedData -} - -txs.push(tx1); - -const tx2 = { - to: usdcAddress, - data: transferFromEncodedData -}; - -txs.push(tx2); - -// Optional: Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransactionBatch({ transactions: txs }); -console.log('UserOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx Hash', txReciept.transactionHash); -// DONE! You just sent a batched gasless transaction -``` - -:::caution -For common errors check [this](https://docs.biconomy.io/references/common-errors). -::: - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth -- https://github.com/bcnmy/sdk-demo -- https://github.com/bcnmy/hyphen-ui/tree/demo-sdk - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/react/gasless-txn/overview.md b/versioned_docs/version-1.0/guides/react/gasless-txn/overview.md deleted file mode 100644 index 1f792e94..00000000 --- a/versioned_docs/version-1.0/guides/react/gasless-txn/overview.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -Smart Account instance has been created and initialized. - -:::info -Smart account address that SDK spins up are counterfactual in nature and remains the same address on all EVM chains. You can securely transfer funds to this counterfactual address using a transfer from a Centralised exchange or via Fiat on-ramps. -::: - -These smart accounts are only deployed when users initiate a first transaction. Optionally as a Dapp you can just deploy the wallets and sponsor gas for it. Please check the below flows. - -## Wallet Deployment flow - -:::info -"Wallet deployment only" is supported using only gasless transactions where gas is sponsored via dApps using Paymasters (Gas Tanks). Users do not need to hold any assets to pay fees for this deployment. -::: - -Initialize Smart Account with appropriate config as mentioned here in the gasless section. - -```js -// Assuming smart account has already been initialised - -const tx = await smartAccount.deployWalletUsingPaymaster(); -``` - -:::note -Note: above deploy wallet uses createSenderIfNeeded() from the Entry point which merely calls the Wallet Factory contract for deployment. One can also plug in a local relayer to make this transaction directly on wallet factory. -::: - -## Wallet Deployment batched with a transaction - -Any gasless or user paid transaction will check whether the wallet is deployed or not. If the wallet is not deployed, the SDK will batch the wallet deployment with the intended transaction/batch transactions. This behaviour is handled within the SDK itself & would require no changes in your code to enable this. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/react/gasless-txn/single-txn.md b/versioned_docs/version-1.0/guides/react/gasless-txn/single-txn.md deleted file mode 100644 index ab817e07..00000000 --- a/versioned_docs/version-1.0/guides/react/gasless-txn/single-txn.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Gasless Single Transaction - -Once the Smart Account has been setup and initialised, one can start sending gasless transactions in the following way: - -```js - -// One needs to prepare the transaction data -// Here we will be transferring ERC 20 tokens from the Smart Contract Wallet to an address -const erc20Interface = new ethers.utils.Interface([ - 'function transfer(address _to, uint256 _value)' -]) - -// Encode an ERC-20 token transfer to recipientAddress of the specified amount -const encodedData = erc20Interface.encodeFunctionData( - 'transfer', [recipientAddress, amount] -) - -// You need to create transaction objects of the following interface -const tx = { - to: usdcAddress, // destination smart contract address - data: encodedData -} - -// Optional: Transaction subscription. One can subscribe to various transaction states -// Event listener that gets triggered once a hash is generetaed -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); -}); -smartAccount.on('onHashChanged', (response: any) => { - console.log('onHashChanged event received via emitter', response); -}); -// Event listener that gets triggered once a transaction is mined -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); -}); -// Event listener that gets triggered on any error -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransaction({ transaction: tx1 }); -console.log('userOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx hash', txReciept.transactionHash); - -// DONE! You just sent a gasless transaction -``` - -:::caution -For common errors check [this](https://docs.biconomy.io/references/common-errors). -::: - -## Code Examples - -- https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth -- https://github.com/bcnmy/sdk-demo -- https://github.com/bcnmy/hyphen-ui/tree/demo-sdk - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/react/smart-account-login.md b/versioned_docs/version-1.0/guides/react/smart-account-login.md deleted file mode 100644 index bd93f1f8..00000000 --- a/versioned_docs/version-1.0/guides/react/smart-account-login.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Setting Up Smart Account with Social Login - -Next, you will need to connect the provider to the Biconomy Smart Account package. To install the smart account run the following command: - -```bash -yarn add @biconomy/smart-account -// or -npm install @biconomy/smart-account -``` - -:::info -**You'll need a dApp API key to create Smart Accounts for your users.** -You can register your dApp and get an API key for it from the **Biconomy Dashboard.** - -If you have problems with using the Dashboard and configuring your dApp and Gas Tank, feel free to get in touch with us for spinning up personal test keys and gas tanks on other test networks. -::: - -## Initialize Smart Account - -```js -import { ChainId } from "@biconomy/core-types"; -import SmartAccount from "@biconomy/smart-account"; - -// Initialize the Smart Account -// All values are optional except networkConfig only in the case of gasless dappAPIKey is required -let options = { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ChainId.GOERLI, ChainId.POLYGON_MAINNET, ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - }, - { - chainId: ChainId.POLYGON_MAINNET, - // Dapp API Key you will get from new Biconomy dashboard that will be live soon - // Meanwhile you can use the test dapp api key mentioned above - dappAPIKey: , - providerUrl: - } - ] -} - -// this provider is from the social login which we created in previous setup -let smartAccount = new SmartAccount(provider, options); -smartAccount = await smartAccount.init(); -``` - -Now using the SDK you can do: - -- Gasless Transactions in which dapp sponsors the gas. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/react/social-login.md b/versioned_docs/version-1.0/guides/react/social-login.md deleted file mode 100644 index cb032c79..00000000 --- a/versioned_docs/version-1.0/guides/react/social-login.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Setting Up Social Login - -Social Login is a pluggable auth infrastructure built on Web3Auth for dApp developers who want to integrate social login without hassle. Developers don't have to create clients or go to any dashboard to whitelist URLs. - -## Steps To Enable Social Login - -- Install and import the web3-auth package from the Biconomy SDK - -```bash -yarn add @biconomy/web3-auth -// or -npm install @biconomy/web3-auth -``` - -```js -import SocialLogin from "@biconomy/web3-auth"; -import "@biconomy/web3-auth/dist/src/style.css"; -``` - -:::info -By installing this package you might get an error like -"Module not found: Error: Can't resolve 'crypto'." -These are polyfills errors that can be resolved by configuring the webpack properly. As mentioned [here](https://github.com/bcnmy/biconomy-client-sdk/issues/87#issuecomment-1329798362). -::: - -:::info -If you're using a biconomy/web3-auth package version below 0.0.4 then you don't need to import the CSS in the project root. -::: - -### SocialLogin Module Functions - -If you check the SocialLogin class you will find different methods which we've got to help you integrate social login - -1. `init()` - is required after initializing. It makes important calls and makes the web3auth ready for you. -2. `showWallet()` - it will show the widget in your UI. -3. `hideWallet()` - it will hide the wallet widget from the UI. -4. `logout()` - Logs out of the wallet, also clears the cache. -5. `getUserInfo()` - This method returns the object of email, name, profileImage, and idToken. -6. `whitelistUrl()` - If you are deploying your site, you must whitelist your deployment URL. It returns signatures that you can pass to init functions. You can also pass the array of URLs to signatures. The signature in init is not required for localhost. - -Initialize the social login SDK - -```js -// create an instance of SocialLogin -const socialLogin = new SocialLogin(); -// init social login SDK, all params are optional -await socialLogin.init(); - -// pops up the UI widget -socialLogin.showWallet(); -``` - -For whitelisting your domain, please use the following code snippet. When deploying on prod it is required to whitelist your domain. In init, you can pass the domain and signature. - -```js -// get signature that corresponds to your website domains -const signature1 = await socialLogin.whitelistUrl("https://yourdomain1.com"); -const signature2 = await socialLogin.whitelistUrl("https://yourdomain2.com"); -// pass the signatures, you can pass one or many signatures you want to whitelist -await socialLogin.init({ - whitelistUrls: { - "https://yourdomain1.com": signature1, - "https://yourdomain2.com": signature2, - }, -}); -``` - -- Access to web3Auth provider after the wallet is connected - -```js -if (!socialLogin?.provider) return; -// create a provider from the social login provider that -// will be used by the smart account package of the Biconomy SDK -const provider = new ethers.providers.Web3Provider(socialLogin.provider); -// get a list of accounts available with the provider -const accounts = await provider.listAccounts(); -console.log("EOA address", accounts); -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/sdk-compatibility.md b/versioned_docs/version-1.0/guides/sdk-compatibility.md deleted file mode 100644 index f86072fe..00000000 --- a/versioned_docs/version-1.0/guides/sdk-compatibility.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -sidebar_position: 7 ---- - -# SDK Compatibility - -> Biconomy SDK compatibility - -The following table showcases the compatibility of our various packages with the given web libraries - -## Smart Account - -| Web Library | Github Links | -| ----------------------------- | -------------------------------------------------------------------------- | -| React.js | https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth | -| Next.js + Rainbow | https://github.com/bcnmy/sdk-examples/tree/master/nextjs-rainbow | -| Next.js + Web3Modal | https://github.com/bcnmy/sdk-examples/tree/master/nextjs-web3modal | -| Next.js + Biconomy's Web3Auth | https://github.com/bcnmy/sdk-examples/tree/master/nextjs-biconomy-web3Auth | - -## Social Login - -| Web Library | Github Links | -| ----------- | -------------------------------------------------------------------------- | -| React.js | https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth | -| Next.js | https://github.com/bcnmy/sdk-examples/tree/master/nextjs-biconomy-web3Auth | - -> Currently it is only compatible for web [Mobile package will be published soon] - -## Fiat On Ramp - -Fiat on Ramp in the Biconomy SDK is powered by Transak. It compiles to a JavaScript and supports all web libraries. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/guides/sdk-migration.md b/versioned_docs/version-1.0/guides/sdk-migration.md deleted file mode 100644 index 215231ee..00000000 --- a/versioned_docs/version-1.0/guides/sdk-migration.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -sidebar_position: 8 ---- - -# SDK Migration Guide - -> If you were previously using SDK version v1.0.0 and are now switching to v2.0.0, please note the following changes. - -## SmartAccount address - -Your SmartAccount address from the previous version will change in v2.0.0. This is because we have deployed new, audited contracts as we launch on mainnet. Going forward, your SmartAccount address will remain the same across all SDK versions. - -## Method Names - -We have updated the method names, to make it more simpler for devs, here we have documented the changes, all the docs code section is updated with the new method names. - -- Gasless Transaction - - sendGaslessTransaction -> sendTransaction - - sendGaslessTransactionBatch -> sendTransactionBatch -- User Pay in ERC20 tokens - - prepareRefundTransaction -> getFeeQuotes - - createRefundTransaction -> createUserPaidTransaction - - sendTransaction -> sendUserPaidTransaction - - prepareRefundTransactionBatch -> getFeeQuotesForBatch - - createRefundTransactionBatch -> createUserPaidTransactionBatch - - sendTransaction -> sendUserPaidTransaction diff --git a/versioned_docs/version-1.0/img/overview.png b/versioned_docs/version-1.0/img/overview.png deleted file mode 100644 index 5fd88299..00000000 Binary files a/versioned_docs/version-1.0/img/overview.png and /dev/null differ diff --git a/versioned_docs/version-1.0/overview.md b/versioned_docs/version-1.0/overview.md deleted file mode 100644 index 6aff7dd3..00000000 --- a/versioned_docs/version-1.0/overview.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -The Biconomy Software Development Kit (SDK) build purely on atop of ERC4337 solution, presents a comprehensive range of solutions, from user onboarding to sustained engagement, specifically designed for decentralised applications (dApps). This SDK functions in a non-custodial fashion, provides a unified solution that enhances the user experience within your dApp. - -Our innovative toolkit simplifies the onboarding process for new users while simultaneously addressing the daily transaction complexities experienced by existing users. The Biconomy SDK not only simplifies the user experience but also refines the underlying operations, seamlessly merging simplicity and functionality in the realm of decentralised applications. With its integration, your dApp is poised to offer an intuitive and effortless experience to its users, setting a new standard in user experience within the blockchain ecosystem. - -## What’s Possible? - -Biconomy SDK brings blockchain-agnostic, web2-like experiences to your dApp in a non-custodial manner. Here's what you can enable today: - -- Easy User Onboarding: Social login, account creation & recovery to seamlessly onboard web2 users. -- Fiat On Ramp: Let your users easily & reliably buy/sell crypto within your dApp. -- Gasless Transactions: dApps can sponsor gas fees to make user interactions as simple as web2 transactions. -- Paying Gas Fees In ERC20 Tokens: Users can utilize any ERC20 asset in their wallet to pay gas fees -- Custom Transaction Bundling: Allow developers to build methods to do transaction batching which enables users to execute multiple actions, even across multiple chains, in a single transaction. Eg. Approve and Deposit can be done in the same transaction without changing anything in dApp smart contracts. - -### How Does It Work: Smart Contract Wallets - -The backbone of the Biconomy SDK is a Smart Contract Wallet (SCW) which is created when any new user onboards to a dApp. - -SCW address is counterfactual in nature. That means the user gets the address instantly after logging into the system, without even deploying anything on-chain. The actual smart contract is deployed along with the first transaction of the user. - -![Overview](img/overview.png) - -A Smart Contract Wallet is a smart contract associated with each user's EOA (Externally Owned Account e.g. traditional MetaMask account or account generated via Social Login). We also call Smart Contract Wallets Smart Accounts. - -Smart Account is a non-custodial account. It provides added security compared to EOAs with a single private key. Users can deposit funds that no one else can control and withdraw at any point in time.' - -The SCW address can remain consistent across chains making it easy to provide a chainless experience for the user from within the dApp itself. dApps can enable all sorts of seamless interactions by leveraging transaction bundling with Smart Contract Wallets using Biconomy SDK. - -## How Smart Contract Wallets Work - -1. There’s an EOA attached to the SC Wallet, which acts as an owner of the SC Wallet. - -2. SC Wallet supports Modules to extend wallet functionality without upgrading it. Examples of Modules are MultiSig, Social Recovery Module, Recurring Transaction Module, Transaction Automation, Session Key Module, etc. - -3. Whenever any transaction is executed via this SC Wallet, it is initiated by the EOA in the form of a cryptographic signature. Txn data along with the signature is then relayed by a Relayer. - -4. The user's SC Wallet address is counterfactual. That means the SC Wallet address can be generated without actually deploying smart contract code on-chain. It’s possible thanks to the CREATE2 opcode. It also means that the SC Wallet address can remain the same on all EVM chains that support the same realization of the CREATE2 opcode. - -5. All dApp interactions on a given chain and all cross-chain interactions happen via this SC Wallet only. - -6. This SC Wallet also acts as a Gas Tank for the user and any token held by the SC Wallet (accepted by the Relayer) can be used to pay the gas fees back to the Relayer in the same transaction. - -7. This allows dApps to do transaction batching allowing users to execute multiple actions in a single transaction. Eg. Approve and Deposit can be done in the same transaction. diff --git a/versioned_docs/version-1.0/quickstart/_category_.json b/versioned_docs/version-1.0/quickstart/_category_.json deleted file mode 100644 index 3f10144b..00000000 --- a/versioned_docs/version-1.0/quickstart/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Quick Start", - "position": 2, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/quickstart/counter.md b/versioned_docs/version-1.0/quickstart/counter.md deleted file mode 100644 index c56c5346..00000000 --- a/versioned_docs/version-1.0/quickstart/counter.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Counter Smart Contract - -[Remix](https://remix.ethereum.org/) is a powerful, open source tool that helps you write Solidity contracts straight from the browser. Remix also supports testing, debugging and deploying of smart contracts and much more. - -It is recommended to use [Remix](https://remix.ethereum.org/) to create and deploy smart contracts quickly. - -In Remix, when opening a basic template you will see a folder called contracts. Right click on the folder and create a new contract called Counter.sol and begin typing the code below. - -## License - -At the start of your smart contract, you can declare a license. In this case, we will leave this as UNLICENSED as we are not too concerned about what this code is used for. - -``` -// SPDX-License-Identifier: UNLICENSED -``` - -## Mention Compiler Version - -``` -pragma solidity ^0.8.9; -``` - -:::caution -Make sure the solidity version declared in the contract matches your compiler version -::: - -Now let's write out our contract: - -```solidity -contract Counter { - uint256 public count; - - event updateCount(uint newCount); - - function incrementCount() public returns(uint256) { - count +=1; - emit updateCount(count); - return count; - } -} -``` - -Here is a breakdown of what this contract is doing: - -1. `uint256 public count`: This line declares a public unsigned integer variable named count. Unsigned integers are non-negative numbers. The `public` keyword automatically generates a function that allows you to access the current value of the `count` state variable from outside the contract. -2. `event updateCount(uint newCount)`: This line declares an event named `updateCount`. Events are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen. In this case, the event will emit the new value of `count`. -3. `function incrementCount() public returns(uint256)`: This line declares a public function named incrementCount that doesn't take any parameters and returns an unsigned integer. - Inside the incrementCount function: - -- `count +=1`: This line increases the `count` variable by one. -- `emit updateCount(count)`: This line triggers the `updateCount` event and sends the new value of the count variable to the listener. -- `return count`: This line returns the new value of `count`. - -Now that we have our basic contract let's deploy this to the Polygon Mumbai Test Network. You can follow the official [Remix Documentation](https://remix-ide.readthedocs.io/en/latest/run.html) for Deployment to get this deployed and verified. diff --git a/versioned_docs/version-1.0/quickstart/first-dapp.md b/versioned_docs/version-1.0/quickstart/first-dapp.md deleted file mode 100644 index 7760bdb5..00000000 --- a/versioned_docs/version-1.0/quickstart/first-dapp.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -sidebar_label: "Build your first AA powered dApp" -sidebar_position: 1 ---- - -# Build your first AA powered dApp - -This tutorial will cover the basics of creating a dApp powered by the Biconomy -SDK. Here's an overview of what you'll learn: - -- Build a basic smart contract that will act as a counter. -- Deploy the smart contract with Remix. -- Register the contract and its write methods on the Biconomy Dashboard. -- Create a frontend with React and Vite that allows for social logins and - gasless transactions with the Biconomy SDK. diff --git a/versioned_docs/version-1.0/quickstart/gasless-txn.md b/versioned_docs/version-1.0/quickstart/gasless-txn.md deleted file mode 100644 index 17640ef5..00000000 --- a/versioned_docs/version-1.0/quickstart/gasless-txn.md +++ /dev/null @@ -1,435 +0,0 @@ ---- -sidebar_position: 6 ---- - -# Creating a Gasless Transaction - -Now with our SDK integration set up let's render our UI and execute some transactions! First let's create a new import in our App.tsx file: - -```js -import Counter from "./Components/Counter"; -``` - -In the return for this component lets add the following JSX: - -```jsx -
-

Biconomy SDK Auth + Gasless Transactions

- {!smartAccount && !loading && } - {loading &&

Loading account details...

} - {!!smartAccount && ( -
-

Smart account address:

-

{smartAccount.address}

- - -
- )} -

- Edit src/App.tsx and save to test -

- - Click here to check out the docs - -
-``` - -If you followed all instructions from the last step to now your file should look something like this: - -```js -import './App.css' -import "@biconomy-sdk-dev/web3-auth/dist/src/style.css" -import { useState, useEffect, useRef } from 'react' -import SocialLogin from "@biconomy/web3-auth" -import { ChainId } from "@biconomy/core-types"; -import { ethers } from 'ethers' -import SmartAccount from "@biconomy/smart-account"; -import Counter from './Components/Counter'; - - -export default function App() { - const [smartAccount, setSmartAccount] = useState(null) - const [interval, enableInterval] = useState(false) - const sdkRef = useRef(null) - const [loading, setLoading] = useState(false) - const [provider, setProvider] = useState(null); - - useEffect(() => { - let configureLogin:any - if (interval) { - configureLogin = setInterval(() => { - if (!!sdkRef.current?.provider) { - setupSmartAccount() - clearInterval(configureLogin) - } - }, 1000) - } - }, [interval]) - - async function login() { - if (!sdkRef.current) { - const socialLoginSDK = new SocialLogin() - const signature1 = await socialLoginSDK.whitelistUrl('http://127.0.0.1:5173/') - await socialLoginSDK.init({ - chainId: ethers.utils.hexValue(ChainId.POLYGON_MUMBAI).toString(), - network: "testnet", - whitelistUrls: { - 'http://127.0.0.1:5173/': signature1, - } - }) - sdkRef.current = socialLoginSDK - } - if (!sdkRef.current.provider) { - sdkRef.current.showWallet() - enableInterval(true) - } else { - setupSmartAccount() - } - } - - async function setupSmartAccount() { - if (!sdkRef?.current?.provider) return - sdkRef.current.hideWallet() - setLoading(true) - const web3Provider = new ethers.providers.Web3Provider( - sdkRef.current.provider - ) - setProvider(web3Provider) - try { - const smartAccount = new SmartAccount(web3Provider, { - activeNetworkId: ChainId.POLYGON_MUMBAI, - supportedNetworksIds: [ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - dappAPIKey: import.meta.env.VITE_BICONOMY_API_KEY, - }, - ], - }) - await smartAccount.init() - setSmartAccount(smartAccount) - setLoading(false) - } catch (err) { - console.log('error setting up smart account... ', err) - } - } - - const logout = async () => { - if (!sdkRef.current) { - console.error('Web3Modal not initialized.') - return - } - await sdkRef.current.logout() - sdkRef.current.hideWallet() - setSmartAccount(null) - enableInterval(false) - } - - return ( -
-

Biconomy SDK Auth + Gasless Transactions

- { - !smartAccount && !loading && - } - { - loading &&

Loading account details...

- } - { - !!smartAccount && ( -
-

Smart account address:

-

{smartAccount.address}

- - -
- ) - } -

- Edit src/App.tsx and save to test -

- - Click here to check out the docs - -
- ) -} -``` - -Now lets create our Counter component! - -If you do not already have a Components folder go ahead and create one within source and create a new file called Counter.tsx - -We will also add `react-toastify` for a nice toast to update our users about their transactions. - -```bash -yarn add react-toastify -``` - -Let's add our imports for this file: - -```js -import React, { useState, useEffect } from "react"; -import SmartAccount from "@biconomy/smart-account"; -import abi from "../utils/counterAbi.json"; -import { ethers } from "ethers"; -import { ToastContainer, toast } from "react-toastify"; -import "react-toastify/dist/ReactToastify.css"; -``` - -Make sure to get the abi from the smart contract we deployed in the first step - I created a utils folder to house that json file. - -Here is an interface we will use for the props of this component: - -```js -interface Props { - smartAccount: SmartAccount - provider: any -} -``` - -Now we can start building out this Counter Component: - -```ts -const Counter: React.FC = ({ smartAccount, provider }) => {}; -``` - -Here we define a Functional component that with the props of `smartAccount` and `provider` - -We will track two things in state: a count and an instance of the counterContract as well as a variable for the smart account address. - -```ts -const [count, setCount] = useState(0); -const [counterContract, setCounterContract] = useState(null); - -const counterAddress = "address for smart account"; -``` - -With this done let's go into the two functions this component will have: - -```ts -const getCount = async (isUpdating: boolean) => { - const contract = new ethers.Contract(counterAddress, abi, provider); - setCounterContract(contract); - const currentCount = await contract.count(); - setCount(currentCount.toNumber()); - if (isUpdating) { - toast.success("count has been updated!", { - position: "top-right", - autoClose: 5000, - hideProgressBar: false, - closeOnClick: true, - pauseOnHover: true, - draggable: true, - progress: undefined, - theme: "dark", - }); - } -}; -``` - -The `getCount` function is an asynchronous function responsible for fetching the current value of the counter from a smart contract on a blockchain and setting the state of the contract and count in the component. - -1. **Create Contract Instance**: It first creates an instance of the smart contract using the `ethers.Contract` constructor. It takes three arguments - the contract address, the contract ABI (Application Binary Interface), and the Web3 provider. This contract instance allows you to interact with the contract on the blockchain. -2. **Set Contract State**: It then calls `setCounterContract(contract)` to set the state of counterContract to the instance of the contract it just created. -3. **Fetch Current Count**: It fetches the current value of the count from the smart contract by calling the `count()` function on the contract instance. Since this function interacts with the blockchain, it returns a Promise, hence the `await` keyword. -4. **Set Count State**: It then calls `setCount(currentCount.toNumber())` to set the state of count to the current value it just fetched. It converts the value to a number since the value returned from the contract is a BigNumber. -5. **Display Toast Notification**: If the `isUpdating` parameter is `true`, it displays a toast notification indicating that the count has been updated. This notification includes configuration for its position, auto-close time, behavior on click and hover, and theme. - -In summary, the `getCount` function creates a contract instance, sets the state of the contract, fetches the current value of the count from the contract, sets the state of the count, and optionally displays a toast notification. - -```ts -const incrementCount = async () => { - try { - toast.info("processing count on the blockchain!", { - position: "top-right", - autoClose: 5000, - hideProgressBar: false, - closeOnClick: true, - pauseOnHover: true, - draggable: true, - progress: undefined, - theme: "dark", - }); - const incrementTx = - await counterContract.populateTransaction.incrementCount(); - const tx1 = { - to: counterAddress, - data: incrementTx.data, - }; - const txResponse = await smartAccount.sendTransaction({ transaction: tx1 }); - - const txHash = await txResponse.wait(); - console.log(txHash); - getCount(true); - } catch (error) { - console.log({ error }); - toast.error("error occured check the console", { - position: "top-right", - autoClose: 5000, - hideProgressBar: false, - closeOnClick: true, - pauseOnHover: true, - draggable: true, - progress: undefined, - theme: "dark", - }); - } -}; -``` - -The `incrementCount` function is an asynchronous function that increments the count on the smart contract by sending a transaction to the blockchain. - -1. **Display Initial Toast Notification**: The function begins by displaying a toast notification to inform the user that the count is being processed on the blockchain. -2. **Create Transaction**: It then creates a transaction object using the counterContract.`populateTransaction.incrementCount()` function. This function prepares the data needed to call the `incrementCount` function on the smart contract but does not send the transaction. The returned transaction object includes the data needed to call the function. -3. **Define Transaction Parameters**: It defines the parameters for the transaction in `tx1`. This includes the address of the contract in to and the data needed to call the function in `data`. -4. **Send Transaction**: It sends the transaction to the blockchain using the `smartAccount.sendTransaction()` function. This function takes an object with the transaction parameters and sends the transaction. Since this function interacts with the blockchain, it returns a Promise, hence the await keyword. -5. **Wait for Transaction Confirmation**: It then calls `txResponse.wait()` to wait for the transaction to be confirmed on the blockchain. This function also returns a Promise, hence the `await` keyword. -6. **Log Transaction Hash**: Once the transaction is confirmed, the transaction hash is logged to the console with `console.log(txHash)`. -7. **Update Count**: It then calls `getCount(true)` to fetch the updated count from the smart contract and update the state in the component. The true argument means that a toast notification will be displayed to indicate that the count has been updated. -8. **Error Handling**: If an error occurs during this process, it is caught by the `catch` block. The error is logged to the console with `console.log({error})` and a toast notification is displayed to inform the user that an error occurred. - -In summary, the `incrementCount` function sends a transaction to a smart contract on a blockchain to increment a count, waits for the transaction to be confirmed, fetches the updated count, and handles any errors that occur during this process. - -Finally we round all this up by displaying the UI for our Toast and button: - -```ts -return( - <> - - - - ) -``` - -Congratulations you just created your first AA powered dApp. Users can now log in and have a smart account created for them and interact with a smart contract without the need to purchase any tokens to pay for gas. Here is the complete implimintation of this component: - -```ts -import React, { useState, useEffect } from "react"; -import SmartAccount from "@biconomy/smart-account"; -import abi from "../utils/counterAbi.json"; -import { ethers } from "ethers"; -import { ToastContainer, toast } from 'react-toastify'; -import 'react-toastify/dist/ReactToastify.css'; - -interface Props { - smartAccount: SmartAccount - provider: any -} - - -const Counter: React.FC = ({ smartAccount, provider }) => { - const [count, setCount] = useState(0) - const [counterContract, setCounterContract] = useState(null) - const [isLoading, setIsLoading] = useState(false); - - const counterAddress = "address for smart account" - - useEffect(() => { - setIsLoading(true) - getCount(false) - },[]) - - const getCount = async (isUpdating: boolean) => { - const contract = new ethers.Contract( - counterAddress, - abi, - provider, - ) - setCounterContract(contract) - const currentCount = await contract.count() - setCount(currentCount.toNumber()) - if(isUpdating) { - toast.success('count has been updated!', { - position: "top-right", - autoClose: 5000, - hideProgressBar: false, - closeOnClick: true, - pauseOnHover: true, - draggable: true, - progress: undefined, - theme: "dark", - }); - } - } - - const incrementCount = async () => { - try { - toast.info('processing count on the blockchain!', { - position: "top-right", - autoClose: 5000, - hideProgressBar: false, - closeOnClick: true, - pauseOnHover: true, - draggable: true, - progress: undefined, - theme: "dark", - }); - const incrementTx = await counterContract.populateTransaction.incrementCount() - const tx1 = { - to: counterAddress, - data: incrementTx.data, - } - const txResponse = await smartAccount.sendTransaction({ transaction: tx1}) - - const txHash = await txResponse.wait(); - console.log(txHash) - getCount(true) - - } catch (error) { - console.log({error}) - toast.error('error occured check the console', { - position: "top-right", - autoClose: 5000, - hideProgressBar: false, - closeOnClick: true, - pauseOnHover: true, - draggable: true, - progress: undefined, - theme: "dark", - }); - } - } - return( - <> - - - - ) -}; - -export default Counter; -``` - -If you would like to see the completed project on github you can use the template below: - -https://github.com/Rahat-ch/biconomy-sdk-social-gasless-starter diff --git a/versioned_docs/version-1.0/quickstart/initialize.md b/versioned_docs/version-1.0/quickstart/initialize.md deleted file mode 100644 index 3c71cfa0..00000000 --- a/versioned_docs/version-1.0/quickstart/initialize.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -sidebar_position: 4 ---- - -# Initialize Frontend - -Now it is time to work on our Frontend. We will be using React and Vite to build this to keep our frontend simple and the default React and Vite template actually gives us a nice Counter button UI to connect with our contract. - -You can learn more about how to set up this frontend [here](https://vitejs.dev/guide/#scaffolding-your-first-vite-project) or just follow the instructions below. - -With NPM: - -```bash -npm create vite@latest -``` - -With Yarn: - -```bash -yarn create vite -``` - -With PNPM: - -```bash -pnpx create vite -``` - -You can follow the prompts to receive the scaffolding for your React application. You can use any of the package managers of your choice, but to keep things simple we will be using Yarn from this point. - -Install the following dependencies: - -```bash -yarn add @biconomy/core-types @biconomy/smart-account @biconomy/web3-auth ethers@5.7.2 -``` - -We will use these tools to build out our front end. In addition, lets also install the following: - -```bash -yarn add @esbuild-plugins/node-globals-polyfill rollup-plugin-polyfill-node stream-browserify -``` - -After installing the above dependencies update you vite.config.ts to the following: - -```js -import react from "@vitejs/plugin-react"; -import { defineConfig } from "vite"; -import { NodeGlobalsPolyfillPlugin } from "@esbuild-plugins/node-globals-polyfill"; - -export default defineConfig({ - plugins: [react()], - optimizeDeps: { - esbuildOptions: { - define: { - global: "globalThis", - }, - plugins: [ - NodeGlobalsPolyfillPlugin({ - buffer: true, - }), - ], - }, - }, - resolve: { - alias: { - process: "process/browser", - stream: "stream-browserify", - util: "util", - }, - }, -}); -``` - -This configuration deals with a few breaking changes introduced by webpack 5. You can learn more about these changes [here.](https://docs.biconomy.io/references/common-errors) diff --git a/versioned_docs/version-1.0/quickstart/register.md b/versioned_docs/version-1.0/quickstart/register.md deleted file mode 100644 index f20c4d8b..00000000 --- a/versioned_docs/version-1.0/quickstart/register.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Register your Smart Contract - -Follow the instructions [on this page](https://docs.biconomy.io/guides/biconomy-dashboard) to register your smart contract on the Biconomy Dashboard and receive an API key needed to use the SDK. - -Before continuing onto the the next step be sure that you have completed the following: - -- Created an account on the Biconomy Dashboard. -- Register a new paymaster on the Dashboard. -- Set up a Gas tank with at least 1-2 testnet Matic tokens. -- Whitelisting the increment count method of the counter smart contract. diff --git a/versioned_docs/version-1.0/quickstart/sdk-integration.md b/versioned_docs/version-1.0/quickstart/sdk-integration.md deleted file mode 100644 index 459e7239..00000000 --- a/versioned_docs/version-1.0/quickstart/sdk-integration.md +++ /dev/null @@ -1,165 +0,0 @@ ---- -sidebar_position: 5 ---- - -# SDK Integration - -Now let's get to work on our App.tsx file! - -First lets update some of our imports. I've changed the initial imports to the following: - -```js -import "./App.css"; -import "@biconomy-sdk-dev/web3-auth/dist/src/style.css"; -import { useState, useEffect, useRef } from "react"; -import SocialLogin from "@biconomy/web3-auth"; -import { ChainId } from "@biconomy/core-types"; -import { ethers } from "ethers"; -import SmartAccount from "@biconomy/smart-account"; -``` - -I'm still using the supplied css given to us by the template but am also importing some css from the Web3 Auth SDK. Note that this is optional and you can build your own login UI but for now we will keep things simple. - -Here is information about the rest of the imports: - -- `useState`, `useEffect`, `useRef`: React hooks for managing component state and lifecycle. -- `SocialLogin` from `@biconomy/web3-auth`: A class from Biconomy SDK that allows you to leverage Web3Auth for social logins. -- ChainId from `@biconomy/core-types`: An enumeration of supported blockchain networks. -- `ethers`: A library for interacting with Ethereum. -- `SmartAccount` from `@biconomy/smart-account`: A class from Biconomy SDK that will allow us to create smart accounts and interact with our contract with them. - -Let's take a look at some state variables that will help us with our implementation: - -```js -const [smartAccount, setSmartAccount] = - (useState < SmartAccount) | (null > null); -const [interval, enableInterval] = useState(false); -const sdkRef = (useRef < SocialLogin) | (null > null); -const [loading, setLoading] = useState < boolean > false; -const [provider, setProvider] = useState < any > null; -``` - -Here we have some state that will be used to track our smart account that will be generated with the sdk, an interval that will help us with checking for login status, a loading state, provider state to track our web3 provider and a reference to our Social login sdk. - -Next let's add a `useEffect` hook: - -```js -useEffect(() => { - let configureLogin: any; - if (interval) { - configureLogin = setInterval(() => { - if (!!sdkRef.current?.provider) { - setupSmartAccount(); - clearInterval(configureLogin); - } - }, 1000); - } -}, [interval]); -``` - -This use effect will be triggered after we open our login component, which we'll create a function for shortly. Once a user opens the component it will check if a provider is available and run the functions for setting up the smart account. - -Now our login function: - -```js -async function login() { - if (!sdkRef.current) { - const socialLoginSDK = new SocialLogin(); - const signature1 = await socialLoginSDK.whitelistUrl( - "http://127.0.0.1:5173/", - ); - await socialLoginSDK.init({ - chainId: ethers.utils.hexValue(ChainId.POLYGON_MUMBAI).toString(), - network: "testnet", - whitelistUrls: { - "http://127.0.0.1:5173/": signature1, - }, - }); - sdkRef.current = socialLoginSDK; - } - if (!sdkRef.current.provider) { - sdkRef.current.showWallet(); - enableInterval(true); - } else { - setupSmartAccount(); - } -} -``` - -The `login` function is an asynchronous function that handles the login flow for the application. Here's a step-by-step explanation: - -1. **SDK Initialization**: The function first checks if the `sdkRef` object (which is a reference to the Biconomy SDK instance) is null. If it is, it means that the SDK is not yet initialized. In this case, it creates a new instance of `SocialLogin` (a Biconomy SDK component), whitelists a local URL (`http://127.0.0.1:5173/`), and initializes the SDK with the Polygon Mumbai testnet configuration and the whitelisted URL. After initialization, it assigns the SDK instance to sdkRef.current. -2. **Provider Check**: After ensuring the SDK is initialized, the function checks if the provider of the `sdkRef` object is set. If it is not, it means the user is not yet logged in. It then shows the wallet interface for the user to login using `sdkRef.current.showWallet()`, and enables the interval by calling `enableInterval(true)`. This interval (setup in a useEffect hook elsewhere in the code) periodically checks if the provider is available and sets up the smart account once it is. -3. **Smart Account Setup**: If the provider of sdkRef is already set, it means the user is logged in. In this case, it directly sets up the smart account by calling `setupSmartAccount()`. - -In summary, the `login` function handles the SDK initialization and login flow. It initializes the SDK if it's not already initialized, shows the wallet interface for the user to login if they're not logged in, and sets up the smart account if the user is logged in. - -:::caution -It is important to make sure that you update the whitelist URL with your production url when you are ready to go live! -::: - -Now lets actually set up the smart account: - -```solidity - async function setupSmartAccount() { - if (!sdkRef?.current?.provider) return - sdkRef.current.hideWallet() - setLoading(true) - const web3Provider = new ethers.providers.Web3Provider( - sdkRef.current.provider - ) - setProvider(web3Provider) - try { - const smartAccount = new SmartAccount(web3Provider, { - activeNetworkId: ChainId.POLYGON_MUMBAI, - supportedNetworksIds: [ChainId.POLYGON_MUMBAI], - networkConfig: [ - { - chainId: ChainId.POLYGON_MUMBAI, - dappAPIKey: "your dapp api key from biconomy dashboard", - }, - ], - }) - await smartAccount.init() - setSmartAccount(smartAccount) - setLoading(false) - } catch (err) { - console.log('error setting up smart account... ', err) - } - } -``` - -The `setupSmartAccount` function is an asynchronous function used to initialize a smart account with Biconomy and connect it with the Web3 provider. Here's a step-by-step explanation of what it does: - -1. **Check Provider Availability**: The function first checks if the provider of the `sdkRef` object is available. If not, it immediately returns and the rest of the function is not executed. The `sdkRef` object refers to the Biconomy SDK instance that was stored using the `useRef` React Hook. -2. **Hide Wallet**: If the provider is available, it hides the wallet interface using `sdkRef.current.hideWallet()`. -3. **Set Loading Status**: It then sets the loading state to `true` by calling `setLoading(true)`. This could be used in the UI to show a loading spinner or other loading indicators. -4. **Create Web3 Provider**: It creates a new Web3 provider using the `ethers` library and the provider from `sdkRef`. This provider is then saved in the state by calling `setProvider(web3Provider)`. -5. **Create and Initialize Smart Account**: It then creates a new `SmartAccount` object using the Web3 provider and a configuration object. This configuration object sets the active network to Polygon Mumbai, the supported networks, and the network configuration, including the chain ID and the Biconomy API key. After creating the smart account, it initializes it by calling `smartAccount.init()`. This is an asynchronous operation, hence the `await` keyword. -6. **Save Smart Account and Update Loading Status**: After the smart account is initialized, it is saved in the state by calling `setSmartAccount(smartAccount)`. The loading status is then set to `false` by calling `setLoading(false)`. -7. **Error Handling**: If any error occurs during the creation or initialization of the smart account, it is caught in the `catch` block and logged to the console. - -So, in summary, the `setupSmartAccount` function checks the availability of the Biconomy provider, hides the wallet interface, sets up a Web3 provider, creates and initializes a smart account, and then saves this account and the Web3 provider in the state. If any error occurs during this process, it is logged to the console. - -Finally our last function will be a logout function: - -```js -const logout = async () => { - if (!sdkRef.current) { - console.error("Web3Modal not initialized."); - return; - } - await sdkRef.current.logout(); - sdkRef.current.hideWallet(); - setSmartAccount(null); - enableInterval(false); -}; -``` - -The `logout` function is an asynchronous function that handles the logout flow for the application. Here's a breakdown of its functionality: - -1. **Check SDK Initialization**: The function first checks if the `sdkRef` object (which is a reference to the Biconomy SDK instance) is null. If it is, it means that the SDK is not yet initialized. In this case, it logs an error message and returns immediately without executing the rest of the function. -2. **Logout and Hide Wallet**: If the SDK is initialized, it logs the user out by calling `sdkRef.current.logout()`. This is an asynchronous operation, hence the await keyword. It then hides the wallet interface by calling `sdkRef.current.hideWallet()`. -3. **Clear Smart Account and Interval**: After logging the user out and hiding the wallet, it clears the smart account by calling `setSmartAccount(null)`, and disables the interval by calling `enableInterval(false)`. - -In summary, the logout function checks if the SDK is initialized, logs the user out and hides the wallet if it is, and then clears the smart account and disables the interval. If the SDK is not initialized, it logs an error message and does not execute the rest of the function. diff --git a/versioned_docs/version-1.0/references/_category_.json b/versioned_docs/version-1.0/references/_category_.json deleted file mode 100644 index c39365f2..00000000 --- a/versioned_docs/version-1.0/references/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "References", - "position": 9, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/references/common-errors.md b/versioned_docs/version-1.0/references/common-errors.md deleted file mode 100644 index 0655fd16..00000000 --- a/versioned_docs/version-1.0/references/common-errors.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Common Errors - -> List of common errors faced while integrating and how to debug. - -## Polyfills Issue (React.js/Next.js) - -`Error example: 'crypto' not found...` - -[Github](https://github.com/bcnmy/biconomy-client-sdk/issues/87) - -## CSS Issue with Social Login - -`Error example: Social Login modal css not loading/breaking` - -Solution: - -```js -import "@biconomy/web3-auth/src/style.css"; -``` - -https://github.com/bcnmy/biconomy-client-sdk/issues/75 - -## Next js: document not found - -`Error: document not found while using Next.js` - -Solution: This happens because the code try to find the root element and create a div via DOM document, but if you are using server-side Next.js then the lib is not able to find the document. This fix is by rendering that component via the next dynamics. An example code is below and the full code setup is [here](https://github.com/bcnmy/sdk-examples/tree/master/nextjs-biconomy-web3Auth). - -```js -import dynamic from "next/dynamic"; -import { Suspense } from "react"; - -const Index = () => { - const SocialLoginDynamic = dynamic( - () => import("../components/SocialLogin").then((res) => res.default), - { - ssr: false, - }, - ); - - return ( -
- Loading...
}> - - - - ); -}; - -export default Index; -``` diff --git a/versioned_docs/version-1.0/references/error-codes.md b/versioned_docs/version-1.0/references/error-codes.md deleted file mode 100644 index e9a8ee6c..00000000 --- a/versioned_docs/version-1.0/references/error-codes.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Error Codes - -> Error code responses from Smart Contracts (business logic revert), Backend node and Relayer. - -## General init related - -- `BSA000`: `Could not finish initialisation` - -## General gas/ execution related - -- `BSA010`: `Not enough gas to execute Safe transaction` -- `BSA011`: `Could not pay gas costs with ether` -- `BSA012`: `Could not pay gas costs with token` -- `BSA013`: `Transaction failed when gasPrice and targetTxGas was 0` - -## General signature validation related - -- `BSA021`: `Invalid contract signature location: inside static part` -- `BSA022`: `Invalid contract signature location: length not present` -- `BSA023`: `Invalid contract signature location: data not complete` -- `BSA024`: `Invalid contract signature provided` - -## General auth related - -- `BSA031`: `Method can only be called from this contract` - -## Module management related - -- `BSA100`: `Modules have already been initialised` -- `BSA101`: `Invalid module address provided` -- `BSA102`: `Module has already been added` -- `BSA103`: `Invalid prevModule, module pair provided` -- `BSA104`: `Method can only be called from an enabled module` diff --git a/versioned_docs/version-1.0/references/using-packages.md b/versioned_docs/version-1.0/references/using-packages.md deleted file mode 100644 index 79287560..00000000 --- a/versioned_docs/version-1.0/references/using-packages.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Using Packages - -> Biconomy SDK exports several packages which can aid your development. - -## Node Client Package - -This package is responsible for the communication between the Client SDK and the Backend Node. - -## Installation - -```bash -yarn add @biconomy/node-client -``` - -or - -```bash -npm install @biconomy/node-client -``` - -## Initialization - -```js -import NodeClient from "@biconomy/node-client"; -const nodeClient = new NodeClient({ - txServiceUrl: "https://sdk-backend.prod.biconomy.io/v1/", -}); -``` - -## Get all the supported Chains - -```js -const supportedChainList = await nodeClient.getAllSupportedChains(); -console.log(supportedChainList); -``` - -## Get all the supported Token - -```js -const supportedTokensList = await nodeClient.getAllTokens(); -console.log(supportedTokensList); -``` - -## Get all the Smart Accounts By Owner - -```js -import { SmartAccountByOwnerDto } from "@biconomy/node-client" - -const smartAccountByOwnerDto: SmartAccountByOwnerDto { -chainId: 1, // network of your choice -owner: 'abcxxx....' // eoa address from whom you want to know smart wallet address -} - -const smartAccountsByOwner = await nodeClient.getSmartAccountsByOwner(smartAccountByOwnerDto) -console.log(smartAccountsByOwner) -``` - -## Get Smart Account Balances - -```js -import { BalancesDto } from '@biconomy/node-client' - -import { ChainId } from '@biconomy/core-types' - -const balanceParams: BalancesDto = - { - // if no chainId is supplied, SDK will automatically pick active one that - // is being supplied for initialization - chainId: ChainId.MAINNET, // chainId of your choice - eoaAddress: smartAccount.address, - // If empty string you receive balances of all tokens watched by Indexer - // you can only whitelist token addresses that are listed in token respostory - // specified above ^ - tokenAddresses: [], - }; - - -const balFromSdk = await smartAccount.getAlltokenBalances(balanceParams); -console.info(balFromSdk); - -const usdBalFromSdk = await smartAccount.getTotalBalanceInUsd(balanceParams); -console.info(usdBalFromSdk); -``` diff --git a/versioned_docs/version-1.0/sdk-reference/_category_.json b/versioned_docs/version-1.0/sdk-reference/_category_.json deleted file mode 100644 index ba88c25a..00000000 --- a/versioned_docs/version-1.0/sdk-reference/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "SDK Reference", - "position": 5, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/sdk-reference/initialize-smart-account.md b/versioned_docs/version-1.0/sdk-reference/initialize-smart-account.md deleted file mode 100644 index abf7060d..00000000 --- a/versioned_docs/version-1.0/sdk-reference/initialize-smart-account.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Initialize Smart Account Instance - -> Connecting your EOA signer account for multi-chain Smart Account access - -:::info -Biconomy Smart Account is a Smart Contract Wallet that sits on top of your EOA account. EOA is the controller for this smart account and authorizes transactions with signing. -::: - -To create Smart Account, you need to pass EOA and provider. - -In this example, we start using `Web3AuthContext` with the `useWeb3AuthContext()`method. And we take the address and provider from this context. - -You can replace this with your wallet provider object and EOA address. - -:::info -Web3AuthContext is a [React Context](https://www.freecodecamp.org/news/react-context-for-beginners/) to store Social Login values. -Please refer to the [demo React app repository](https://github.com/bcnmy/sdk-examples/tree/master/react-biconomy-web3Auth) which uses contexts for more details on this approach. -::: - -```js -import { ChainId } from "@biconomy/core-types"; -import { useWeb3AuthContext } from "./contexts/SocialLoginContext"; - -import SmartAccount from "@biconomy/smart-account"; - -// Get the EOA and provider from the wallet of your choice. -const { provider, address } = useWeb3AuthContext(); -const walletProvider = new ethers.providers.Web3Provider(provider); - -// Initialize the Smart Account - -let options = { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ - ChainId.GOERLI, - ChainId.POLYGON_MAINNET, - ChainId.POLYGON_MUMBAI, - ], -}; - -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); -``` - -The above code connects your EOA signer and spins up a multi-chain instance of the Smart Account - -:::info -Options that can be provided for Smart Account initialization are below. If you don't provide any of the values it gets merged with the default Biconomy SDK config. -::: - -```js -export interface SmartAccountConfig { - activeNetworkId: ChainId // active (default) networkId - supportedNetworksIds: ChainId[] // array of supported networks your Dapp is on - backendUrl: string - relayerUrl: string // if you're running your own relayer provide url here - socketServerUrl: string // specific to biconomy messaging sdk - signType: SignTypeMethod // by default is EIP712_SIGN - networkConfig: NetworkConfig[] // array of chain specific network config - entryPointAddress?: string // optional entry point address - biconomySigningServiceUrl?: string - bundlerUrl?: string // bundlerUrl to fallback to if chain specific is not provided - environment?: Environments // environment PROD/STAGING/DEV -} - -// where NetworkConfig is... - -export type NetworkConfig = { - chainId: ChainId - providerUrl?: string // custom RPC url of your choice - bundlerUrl?: string // if you're running your own bundler provide url here - customPaymasterAPI?: IPaymasterAPI // if you need to plug in custom paymaster - dappAPIKey?: string // optional dapp api key. must be added while using Biconomy paymaster dashboard -} -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/installation.md b/versioned_docs/version-1.0/sdk-reference/installation.md deleted file mode 100644 index 774b4983..00000000 --- a/versioned_docs/version-1.0/sdk-reference/installation.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Installation - -> Biconomy SDK ships multiple development libraries as single Monorepo. - -First install the main package of Biconomy SDK which is [smart-account](https://www.npmjs.com/package/@biconomy/smart-account). - -```bash -yarn add @biconomy/smart-account -``` - -or - -```bash -npm install @biconomy/smart-account -``` - -You can find the source code of all shipped packages on [Github](https://github.com/bcnmy/biconomy-client-sdk). - -:::info -After webpack version >=5, NodeJS polyfills are not included and user have to configure the webpack themselves. If you're facing a problem with polyfills in your front end app check out below issue - -https://github.com/bcnmy/biconomy-client-sdk/issues/87 -::: - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/network-supported.md b/versioned_docs/version-1.0/sdk-reference/network-supported.md deleted file mode 100644 index 0fe9256a..00000000 --- a/versioned_docs/version-1.0/sdk-reference/network-supported.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -sidebar_position: 8 ---- - -# Networks Supported - -Biconomy Smart Accounts are multi-chain. In order to make your users interact on another chain using their Smart Account, you'd only need to change either activeChainId or when interacting pass the chainId as part of Data Transfer Object (txn method argument). We currently have support for the following blockchain networks & will be adding more soon. - -## Mainnets - -1. Ethereum -2. Polygon - -## Testnets - -1. Goerli -2. Mumbai -3. BSC Testnet - -Haven't found the Network you are looking for? Do not worry, [Contact us](https://docs.biconomy.io/comm/contact-us) for the network support. diff --git a/versioned_docs/version-1.0/sdk-reference/network-switch.md b/versioned_docs/version-1.0/sdk-reference/network-switch.md deleted file mode 100644 index 963ef622..00000000 --- a/versioned_docs/version-1.0/sdk-reference/network-switch.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -sidebar_position: 7 ---- - -# Network Switching - -Let's talk about network switching. Biconmy SDK allows for easy network switching. - -```js -import { ChainId } from "@biconomy/core-types"; -import SmartAccount from "@biconomy/smart-account"; - -// Get the EOA provider for choice of your wallet which manages your signer - -const { provider, address } = useWeb3AuthContext(); -const walletProvider = new ethers.providers.Web3Provider(provider); - -// Initialize the Smart Account - -let options = { - activeNetworkId: ChainId.GOERLI, - supportedNetworksIds: [ - ChainId.GOERLI, - ChainId.POLYGON_MAINNET, - ChainId.POLYGON_MUMBAI, - ], -}; - -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); -``` - -In the example above, Goerli has been selected as the currently active chain. Goerli, Polygon Mainnet, and Polygon Mumbai are the supported chains. - -Once the wallet instance is instantiated, and the default chain is selected, dApp can choose to make transactions on any of the supported chains other than a currently active chain. - -You can do that in two ways. - -## Active switching - -The first one is active switching to a different network (for complete smart account API) - -```js -// you can change your active chain and make transactions -smartAccount.setActiveChain(ChainId.POLYGON_MAINNET); -// Now your default active chain has been changed from GOERLI to POLYGON MAINNET -``` - -## Temporary Switching - -The second way is to just change the **chainId** in the DTO (Data Transfer Object) of the method. This will only affect the current action while the remaining actions will be executed on the chain that is currently active by default. - -```js -const txResponse = await smartAccount.sendTransaction({ - chainId: ChainId.POLYGON_MAINNET, - transaction: tx1, -}); -``` - -When instantiating the wallet instance, GOERLI is currently used as the default chainId. - -However, in the Transaction DTO you state Polygon Mainnet as the chain to execute this exact transaction on. - -List of the methods whose DTOs support custom ChainId - -```js -1. sendTransaction( - transactionDto: TransactionDto - ): Promise - -2. sendTransactionBatch( - transactionBatchDto: TransactionBatchDto - ): Promise - -3. getAlltokenBalances( - balancesDto: BalancesDto, - chainId: ChainId = this.#smartAccountConfig.activeNetworkId - ): Promise - -4. getTotalBalanceInUsd( - balancesDto: BalancesDto, - chainId: ChainId = this.#smartAccountConfig.activeNetworkId - ): Promise - -5. getSmartAccountsByOwner( - smartAccountByOwnerDto: SmartAccountByOwnerDto - ) - -6. getTransactionByAddress( - chainId: number, - address: string - ): Promise - -7. signTransaction(signTransactionDto: SignTransactionDto): Promise - -8. sendTransaction(sendTransactionDto: SendTransactionDto): Promise - -9. getFeeQuotesForBatch( - getFeeQuotesForBatchDto: PrepareRefundTransactionDto - ): Promise - -10. prepareRefundTransactionBatch( - getFeeQuotesForBatchDto: GetFeeQuotesForBatchDto - ): Promise - -11. createUserPaidTransaction( - createUserPaidTransactionDto: CreateUserPaidTransactionDto - ): Promise - -12. createTransaction(transactionDto: TransactionDto): Promise - -13. createTransactionBatch( - transactionBatchDto: TransactionBatchDto - ): Promise - -14. createRefundTransactionBatch( - refundTransactionBatchDto: RefundTransactionBatchDto - ): Promise - -15. getAddress( - addressForCounterFactualWalletDto: AddressForCounterFactualWalletDto - ) -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/send-batch-txn.md b/versioned_docs/version-1.0/sdk-reference/send-batch-txn.md deleted file mode 100644 index 03e6b197..00000000 --- a/versioned_docs/version-1.0/sdk-reference/send-batch-txn.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -sidebar_position: 5 ---- - -# Sending a Batch of Transactions - -> One Click Batching With Atomicity - -With batching functionality, you can send multiple user actions in a single native transaction on Smart Account. - -In this example, the user approves `amount` of USDC to the Hyphen Liquidity Pool. Then user adds liquidity to the pool by calling the `addTokenLiquidity` function that transfers part of the approved USDC from the user's Smart Account to itself. - -`USDCAddress.approve` and `hyphenLiquidityPoolAddress.addTokenLiquidity` methods calls are batched together and executed as a single on-chain transaction. - -In order to create a batch of transactions, just create a Transaction Request array and push individual transaction requests (destination contract and encoded data for method to be called) to it. - -```js -// Init Smart account instance - -const usdcAddress = -const hyphenLiquidityPoolAddress = // spender - -// create an array of txs -const txs = [] - -const erc20Interface = new ethers.utils.Interface([ - 'function approve(address _to, uint256 _value)' -]) - -// Encode an ERC-20 token approval. User approves the amount of tokens to the Hyphen LP -const data = erc20Interface.encodeFunctionData( - 'approve', [hyphenLiquidityPoolAddress, amount] -) - -const tx1 = { - to: usdcAddress - data: data -} - -txs.push(tx1) - -const hyphenLPTx = - await hyphenContract.populateTransaction.addTokenLiquidity( - usdcAddress, - ethers.BigNumber.from("1000000") // providing liquidity for 1 USDC - ); - -const tx2 = { - to: hyphenLiquidityPoolAddress, - data: hyphenLPTx.data, -}; - -txs.push(tx2); - -// Fee Abstraction and Dispatching - -// 1. Gasless -const txResponse = await smartAccount.sendTransactionBatch({ transactions: txs }); -console.log('userOp Hash', txResponse); -const txReciept = await txResponse.wait(); -console.log('Tx hash', txReciept.transactionHash); - -// 2. User Self Refund (Native / ERC20) -const feeQuotes = await smartAccount.getFeeQuotesForBatch({ - transactions: txs, -}); - -// Choose a fee quote of your choice provided by the relayer -const transaction = await smartAccount.createUserPaidTransactionBatch({ - transactions: txnArray, - feeQuote: feeQuotes[1], -}); - -// optional -let gasLimit: GasLimit = { - hex: "0x1E8480", - type: "hex", -}; - -// send transaction internally calls signTransaction and sends it to connected relayer -const txHash = await smartAccount.sendUserPaidTransaction({ - tx: transaction, - gasLimit, -}); -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/send-txn/_category_.json b/versioned_docs/version-1.0/sdk-reference/send-txn/_category_.json deleted file mode 100644 index ffdc2a02..00000000 --- a/versioned_docs/version-1.0/sdk-reference/send-txn/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Send Transactions", - "position": 4, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/_category_.json b/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/_category_.json deleted file mode 100644 index 343ee7b4..00000000 --- a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Gasless Transactions", - "position": 2, - "link": { - "type": "generated-index" - } -} diff --git a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/overview.md b/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/overview.md deleted file mode 100644 index d2a27a31..00000000 --- a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/overview.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -> Gasless transactions are supported using Account abstraction Paymasters and Biconomy Paymaster Dashboard for your managed gas tank. - -Gasless sponsorships can be managed by passing relevant parameters in the Smart Account custom config. - -## Dapp API Key - -Please sign up to Biconomy Dashboard to create your dApp, get the API key for it, and set up the Gas Tank to sponsor transactions for your users. - -:::note -The dashboard is not live yet and will be launching soon. Meanwhile, to enable Gasless transactions please reach out to us. -::: - -:::info -Gasless transactions are currently supported on all the major testnets and selected mainnets. - -If you have problems with using the Dashboard and configuring your dApp and Gas Tank, feel free to get in touch with us for spinning up personal test keys and gas tanks on other test networks. -::: - -# Link your Custom Paymaster - -:::info -You only need to either pass dApp API Key or Custom Paymaster Api in the Smart Account Config (options) -> Network Config -::: - -:::info -Custom Paymaster should implement the `IPaymaster` interface to `getPaymasterAndData` for 4337 User Operation. -::: - -Here's what configuration initialization looks like to enable gasless transactions through Smart Contract Wallets. - -```js -/// only used for creating your custom paymaster -import { IPaymaster, ChainId } from "@biconomy/core-types"; - -import SmartAccount from "@biconomy/smart-account"; -// initialise Smart Account - -const { provider, address } = useWeb3AuthContext(); -const walletProvider = new ethers.providers.Web3Provider(provider); - -// Initialize the Smart Account - -export let activeChainId = ChainId.GOERLI; -export const supportedChains = [ - ChainId.GOERLI, - ChainId.POLYGON_MAINNET, - ChainId.POLYGON_MUMBAI, -]; - -let options = { - activeNetworkId: activeChainId, - supportedNetworksIds: supportedChains, - // Network Config. - // Link Paymaster / DappAPIKey for the chains you'd want to support Gasless transactions on - networkConfig: [ - { - chainId: ChainId.GOERLI, - dappAPIKey: "", // if you are using Biconomy Paymaster configured from a Dashboard - // customPaymasterAPI: - }, - ], -}; - -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sendind-erc1155.md b/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sendind-erc1155.md deleted file mode 100644 index 87fdbc7c..00000000 --- a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sendind-erc1155.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Sending ERC-1155 Tokens - -Create a transaction on smart account that transfers single ERC-1155 token similar to sending an ERC20 or ERC721 token. - -Once you have the [Smart Account instance initialized](../../initialize-smart-account) with the appropriate config, check the code below. - -```js -const erc1155Interface = new ethers.utils.Interface([ - "function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data)", -]); - -// Encode the transfer of the collectible to recipient -const address = await smartAccount.address; -const data = erc1155Interface.encodeFunctionData("safeTransferFrom", [ - address, - recipientAddress, - tokenId, - amount, - "0x", -]); - -const tx1 = { - to: nftAddress, - data, -}; - -// Transaction events subscription -smartAccount.on("txHashGenerated", (response) => { - console.log("txHashGenerated event received via emitter", response); -}); -smartAccount.on("txMined", (response) => { - console.log("txMined event received via emitter", response); -}); -smartAccount.on("error", (response) => { - console.log("error event received via emitter", JSON.stringify(response)); -}); -// Sending transaction -const txResponse = await smartAccount.sendTransaction({ transaction: tx }); -console.log("UserOp Hash", txResponse); -const txReciept = await txResponse.wait(); -console.log("Tx hash", txReciept.transactionHash); -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sendind-erc721.md b/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sendind-erc721.md deleted file mode 100644 index e3e75cc5..00000000 --- a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sendind-erc721.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Sending ERC-721 (NFT) Tokens - -Create a transaction on a smart account that transfers a single ERC-721 token similar to sending an ERC20 token. - -Once you have the [Smart Account instance initialized](../../initialize-smart-account) with the appropriate config, check the code below. - -```js -const erc721Interface = new ethers.utils.Interface([ - "function safeTransferFrom(address _from, address _to, uint256 _tokenId)", -]); - -// Encode an ERC-721 token transfer to recipient of the specified amount -const address = await smartAccount.address; -const data = erc721Interface.encodeFunctionData("safeTransferFrom", [ - address, - recipientAddress, - tokenId, -]); - -const tx = { - to: nftAddress, - data, -}; - -// Transaction events subscription -smartAccount.on("txHashGenerated", (response) => { - console.log("txHashGenerated event received via emitter", response); -}); -smartAccount.on("txMined", (response) => { - console.log("txMined event received via emitter", response); -}); -smartAccount.on("error", (response) => { - console.log("error event received via emitter", JSON.stringify(response)); -}); -// Sending transaction -const txResponse = await smartAccount.sendTransaction({ transaction: tx }); -console.log("UserOp Hash", txResponse); -const txReciept = await txResponse.wait(); -console.log("Tx hash", txReciept.transactionHash); -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sending-erc20.md b/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sending-erc20.md deleted file mode 100644 index e13a192c..00000000 --- a/versioned_docs/version-1.0/sdk-reference/send-txn/gasless-txn/sending-erc20.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Sending ERC-20 Tokens - -One can create a gasless transaction that transfers the amount of the ERC-20 token from a Smart Account. - -Once you have the [Smart Account instance initialized](../../initialize-smart-account) with the appropriate config, check the code below. - -```js -const erc20Interface = new ethers.utils.Interface([ - 'function transfer(address _to, uint256 _value)' -]) - -// Encode an ERC-20 token transfer to the recipient of the specified amount -const data = erc20Interface.encodeFunctionData( - 'transfer', [recipientAddress, amount] -) - -const tx1 = { - to: usdcAddress, - data -} - -// Transaction subscription -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); - showSuccessMessage(`Transaction sent: ${response.hash}`); -}); -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); - showSuccessMessage(`Transaction mined: ${response.hash}`); -}); -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - -// Sending gasless transaction -const txResponse = await smartAccount.sendTransaction({ transaction: tx1 }); -console.log('userOp hash', txResponse.hash); -// If you do not subscribe to listener, one can also get the receipt like shown below -const txReciept = await txResponse.wait(); -console.log('Tx hash', txReciept.transactionHash); - -// DONE! You just sent a gasless transaction -``` - -With batching functionality, you can send multiple token transfers in a single transaction - -```js -const erc20Interface = new ethers.utils.Interface([ - 'function transfer(address _to, uint256 _value)' -]) - -// Encode two different ERC-20 token transfers -const data1 = erc20Interface.encodeFunctionData( - 'transfer', [recipient1Address, amount1] -) -const data2 = erc20Interface.encodeFunctionData( - 'transfer', [recipient2Address, amount2] -) - -const txs = [] - -const tx1 = { - to: usdcAddress, - data: data1 -} - -txs.push(tx1) - -const tx2 = { - to: usdcAddress, - data: data2 -} - -txs.push(tx2) - -// Transaction subscription -smartAccount.on('txHashGenerated', (response: any) => { - console.log('txHashGenerated event received via emitter', response); - showSuccessMessage(`Transaction sent: ${response.hash}`); -}); -smartAccount.on('txMined', (response: any) => { - console.log('txMined event received via emitter', response); - showSuccessMessage(`Transaction mined: ${response.hash}`); -}); -smartAccount.on('error', (response: any) => { - console.log('error event received via emitter', response); -}); - - -// Sending transaction -const txResponse = await smartAccount.sendTransactionBatch({ transactions: txs }); -console.log('UserOp Hash', txResponse); -const txReciept = await txResponse.wait(); -console.log('Tx hash', txReciept.transactionHash); -``` - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/send-txn/overview.md b/versioned_docs/version-1.0/sdk-reference/send-txn/overview.md deleted file mode 100644 index eb4c361a..00000000 --- a/versioned_docs/version-1.0/sdk-reference/send-txn/overview.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -sidebar_position: 1 ---- - -# Overview - -> Biconomy smart accounts are smart contract wallets that can batch the transactions and have different fee mechanism. - -Just like [ethers.js](https://docs.ethers.io/v5/) or web3.js needs a Transaction Request (for destination contract and action on this smart contract) , Biconomy SDK allows to input single transaction or array of transactions from a Dapp developer. - -Relayer then triggers this above transaction / batch on user's Smart Account to interact with multiple contracts in one-click (just a signature!) - -**Fee Mechanism** - -1. **Gasless (Account Abstraction Paymasters)** -2. **Make your user pay the fees ( in tokens help by the wallet)** diff --git a/versioned_docs/version-1.0/sdk-reference/smart-account-methods.md b/versioned_docs/version-1.0/sdk-reference/smart-account-methods.md deleted file mode 100644 index df77a207..00000000 --- a/versioned_docs/version-1.0/sdk-reference/smart-account-methods.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -sidebar_position: 3 ---- - -# Smart Account Methods - -After initialising a smart account instance you will gain access to several useful methods. Below are the listed methods you can use. - -:::info -**The address of the Smart Account address is counterfactual in nature. This means you can still retrieve the account address before it has been deployed.**\ -::: - -## Address - -```js -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); - -const address = smartAccount.address; -console.log("address", address); -``` - -This returns a string representing the address of your Smart Account - -```js -let smartAccount = new SmartAccount(walletProvider, options); -smartAccount = await smartAccount.init(); - -const anyEoaAddress = "0x048617BfD445FD1E0AC1b827AA0d00024439fe7a"; -const chainId = 137; -const index = 0; // You can generate multiple smartAccount per EOA, index 0 is first/default -const address = await smartAccount.getSmartAccountAddress( - anyEoaAddress, - chainId, - index, -); -console.log("address", address); -``` - -You can also generate an array of all Smart Account addresses owned by an EOA, the address at index 0 will be the default address. - -## Owner - -```js -const ownerEOA = smartAccount.owner; -``` - -This returns a string representing the address of the EOA wallet that owns this smart account. This information is derived from the Web3 Provider passed to the smart account initialization in the previous step. - -## Send Transaction - -```js -const trxResponse = smartAccount.sendTransaction({ transaction: tx }); -``` - -This method allows you to execute a gasless transaction paid by the paymaster you set up on the [Biconomy Dashboard](https://docs.biconomy.io/guides/biconomy-dashboard). It takes a transaction object as a parameter and returns a promise with the transaction response data. - -Here is how you would set up your transaction object: - -```js -const myTx = await .populateTransaction.() -const tx = { -to: //contract address, -data: myTx.data, -} -``` - -## Send Transaction Batch - -```js -const trxResponse = smartAccount.sendTransactionBatch({ - transactions: [tx1, tx2], -}); -``` - -This method allows you to execute a batch of gasless transactions paid by the paymaster you set up on the [Biconomy Dashboard](https://docs.biconomy.io/guides/biconomy-dashboard). It takes an object as a parameter with an array of transactions and works similarly to `sendTransaction`. - -## Get Fee Quotes - -```js -const mytrx = .populateTransaction.() - -const tx = { - to: //contract address, - data: mytrx.data, -} - -smartAccount.getFeeQuotes({ - transaction: tx, -}) -``` - -Before executing a User Paid transaction we need some information about the potential gas price of the transaction. This method takes transaction data similar to Send Transaction method and will return a promise that resolves an array of fee quotes that the user can choose. - -## Create User Paid Transaction - -```js -const transaction = await smartAccount.createUserPaidTransaction({ - transaction: tx, - feeQuote: quote, -}); -``` - -After choosing a quote for the gas price this method will create a promise that resolves to transaction data that can be passed to the Send User Paid Transaction method. - -## Send User Paid Transaction - -```js -smartAccount.sendUserPaidTransaction({ - tx: transaction, - gasLimit: { - hex: "0xC3500", - type: "hex", - }, -}); -``` - -This method allows you to have the user sponsor their own transaction. It takes an object as a parameter that includes transaction information and a gas limit. - -## Get Account Balances - -```js -import {BalancesDto } from '@biconomy/node-client' - -import { ChainId } from '@biconomy/core-types' - -const balanceParams: BalancesDto = - { -// if no chainId is supplied, SDK will automatically pick active one that -// is being supplied for initialization - chainId: ChainId.MAINNET, // chainId of your choice - eoaAddress: smartAccount.address, - // If empty string you receive balances of all tokens watched by Indexer - // you can only whitelist token addresses that are listed in token respostory - // specified above ^ - tokenAddresses: [], - }; - - -const balFromSdk = await smartAccount.getAlltokenBalances(balanceParams); -console.info("getAlltokenBalances", balFromSdk); - -const usdBalFromSdk = await smartAccount.getTotalBalanceInUsd(balanceParams); -console.info("getTotalBalanceInUsd", usdBalFromSdk); -``` - -The two methods here will allow you to read asset balances and their USD values across networks. - -For a list of all supported token balances, please take a look at the list in the repository specified below. - -https://github.com/bcnmy/token-list/blob/master/biconomy.tokenlist.json - -## Deploy Wallet Using Paymaster - -```js -const deployTx = smartAccount.deployWalletUsingPaymaster(); -``` - -Using this method, you can choose to have a smart account deployed at any time. Gas fees will be deducted from your associated gas tank on your Pay master. Alternatively, you can allow for the smart account to be deployed when the user does their first transaction. This happens automatically during the first transaction. - -## Smart Account is Deployed - -```js -smartAccount = await smartAccount.setActiveChain(chainID); -``` - -This method returns a promise that resolves into the Smart Account Object and allows you to switch the active chain to the specified chain ID passed to the method. - -:::info -If you have any questions please post them on the [Biconomy SDK Forum](https://forum.biconomy.io/) -::: diff --git a/versioned_docs/version-1.0/sdk-reference/txn-response.md b/versioned_docs/version-1.0/sdk-reference/txn-response.md deleted file mode 100644 index ed38da42..00000000 --- a/versioned_docs/version-1.0/sdk-reference/txn-response.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -sidebar_position: 6 ---- - -# Transaction Response - -```js -const myTx = await .populateTransaction.() -const tx = { -to: //contract address, -data: myTx.data, -} - -const trxResponse = smartAccount.sendTransaction({ transaction: tx }) -``` - -You will get a transaction response object when sending single or batched transactions. Below are the methods available from this object. - -### Wait - -```js -const txHash = await txResponse.wait(); -``` - -This method returns a promise which resolves to a transaction hash once the transaction has completed on the associated chain. diff --git a/versioned_sidebars/version-1.0-sidebars.json b/versioned_sidebars/version-1.0-sidebars.json deleted file mode 100644 index caea0c03..00000000 --- a/versioned_sidebars/version-1.0-sidebars.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "tutorialSidebar": [ - { - "type": "autogenerated", - "dirName": "." - } - ] -} diff --git a/versions.json b/versions.json index b5969a07..1e50a9d8 100644 --- a/versions.json +++ b/versions.json @@ -1 +1 @@ -["3.0", "1.0"] +["3.0"]