diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000..9dd8238 Binary files /dev/null and b/.DS_Store differ diff --git a/docs/.DS_Store b/docs/.DS_Store index aa43d0b..c02d821 100644 Binary files a/docs/.DS_Store and b/docs/.DS_Store differ diff --git a/docs/pages/.DS_Store b/docs/pages/.DS_Store new file mode 100644 index 0000000..73e09ae Binary files /dev/null and b/docs/pages/.DS_Store differ diff --git a/docs/pages/abstractjs.mdx b/docs/pages/abstractjs.mdx deleted file mode 100644 index 6db22ff..0000000 --- a/docs/pages/abstractjs.mdx +++ /dev/null @@ -1,123 +0,0 @@ -# AbstractJS SDK - -```bash [Install AbstractJS] -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -### Single and Multichain Capabilities -AbstractJS is a comprehensive smart account SDK that goes beyond standard account management capabilities. While it -provides all the features you'd expect from a smart account SDK - executing UserOps, gas management, signature handling, installing account modules - it's -been supercharged with powerful utilities for multi-chain development. - -### Support for both EOAs and Smart Accounts -Additionally, what sets AbstractJS apart is its support for both smart accounts and EOAs. Through our [Fusion module](/mee/fusion), -EOA users can batch execute operations across multiple chains with a single signature. - -For wallet developers, AbstractJS enables EIP7702, enabling seamless migration of users from EOAs to smart contract accounts while maintaining support for both our innovative Modular Execution Environment (MEE) and traditional Bundler/Paymaster execution paths. - -![Abstract](https://i.imgur.com/80tPZRF.png) - -## Work with Chains, Intents and Bridges -Working with multiple chains, bridges, and intents has traditionally required complex infrastructure and significant development effort. AbstractJS eliminates this complexity by providing advanced tools that make multi-chain operations as simple as single-chain ones. Through our innovative MEE infrastructure, developers can orchestrate complex cross-chain transactions and intents with unprecedented ease. - -Check out a quick guide on [building a chain abstracted app](/mee/tutorials/build-chainabstracted-app). - -## Open-Source, Built on `viem` -AbstractJS is vendor-neutral, open source and built on the industry-leading `viem` SDK - -:::info[Key Benefits] -- Multi-chain environment support out of the box -- Infrastructure and account neutral design -- Open-source (MIT licensed) -- Built on industry-standard viem SDK -::: - -:::tip[Vendor Neutral Design] -AbstractJS works with any ERC4337-compliant smart account including: -- Biconomy Nexus -- Safe -- Kernel -- Other compliant implementations -::: - -## Execution Environment Support -AbstractJS supports two distinct execution environments. [Learn more about execution environments](/explained/exec-environments) - -::::steps -#### **Modular Execution Environment (MEE)** -A novel execution environment, serving as an evolution to Bundlers and Paymasters, enabling -execution of transactions and intents and the orchestration of complex multi-chain sequences. - -[Learn more about MEEs](/explained/mee) - -#### **ERC4337 Bundler & Paymaster Execution Environment** -Industry standard and battle tested execution stack. Enables developers to sponsor transactions for users, -users to pay for transactions with ERC20 tokens and batch executions. - -[Learn more about Bundlers & Paymasters](/explained/bundlers-paymasters) - -:::: - -## Advanced Smart Account & Module Support -AbstractJS enables developers to create smart accounts, connect them to execution environments, install account -modules (like Passkeys, Session Keys, MultiSigs, Account Recover and more...), encode and execute UserOps and -Supertransactions through Smart Accounts and use Smart Accounts with EOA users. - -[Learn more](/modules) - -## Multi-Chain Smart Account Management -AbstractJS streamlines the complexity of working with smart accounts across multiple chains. You can deploy and manage accounts across networks like Polygon, Optimism, and Base with unified interfaces and consistent APIs. - -```ts [Code Example: Using a Biconomy Nexus Account on Multiple Chains] -const mcNexus = await toMultichainNexusAccount({ - signer: eoa, - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()] -}) -``` - -[Learn More](/mee/tutorials/manage-multichain-sca) - -## EOA Multi-Chain Batch Execution (Fusion) -The Fusion feature provides advanced capabilities for EOA accounts: -- Execute multiple transactions across chains with one signature -- Pay gas fees on a single chain -- Automated cross-chain execution sequencing - -[Learn More](/mee/fusion) - - -## Multi-Chain Utilities - -AbstractJS provides essential tools for multi-chain development: - -::::steps -#### **Contract Management Across Chains** -Map multiple contract instances across multiple chains into a single object. Use it to -effortlessly encode UserOps across on all chains. - -#### **Unified Multichain Balance** -All utility functions within AbstractJS can work with a Unified Multichain Balance -object - which treats all balances across all chains - as if it was a single one. - -#### **Bridge & Intent Integration** -Find optimal bridging routes and combine multiple intent providers in just a few lines of code. Modern -onchain environments require a lot of moving funds across chains - AbstractJS makes this effortless for -the developer and invisible for the user. - -:::: - -## Transaction Orchestration -AbstractJS enables complex transaction sequences across multiple chains. You can build operations that: -- Move tokens between chains -- Interact with DeFi protocols -- Manage approvals and permissions -- Execute multi-step operations atomically - - -:::info[Quick Start] -Install AbstractJS: -```bash -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` -::: \ No newline at end of file diff --git a/docs/pages/account-providers/others.mdx b/docs/pages/account-providers/others.mdx deleted file mode 100644 index e69de29..0000000 diff --git a/docs/pages/account-providers/overview.mdx b/docs/pages/account-providers/overview.mdx deleted file mode 100644 index e2a255e..0000000 --- a/docs/pages/account-providers/overview.mdx +++ /dev/null @@ -1,68 +0,0 @@ -# Modular Smart Accounts - -The backbone of the Biconomy infrastructure, providing developers with interoperability, execution and user -experience benefits are - Modular Smart Accounts. - -Smart Accounts are based on the [ERC4337](https://www.erc4337.io/) Account Abstraction standard set by the Ethereum -Foundation. They can complement or replace commonly used Externally Owned Accounts (EOAs). - -![Smart Accounts](https://i.imgur.com/PhfZrml.png) - -## About Smart Accounts - -Modular Smart Accounts solve for many of the limitations of the traditionally used Externally Owned Accounts (EOAs). - -Some core benefits of Modular Smart Contract Accounts (SCAs): - -::::steps -#### Pay with Tokens -SCAs enable users to pay for gas with ERC20 tokens - -#### Free Transactions -SCAs enable developers to sponsor transactions for their users - -#### Login and Sign Transactions with Passkeys -Users can log-in and sign-transactions with Passkeys, drastically improving their onboarding process - -#### Recover Accounts -In case the user loses access to an SCA, they enable many ways to recover that account. - -#### Automate Account with Bots and Agents -Developers can delegate account access to a bot or an AI agent. The bot can be constrained with -various permissions - preventing it from executing unwanted transactions. - -:::: - -## Benefits Unique to the Biconomy Stack -Beyond the core benefits, `AbstractJS` and the Biconomy Modular Execution Environment - enable advanced -features for developers building in a modern, multi-chain execution environment: - -::::steps -#### Hybrid Execution -Execute both transactions and intents and mix and match their execution - -#### Lightspeed Transactions -Resource locked accounts for lightspeed cross-chain execution - -#### Cross-Chain Transaction Sequencing -Automatically sequence multiple transactions across chains and execute them with a single signature - -#### Vendor-Neutral Chain Abstraction -Orchestrate multiple intent, bridge and cross-chain messaging providers - -#### Cross-Chain Composability -Compose complex, interdependent function calls without writing smart contracts -:::: - -## Smart Account Modules - -![Modules](https://i.imgur.com/YJcDR0L.png) - -Much of the functionality of Smart Accounts is offered through Account Modules. Biconomy Nexus and other supported -Modular Smart Accounts are based on the [ERC7579](https://erc7579.com/) standard and can accept any module compliant -with the standard. This is an industry-leading modules standard and has been adopted by most leading Smart Account providers. - -:::tip[Choose Industry Leading Standards] -By working on top of an ERC7579 standard, you're ensuring your smart account will be compliant with the most widely used -Smart Account standard. -::: \ No newline at end of file diff --git a/docs/pages/addOns/crosschain.mdx b/docs/pages/addOns/crosschain.mdx deleted file mode 100644 index 1f4aa77..0000000 --- a/docs/pages/addOns/crosschain.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -title : Cross chain ---- - -# Cross-chain Swap API-s - -## **Seamless Crypto-to-Crypto Swap Integration** - -We've established partnerships with leading crypto-to-crypto swap service providers and aggregators to facilitate a seamless integration of swap functionalities within our platform. Through their developer integration toolkits, users can now exchange cryptocurrencies directly within any app, website, or web plugin. This collaboration enables users to swap between various crypto assets without the need for multiple transactions or dealing with the intricacies of swapping different assets on separate platforms. It simplifies the process and ensures a convenient experience for managing their crypto portfolios. Please note that compliance with relevant regulatory requirements may apply to working with some of these providers. - -## Our preferred Swap aggregator - -## Our preferred Cross-chain Swap aggregator - -Crypto swap aggregators enable access to multiple swap providers. The one listed below can be integrated through a unified interface, providing access to a broader audience right from the start. - -| Partner | KYC requirement for users | Outlier factor | Link to docs | Supported pairs | KYB requirement to integrate | -| ------- | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | ------------------------------------------------------------------------------ | ---------------------------- | -| Li Fi | no KYC, self-custodial cross chain or single chain swaps | Supports all major networks and most popular assets



Finds the lowest prices across multiple DEX providers & bridges on the market | [Docs](https://docs.li.fi/) | [Link](https://docs.li.fi/list-chains-bridges-dexs-solvers) to Supported Pairs | No! | - - -## Our preferred Swap partners - -| Partner | KYC requirements for users | Outlier factor | Link to docs | Supported pairs | KYB requirement to integrate | -| ---------------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------ | ----------------------------------------------------------------------------- | -| **XO Swaps by Exodus** | no KYC, self-custodial swaps | 1000+ tokens, millions of trading pairs across 50+ networks



Fast & frictionless atomic swaps | Available after KYB



Read more and get in touch with the team [here](https://www.exodus.com/xo-swap/). | Link to [supported pairs](https://www.exodus.com/status/) | Yes, get in touch with the team [here](https://www.exodus.com/xo-swap/). | -| **Moonpay Swaps** | KYC-d swaps | 1500+ trading pairs across major blockchains



Regulated, compliant, secure (ISO 27001) | [Read docs](https://dev.moonpay.com/v1.0/docs/ramps-swap) | Link to [supported pairs](https://dev.moonpay.com/docs/swap-pairs) | Yes, get started [here](https://dashboard.moonpay.com/signup?invite=16548771) | - -## Example User flow via Moonpay - -### 1. **Enterswap details** - -Enter the amount of your starting cryptocurrency and select a trading pair from a wide variety of combinations. Then, enter the destination address, which can be a different wallet application than the one for the base swap token. Addresses can be pre-filled by the app to simplify UX. - -### 2. **Confirm the swap** - -Review the details of the exchange, including swap amount, destination crypto wallet address, exchange rate, as well as any transaction fees incurred. Click the Swap button and you’ll be redirected to your wallet interface. - -> ⚠️ If this is the user’s first time using Moonpay they will be required to go through a simple KYC process to comply with regulations. - -### 3. **Sign the transaction in your wallet** - -In your wallet application, sign the transaction to send crypto to the MoonPay wallet address to complete the exchange. Make sure that you have enough crypto in your wallet to cover any network fees. - -> 💡 Using **Session Keys** within your app will eliminate the need for this step, and using our **Paymaster** will eliminate the need for the user to keep the blockchain’s native token to complete the swap. - -### 4. **Check your crypto wallet** - -After signing the transaction, your swap will begin processing. This typically takes between a few minutes and a few hours. You will receive an email once the swap is complete, after which you can check your cryptocurrency wallet to view your newly acquired coins, as well as your portfolio balance. diff --git a/docs/pages/addOns/fiatRails.mdx b/docs/pages/addOns/fiatRails.mdx deleted file mode 100644 index 5bec030..0000000 --- a/docs/pages/addOns/fiatRails.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Fiat Rails ---- - -# Fiat Rails - -## Seamless Fiat On-Ramp & Off-Ramp Integration - -We've partnered with leading fiat On-Ramp & Off-Ramp service providers and aggregators, 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 aggregators - -Onramp aggregators enable access to multiple onramp providers. The one listed below can also be integrated through a single interface. This helps in gaining access to a larger audience from day one. - -| Fiat Onramp | Outlier Factor | Quick Guides | Supported Currencies | -| ----------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | -| **Meld** | 15+ onramps and offramps support, easy integration, serves global audience. | [Technical Docs](https://docs.meld.io/password?redirect=/docs/getting-started) (pwd: 'build-easy') | [List](https://docs.meld.io/docs/crypto-supported-service-providers-assets) | -| **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) | - -## Our preferred onramp partners - -| Fiat Onramp | Outlier Factor | Quick Guides | Supported Currencies | -| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | -| **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) | -| [**Transak**](/smartAccountsV2/account/fiatonramp) | 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/account/fiatonramp) | [List](https://docs.transak.com/docs/fiat-currency-country-payment-method-coverage-plus-fees-and-limits) | -| **Unlimit** | Simple and flexible integration methods, easy and secure verification methods. | [Technical Docs](https://docs.gatefi.com/docs/gatefi-docs/zczlqjv647sxz-what-is-unlimit-crypto) | [List](https://docs.gatefi.com/docs/gatefi-docs/dqboe8phjgui5-supported-assets-and-payments) | - -## 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/docs/pages/addOns/fundSmartAccounts.mdx b/docs/pages/addOns/fundSmartAccounts.mdx deleted file mode 100644 index b55a0a6..0000000 --- a/docs/pages/addOns/fundSmartAccounts.mdx +++ /dev/null @@ -1,102 +0,0 @@ ---- -title : Fund Smart Account ---- - -# Aarc - Fund Migration SDK - -## Introduction - -The Aarc SDK is a TypeScript library designed to facilitate the transfer of assets from Externally Owned Accounts (EOA) to Biconomy Smart Wallets. It supports various token standards like ERC20 and ERC721 and offers advanced features such as batched transactions, gasless transactions, and the ability to pay gas fees with the transferred asset. The SDK also allows custom contract interactions within the same transaction using permit2(), enabling direct swaps and bridge functionalities. - -:::tip - -Check out an end-to-end integration of AARC on this [example repo](https://github.com/bcnmy/biconomy_aarc_example)! - -::: - -## Prerequisites - -### Dependencies - -To use the Aarc SDK, you need to install the following dependencies: - -```javascript -npm install @aarc-xyz/migrator ethers@5.7.2 -``` - -### API Key - -Get the Aarc API Key (you can learn how to get it from [here](https://docs.aarc.xyz/developer-docs/getting-started/quick-start-guide/get-the-api-key)), your EOA private key and the RPC URL. - -## Setup and Configuration - -### Importing and Initializing the SDK - -First, import and initialize the Aarc SDK in your project: - -```javascript -import { ethers, BigNumber } from "ethers"; -import { Migrator, WALLET_TYPE } from "@aarc-xyz/migrator"; - -let provider = new ethers.providers.JsonRpcProvider("YOUR_RPC_URL"); -let signer = new ethers.Wallet("YOUR_PRIVATE_KEY", provider); -let eoaAddress = signer.address; - -let aarcSDK = new Migrator({ - rpcUrl: "YOUR_RPC_URL", - chainId: 80002, - apiKey: "YOUR_AARC_API_KEY", -}); -``` - -### Fetching Smart Accounts - -To retrieve the smart account addresses of the associated EOA. - -```javascript -async function main() { - try { - const smartWalletAddresses = await aarcSDK.getSmartWalletAddresses( - WALLET_TYPE.BICONOMY, // WALLET_TYPE imported from @aarc-xyz/migrator - eoaAddress - ); - console.log(" smartWalletAddresses ", smartWalletAddresses); - } catch (error) { - console.error(" error ", error); - } -} -``` - -Here, we provide the WALLET_TYPE.BICONOMY to fetch the Smart Account addresses associated with the EOA. -In the response, we will see the addresses associated with the EOA for Biconomy's Smart Accounts. No Smart Account may be deployed so it will only generate and return the Smart Account address, mentioning its deployment status and the walletIndex. - -### Deploy the Smart Account - -To deploy the smart account, use aarcSDK.transferNativeAndDeploy this will take a few parameters, as shown below. - -:::info - -- **deploymentWalletIndex** and **receiver** can be fetched from the above response. -- **amount** should be in hex string, which can be easily done by usingBigNumbers from ethers. - ::: - -```javascript -async function main() { - // ... Previous Code ... - try { - const response = await aarcSDK.transferNativeAndDeploy({ - walletType: WALLET_TYPE.BICONOMY, - owner: eoaAddress, - receiver: "0xcba2d1f7522757f4f1b2e1f7ce54612c61fbd366", - signer: signer, - deploymentWalletIndex: 0, - amount: BigNumber.from("10000")._hex, - }); - console.log("Transfer and Deploy Response: ", response); - } catch (error) { - console.error(" error ", error); - } -} -``` - -Go through the [AARC SDK Documentation](https://docs.aarc.xyz/) for more functionalities and integration details. diff --git a/docs/pages/addOns/overview.mdx b/docs/pages/addOns/overview.mdx deleted file mode 100644 index d0ac891..0000000 --- a/docs/pages/addOns/overview.mdx +++ /dev/null @@ -1,9 +0,0 @@ ---- -id: overview -title: Overview ---- - -## Add-On APIs & SDKs -Biconomy SDK is a full stack Account Abstraction solution written in Typescript. Acknowledging that, developers often require functionalities in addition to Account Abstraction for building user-friendly applications, some may seek alternative solutions to seamlessly integrate with Account Abstraction. - -Our aim is to assist everyone! Explore the following solutions, which can be used alongside Biconomy and built on the Biconomy Infrastructure, to optimize the benefits of Account Abstraction. diff --git a/docs/pages/addOns/raasProvider.md b/docs/pages/addOns/raasProvider.md deleted file mode 100644 index 2415eda..0000000 --- a/docs/pages/addOns/raasProvider.md +++ /dev/null @@ -1,97 +0,0 @@ -# One click integration for RAAS providers - -This guide walks you through the process of integrating with Biconomy using a one-click setup on RAAS (Rollup as a service) provider platforms. - -Essentially, you will need to use the `raas-request` API to submit your requests. The request will be reviewed internally and subsequently the status will be updated through an `update` API at your end. - -### 1. RAAS provider request Endpoint: - -**POST API Endpoint** - -```bash -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/raas-request -``` - -This endpoint processes incoming webhook requests from RAAS providers, such as Conduit. It performs validation, updates the database, and triggers Slack notifications. - -**Header** - -Based on each RAAS provider a new header will be generated. for eg. `X-Conduit-Integration-Secret` (Header name for conduit). You can reach out to us on [Telegram](https://t.me/monikatudja) or [discord](https://discord.com/invite/biconomy) for the new header. - -**Request Payload Structure** - -The payload received at this endpoint must adhere to the following structure: - -```json -{ - "event": "INSTALLING", - "id": "unique-request-id", - "chain_id": "1", - "parent_chain_id": "0", - "type": "rollup", - "native_currency": { - "name": "Ether", - "symbol": "ETH", - "decimals": 18, - "contract": "0x..." - }, - "name": "Ethereum Mainnet", - "rpc": "https://mainnet.infura.io/v3/...", - "ws": "wss://mainnet.infura.io/ws/v3/...", - "explorer": "https://etherscan.io/", - "logo_url": "https://example.com/logo.png", - "icon_url": "https://example.com/icon.png", - "brand_color": "#FFFFFF", - "file_optimism_contracts": "https://api.conduit-stg.xyz/file/v1/optimism/contracts/m-integrations-testnet-kn5qqp4tzd", - "file_optimism_genesis": "https://api.conduit-stg.xyz/file/v1/optimism/genesis/m-integrations-testnet-kn5qqp4tzd", - "file_optimism_rollup": "https://api.conduit-stg.xyz/file/v1/optimism/rollup/m-integrations-testnet-kn5qqp4tzd", - "file_arbitrum_core": "", - "file_arbitrum_chaininfo": "", - "contracts": { - "AddressManager": "0xd9839AE04fe2E7D530011F789eCE10097ddde683", - "BondManager": "0x0000000000000000000000000000000000000000", - "CanonicalTransactionChain": "0x0000000000000000000000000000000000000000", - "L1CrossDomainMessenger": "0x3036963aad081c0dB89Ca71119D66da998f40c64", - "L1StandardBridge": "0xA402C554cbA7e702232F35fDec5c3C3B91eED50a", - "L2OutputOracle": "0x4FA4370Dc6A221b937A95cA84601648424e7Bf21", - "OptimismPortal": "0x6cfbe05548ABDeff451B71592ccaB84e7B64c631", - "StateCommitmentChain": "0x0000000000000000000000000000000000000000" - } -} -``` -**Response** - -```json -{ - "status": "INSTALLING", - "eta_seconds": 1209600, // Estimated time of completion in seconds - "manage_integration_link": "https://dashboard.biconomy.io" -} -``` -Here’s a breakdown of the fields: -- `status`: Indicates the current status of the integration. Possible values include: - - - "INSTALLING": The integration is currently in progress. - - "INSTALLED": The integration has been successfully completed. - - "UNINSTALLED": The integration has been removed. - - "NOT_INSTALLED": The integration has not been attempted or is not applicable. - -- `eta_seconds`: The estimated time of completion for the integration, expressed in seconds. This value provides an estimate of how long it will take for the integration to be finalized. For example, 1209600 seconds equals approximately 14 days. - -- `manage_integration_link`: A URL that directs to the Biconomy dashboard where you can manage and monitor the integration status. - - -### 2. RAAS Provider Update Endpoint: - -We will require an endpoint for updating the status of installations/completions on your end. - -**Payload** -```json -{ - "status": "INSTALLED", // ["INSTALLING", "INSTALLED", "UNINSTALLED", "NOT_INSTALLED"] - "id": "unique-request-id", - "manage_integration_link": "" -} -``` - -You can contact us via [Telegram](https://t.me/monikatudja) or [discord](https://discord.com/invite/biconomy) for further queries. diff --git a/docs/pages/addOns/socialLogins.md b/docs/pages/addOns/socialLogins.md deleted file mode 100644 index 8cf9e01..0000000 --- a/docs/pages/addOns/socialLogins.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title : Social Login ---- - -# Social Login - Signers for your SA - -Every account generated on a blockchain has a logic that allows us to cryptographically sign transactions using our private keys. Authentication services like Particle, Web3Auth, and wallet applications such as Metamask provide us with easier options to manage private keys and initiate transactions. - -As you might already know, there are two types of accounts i.e. Smart Accounts and Externally Owned Accounts (EOAs). A lot of web3 users have EOAs that they manage using their Metamask and other similar self-custodial wallet services. - -Similar to EOAs, Smart Accounts also have a signer vis-a-vis a validation logic which can be set to an ECDSA signature. These ECDSA signatures can be generated using an associated private key. Developers have the flexibility to choose a singer to manage these private keys for the user. Services like Web3Auth, Particle, etc provide creative and more user-friendly ways like Passkeys, Social Login, and Emails to use the said private keys which are secured using different security methods like MPC, DKG, etc. - -We've rounded up the best social login options out there, all in one spot for you. The Biconomy stack works smoothly with these logins, supporting easy integration. When developers pick wallets for their apps, they should think about things like security, cost, user experience, flexibility, privacy, and recoverability. Check out the table below to get a quick look at these factors. - -  - -| Signer | Outlier Factors | Additional Links | Security Method | -| ---------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [**Particle Auth**](/smartAccountsV2/account/signers/particle) | Integrated AA Experience & free to use via Biconomy | [Authentication Methods](https://docs.particle.network/developers/connect-service#1.-simple-onboarding) | MPC-TSS | -| [**Web3Auth**](/smartAccountsV2/account/signers/web3auth) | Pop-up less experience | [Authentication Methods](https://web3auth.io/docs/auth-provider-setup/#supported-auth-providers) | MPC-SSS/TSS | -| [**Privy**](/smartAccountsV2/account/signers/privy) | Choose between having popups for more transparency vs abstract signing away | [Authentication Methods](https://docs.privy.io/guide/configuration/#login-methods) | SSS | -| [**Capsule**](/smartAccountsV2/account/signers/capsule) | Policy engine for sessions | [Demo Apps](https://docs.usecapsule.com/getting-started/examples) | MPC + DKG ([Link](https://docs.usecapsule.com/how-capsule-works/key-management)) | -| [**Magic**](/smartAccountsV2/account/signers/magic) | | [Authentication Methods](https://magic.link/docs/authentication/overview) | Delegated Key Management System ([DKMS](https://magic.link/docs/home/security/product-security#private-keys-can-be-lost-or-stolen-how-do-you-protect-my-private-key)) | -| **Lit Protocol** | Programmable key pairs | [More about PKPs](https://developer.litprotocol.com/v2/pkp/intro/) | MPC | -| [**DFNS**](/smartAccountsV2/account/signers/dfns) | Policy engine for setting limits | [Policy Engine](https://www.dfns.co/product/wallets-as-a-service) | MPC + TSS ([Link](https://www.dfns.co/security)) | diff --git a/docs/pages/addOns/unitySDK.md b/docs/pages/addOns/unitySDK.md deleted file mode 100644 index 92a6fbe..0000000 --- a/docs/pages/addOns/unitySDK.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title : Unity SDK ---- - -# Lync - Unity SDK - -Introducing the LYNC Account Abstraction SDK – a pioneering no-code solution designed for seamless integration into the gaming world of Web3. Developed in collaboration with Lync, this SDK is your gateway to simplified and efficient gamer onboarding. With the LYNC AA SDK, game developers can now offer players effortless login options through social media accounts, digital wallets, email, and more. - -Our SDK is versatile and fully compatible with a wide range of platforms, including PC (MacOS and Windows), Mobile (Android and iOS), and web browsers. This ensures a broad reach, allowing game developers to cater to a diverse audience seamlessly. - -The LYNC AA SDK is tailored to enhance the gaming experience, offering a user-friendly interface that connects gamers effortlessly. Whether you're developing a game for Mac, Windows, Android, iOS, or a web browser, integrating the LYNC AA SDK is swift and straightforward, aligning perfectly with the dynamic needs of Web3 gaming environments. - -Embrace the future of gaming with the LYNC Account Abstraction SDK. Simplify your game’s user experience and open doors to a wider audience in the ever-expanding world of Web3 gaming. - -![Image1](/addOns/lync.png) - -**[Contact](https://t.me/SarDwi8) Biconomy's BD/Sales team to integrate with Lync AA SDK.** diff --git a/docs/pages/addOns/walletUiKit.md b/docs/pages/addOns/walletUiKit.md deleted file mode 100644 index 32c204d..0000000 --- a/docs/pages/addOns/walletUiKit.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title : Wallet UI Kit ---- - -# Obvious - Embedded Wallet UI Kit - -Developers can now integrate Biconomy’s account abstraction-based wallet in their apps in just 5 minutes and a few lines of code. Our partners at Obvious have built out a UI kit on our existing infrastructure that removes the need for developers to build an in-app wallet UI experience for the user. The developers can now use the Obvious Embed for a smooth in-app Smart Account experience. - -**What do dApps get by integrating with the Obvious Embed kit?** - -- Obvious embed kit helps developers to build for both EOA & SCW by abstracting out complexities around gas fees. -- Standard signer & provider interface for EOA & SCW -- UI Kit for showing portfolio across multiple chains, including tokens, NFTs & transaction history -- UI Kit for 1-click swapping & bridging of tokens -- Customizations (colors & styles) that can be plugged into your dApp, as a popup or a separate tab, with minimal effort. -- [Obvious](https://www.obvious.technology/) as a wallet partner, built on top of Biconomy Account Abstraction SDK, users of your dApp can take their credentials and log in to Obvious Wallet for a complete wallet experience. - -The pictures below give you a peek into what the Obvious Embed UI looks like and the cool features it comes with. - -![Image 1](/addOns/image1.png) ![Image2](/addOns/image2.png) ![Image3](/addOns/image3.png) ![Image4](/addOns/image4.png) - -This is how the wallet embed might be integrated into the application, seamlessly blending with its interface and functionality. - -![Image5](/addOns/image5.png) - -[**Link for the SDK Docs**](https://obvious-embed.vercel.app/docs) - -[**Obvious Embed**](https://obvious-embed.vercel.app/) - -**[Contact](https://t.me/SarDwi8) Biconomy's BD/Sales team to integrate with Wallet UI Kit.** diff --git a/docs/pages/composability/index.mdx b/docs/pages/composability/index.mdx deleted file mode 100644 index 4b86a9b..0000000 --- a/docs/pages/composability/index.mdx +++ /dev/null @@ -1,91 +0,0 @@ -# The Need for DeFi Composability - -## The Challenge - -In the world of DeFi development, one of the most common challenges developers face is building transactions that depend on the results of previous operations. This limitation has traditionally forced developers to write custom smart contracts for even relatively simple multi-step operations. - -## A Common Scenario - -Consider what happens when a user wants to take their USDC tokens, swap them on Uniswap, and then deposit the received tokens into Aave. While this sounds straightforward, it presents a fundamental challenge: you don't know exactly how many tokens you'll receive from the swap until it happens. This uncertainty ripples through your entire transaction flow. - -## The Traditional Solution - -Until now, developers had two options: -1. Write a custom smart contract to handle the entire flow -2. Split the operation into multiple transactions requiring user intervention - -Neither solution is ideal. Custom contracts need auditing, are expensive to deploy, and create maintenance overhead. Multiple transactions lead to a poor user experience and higher gas costs. - -## Enter the Composability Stack - -The composability stack solves this by allowing developers to create dynamic, multi-step transactions entirely from frontend code. Let's look at how this works in practice: - -*Note: The following is pseudocode to demonstrate the concept* -```javascript -transaction = { - steps: [ - // Step 1: Swap tokens - swap({ - from: "USDT", - to: "USDC", - amount: 1500, - dex: "uniswap" - }), - - // Step 2: Supply to Aave - // Uses exactly what we received from the swap - supplyToAave({ - token: "USDC", - amount: executionTimeBalanceOf(USDC) - }) - ] -} -``` - -## Cross-Chain Complexity - -The challenge becomes even more pronounced when working across different chains. Developers need to track values and states across different networks. Here's how the composability stack handles this: - -*Note: The following is pseudocode to demonstrate the concept* -```javascript -transaction = { - steps: [ - // Bridge USDC from Arbitrum to Optimism - bridgeTokens({ - from: "arbitrum", - to: "optimism", - token: "USDC", - amount: 1000 - }), - - // Supply whatever we received after bridging to Aave - supplyToAave({ - chain: "optimism", - token: "USDC", - amount: executionTimeBalanceOf(USDC) - }) - ] -} -``` - -## Beyond Simple Transfers - -The power of this system extends far beyond simple token transfers. It enables complex DeFi operations like: -- Multi-hop trades across different DEXs -- Cross-chain yield farming strategies -- NFT minting and marketplace listings -- DAO treasury management -- Automated portfolio rebalancing - -## Frontend-First Development - -What makes this approach revolutionary is that it shifts complex transaction composition from smart contracts to frontend code. Instead of spending time writing and auditing custom contracts, developers can focus on building their application logic using familiar programming patterns. - -This means: -- Faster development cycles -- Lower deployment costs -- Reduced security risks -- Better user experiences -- More flexible application architectures - -The composability stack handles all the complexity of parameter injection, state management, and cross-chain communication, while developers focus on building their applications. \ No newline at end of file diff --git a/docs/pages/composability/using-fallback-handlers.mdx b/docs/pages/composability/using-fallback-handlers.mdx deleted file mode 100644 index ea0f177..0000000 --- a/docs/pages/composability/using-fallback-handlers.mdx +++ /dev/null @@ -1,169 +0,0 @@ -# Fallback Handlers: The Engine of Composability - -## Calling `executeComposable` -The composability stack works by executing an `executeComposable` function on top of a Smart Account implementation. When -calling `executeComposable` the developer can encode exactly which parameters they'd like to define ahead of time and which -parameters they'd like to dynamically inject through the Composability stack. - -:::tip[Abstracted] -Encoding calls to the `executeComposable` will be done by `AbstractJS` through a developer-friendly -set of utility functions. Writing composable function calls should be no harder then writing regular -function calls. -::: - -```solidity -/** - * @notice Executes a composable transaction with dynamic parameter composition and return value handling - * @param to The target address for the transaction - * @param value The amount of native tokens to send - * @param functionSig The 4-byte function signature - * @param params Array of Parameter structs defining how to compose the calldata - * @param returnConfig Configuration for handling the return value - */ -function executeComposable( - address to, - uint256 value, - bytes4 functionSig, - Parameter[] calldata params, - ReturnValueConfig calldata returnConfig -) external -``` - -## Understanding Fallback Handlers - -Traditionally, smart accounts (like Biconomy Nexus) use fallback handlers as a way to handle transactions that don't match any standard function signatures. When a smart account receives a transaction it doesn't recognize, instead of failing, it passes the transaction to its fallback handler to deal with. - -## Making the Fallback Handler do More - -What makes Biconomy's approach special is how it leverages this fallback mechanism. Instead of just handling unknown transactions, the fallback handler becomes an active participant in transaction composition. It acts as a middleware layer that can intercept, modify, and enhance transactions before they're executed. - - -## Why Fallback Handlers Are Perfect for Composability - -The beauty of using fallback handlers for composability lies in their position in the transaction flow. When a transaction goes through a smart account, the fallback handler gets to see it before it reaches its final destination. This means it can: - -::::steps -#### Read the original transaction -Since the developer encoded a call to `executeComposable` this will forward the -transaction to the fallback handler. The handler will deduce which parameters the -developer encoded ahead of time and which they want to be dynamically injected during execution - -#### Access current blockchain state -The fallback handler will then, if encoded as such - read the state of certain onchain variables or -storage slots. - -#### Modify the transaction parameters -The fallback handler will inject the results of those reads into the required parameters in the -function call - -#### Handle the execution results -The fallback handler will call the required target function -:::: - -This positioning makes fallback handlers the perfect place to inject dynamic values and handle transaction composition. - -![ComposerFallbackHandler](https://i.imgur.com/zESn9BO.png) - - -## Intercept, Inject, Execute - -The fallback handler's ability to intercept and modify transactions in flight is what enables dynamic composition. Because it sits between the transaction initiation and execution, it can modify the transaction parameters in real-time, injecting current values exactly when they're needed. - -## Unlocking Transaction Composability with Frontend Code - -Previously, if you wanted to use the result of one transaction in another, you'd need to: -1. Write a custom smart contract -2. Build complex storage mechanisms -3. Handle all the cross-transaction state management - -With the fallback handler approach, all of this complexity is handled by pre-deployed infrastructure. The fallback handler can capture transaction outputs, store them in namespaced slots, and inject them into subsequent transactions - all without requiring custom smart contract development. - -Pseudocode example of a composable call to `supply` function on a smart contract: - -``` -composableSupply = { - token: '0xUSDC_ADDRESS', - amount: injectParameter(storage_slot_xyz) -} -``` - -## Composability Stack Supports Cross-Chain Composability - -The fallback handler's power extends even further when working across chains. Because it can intercept and modify transactions, it can: -1. Capture values on the source chain -2. Trigger cross-chain messages -3. Have another fallback handler receive and store these values on the destination chain -4. Inject these values into new transactions - -![Cross-chain](https://i.imgur.com/XbGIeDn.png) - -## Go to Market Quicker - -What makes this truly revolutionary is that all of this power is accessible through frontend code. Developers don't need to understand the intricacies of fallback handlers or write smart contracts - they just need to use the SDK to compose their transactions. The fallback handlers handle all the complexity of: -- Parameter injection -- State management -- Cross-chain messaging -- Value storage and retrieval - -This creates a powerful abstraction layer that makes complex blockchain interactions accessible to frontend developers while maintaining the security and reliability of smart contract infrastructure. - -Here is a pseudocode example which will be very similar to the end composability features in the -`AbstractJS` SDK: - -:::danger[Not implemented] -The Composability stack is still in active development. This document is meant as an overview of the -architecture and a preview of the future implementation of the Composability stack -::: - -### Single-chain -```ts -const supertx: Supertransaction = { - instructions: [ - uniswapContract.on(optimism).swap({ - args: [ - usdc.addressOn(optimism), //swap from USDC - usdt.addressOn(optimism) // Swap to USDT - ] - }), - aaveContract.on(optimism).supply({ - args: [ - usdt.addressOn(optimism), // Supply USDT - - // Dynamically inject the exact amount of USDT - // available at the time the of the execution of - // the supply function - inTimeBalanceOf(usdt.addressOn(Optimism)) - ] - }) - ] -} -``` - -### Cross-chain -```ts -const amountToBridge = parseUnits('100', 6) // 100 USDC -const supertx: Supertransaction = { - instructions: [ - acrossPool.on(optimism).bridge({ - args: [ - usdc.addressOn(optimism), // Bridge USDC from OP - usdc.addressOn(arbitrum), // to USDC on Arbitrum - optimism.id,// Bridge from Optimism - arbitrum.id, // Bridge to Arbitrum - amountToBridge - ] - }), - uniswap.on(arbitrum).swap({ - args: [ - usdc.addressOn(arbitrum), // Swap USDC on Arbitrum, - usdt.addressOn(arbitrum), // to USDT on Arbitrum - - // Dynamically inject the amount of USDC - // which arrived from Optimism, compensating - // for any slippage a bridge might have had - inTimeBalanceOf(usdc.addressOn(arbitrum)) - ] - }) - ] -} -``` \ No newline at end of file diff --git a/docs/pages/dashboard/apis.md b/docs/pages/dashboard/apis.md deleted file mode 100644 index b093d99..0000000 --- a/docs/pages/dashboard/apis.md +++ /dev/null @@ -1,959 +0,0 @@ -# Dashboard APIs -Using these APIs allow you to perform various actions without the need to access the dashboard UI manually. -## Auth Token -To obtain an authToken required in the header, you can generate one in your account settings page on the [biconomy dashboard](https://dashboard.biconomy.io/account). - -## Paymaster Setup - -### 1. Get list of Paymasters - -> **_GET Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "DApp list fetched", - "data": [ - { - "name": "setQuoteAmoy", - "chainId": 80002, - "apiKey": "lU3R_dRgt.22c06266-1faa-4c47-8477-e8eaacd90330" - }, - { - "name": "setQuote", - "chainId": 137, - "apiKey": "rEEgKf5DS.a4e4f2c9-de7e-4a13-ac2d-6a9120714d61" - } - ] -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -### 2. Create a new Paymaster - -> **_POST Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | - -Body - -| Param | Type | Description | Required | -| ------- | ------ | ----------------------------------------------------------------------- | -------- | -| name | string | Unique name of the DApp for a chain id | Required | -| type | string | Type of paymaster to be set up, in this case will be "HYBRID" | Required | -| chainId | number | Network on which the DApp exists | Required | -| version | string | String that represents the version of Paymaster to be used for the dApp | Required | - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "DApp registered successfully", - "data": { - "name": "setQuoteAmoy", - "chainId": 80002, - "apiKey": "vrTVKqTZI.7ea9dae1-9a06-4c17-a4fb-7728177b76d3" // apiKey is used to init biconomy instance to relay transactions for this Dapp - } -} -``` - -> **_400 Bad Request_** - -Paymaster Name Already Exists - -```json -{ - "statusCode": 400, - "message": "paymaster_name_exists" -} -``` - -> **_400 Bad Request_** - -Chain Id not supported - -```json -{ - "statusCode": 400, - "message": "Chain ID not supported" -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token is required in the headers" -} -``` - -To manage the smart contracts associated with your DApp, we provide a set of endpoints that allow you to perform actions such as adding, updating, deleting, and retrieving a list of smart contracts. To access these endpoints, you will need to include the "apiKey" parameter in the header of your requests along with the "authToken". - -The "apiKey" can be obtained in two ways: - -When creating your DApp, you will receive an "apiKey" as part of the registration process. - -Alternatively, if you already have a DApp registered, you can find the "apiKey" in the list API of the DApp. - -## Configuring Paymaster Rules - -### 1. Whitelist a Smart Contract - -> **_POST Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/smart-contract -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Body - -| Param | Type | Description | Required | -| ------------------ | ---------------- | ------------------------------------------------------------------------ | -------- | -| name | string | Unique name of smart contract | Required | -| address | string | Address of smart contract | Required | -| abi | string | Stringified ABI of smart contract | Required | -| whitelistedMethods | array of strings | List of method names of smart contract which are to be sponsored by DApp | Optional | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Smart contract registered successfully" -} -``` - -> **_400 Bad Request_** - -Smart Contract Already Exists - -```json -{ - "statusCode": 400, - "message": "Smart contract address already exists" -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -### 2. Get List of Smart Contracts - -> **_GET Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/smart-contract -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Smart contract list fetched", - "data": [ - { - "name": "Set Quote", - "address": "0xe31b0bcbda693bff2529f4a1d9f7e8f6d924c6ab", - "abi": "[ { \"inputs\": [ { \"internalType\": \"string\", \"name\": \"newQuote\", \"type\": \"string\" } ], \"name\": \"setQuote\", \"outputs\": [], \"stateMutability\": \"nonpayable\", \"type\": \"function\" }, { \"inputs\": [], \"stateMutability\": \"nonpayable\", \"type\": \"constructor\" }, { \"inputs\": [], \"name\": \"admin\", \"outputs\": [ { \"internalType\": \"address\", \"name\": \"\", \"type\": \"address\" } ], \"stateMutability\": \"view\", \"type\": \"function\" }, { \"inputs\": [], \"name\": \"getQuote\", \"outputs\": [ { \"internalType\": \"string\", \"name\": \"currentQuote\", \"type\": \"string\" }, { \"internalType\": \"address\", \"name\": \"currentOwner\", \"type\": \"address\" } ], \"stateMutability\": \"view\", \"type\": \"function\" }, { \"inputs\": [], \"name\": \"owner\", \"outputs\": [ { \"internalType\": \"address\", \"name\": \"\", \"type\": \"address\" } ], \"stateMutability\": \"view\", \"type\": \"function\" }, { \"inputs\": [], \"name\": \"quote\", \"outputs\": [ { \"internalType\": \"string\", \"name\": \"\", \"type\": \"string\" } ], \"stateMutability\": \"view\", \"type\": \"function\" } ]", - "whitelistedMethods": [ - "setQuote" - ], - "methods": [ - "setQuote" - ] - } - ] -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -### 3. Update Smart Contract Whitelisted Methods - -> **_PATCH Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/smart-contract -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Body - -| Param | Type | Description | Required | -| ------------------ | ---------------- | ------------------------------------------------------------------------ | -------- | -| address | string | Smart contract address | Required | -| whitelistedMethods | array of strings | List of method names of smart contract which are to be sponsored by DApp | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Smart contract updated", - "data": { - "name": "Set Quote", - "address": "0xe31b0bcbda693bff2529f4a1d9f7e8f6d924c6ab", - "abi": "[ { \"inputs\": [ { \"internalType\": \"string\", \"name\": \"newQuote\", \"type\": \"string\" } ], \"name\": \"setQuote\", \"outputs\": [], \"stateMutability\": \"nonpayable\", \"type\": \"function\" }, { \"inputs\": [], \"stateMutability\": \"nonpayable\", \"type\": \"constructor\" }, { \"inputs\": [], \"name\": \"admin\", \"outputs\": [ { \"internalType\": \"address\", \"name\": \"\", \"type\": \"address\" } ], \"stateMutability\": \"view\", \"type\": \"function\" }, { \"inputs\": [], \"name\": \"getQuote\", \"outputs\": [ { \"internalType\": \"string\", \"name\": \"currentQuote\", \"type\": \"string\" }, { \"internalType\": \"address\", \"name\": \"currentOwner\", \"type\": \"address\" } ], \"stateMutability\": \"view\", \"type\": \"function\" }, { \"inputs\": [], \"name\": \"owner\", \"outputs\": [ { \"internalType\": \"address\", \"name\": \"\", \"type\": \"address\" } ], \"stateMutability\": \"view\", \"type\": \"function\" }, { \"inputs\": [], \"name\": \"quote\", \"outputs\": [ { \"internalType\": \"string\", \"name\": \"\", \"type\": \"string\" } ], \"stateMutability\": \"view\", \"type\": \"function\" } ]", - "whitelistedMethods": [ - "setQuote" - ], - "methods": [ - "setQuote" - ] - } - -} -``` - -> **_400 Bad Request_** - -Whitelisted methods must be an array - -```json -{ - "statusCode": 400, - "message": "whitelistedMethods must be an array" -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -> **_404 Not Found_** - -Usually, this occurs when incorrect apiKey is used or the address is not added - -```json -{ - "statusCode": 400, - "message": "Smart contract not found" -} -``` - -### 4. Update Sponsorship Paymaster Funding Wallet - -#### It is a 3-step process -::::steps - -### Generate a message from Biconomy servers for the sponsorship paymaster - -> **_GET Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/funding-message/{{paymasterId}} -``` - -Headers - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Funding message sent", - "data": { - "fundingMessage": "Timestamp: November 27, 2023, 5:05 PM\nWelcome to Biconomy! This request will connect your gas tank to our app. It will not trigger a blockchain transaction or incur any fees." - } -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -### Sign the generated message using the private key of the EOA (Funding Wallet). - -### Send the request to Biconomy to update the funding wallet address. - -> **_PATCH Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io//api/v2/public/sdk/paymaster -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Body - -| Param | Type | Description | Required | -| ----------- | ------ | ----------------------------------------------------------- | -------- | -| paymasterId | string | Sponsorship Paymaster Id | Required | -| type | string | Method Name.
Use "paymasterFundingId" here | Required | -| signature | string | Signature generated using private key of EOA | Required | -| address | string | Address of the EOA which is to be updated as funding wallet | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Paymaster updated successfully", - "data": { - "name": "testXXX", - "chainId": 80002, - "apiKey": "GwfDKydYq.2967f140-XXXX-4042-XXXX-76684f9XXXX", - "paymasterId": "e998530d-XXXX-451e-XXXX-cb6fXXXXef54" - } -} -``` - -> **_400 Bad Request_** - -This happens, when there is a signature mismatch, either because an older message is used to generate the signature, or EOA address mentioned in the request body, is not the address which signed the message. - -```json -{ - "statusCode": 400, - "message": "Invalid signature" -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -> **_404 Not Found_** - -Usually, this occurs when incorrect apiKey or authToken is used - -```json -{ - "statusCode": 404, - "message": "User not found" -} -``` -:::: - -### 5. Delete Smart Contract - -> **_DELETE Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/smart-contract -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Body - -| Param | Type | Description | Required | -| ------- | ------ | ---------------------- | -------- | -| address | string | Smart contract address | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Smart contract deleted" -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -> **_404 Not Found_** - -```json -{ - "statusCode": 400, - "message": "Smart contract not found" -} -``` -## Spending Limits & Webhooks - -### 1. Add spending limit rule to a paymaster - -> **_POST Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster-policy -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Body - -| Param | Type | Description | Required | -|------------|--------|----------------------------------------------| -------- | -| name | string | Unique Policy name | Required | -| policyType | string | Pass "PAYMASTER_SA_LIMIT" for spending limit | Required | -| policyData | object | Described below | Required | - -Policy Data - -| Param | Type | Description | Required | -|------------|-------|-------------------------------------------------------------------------------------------------------------------------| -------- | -| type | string | "PAYMASTER"(Global limit) / "SMART_ACCOUNT" (Individual User Limit) | Required | -| cycleDuration | object | eg. `{value:3, unit: "hour"}`, `{value:2, unit: "day"}`.
Currently only supported time units are "hour" and "day" | Required | -| threshold | number | Limit Value | Required | -| thresholdType | type | "COUNT" (Number of Userops) / "NATIVE_ASSET" (Gas Spend in native token, in eth) | Required | -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Paymaster Policy created successfully", - "data": { - "_id": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "name": "paymaster limit", - "policyType": "PAYMASTER_SA_LIMIT", - "organisationId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "paymasterId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "createdBy": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "chainId": 84532, - "active": true, - "policyData": { - "type": "PAYMASTER", - "startTimeInEpoch": 1709053430301, - "durationInMs": 10800000, - "cycleDuration": { - "value": 3, - "unit": "hour" - }, - "threshold": 10, - "thresholdType": "COUNT" - } - } -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -### 2. Add a webhook rule to the paymaster - -> **_POST Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster-policy -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Body - -| Param | Type | Description | Required | -|------------|--------|---------------------------------| -------- | -| name | string | Unique Policy name | Required | -| policyType | string | Pass "WEBHOOK" for webhook rule | Required | -| policyData | object | Described below | Required | - -Policy Data - -| Param | Type | Description | Required | -|--------------|-------|---------------------------------------------------------------------------------| -------- | -| url | string | Webhook URL which will be sent a POST request with the webhook data, and userOp | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Paymaster Policy created successfully", - "data": { - "_id": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "name": "webhook rule", - "policyType": "WEBHOOK", - "organisationId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "paymasterId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "createdBy": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "chainId": 84532, - "active": true, - "policyData": { - "url": "https://www.google.com" - }, - } -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - - -### 3. Add a "Wallet Deployment" rule to the paymaster - -> **_POST Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster-policy -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Body - -| Param | Type | Description | Required | -|------------|--------|-------------------------| -------- | -| name | string | Unique Policy name | Required | -| policyType | string | Pass "WALLET_DEPLOYMENT" | Required | -| policyData | object | Pass empty object (`{}`) | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Paymaster Policy created successfully", - "data": { - "_id": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "name": "wallet deployment rule", - "policyType": "WALLET_DEPLOYMENT", - "organisationId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "paymasterId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "createdBy": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "chainId": 84532, - "active": true, - "policyData": { - "operator": "walletDeployment" - }, - } -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - - - -#### 3. Get all rules for a paymaster (spending limit, webhook, wallet deployment, whitelisted contracts) - -> **_GET Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster-policy -``` -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Paymaster Policies found!", - "data": [ - { - "_id": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "name": "paymaster spending limit", - "policyType": "PAYMASTER_SA_LIMIT", - "organisationId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "paymasterId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "createdBy": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "chainId": 84532, - "active": true, - "policyData": { - "type": "PAYMASTER", - "startTimeInEpoch": 1709053430301, - "durationInMs": 10800000, - "cycleDuration": { - "value": 3, - "unit": "hour" - }, - "threshold": 10, - "thresholdType": "COUNT" - } - }, - { - "_id": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "name": "wallet deployment rule", - "policyType": "WALLET_DEPLOYMENT", - "organisationId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "paymasterId": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "createdBy": "xxxxx-xxxx-xxxx-xxxx-xxxxx", - "chainId": 84532, - "active": true, - "policyData": { - "operator": "walletDeployment" - } - } - ] -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -### 4. Update spending limit rule for a paymaster - -> **_PATCH Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster-policy/limit/:policyId -``` -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Body - -| Param | Type | Description | Required | -|------------|--------|------------------------------| -------- | -| name | string | New Policy name | | -| cycleDuration | string | updated cycle duration | | -| threshold | number | New spending limit threshold | | -| thresholdType | string | New spending limit type | | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Paymaster Limit updated" -} -``` - -On a successful update, the cycle of the spending limit will be reset and the new limit will be applied from the time of the update. - -```json -{ - "statusCode": 200, - "message": "Paymaster Limit updated" -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -### 5. Pause a policy -> **_PATCH Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster-policy/deactivate/:policyId -``` - -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Paymaster Policy Deactivated!" -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -### 6. Unpause a policy -> **_PATCH Request_** - -``` -https://paymaster-dashboard-backend.prod.biconomy.io/api/v2/public/sdk/paymaster-policy/activate/:policyId -``` -Parameters - -Header - -| Param | Type | Description | Required | -| --------- | ------ | ---------------------------------- | -------- | -| authToken | string | Token unique to every user account | Required | -| apiKey | string | API Key Associated with dApp | Required | - -Responses - -> **_200 OK_** - -```json -{ - "statusCode": 200, - "message": "Paymaster Policy Activated!" -} -``` - -> **_401 Unauthorized_** - -```json -{ - "statusCode": 401, - "message": "Auth token and API key is required in the headers" -} -``` - -## Using Webhooks with the SDK - -When building out the `paymasterServiceData` object you can optionally pass your `webhookData` to it. In the example below we pass a num value of 2 into the webhook data. Our webhook will check this data and verify if the number passed is an even or odd number. - -```typescript -let paymasterServiceData: SponsorUserOperationDto = { - mode: PaymasterMode.SPONSORED, - smartAccountInfo: { - name: "BICONOMY", - version: "2.0.0", - }, - calculateGasLimits: true, - webhookData: { - num: 2, - }, -}; -``` - -The webhookData gets passed to your webhook from our backend like this: - -```typescript -import axios from "axios"; - -// POST -const response = await axios.post(webhookUrl, { - data: webhookData, -}); - -// GET -const response = await axios.get(webhookUrl, webhookData); -``` - -Our backend expects a response in this format: - -```typescript -const webhookResponseData = response.data; -this.logger.log( - `webhookResponseData: ${JSON.stringify( - webhookResponseData, - )} for dappId: ${dappId}`, -); -const { arePoliciesVerified } = webhookResponseData; -``` - -`arePoliciesVerified` should either be true or false based on which it gets determined if the webhook conditions are passed or not. - -A sample webhook implementation that checks if the num data passed to is even: - -```javascript -const express = require("express"); -const app = express(); - -app.use(express.json()); - -app.post("/", (req, res) => { - const data = req.body; - console.log("data", data); - const { num } = data.data; - - if (num % 2 === 0) { - res.json({ - arePoliciesVerified: true, - }); - } else { - res.json({ - arePoliciesVerified: false, - }); - } -}); - -app.listen(8080, () => console.log("Server listening on port 8080!")); -``` diff --git a/docs/pages/dashboard/index.mdx b/docs/pages/dashboard/index.mdx deleted file mode 100644 index 071ce26..0000000 --- a/docs/pages/dashboard/index.mdx +++ /dev/null @@ -1,31 +0,0 @@ -# Dashboard - -The Biconomy dashboard is your gateway to accessing our services such as Paymaster, Bundlers, and allows you to retrieve your API keys for usage with our SDK and API. Additionally, this is where you can top up and configure your Paymasters for sponsoring transactions. - -:::info -Please note that this documentation refers to our Account Abstraction SDK solution. If you need information about the EOA gasless dashboard please refer to these [docs](https://docs-gasless.biconomy.io/guides/biconomy-dashboard) -::: - -## Login - -The Biconomy Dashboard can be found at [dashboard.biconomy.io/](https://dashboard.biconomy.io/). Several sign in options are available including Email, Github, and Gitlab. - -## Paymaster Keys - -Paymaster keys can be found on the Overview page of the paymasters. You can copy your Paymaster API Key as well as your Paymaster URL as shown below - -![paymaster keys](/keys/paymaster_keys.png) - -## Bundler URL - -Our Bundler as a service is coming soon but for now you can use the following URL for your bundler package: - -``` -https://bundler.biconomy.io/api/v2/{chain-id-here}/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44 -``` - -For a Bundler URL on mainnet, please contact [us](https://t.me/rhicsanchez). - -In the following sections, we will more systematically introduce the following concepts: - - diff --git a/docs/pages/dashboard/organization.md b/docs/pages/dashboard/organization.md deleted file mode 100644 index 5bc399c..0000000 --- a/docs/pages/dashboard/organization.md +++ /dev/null @@ -1,79 +0,0 @@ -# Organization Overview - -The organization feature is designed to enhance collaboration and streamline team management within your workspace. -This feature allows you to invite new team members to your organization and manage their access permissions. Whether you're looking to onboard new hires, collaborate with external partners, or reorganize teams, this feature was designed to provide you with a seamless management experience. - -## Inviting Team Members - -Inviting colleagues to join your organization is straightforward. Follow these simple steps to send an invitation: - -1. Click on the user settings dropdown and select 'Account Settings'. - -2. Navigate to 'Team' page. - -3. Click on '+ Invite User' button. - -4. Enter the email address of the individuals you wish to invite. - -5. Select the appropriate role from the predefined list to ensure each team member receives the access they require. - -6. Send the invitation by clicking the 'Invite' button. - You can invite more team members at once by clicking '+ Add More' and following steps 4 to 6. - -Once invited, team members will receive an email with a link to join the organization. -They will need to follow the link to set up their account and gain access to the resources permitted by their assigned role. - -## Role Permissions - -Roles are defined as follows: - -- `Admin`: Admins have full access to all settings and features, including the ability to invite new members, change any member’s role, manage permissions, and view and edit all projects and financial settings. - -- `Editor`: Editors can access and modify all projects and settings except for team member management. This role is suited for team members who need to make substantial contributions to projects but do not need control over user roles and permissions. - -- `Viewer`: Viewers have read-only access to all projects, meaning they cannot alter any project content. However, Viewers can deposit funds into the paymaster account, supporting financial operations without modifying project data. - -## Changing User Roles - -Adjusting the roles of existing team members is a critical part of managing your organization's operations efficiently. Whether you need to upgrade a team member's access due to a change in responsibilities or downgrade access as part of a security protocol, our system provides a straightforward process for modifying user roles. - -Steps to Change User Role: - -1. Click on the user settings dropdown and select 'Account Settings'. - -2. Navigate to 'Team' page. - -3. Find the team member whose role you want to change. - -4. Click on the user's current role displayed next to their status and select the new role you wish to assign to the user. - -## Removing Team Members - -Removing a team member from your organization may be necessary due to changes in staffing, roles, or security policies. Our platform allows admins to delete members easily and securely to ensure that only authorized users have access to sensitive organizational data. - -1. Click on the user settings dropdown and select 'Account Settings'. - -2. Navigate to 'Team' page. - -3. Find the team member you wish to remove. - -4. Click on the Delete icon, located in the table row corresponding to the member you want to remove. - -## Removing Yourself from the Organization - -There may come a time when you need to remove yourself from an organization, whether due to a change in job roles or leaving the company. Our system ensures that the organization continues to be managed effectively by requiring a smooth transition of administrative responsibilities before you can exit. - -### Prerequisites for Self-Removal: - -1. Assign Another Admin: - Before you can remove yourself from the organization, ensure that at least one other team member is assigned and has accepted the role of Admin. This is crucial to maintain uninterrupted access to all settings and features within the organization. -2. Admin Acceptance: - The newly assigned Admin must accept their invitation and fully activate their account. This ensures that there is always at least one active Admin to manage the organization. - -### Steps to Remove Yourself: - -1. Click on the user settings dropdown and select 'Account Settings'. - -2. Navigate to 'Team' page. - -3. Click on the Delete icon, located in the table row corresponding to your email. diff --git a/docs/pages/dashboard/paymaster.md b/docs/pages/dashboard/paymaster.md deleted file mode 100644 index 730ad40..0000000 --- a/docs/pages/dashboard/paymaster.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -sidebar_label: "Create a Paymaster" -sidebar_position: 2 ---- - -# Create a Paymaster - -## Add Paymaster - -Once you log in to our dashboard, you'll be directed to the paymaster page. To add a paymaster, simply click the "Add Paymaster" button. - -![Add Paymaster](/paymaster/add_paymaster.png) - -## Register Paymaster - -After clicking the "Add Paymaster" button, you can register the paymaster. Give it a name, choose a version (currently 1.0.0), and select your preferred chain. - -![Register Paymaster](/paymaster/register_paymaster.png) - -## Create Gas Tank - -If you want to sponsor users' transactions to make them gasless, you'll need to set up a gas tank. - -![First time gas tank](/paymaster/first_time_gastank.png) - -On the Gas Tank page, which you'll see for the first time, note the wallet you use for the initial setup. This wallet is the only one authorized to withdraw funds from the gas tank. When you click "I understand and set up gas tank," your wallet will prompt you for a signature. This action incurs some gas costs. Congratulations! -Your gas tank is now set up. - -## Deposit Funds - -Now that your gas tank is set up, you can deposit funds into it. Choose an amount and click "Deposit" to fill up your tank. Once the transaction is confirmed, you'll be able to see the available funds in your gas tank. - -You can programmatically deposit funds using the paymasterContract `depositFor` function by passing the `amount` and `paymasterId` which is the EOA address. For instance, you can invoke the following [function](https://polygonscan.com/address/0x00000f79b7faf42eebadba19acc07cd08af44789#writeContract#F3) on the Polygon chain. - -![Deposit funds](/paymaster//deposit_funds.png) - -## Withdraw funds - -If you need to withdraw funds from your gas tank at any time, go to the gas tank page. Enter the desired withdrawal amount and click the "Withdraw" button. - -![Withdraw Funds](/paymaster/withdraw_funds.png) - -:::info -Reminder that only the wallet you initially set up the gas tank with can actually perform a withdrawal. Any wallet is allowed to deposit as needed. -::: diff --git a/docs/pages/dashboard/paymasterRules.md b/docs/pages/dashboard/paymasterRules.md deleted file mode 100644 index f307ee8..0000000 --- a/docs/pages/dashboard/paymasterRules.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -sidebar_label: "Paymaster Rules" -sidebar_position: 3 ---- - -# Paymaster Rules - -For a paymaster, you can restrict the sponsorship to only specified contracts and methods if needed. If no contract is whitelisted, then paymaster will facilitate all the contract interactions. - -## Whitelist a Smart Contract - -Navigate to the Paymaster you have created, then click rules and contract. If this is the first time you are adding a smart contract the page will look like this: - -![new contract](/contracts/new_contract.png) - -Click on Add your First Contract and a side menu will show up asking you for details. Name your contract and provide an address. If your contract is verified the dashboard will automatically fetch the ABI for it, otherwise you can manually paste in the ABI yourself. You will then be able to choose any write methods to whitelist for sponsorship. In the example below I added the USDC contract on the Goerli testnet and chose to authorize the approve method for sponsorship. - -![add contract](/contracts/add_contract.png) - -## Updating your Smart Contract - -After adding your contract and whitelisting your methods you can make a few changes on the contract. - -- You can edit the contract to change the name or update which write methods you would like to authorize. -- You can pause the contract to temporarily stop any sponsorships -- You can delete the contract if you no longer need it on your Paymaster at all - -![update contract](/contracts/changes.png) diff --git a/docs/pages/dashboard/spendingLimits.md b/docs/pages/dashboard/spendingLimits.md deleted file mode 100644 index a588196..0000000 --- a/docs/pages/dashboard/spendingLimits.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -sidebar_label: "Spending Limits" -sidebar_position: 4 ---- - -# Spending limits & Dashboard notifications - -This feature allows you to set limits to the gas usage. You can define global limits or per-user quotas, specifying either transaction count or total gas consumption. - -## Add a global limit - -Navigate to the Paymaster you have created, then click Rules and Spending. -If this is the first time you are adding a limit the page will look like this: - -![new limit](/limits/new_limit.png) - -Click on `Add limit` inside the Global Limit card and the new global limit modal will appear. -Inside the modal you will be presented with the option of choosing: - -- Threshold type (Gas Spend | Number of user operations) -- Threshold value -- Cycle duration (minimum 1 hour, maximum 23 hours) - -After clicking `Create` the limit will be created. - -Please note that whenever the limit policy is edited (duration/ threshold/ threshold type), the cycle is reset, and the new cycle starts from the moment of edit. -Pausing/Activating a limit will not reset the cycle. - -![add global limit](/limits/global_limit_modal.png) - -## Add a user limit - -Click on `Add limit` inside the User Limit card and the new user limit modal will appear. -Both the global and the user limit modals are very similar and offer the same options. - -![add user limit](/limits/user_limit_modal.png) - - -## Low Gas Tank Balance Notifications - -The Low Gas Tank Balance Notification is designed to alert organizations when the balance in their Paymaster account falls below a predefined threshold, ensuring that they maintain sufficient funds to continue operations without disruption. - -### How It Works -- Depletion Rate Monitoring: The system tracks the depletion rate of each Paymaster by monitoring gas usage over time. This data is used to calculate the average gas consumption. - -- Threshold Calculation: A threshold is dynamically computed based on the Paymaster’s historical gas usage. The threshold represents the estimated gas consumption for a defined period (3 days). - -- Balance Monitoring: The balance of each Paymaster is frequently checked against the calculated threshold. If the balance drops below this threshold, a notification is triggered. - -### Notification Process -- When a Paymaster’s balance is below the calculated threshold, the system flags it for notification. -- Notifications are sent to the organization’s owner (email associated with the Paymaster). -- The message informs the organization that their Paymaster is running low on funds, urging them to top up the gas tank. The email includes metadata such as the Paymaster ID, organization name, and relevant links for topping up. -- The system checks Paymasters' balances daily at midnight. When a Paymaster's balance falls below the threshold, the first notification is sent immediately. Subsequent notifications are only sent if 24 hours have passed since the last notification and the balance remains below the threshold. diff --git a/docs/pages/demos/fusion/index.mdx b/docs/pages/demos/fusion/index.mdx deleted file mode 100644 index 6a52f20..0000000 --- a/docs/pages/demos/fusion/index.mdx +++ /dev/null @@ -1,218 +0,0 @@ -import FusionDemo from "../../../src/components/Fusion"; - -# Fusion - -*Make your EOA work like a smart contract account - no upgrades or pre-signatures required. Approve & swap with one signature, compatible with any EOA, works today. * - -[GitHub](https://github.com/bcnmy/examples/tree/main/nextjs-demo-fusion) - -:::warning[This demo on testnets is slow because cross-chain intents have a lot of latency on testnets. Flick to mainnet mode to check out how zippy the meeNode is in production.] -::: - - - -# Building a single signature EOA cross-chain swap with MEE: A Step-by-Step Guide - -Building complex cross-chain transactions has never been easier. With Biconomy's Modular Execution Environment (MEE), you can create powerful multi-chain workflows in just a few steps. Let's walk through a real example that bridges USDC from Optimism to Base and swaps it for FUSION tokens via Uniswap - all with a single signature and simple code. - -## The Power of Supertransactions - -Before we dive into the code, let me share what makes this demo interesting. Imagine you want to: -1. Move USDC from Optimism to Base -2. Use that USDC to buy FUSION tokens on Base -3. Have it all happen atomically with one signature - -Traditionally, this would be a painful process requiring multiple steps and signatures. But what if we could bundle these operations into a single "Supertransaction"? That's exactly what we're exploring here. - -All of this happens atomically, with just one signature from the user. Under the hood, we leverage smart accounts in an ERC-4337-like way to act on behalf of your EOA (Externally Owned Account), enabling this complex multi-chain orchestration while maintaining security and user control. - -## Building the Instructions - -### 1. First, let's set up our multichain contracts using `getMultichainContract`: - -```typescript -import { getMultichainContract } from "@biconomy/abstractjs" -import { erc20Abi } from "viem" -import { optimismSepolia, baseSepolia } from "viem/chains" - -// Set up USDC multichain contract -const mcUSDC = getMultichainContract({ - abi: erc20Abi, - deployments: [ - ["0x5fd84259d66Cd46123540766Be93DFE6D43130D7", optimismSepolia.id], - ["0x036CbD53842c5426634e7929541eC2318f3dCF7c", baseSepolia.id] - ] -}) - -// Set up Uniswap SwapRouter multichain contract -const mcUniswapSwapRouter = getMultichainContract({ - abi: UniswapSwapRouterAbi, - deployments: [ - ["0x94cC0AaC535CCDB3C01d6787D6413C739ae12bc4", optimismSepolia.id], - ["0x94cC0AaC535CCDB3C01d6787D6413C739ae12bc4", baseSepolia.id] - ] -}) -``` - -Now that we have our contracts set up, let's build our instructions: - -### 2. Define the Trigger Condition - -```typescript -const trigger: Trigger = { - chainId: optimismSepolia.id, - tokenAddress: mcUSDC.addressOn(optimismSepolia.id), - amount: sellAmount -} -``` - -The trigger condition is a required parameter for a fusion quote that specifies the initial token, amount, and chain for the transaction. When the user signs and submits the transaction, this trigger amount will be transferred from their EOA to their smart account on the specified chain, initiating the cross-chain sequence. - -### 3. Create the Bridging Intent - -```typescript -const intent: InstructionLike = mcNexus.build({ - type: "intent", - data: { - amount: sellAmount, - mcToken: mcUSDC, - toChain: baseSepolia, - mode: "OPTIMISTIC" - } -}) -``` - -The `intent` instruction tells MEE to bridge our USDC from Optimism to Base. Notice the `OPTIMISTIC` mode - this allows subsequent instructions to execute without waiting for balance checks, enabling true atomic cross-chain operations. - -### 4. Set Up Token Approval - -```typescript -const approval: InstructionLike = mcNexus.build({ - type: "approve", - data: { - amount: sellAmount, - chainId: baseSepolia.id, - tokenAddress: usdc, - spender: mcUniswapSwapRouter.addressOn(baseSepolia.id) - } -}) -``` - -Once our USDC arrives on Base, we'll need to approve the Uniswap router to spend it. This instruction handles that approval. - -### 5. Configure the Swap - -```typescript -const swap: InstructionLike = mcUniswapSwapRouter.build({ - type: "exactInputSingle", - data: { - chainId: baseSepolia.id, - args: [{ - tokenIn: mcUSDC.addressOn(baseSepolia.id), - tokenOut: mcFUSION.addressOn(baseSepolia.id), - fee: 3000, - recipient: account.address, - amountIn: safeMultiplier(sellAmount, 0.8), // Account for potential slippage, compasability coming soon... - amountOutMinimum: 1n, - sqrtPriceLimitX96: 0n - }], - // Some complex userOps will sometimes require more gas than the default. All surpluses are returned to the users smart account in native token - gasLimit: 1000000n - } -}) -``` - -This instruction configures our Uniswap swap parameters. Note that we currently have to manually account for potential slippage and dust amounts during bridging, as cross-chain composability (where the output amount from the bridge becomes the exact input for the swap) is not yet supported. This limitation means we need to use conservative estimates and may leave small amounts of dust tokens behind. -This significant limitation will be addressed in an upcoming release that enables true cross-chain composability - allowing the exact output from one instruction to be used as the input for another, even across different chains. When this feature ships, we'll provide a new demo showcasing seamless token bridging and swapping without any dust or manual amount calculations. - -### 6. Execute the Supertransaction - -```typescript -const fusionQuote = await meeClient.getFusionQuote({ - trigger, - instructions: [intent, approval, swap], - feeToken -}) - -const { hash } = await meeClient.executeFusionQuote({ fusionQuote }) -const receipt = await meeClient.getUserOperationReceipt(hash) -``` - -Finally, we bundle everything into a Fusion quote and execute it. Under the hood every instruction will be batched by chain so that gas costs and latency are minimized. The MEE handles all the complexity of: -- Monitoring the trigger condition -- Executing the bridge operation -- Waiting for funds to arrive on Base -- Executing the batched approval and swap - -## Gasless by Default - -When using tokens that support ERC20Permit (like USDC in this demo), the entire flow becomes completely gasless! MEE automatically detects permit support and handles all the complexity: -- No gas needed for approvals -- No gas needed for token transfers -- Just one signature for the entire cross-chain flow -- Works automatically - no extra code needed - -## Seamless Cross-Chain Zaps - -Imagine letting your users deposit into your protocol using any token from any chain. No more forcing users to: -- Bridge tokens themselves -- Source specific tokens on specific chains -- Execute multiple transactions -- Pay for gas on multiple chains - -Instead, users can zap directly into your pool or vault using whatever assets they already have in their EOA. MEE handles all the complexity of bridging, swapping, and depositing - all with a single signature and no gas costs (when using permit-compatible tokens). - -## The Challenge of Cross-Chain Composability - -One of the hardest problems in cross-chain development is handling the outputs of one operation as inputs to another. Let me explain why: - -Imagine you're trying to: -1. Bridge 100 USDC from Optimism to Base -2. Use that exact USDC to swap for FUSION tokens - -Sounds simple, right? But there's a catch: when tokens are bridged, you don't get exactly what you sent. Bridges often take fees, and the exact amount that arrives can vary. This means you can't know precisely how many tokens you'll have available for the swap until after the bridge operation completes. - -### The Current Workaround - -```typescript -const swap: InstructionLike = mcUniswapSwapRouter.build({ - type: "exactInputSingle", - data: { - args: [{ - // We have to estimate conservatively to account for bridge fees - amountIn: safeMultiplier(sellAmount, 0.8), // 20% buffer for fees - // ... other swap parameters - }] - } -}) -``` - -Right now, we have to: -1. Estimate conservatively how many tokens will arrive -2. Leave a buffer for bridge fees -3. Accept that some tokens might be left as "dust" - -### True Composability (Coming Soon!) - -We're about to release a major update that solves this. Here's how it will work: - -```typescript -const swap: InstructionLike = mcUniswapSwapRouter.build({ - type: "exactInputSingle", - data: { - args: [{ - // Use the exact output from the bridge operation - amountIn: bridgeIntent.output.amount, - // ... other swap parameters - }] - } -}) -``` - -With true composability: -- Instructions can reference the exact outputs of previous operations -- No more manual estimates or buffers needed -- Zero dust tokens left behind -- Works seamlessly across different chains - -This update will make cross-chain operations as simple as writing single-chain transactions. Stay tuned - we'll update this demo as soon as the feature is live! \ No newline at end of file diff --git a/docs/pages/demos/index.md b/docs/pages/demos/index.md deleted file mode 100644 index 026ef08..0000000 --- a/docs/pages/demos/index.md +++ /dev/null @@ -1,4 +0,0 @@ -# Demos - -- [Fusion](./fusion) -- [Smart Sessions](./smartSessions) \ No newline at end of file diff --git a/docs/pages/demos/smartSessions/index.mdx b/docs/pages/demos/smartSessions/index.mdx deleted file mode 100644 index 2c106f8..0000000 --- a/docs/pages/demos/smartSessions/index.mdx +++ /dev/null @@ -1,135 +0,0 @@ -import SmartSessionsDemo from "../../../src/components/SmartSessionsDemo"; - -# Smart Sessions - -*What if your dapp could execute transactions on behalf of users, without requiring them to sign every time? Let's explore how Smart Sessions enable automated trading while maintaining security and user sovereignty.* - -[GitHub](https://github.com/bcnmy/examples/tree/main/nextjs-demo-smart-sessions) - - - -## The Concept - -Smart Sessions allow dapps to execute transactions on behalf of users within strictly defined boundaries. Think of it like giving your broker limited trading permissions - they can execute trades for you, but only within the parameters you've set. - -Smart Sessions are blockchain-native JWTs. While JWTs let users stay logged into web apps, Smart Sessions let dapps execute transactions on users' behalf - but with stronger security guarantees: - -| Web2 (JWTs) | Web3 (Smart Sessions) | -|-------------|----------------------| -| Stored in databases | Validated on-chain | -| Server controls permissions | User defines exact limits | -| Can be compromised if server is hacked | Enforced by blockchain | -| Basic role-based access | Function & parameter-level control | - -For example: -```typescript -// Web2: Basic role-based permissions -{ - "role": "trader", - "permissions": ["execute_trades"] -} - -// Web3: Granular, trustless control -{ - sessionRequestedInfo: [{ - actionPoliciesInfo: [{ - contractAddress: POOL_ADDRESS, - functionSelector: "trade", - rules: [{ - condition: "LESS_THAN", - offsetIndex: 1, - ref: parseEther("1.0") // max 1 ETH per trade - }] - }] - }] -} -``` - -Unlike traditional trading bots, you never give up control of your keys. Instead, you grant specific, limited permissions that are enforced by the blockchain itself. Set spend limits, timeouts, and contract restrictions - then let your strategy run automatically. - -## What Makes This Different? - -1. **True Self-Custody**: Your keys stay yours - we just automate within your rules -2. **Gas-Free Experience**: All gas fees are covered by our Paymaster -3. **Seamless Approvals**: No separate approval transactions needed -4. **Developer Friendly**: Complex AA features with clean, simple code - - -### How Sessions Work with AbstractJS - -1. **Session Creation** - -```typescript -// Create a session with specific permissions -const session = await client.grantPermission({ - sessionRequestedInfo: [{ - sessionPublicKey: sessionKey, - actionPoliciesInfo: [{ - contractAddress: POOL_ADDRESS, - functionSelector: "0x...", // trade function - rules: [/* trading parameters */] - }] - }] -}) -``` - -2. **Permission Boundaries** - - Whitelist specific contract addresses - - Allow only certain functions (e.g., trading) - - Set maximum transaction amounts - - Define time-based constraints - -3. **Automated Execution** - -```typescript -// Execute trades using session permissions -const userOpHash = await sessionClient.usePermission({ - calls: [{ - to: POOL_ADDRESS, - data: encodeFunctionData({ - abi: POOL_ABI, - functionName: "trade", - args: [/* trade parameters */] - }) - }] -}) -``` - -## Security First - -Sessions are designed with security as the primary concern: - -- **Time-Bound**: Sessions automatically expire after 24 hours -- **Limited Scope**: Each permission grant is strictly bounded to specific actions -- **User Control**: Sessions can be revoked at any time -- **On-Chain Verification**: All permissions and rules are verified on-chain - -## Technical Implementation - -### Key Components - -1. **Session Management** - - Single dapp session key pattern - - Universal action policy for trade validation - - Time-based session expiry - -2. **Trading Logic** - - EMA-based trend detection - - Automated buy/sell execution - - Position size management - -3. **Gas Optimization** - - Gasless transactions via Biconomy Paymaster - - Batched permission updates - - Efficient session validation - -## Try It Out - -1. Connect your wallet -2. Grant trading permissions -3. Watch the automated trading in action -4. Revoke permissions any time - -For implementation details, check out the [complete source code](https://github.com/bcnmy/examples/tree/main/nextjs-demo-smart-sessions) or visit our [Smart Sessions documentation](/modules/validators/smartSessions). - -*Next: We'll explore combining Smart Sessions with cross-chain messaging for multi-chain automated trading strategies.* \ No newline at end of file diff --git a/docs/pages/eip7702/explained.mdx b/docs/pages/eip7702/explained.mdx deleted file mode 100644 index b465537..0000000 --- a/docs/pages/eip7702/explained.mdx +++ /dev/null @@ -1,45 +0,0 @@ -# EIP-7702: A Technical Overview - -## What Is EIP-7702? - -EIP-7702 is an Ethereum Improvement Proposal that introduces a new transaction type allowing Externally Owned Accounts (EOAs) to delegate their execution to smart contracts. This protocol-level enhancement effectively gives traditional EOAs programmable capabilities without requiring users to migrate to entirely new wallet addresses. - -## The Problem It Solves - -The Ethereum ecosystem has long faced a fundamental divide in account types. Traditional user wallets (EOAs) offer simplicity but lack programmability, while smart contract accounts provide powerful features but require users to adopt entirely new addresses. Users have been forced to choose between keeping their established on-chain identity or gaining access to advanced functionality. Many users understandably resist migrating due to the fragmentation of their digital identity and the complexity involved. - -EIP-7702 bridges this gap by enabling EOAs to behave like smart accounts while maintaining their original addresses and established on-chain history. - -## How EIP-7702 Works - -At its core, EIP-7702 introduces a new transaction type that contains an "authorizations" field. When an EOA owner signs a special authorization message, the Ethereum protocol records this delegation at the network level. Future transactions to this EOA will then execute the delegated smart contract's code, while still maintaining the EOA as the `msg.sender` in these transactions. - -This approach differs fundamentally from proxy contracts because the delegation happens at the protocol level. There's no need to deploy separate contracts for each user, making the process significantly more gas-efficient and seamless from a user perspective. - -## Core Capabilities - -EIP-7702 transforms traditional EOAs by enabling three key enhancements: - -First, it enables transaction batching, allowing users to combine multiple operations into single atomic transactions. For instance, token approval and swap operations that previously required separate signatures can be executed in one go. - -Second, it opens the door to alternative gas payment mechanisms. Users could have transactions sponsored by applications, pay fees using ERC-20 tokens instead of ETH, or benefit from optimized transaction bundling services. - -Third, it introduces sophisticated permission management. Users can create specialized access keys with limited authority for specific applications, implement spending limits, or restrict certain functionality while preserving core account security. - -## Technical Limitations - -Despite its innovations, EIP-7702 has inherent constraints. The EOA's private key retains ultimate control and can override any delegation through a new signed transaction. This means that unlike true smart accounts, an EIP-7702 enhanced EOA cannot implement immutable security measures like true multi-signature requirements or irreversible time-locks. - -Additionally, delegations can be overwritten, making them less permanent than deployed smart accounts. The chain-specific nature of authorizations also presents challenges for multichain applications, as synchronizing delegation across networks remains complex. - -## Protocol-Level Integration - -What sets EIP-7702 apart from application-level solutions is its integration at the Ethereum protocol layer. This approach eliminates the need for per-user contract deployments, resulting in significant gas savings—approximately 12,500 gas per authorization compared to full smart account deployments that can cost over 500,000 gas. - -This native integration with Ethereum's transaction processing system ensures broad compatibility while maintaining security guarantees. - -## Future Impact - -EIP-7702 represents a foundational building block for the next evolution of Ethereum accounts. It enables dramatically lower-cost smart account deployment—up to 80% cheaper than current methods. When combined with complementary standards like ERC-7710, ERC-7715, and ERC-5792, it creates a powerful framework for more intuitive blockchain interactions. - -As the ecosystem matures, these technologies could ultimately enable intent-based transaction systems where users express what they want to accomplish rather than specifying exact transaction parameters. diff --git a/docs/pages/eip7702/wallet-guide.mdx b/docs/pages/eip7702/wallet-guide.mdx deleted file mode 100644 index 6ec7e15..0000000 --- a/docs/pages/eip7702/wallet-guide.mdx +++ /dev/null @@ -1,130 +0,0 @@ -# For dApps using Embedded Wallets - -If you are using an embedded wallet provider (e.g. Privy, Dynamic, Web3Auth, Magic, ...) -you're able to *delegate* your EOA to a Biconomy Smart Account (this is not possible with -external wallets such as MetaMask, Rabby, etc... - for those, use [Companion Account](/smarteoa/companion-explained) based execution) - -## Why EIP-7702 -EIP-7702 is an upcoming upgrade to Ethereum and EVM blockchains which enables -wallets to convert the user EOA wallets into Smart Accounts - -With EIP-7702, wallets can drastically improve the UX for their users by offering smart -account features, such as: - - -* **Gas Abstraction**
-The ability to pay for gas with ERC20 tokens

- - -* **Gas Sponsorship**
-Wallets can sponsor user gas onchain and offer their users a different way of paying for their -transactions (e.g. prepaid, postpaid, ...)

- - -* **Batch Execution**
-The ability to batch execute transactions with a single signature

- - -* **Enable Automation**
-Wallets can install (or enable apps to install) Session Keys on accounts, which provide a -safe way to automate wallet actions. Session keys provide guardrails, meaning that the Session Key -signer can only execute the exact transactions approved by the wallet/user. This can include enabling -dollar cost averaging, TWAP selling, yield rebalancing, ...

- - -## The Most Comprehensive EIP-7702 Solutions Suite - -At Biconomy, we have built the most comprehensive EIP-7702 solution on the market, enabling -wallets to add all of the above mentioned features, as well as many advanced - Biconomy -stack specific features: - -* **Unified User Balances**
-Wallets can present apps with a _Unified Multichain Balance_. The app can then "pull" the -funds they need to the chain of their choosing. Wallets can work with solvers and bridges -to provide this liquidity.

- -* **Cross-Chain Gas Abstraction**
-Wallets can enable users to pay for gas with native or ERC20 tokens across chains. E.g. a -user can pay for a transaction on Base with USDC or ETH on Arbitrum.

- - -* **Native Scheduling and Automation**
-The Biconomy MEE Nodes can commit to execute a transaction at some point in the future or to -execute a series of transactions in some time period. For Biconomy integrators, this is available -without installing a separate module.

- -:::info -If you're a wallet team looking for an EIP-7702 strategy - [Contact Us](https://calendly.com/balaghi) -::: - -## Quickstart Guide for Developers - -::::steps -#### Install Packages -Install `AbstractJS` TypeScript SDK and viem - -```bash -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -#### Override the Smart Account Address - -In order to create an EIP-7702 enabled wallet, you need to implement just one small change to the initialization -process. When initializing your Nexus account instance, you need to _override_ the `accountAddress` paramter to the -address of your embbeded wallet EOA. - -```ts -// Function which initializes your embedded wallets. For this, check the tutorials -// from the embedded wallet providers themselves. This function should result in a -// signer object. -const embeddedWalletEOA = initializeEmbeddedWallet() - -// The multichain Nexus account -const mcNexus = await toMultichainNexusAccount({ - - // Make sure that the chains here are actually EIP-7702 enabled - chains: [sepolia], - transports: [http(), http(), http()], - signer: embeddedWalletEOA, - - // Overriding the account address parameter here! You *must* set - // this paramter to the EOA address in order to enable EIP-7702 - accountAddress: embeddedWalletEOA.address -}) -``` - -:::info -To check which chains have EIP-7702 enabled, check our information on -[Supported Networks](/supportedNetworks) -::: - -#### Execute with MEE - -After you have delegated your EOA to a Nexus Account with the EIP-7702 delegation, you're able to use -the full feature-set of Multichain Orchestration, Smart Sessions and Gas Abstraction APIs. The only difference -from the regular execution flow is that you have to set the `delegate` field to `true`! - -:::info -Delegations are set just-in-time, which means that they're sent with the first useful transaction! The Biconomy -stack signs delegations with `chainId` paramter set to `0` - which means they can get replayed on all chains. -::: - -```ts -const eip7702TxResult = await meeClient.execute({ - feeToken: { - chainId: sepolia.id, // Pay for gas on Sepolia - address: zeroAddress // Native token (ETH) - }, - instructions: [ ], // Supertransaction instructions - - // This enables the EIP-7702 Flow - delegate: true -}) -``` -:::: - -From this guide you can see that adding EIP-7702 to your flows is as easy as overriding -two properties in the standard MEE execution flow. - - - diff --git a/docs/pages/explained/bundlers-paymasters.mdx b/docs/pages/explained/bundlers-paymasters.mdx deleted file mode 100644 index 2bb8c56..0000000 --- a/docs/pages/explained/bundlers-paymasters.mdx +++ /dev/null @@ -1,82 +0,0 @@ -# Understanding Bundlers and Paymasters - -## What are UserOperations? - -UserOperations (UserOps) are the foundation of ERC4337, replacing standard Ethereum transactions for smart accounts. A UserOperation describes everything needed to execute actions from a smart account: the intended operation, validation rules, gas limits, and payment details. - -Key aspects of UserOperations: -- They represent one or more actions a smart account wants to take -- They include validation data for signature verification -- They specify how gas will be paid (either by the account or a paymaster) -- They can trigger account deployment if needed -- They enable atomic execution of multiple actions - -![UserOp](https://i.imgur.com/sCzKkPc.png) - -## Why Use Bundlers? - -Bundlers are specialized network participants that handle UserOperations. They serve as the bridge between your application's smart account operations and the blockchain. - -#### Core bundler functions: -1. Receiving and validating UserOperations -2. Maintaining a separate mempool for UserOperations -3. Simulating operations before execution -4. Combining multiple operations into efficient bundles -5. Submitting the final bundles to the blockchain - -A bundler ensures your UserOperations are valid, properly formatted, and will execute successfully on-chain. They handle all the complexity of ERC4337 validation rules and provide an efficient way to submit smart account transactions. - -## Why Use Paymasters? - -Paymasters are smart contracts that enable flexible gas payment options. They remove the requirement for users to hold native tokens (like ETH) for gas fees. - -#### Paymaster capabilities: -1. Sponsoring transactions (making them gasless for users) -2. Accepting ERC20 tokens as gas payment -3. Implementing subscription models -4. Adding custom rules for transaction sponsorship - -:::info[Use Cases] -Common paymaster applications: -- Free transactions for new users -- Subscription-based dapps -- Enterprise applications paying for user transactions -- Token-based gas fee payments -::: - -## How They Work Together - -The bundler-paymaster flow follows these steps: - -1. Your application creates a UserOperation -2. If using a paymaster, it verifies and approves the operation -3. The bundler receives the operation and validates it -4. The bundler simulates the full execution including paymaster interactions -5. When ready, the bundler includes your operation in a bundle -6. The bundle is submitted to the blockchain -7. The paymaster handles gas payment during execution - -## Benefits for Your Application - -Implementing bundlers and paymasters enables: - -1. Better User Experience - - No need for users to hold native tokens - - Simplified transaction flow - - Predictable gas costs - -2. Enhanced Functionality - - Batch multiple operations - - Implement complex transaction logic - - Flexible gas payment options - -3. Risk Management - - Pre-execution validation - - Simulation before submission - - Gas cost estimation - -## Getting Started - -Read our [Quickstart Guide](/tutorials/gasless) to account abstraction. - -Bundlers and paymasters are the key infrastructure components that make smart accounts practical and user-friendly. Understanding how they work helps you build better web3 applications with superior user experience. \ No newline at end of file diff --git a/docs/pages/explained/eoa.mdx b/docs/pages/explained/eoa.mdx deleted file mode 100644 index 2aef49c..0000000 --- a/docs/pages/explained/eoa.mdx +++ /dev/null @@ -1,67 +0,0 @@ - - - -# EOA Support -The Biconomy stack offers industry-leading support for giving EOA account smart account features. With support for -both wallets trying to migrate their users to smart accounts through EIP7702 and for apps looking to provide their -EOA users with advanced smart account features - the Biconomy stack is the perfect choice for all developers building -for users with EOA accounts. - -## Fusion Module - -Biconomy Fusion allows you to encode and execute batch transactions, including multichain batch transactions - with a single -onchain EVM transaction. The Fusion module works by employing the concept of a `Companion` Smart Contract Account assinged -to every EOA account. The Companion account is used by the MEE to execute an arbitrary number of transactions across -multiple chains. - -In order to enable the execution of the Fusion transaction though the Companion account, the user needs to sign a specially -formatted EVM transaction (encoded by our SDK) and post it onchain. This transaction contains instructions on how much -funds will be consumed by the Fusion transaction as well as all of the instructions that the user wants to execute. - - -::::steps -#### Transfer Funds to Companion Account -The user encodes a Fusion formatted transaction which transfers the amount of funds required for the execution of the -desired action to the Companion Account address. (e.g. transfer 1000 USDC to Companion account) - -#### Execute Transactions -Once the funds arrive to the Companion account, the MEE Node starts executing all required transactions - even across -multiple chains. (e.g. once 1000 USDC arrive to Companio account - bridge the funds to Base and supply to a lending protocol) - -#### Return Funds to EOA -The last action encoded in the instructions can be the transfer of any resulting funds from the Companion account to the -EOA -:::: - - -#### Single Signature Execution - -The real magic of the Fusion Module comes from an innovative transaction encoding scheme, all of those transactions to be -executed with a single user signature. - -Read more about Fusion Accounts [here](https://ethresear.ch/t/fusion-module-7702-alternative-with-no-protocol-changes/20949) - - -## EIP7702 Support -If you're a wallet looking to integrate EIP7702, read our [Integration Guide](/eip7702/wallet-guide) to get a comprehensive -overview of the steps needed to enable gas abstraction, gas sponsorhips and batch execution for your users. - -Our EIP7702 stack uses the advanced Biconomy Modular Execution Environment as the backbone, offering notable benefits -compared to alternatives using the Bundler/Paymaster stack. - -### Biconomy MEE Stack Benefits for EIP7702 Integrators - -#### **Multichain Gas Sponsorships** - - Use a single gas tank to sponsor user transactions across all supported blockchains. - -#### **Multichain Gas Abstraction** - - Use native or ERC20 tokens on any chain to pay for transaction execution on any other chain. E.g. pay for - a transaction on Optimism with USDC on Arbitrum. - -#### **Unfied Balances** - - Treat user balances across multiple chains as a single balance. When users wish to execute an action on one chain - the Biconomy MEE infrastructure will enable you to encode a Suprtransaction which pulls their funds from multiple - blockchains and executes the action on the destination chain - in a single signature. \ No newline at end of file diff --git a/docs/pages/explained/exec-environments.mdx b/docs/pages/explained/exec-environments.mdx deleted file mode 100644 index 255e6a7..0000000 --- a/docs/pages/explained/exec-environments.mdx +++ /dev/null @@ -1,32 +0,0 @@ -# Smart Account Execution Environments - -When interacting onchain with Smart Accounts, the users don't post the transactions themselves on the blockchain. Instead, -they use more advanced transaction data models - in the case of Biconomy infra - `UserOps` and `Supertransactions`! - -These data models contain extra information which a normal onchain transaction doesn't have. This can include anything -from gas sponsorship information and batch execution instructions in UserOps, to multi-chain execution sequences and -cross-chain composability instructions in Supertransactions. - -In order to convert these complex data objects into transactions and post them onchain, Smart Account users use -**Execution Environments**. - -![Execution Environments](https://i.imgur.com/RzOBVwn.png) - -## Types of Execution Environments - -### Bundlers and Paymasters -The most common type of a Smart Account execution environment is the [ERC4337](https://erc4337.com) Bundler & Paymaster -stack. In this execution environment the Bundler parses the UserOp data model and posts the function calls contained -within it onchain. If the developer decides to sponsor the user transactions or enable users to pay for gas with ERC20 -tokens - they can enable a Paymaster, which takes care of that functionality. - -[Learn more about Bundlers and Paymasters](/explained/bundlers-paymasters.mdx) - -### Modular Execution Environment -The Modular Execution Environment, or MEE - is an innovative execution environment standard - developed by Biconomy. -MEEs enable much more complex transaction sequences to be executed than just Bundlers and Paymasters. Beyond supporting just -transactions, Modular Execution Environments support both the execution of intents and transactions. Additionally, MEEs were -built with the future in mind - with an elegant mechanism which can provide execution across 1000+ blockchains, rollups -and appchains. - -[Learn more about MEEs](/explained/mee.mdx) \ No newline at end of file diff --git a/docs/pages/explained/mee.mdx b/docs/pages/explained/mee.mdx deleted file mode 100644 index 38889f6..0000000 --- a/docs/pages/explained/mee.mdx +++ /dev/null @@ -1,100 +0,0 @@ -:::warning[In Active Development] -Biconomy Modular Execution Environment is in active development and is planned for production launch at the -end of Q1/2025! Developers can start integrating the MEE Features while the contracts and modules are being -audited. -::: - -# Understanding Modular Execution Environments - -Let's dive into how Modular Execution Environments (MEE) transform complex cross-chain transactions into seamless -operations. At its heart, MEEs solve a crucial problem in blockchain development: -orchestrating multiple transactions and intent executions across different chains while maintaining security and user intent. - -## The Power of MEE Nodes - -Think of MEE Nodes as highly intelligent transaction conductors. Unlike traditional bundlers that simply batch and execute transactions, MEE Nodes understand the intricate dance of cross-chain operations. When your user initiates a complex sequence - say, bridging tokens from Optimism to Base and then using them in a DeFi protocol - the MEE Node choreographs the entire sequence. - -:::info[Key Capability] -MEE Nodes can pause execution at critical points, waiting for confirmations and watching for successful bridge operations before proceeding with subsequent steps. This ensures your transactions execute in perfect sequence, regardless of which chains they span. -::: - -What makes this truly powerful is the Node's ability to automatically determine the optimal ordering of transactions, both within a single chain and across multiple chains. It's like having a smart assistant that knows exactly when each piece of your transaction puzzle needs to fall into place. -:::info -The orchestration capabilities of the MEE Node will be greatly improved with the production release of the -[Composability Stack](/composability) -::: - -![MEE Node Power](https://i.imgur.com/CdLkOZw.png) - -## Supertransactions: The Innovation Under the Hood - -At the technical core of MEE lies the concept of Supertransactions. This isn't just another transaction format - it's a fundamental reimagining of how we can bundle and secure complex cross-chain operations. - -Here's how it works: - -1. Each individual operation (like a token approval or a swap) becomes a child transaction, encoded as a UserOp -2. These UserOps are organized into a Merkle Tree structure -3. The root of this tree becomes the Supertransaction hash - a single piece of data that cryptographically represents the entire execution sequence - -:::tip[Developer Impact] -Instead of managing multiple signatures and complex transaction ordering logic, you can have your users sign a single hash that validates the entire operation sequence. -::: - -The security of this system is anchored in ERC7579 smart contract accounts. Each account has a validator that verifies the execution, ensuring the MEE Node can only execute transactions that were explicitly approved in the signed Supertransaction. - -![Supertransaction](https://i.imgur.com/ulvvS0h.png) - -## The Future: Biconomy Network - -The current MEE architecture is just the beginning. We're building toward Biconomy Network, a system where MEE Nodes can collaborate trustlessly to execute Supertransactions across an even broader range of chains. - -Imagine this scenario: -- You have a Supertransaction that needs to execute across Optimism, Arbitrum, and Berachain -- MEE Node A supports Optimism and Arbitrum -- MEE Node B specializes in Berachain operations - -In the Biconomy Network, these nodes can seamlessly collaborate to execute your transaction, with each handling the chains they specialize in. - -![Collaborative Execution](https://i.imgur.com/eSJusML.png) - -### Making Trustless Collaboration Possible - -The key to enabling this collaboration is an elegant stake/slash mechanism: - -![Security Graph](https://i.imgur.com/R2TCego.png) - -When a node commits to executing part of a Supertransaction: -1. It posts a stake for the transactions it plans to execute -2. Signs the root hash, cryptographically committing to the execution -3. Must execute successfully or lose its stake - -:::info[Economic Security] -This economic model means nodes can collaborate without trusting each other - the stake ensures they'll execute their committed transactions or face financial consequences. -::: - -## Technical Benefits for Developers - -This architecture provides several key advantages: - -::::steps -#### **Simplified Complex Operations** - - Handle multi-chain sequences with single-signature UX - - Automatic transaction ordering and dependency management - -#### **Enhanced Security** - - Cryptographic verification of transaction sequences - - Economic security through stake/slash mechanism - - Smart contract validation of execution paths - -#### **Future Scalability** - - Access to growing network of specialized nodes - - Broader chain coverage through node collaboration - - Maintained simplicity despite increasing complexity -:::: -## Implementation Considerations - -:::warning[Important Note] -While MEE Nodes handle much of the complexity, understanding the underlying execution flow helps in designing more efficient cross-chain applications. -::: - -By leveraging MEE, you're not just building another blockchain application - you're creating solutions that can seamlessly operate across the entire blockchain ecosystem, while maintaining the simplicity your users expect. \ No newline at end of file diff --git a/docs/pages/explained/modular-sca.mdx b/docs/pages/explained/modular-sca.mdx deleted file mode 100644 index 85ee56c..0000000 --- a/docs/pages/explained/modular-sca.mdx +++ /dev/null @@ -1,78 +0,0 @@ -# Modular Smart Accounts - -Smart accounts drastically simplify the user exeperience of interacting with -blockchains and enable developers to build feature-rich accounts. Traditionally, -users would interact with blockchain though their Externally Owned Account (EOA). - -With Smart Accounts, the user accounts themselves become _programmable_, allowing -you to take advantage of powerful features like: - -- Sponsoring user transcations -- Enabling users to pay for gas with ERC20 tokens -- Enabling login with Passkeys or Social Accounts -- Sign transactions with biometrics (fingerprint, FaceID) -- Add automation to accounts (with bots, or AI Agents) -- Add additional signers - require multiple signers for a single call -- Add policies to accounts - restrict what certain signers can do with your accounts. - - Which contracts a signer can call - - Conditions - Under which conditions is a signer allowed to execute calls - - Time bounds - When can a signer execute calls -- Add custom functionality to accounts with Account Modules - -Biconomy infrastructure and our AbstractJS SDK work with industry-standard -ERC4337 and ERC7579 compliant smart accounts. You can use our reference -account implementation - Nexus or use other ERC7579 smart accout providers - -## Choose Nexus as Your Smart Account -:::tip - -Biconomy has an in-house implementation of the Modular Smart Account called Nexus. It's a -fully featured smart account using the ERC4337 and ERC7579 standards. - ---- - -Nexus highlights: -- The most gas efficient Smart Account implementation on the market. [Check Benchmarks -- Rigorously audited. Backed by 92% score from the industry leader [@DefiSafety](https://www.defisafety.com/app/pqrs/603)! [Check Audits - ---- - -[Learn More About Nexus](/overview) -::: - -## Smart Account Modules - -Smart accounts compliant with the [ERC7579 standard enable developers to -install [Account Modules](/modules) and add extra functionality to their users accounts. - -`AbstractJS` makes [installing and managing account modules easy. - -Some common modules are: - -- **Passkeys** - - Get rid of seed phrases and enable your users to sign transactions with their fingerprints or other biometrics. - -- **Smart Sessions** - - Enable bots or AI agents to automate execution on your account while providing strict guardrails on what they're - allowed to execute. Smart Sessions allow you to build complex automation, while giving your users the peace of - mind that their funds can't be misappropriated. - -- **Resource Locks** - - Enable unified balances and lightning fast cross-chain liquidity fronting with a resource lock module. Apps - interacting with users who have resource locks installed can access their funds across multiple chains in a - fraction of the time it would take to bridge them. - -:::success -**🔒 Security:** Nexus has been rigorously audited and tested, ensuring that dapps integrating it can trust its smart - account implementation. [Audits](/contractsAndAudits) by leading firms Spearbit and Cyfrin provide top-tier security - assurances. Backed by 92% score from the industry leader [@DefiSafety](https://www.defisafety.com/app/pqrs/603)! -::: - -:::info -🪙 Nexus is the most gas efficient smart account on the market, being - on average - 25% cheaper than alternatives. -Check the [Overview](https://pbs.twimg.com/media/GgseeCeWoAAP1pA?format=png&name=900x900) and -[Benchmarks](https://github.com/bcnmy/aa-benchmarks) -::: \ No newline at end of file diff --git a/docs/pages/explained/stack.mdx b/docs/pages/explained/stack.mdx deleted file mode 100644 index e69de29..0000000 diff --git a/docs/pages/infra/bundler/integration.md b/docs/pages/infra/bundler/integration.md deleted file mode 100644 index 715a7b0..0000000 --- a/docs/pages/infra/bundler/integration.md +++ /dev/null @@ -1,149 +0,0 @@ - -## Bundler - -Nexus smart accounts are compatible with the Entrypoint v7. To maximize efficiency, [Entrypoint v0.7.0](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.7.0) has introduced optimized data structures that significantly reduce transaction costs and enhance contract performance. - -:::tip -The key difference from EntryPoint v0.6 is that in v0.7, the request no longer includes `initCode`; instead, it uses `factory` and `factoryData`. -::: - -## How to get Bundler URL - -To start, send your transaction using this URL on the test networks: - -```bash -https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44 -``` -For the mainnet bundler URL, reach out to us via email at `bd@biconomy.io` or [telegram](https://t.me/pitonivan). - - -## Supported Endpoints - -### eth_sendUserOperation - -This method submits the user operation for on-chain execution and returns the userOpHash if it succeeds (or gets queued). In case of failure, an error will be returned. - - -**Parameters** - -| Param | Type | Description | Required | -| ------- | ------ | -------------------------------------------------------------------------------------- | -------- | -| method | string | Name of method in this case: `eth_sendUserOperation` | Required | -| params | array | An array consisting of the `UnPackedUseroperation` object, entrypoint address | Required | -| id | string | id for request determined by client for JSON RPC requests | Required | -| jsonrpc | string | JSON RPC version in this case 2.0.0 | Required | - -**Request** - -```json -{ - "jsonrpc": "2.0", - "method": "eth_estimateUserOperationGas", - "params": [ - { - "sender":"0x43a069aeA6122cd46aE8d451Bb599068ac5616a9", // required - "factory": "0x00000001cdE7c53f30b20Bd36015C48652F3faaC", - "factoryData": "0x123433", - "nonce": "0x663e709f60477f07885230e213b8149a7027239b0000000000000035", // required - "callData": "0x1235", // required - "callGasLimit": "0x1e8480", // required - "verificationGasLimit": "0x1e8480", // required - "preVerificationGas": "0x2aea540", // required - "maxFeePerGas": "0x1e86e6", // required - "maxPriorityFeePerGas": "0x1e8480", // required - "signature": "0xd1a0bba40a34be11544af179b04e234298b84dabc0f4e410a5571a46b6eb1fa44073049ecf1035c896f64fc979427a0369304ccc3c765c8d304b64a6f1bb3d921c", // required - "paymaster": "0x", - "paymasterVerificationGasLimit": "0x0", - "paymasterPostOpGasLimit": "0x0", - "paymasterData": null - }, - "0x0000000071727de22e5e9d8baf0edac6f37da032", // required - {} // stateOverrideSet (optional) - ], - "id": 1 -} -``` - -**Response** - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": "0x6ce281a7e0e560ccfd19162a0c8fc223c82f3ff964b1a8c5073f09c093510a6c" -} -``` - -### eth_estimateUserOperationGas - -**Parameters** - -| Param | Type | Description | Required | -| ------- | ------ | -------------------------------------------------------------------------------------- | -------- | -| method | string | Name of method in this case: `eth_estimateUserOperationGas` | Required | -| params | array | An array consisting of the `UnPackedUseroperation` object, entrypoint address | Required | -| id | string | id for request determined by client for JSON RPC requests | Required | -| jsonrpc | string | JSON RPC version in this case 2.0.0 | Required | - - -**Request** - -```json -{ - "jsonrpc": "2.0", - "method": "eth_estimateUserOperationGas", - "params": [ - { - "sender":"0x43a069aeA6122cd46aE8d451Bb599068ac5616a9", // required - "factory": "0x00000001cdE7c53f30b20Bd36015C48652F3faaC", - "factoryData": "0x123433", - "nonce": "0x663e709f60477f07885230e213b8149a7027239b0000000000000035", // required - "callData": "0x1235", // required - "callGasLimit": "0x1e8480", - "verificationGasLimit": "0x1e8480", - "preVerificationGas": "0x2aea540", - "maxFeePerGas": "0x1e86e6", - "maxPriorityFeePerGas": "0x1e8480", - "signature": "0xd1a0bba40a34be11544af179b04e234298b84dabc0f4e410a5571a46b6eb1fa44073049ecf1035c896f64fc979427a0369304ccc3c765c8d304b64a6f1bb3d921c", - "paymaster": "0x", - "paymasterVerificationGasLimit": "0x0", - "paymasterPostOpGasLimit": "0x0", - "paymasterData": null - }, - "0x0000000071727de22e5e9d8baf0edac6f37da032", // required - {} // stateOverrideSet (optional) - ], - "id": 1 -} - -``` -**Response** - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": { - "preVerificationGas": "0x2aea540", - "verificationGasLimit": "0x2aea540", - "callGasLimit": "0x2aea540", - "paymasterVerificationGasLimit": "0x0", - "paymasterPostOpGasLimit": "0x0", - } -} -``` - - -### [eth_getUserOperationReceipt](/smartAccountsV2/bundler/api/get-useroperation-receipt) - - -### [eth_getUserOperationByHash](/smartAccountsV2/bundler/api/get-useroperation-by-hash) - - -### [eth_supportedEntryPoints](/smartAccountsV2/bundler/api/supported-EntryPoints) - - -### [biconomy_getGasFeeValues](/smartAccountsV2/bundler/api/get-gas-fee-values) - - -### [biconomy_getUserOperationStatus](/smartAccountsV2/bundler/api/get-useroperation-status) \ No newline at end of file diff --git a/docs/pages/infra/index.md b/docs/pages/infra/index.md deleted file mode 100644 index e69de29..0000000 diff --git a/docs/pages/infra/paymaster/integration.md b/docs/pages/infra/paymaster/integration.md deleted file mode 100644 index f124642..0000000 --- a/docs/pages/infra/paymaster/integration.md +++ /dev/null @@ -1,87 +0,0 @@ -## Paymaster - -In EntryPoint v0.7.0, significant updates have been introduced regarding paymaster interactions. - -In v0.6, the `PaymasterAndData` field contained both the paymaster's address and any related data within a single field. In v0.7, this field has been split into two distinct fields: - -- `paymaster`: This represents the address of the paymaster. -- `paymasterData`: This field now holds any additional data needed by the paymaster for operation validation. - -This separation helps modularize the paymaster's responsibilities and makes it easier to handle specific paymaster-related logic, such as gas reimbursement or fee structure. - - -### pm_getPaymasterStubData - -This endpoint provides the stub values to be used in the paymaster-related fields of an unsigned user operation for gas estimation purposes. - - -**Parameters** - -Body - -| Param | Type | Description | Required | -| ------- | ------ | -------------------------------------------------------------------------- | -------- | -| method | string | Name of method `pm_getPaymasterStubData` | Required | -| params | array | Unsigned user operation, entrypoint address, chain id and a context object | Required | -| id | string | id for request determined by client for JSON RPC requests | Required | -| jsonrpc | string | JSON RPC version in this case 2.0 | Required | - -:::tip -The context object for Biconomy Paymaster service should be exactly the second element -of the params object that is supported on [`pm_sponsorUserOperation`](https://docs.biconomy.io/paymaster/api/sponsor-useroperation#1-mode-is-sponsored-) -::: - -**Request** - -```javascript -{ - "method":"pm_getPaymasterStubData", - "id": 1701955829, - "jsonrpc": "2.0", - "params":[ - { - "callData":"0xe9ae5c53000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000034fa66e705cf2582cf56528386bb9dfca1197672620000000000000000000000000000000000000000000000000000000000000001000000000000000000000000", - "maxFeePerGas":"0x1e8718", - "maxPriorityFeePerGas":"0x1e8480", - "nonce":"15224955350639496636633250427077404792929322447987211085485661224960", - "sender":"0xf5D9e9be20785759bd02A8723e5354dc9b98a8c1", - "signature":"0x0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000663E709f60477f07885230E213b8149a7027239B000000000000000000000000000000000000000000000000000000000000004181d4b4981670cb18f99f0b4a66446df1bf5b204d24cfcb659bf38ba27a4359b5711649ec2423c5e1247245eba2964679b6a1dbb85c992ae40b9b00c6935b02ff1b00000000000000000000000000000000000000000000000000000000000000", - "callGasLimit":"0x0", - "verificationGasLimit":"0x0", - "preVerificationGas":"0x0", - "factory": "0x", - "factoryData": "0x" - }, - "0x0000000071727De22E5E9d8BAf0edAc6f37da032", - "0x14a34", - { - "mode":"SPONSORED", - "calculateGasLimits":true, - "expiryDuration":300, - "sponsorshipInfo":{ - "webhookData":{ - - }, - "smartAccountInfo":{ - "name":"BICONOMY", - "version":"1.0.0" - } - } - } - ] -} -``` - -**Response** - -```javascript -{ - "jsonrpc": "2.0", - "id": 1701955829, - "result": { - "paymaster": "0x4688606914bF4C0595B443dB3d6822791Fec0A97", - "paymasterData": "0xc1a9a8d0f6448e61d3500262ce3ce857b02f1d0f000066e19b61000066e19459000f424017c71b4f34fd1f3ca5290c611053798b1199555415301f4610d685cab5c72ded375e65aa4f3eb7af900bf6d7f2202e0251087a6a7121c2cff07ef5dba7c38e861c", - "isFinal": false - } -} -``` diff --git a/docs/pages/infra/paymaster/supportedTokens.md b/docs/pages/infra/paymaster/supportedTokens.md deleted file mode 100644 index 9d9396e..0000000 --- a/docs/pages/infra/paymaster/supportedTokens.md +++ /dev/null @@ -1,185 +0,0 @@ -# ERC20 Gas Payments - -Our Paymaster not only allows you to sponsor transactions for your users but also allows users to pay for transactions using ERC20 tokens. Below are the supported tokens list grouped by chain. - -Please note that we will be reviewing DEX activity on each network to determine additional ERC20 token support on an ongoing basis. - -## Mainnets - -### Ethereum Mainnet 1 - -| Token symbol | Token name | Token Address | -| ------------ | -------------------------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| USDC | USD Coin | 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 | -| USDT | Tether USD | 0xdac17f958d2ee523a2206206994597c13d831ec7 | -| DAI | Dai Stablecoin | 0x6b175474e89094c44da98b954eedeac495271d0f | -| stETH | Liquid staked Ether 2.0 | 0xae7ab96520de3a18e5e111b5eaab095312d7fe84 | -| wstETH | Wrapped liquid staked Ether 2.0 | 0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0 | - -### Base 8453 - -| Token symbol | Token name | Token Address | -| ------------ | --------------- | -------------------------------------------| -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| wstETH | Wrapped liquid staked Ether 2.0 | 0xc1cba3fcea344f92d9239c08c0568f6f2f0ee452 | -| DAI | Dai Stablecoin | 0x50c5725949a6f0c72e6c4a641f24049a917db0cb | -| USDC | USD Coin | 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 | -| USDbC | USD Base Coin | 0xd9aaec86b65d86f6a7b5b1b0c42ffa531710b6ca | -| cbETH | Coinbase Wrapped Staked ETH | 0x2ae3f1ec7f1f5012cfeab0185bfc7aa3cf0dec22 | -| YFI | yearn.finance | 0x9eaf8c1e34f05a589eda6bafdf391cf6ad3cb239 | -| PRIME | PRIME | 0xfA980cEd6895AC314E7dE34Ef1bFAE90a5AdD21b | -| KNC | Kyber Network Crystal v2 | 0x28fe69ff6864c1c218878bdca01482d36b9d57b1 | -| SDEX | SmarDex Token | 0xfd4330b0312fdeec6d4225075b82e00493ff2e3f | -| RETH | Rocket Pool ETH | 0xb6fe221fe9eef5aba221c348ba20a1bf5e73624c | -| DEGEN | Degen | 0x4ed4e862860bed51a9570b96d89af5e1b0efefed | - -### Optimism Mainnet 10 - -| Token symbol | Token name | Token Address | -| ------------ | ------------------------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| WETH | Wrapped Ether | 0x4200000000000000000000000000000000000006 | -| DAI | Dai Stablecoin | 0xda10009cbd5d07dd0cecc66161fc93d7c9000da1 | -| USDT | Tether USD | 0x94b008aa00579c1307b0ef2c499ad98a8ce58e58 | -| WBTC | Wrapped Bitcoin | 0x68f180fcce6836688e9084f035309e29bf0a2095 | -| USDC | USD Coin | 0x7f5c764cbc14f9669b88837ca1490cca17c31607 | -| wstETH | Wrapped liquid staked Ether 2.0 | 0x1f32b1c2345538c0c6f582fcb022739c4a194ebb | -| BUSD | BUSD Token | 0x9c9e5fd8bbc25984b178fdce6117defa39d2db39 | -| LINK | ChainLink Token | 0x350a791bfc2c21f9ed5d10980dad2e2638ffa7f6 | -| OP | Optimism | 0x4200000000000000000000000000000000000042 | -| THALES | Thales DAO Token | 0x217d47011b23bb961eb6d93ca9945b7501a5bb11 | - -### Arbitrum One Mainnet 42161 - -| Token symbol | Token name | Token Address | -| ------------ | ------------------------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| USDT | Tether USD | 0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9 | -| WBTC | Wrapped BTC | 0x2f2a2543b76a4166549f7aab2e75bef0aefc5b0f | -| DAI | Dai Stablecoin | 0xda10009cbd5d07dd0cecc66161fc93d7c9000da1 | -| wstETH | Wrapped liquid staked Ether 2.0 | 0x5979d7b546e38e414f7e9822514be443a4800529 | -| ARB | Arbitrum | 0x912ce59144191c1204e64559fe8253a0e49e6548 | -| USDC | USD Coin | 0xaf88d065e77c8cc2239327c5edb3a432268e5831 | -| GMX | GMX | 0xfc5a1a6eb076a2c7ad06ed22c90d7e710e35ad0a | -| UNI | Uniswap | 0xfa7f8980b0f1e64a2062791cc3b0871572f1f7f0 | -| DPX | Dopex Governance Token | 0x6c2c06790b3e3e3c38e12ee22f8183b37a13ee55 | -| JOE | JoeToken | 0x371c7ec6d8039ff7933a2aa28eb827ffe1f52f07 | -| LINK | ChainLink Token | 0xf97f4df75117a78c1a5a0dbb814af92458539fb4 | -| WETH | Wrapped Ether | 0x82af49447d8a07e3bd95bd0d56f35241523fbab1 | - -### Scroll Mainnet 534352 - -| Token symbol | Token name | Token Address | -| ------------ | -------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| wstETH | Wrapped liquid staked Ether 2.0 | 0xf610a9dfb7c89644979b4a0f27063e9e7d7cda32 | -| USDT | Tether USD | 0xf55bec9cafdbe8730f096aa55dad6d22d44099df | -| USDC | USD Coin | 0x06efdbff2a14a7c8e15944d1f4a48f9f95f663a4 | - -### BNB Smart Chain Mainnet 56 - -| Token symbol | Token name | Token Address | -| ------------ | ----------------- | ------------------------------------------ | -| BNB | BNB | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| WBNB | Wrapped BNB | 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c | -| WSTETH | Wrapped liquid staked Ether 2.0 | 0x26c5e01524d2E6280A48F2c50fF6De7e52E9611C | -| USDT | Tether USD | 0x55d398326f99059ff775485246999027b3197955 | -| CAKE | PancakeSwap Token | 0x0e09fabb73bd3ade0a17ecc321fd13a19e81ce82 | -| BUSD | BUSD Token | 0xe9e7cea3dedca5984780bafc599bd69add087d56 | -| ETH | Ether | 0x2170ed0880ac9a755fd29b2688956bd959f933f8 | -| USDC | USD Coin | 0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d | -| DAI | Dai Token | 0x1af3f329e8be154074d8769d1ffa4ee058b1dbc3 | -| TWT | Trust Wallet | 0x4b0f1812e5df2a09796481ff14017e6005508003 | -| XRP | XRP Token | 0x1d2f0da169ceb9fc7b3144628db156f3f6c60dbe | -| TUSD | TrueUSD | 0x14016e85a25aeb13065688cafb43044c2ef86784 | -| MATIC | Matic Token | 0xcc42724c6683b7e57334c4e856f4c9965ed682bd | -| UNI | Uniswap | 0xbf5140a22578168fd562dccf235e5d43a02ce9b1 | -| LINK | ChainLink Token | 0xf8a0bf9cf54bb92f17374d9e9a321e6a111a51bd | - -### Polygon Mainnet 137 - -| Token symbol | Token name | Token Address | -| ------------ | -------------------- | ------------------------------------------ | -| AAVE | Aave | 0xd6df932a45c0f255f85145f286ea0b292b21c90b | -| BUSD | BUSD Token | 0x9c9e5fd8bbc25984b178fdce6117defa39d2db39 | -| DAI | (PoS) Dai Stablecoin | 0x8f3cf7ad23cd3cadbd9735aff958023239c6a063 | -| ETH | Ether | 0x7ceb23fd6bc0add59e62ac25578270cff1b9f619 | -| LINK | ChainLink Token | 0x53e0bca35ec356bd5dddfebbd1fc0fd03fabad39 | -| MANA | Decentraland MANA | 0xa1c57f48f0deb89f569dfbe6e2b7f46d33606fd4 | -| MATIC | MATIC | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| QUICK | QuickSwap | 0xb5c064f955d8e7f38fe0460c556a72987494ee17 | -| SAND | SAND | 0xbbba073c31bf03b8acf7c28ef0738decf3695683 | -| SUSHI | SushiToken | 0x0b3f868e0be5597d5db7feb59e1cadbb0fdda50a | -| TUSD | TrueUSD (PoS) | 0x2e1ad108ff1d8c782fcbbb89aad783ac49586756 | -| UNI | Uniswap | 0xb33eaad8d922b1083446dc23f610c2567fb5180f | -| USDC | USD Coin (PoS) | 0x2791bca1f2de4661ed88a30c99a7a9449aa84174 | -| USDT | Tether USD | 0xc2132d05d31c914a87c6611c10748aeb04b58e8f | -| WBTC | Wrapped BTC | 0x1bfd67037b42cf73acf2047067bd4f2c47d9bfd6 | -| WSTETH | Wrapped liquid staked Ether 2.0 | 0x03b54a6e9a984069379fae1a4fc4dbae93b3bccd | - -### Gnosis Mainnet 100 - -| Token symbol | Token name | Token Address | -| ------------ | -------------- | ------------------------------------------ | -| xDAI | xDAI | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| USDC | USD//C on xDai | 0xddafbb505ad214d7b80b1f830fccc89b60fb7a83 | -| USDT | Tether USD on xDai | 0x4ecaba5870353805a9f068101a40e0f32ed605c6 | - -### Blast Mainnet 81457 - -| Token symbol | Token name | Token Address | -| ------------ | -------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| BLAST | Blast | 0xb1a5700fa2358173fe465e6ea4ff52e36e88e2ad | -| USDB | USDB | 0x4300000000000000000000000000000000000003 | -| ESE | eesee | 0x491e6de43b55c8eae702edc263e32339da42f58c | - -### Sonic Mainnet - -* coming soon * - -## Testnets - -### Ethereum Sepolia 11155111 - -| Token symbol | Token name | Token Address | -| ------------ | -------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| DAI | Dai Stablecoin | 0x77ab54631bfbae40383c62044dc30b229c7df9f5 | - -### Base Sepolia 84532 - -| Token symbol | Token name | Token Address | -| ------------ | -------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| DAI | Dai Stablecoin | 0x7683022d84f726a96c4a6611cd31dbf5409c0ac9 | -| USDC | USDC | 0x036cbd53842c5426634e7929541ec2318f3dcf7e | - -### Optimism Sepolia 84532 - -| Token symbol | Token name | Token Address | -| ------------ | -------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| USDC | USDC | 0x5fd84259d66Cd46123540766Be93DFE6D43130D7 | - -### Arbitrum Sepolia 421614 - -| Token symbol | Token name | Token Address | -| ------------ | -------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| USDC | USD Coin | 0x75faf114eafb1BDbe2F0316DF893fd58CE46AA4d | -| USDT | Tether USD | 0x93d67359a0f6f117150a70fdde6bb96782497248 | -| LINK | Chainlink token | 0xb1D4538B4571d411F07960EF2838Ce337FE1E80E | - -### BNB Smart Chain Testnet 97 - -| Token symbol | Token name | Token Address | -| ------------ | ----------------- | ------------------------------------------ | -| ETH | Ether | 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee | -| USDC | USD Coin | 0x1ffa9c87ead57adc9e4f9a7d26ec3a52150db3b0 | -| USDT | Tether USD | 0x03bbb5660b8687c2aa453a0e42dcb6e0732b1266 | -| DAI | Dai Stablecoin | 0x355c8c8395fadf2eaa6bb27f86e53e432e3de4e6 | -| AAVE | Aave token | 0xc1537ab4f2e0b1c578baea06b5baae8f87ce971c | -| CAKE | PancakeSwap Token | 0x81f9e7a56f6869a9a8c385d1e0701b312439501f | -| LINK | ChainLink Token | 0xdeb12ea437c116ed823ab49244cafec4e41704cb | diff --git a/docs/pages/mee/fusion.mdx b/docs/pages/mee/fusion.mdx deleted file mode 100644 index 07eb923..0000000 --- a/docs/pages/mee/fusion.mdx +++ /dev/null @@ -1,138 +0,0 @@ -# For dApps Using External Wallets - -If you're building an application which expects users to connect with -external/extension wallets such as MetaMask, Rabby, Trust or through -WalletConnect - this is the approach to take to enable a lot of the -Smart EOA functionality. - -## Single Signature Approve + Execute for EOAs -One of the biggest pain points of using EOAs is the requirement to sign two separate transactions `approve` and `execute`, -when interacting with a smart contract. Here, we will demonstrate how to supply to AAVE - a transaction which would -usually require two signatures - with just one signature from the user: - -:::info[EIP-7702 Support] -As of writing this documentation, there are no wallets which support -accesing their smart accounts. There are multiple standards being developed -to enable this and Biconomy has working support for the MetaMask Delegator -framework and we're working on support for using ERC-7715. - -[Contact Us](https://t.me/pitonivan) if you need to use one of the wallet -frameworks and/or ERC-7715. - -The following tutorial applies to _all_ EOA wallets, even ones without -EIP-7702 support. -::: - -### Fusion Execution - -Fusion Execution is the Biconomy name for a backwards compatible method -of enabling smart account features on EOA wallets. It's 100% compatible -with future EIP-7702 upgrades, but also works with legacy wallets and on -chains which haven't merged EIP-7702. - -## Using Fusion Execution -::::steps -#### Define an Amount to be Used by the Fusion Transaction - -Every Fusion Transaction has an exact amount of some `ERC20` token that it will use. This is usually the amount -that you want to do an action with. In this example, this amount will be the amount that we want to supply to -AAVE - -```ts -const amountToSupply = parseUnits('100', 6) // 100 USDC -``` - -#### Encode an Approve Call -We will use the `MultichainSmartContract` utilities in `AbstractJS` to encode -an approval for AAVE v3 Pool on Optimism to spend the users USDC - -```ts [Encode ERC20 Approve Call] -const approve = mcUSDC.on(optimism.id).approve({ - args: [ - mcAaveV3Pool.addressOn(optimism.id), // approve to aave v3 pool contract - amountToSupply // amount approved - ] -}), -``` - -#### Encode a Supply Call -We'll use the same utilities to encode a supply call to the -AAVE v3 Contract - -```ts [Encode a Supply Call] -const supply = mcAaveV3Pool.on(optimism.id).supply({ - args: [ - mcUSDC.addressOn(optimism.id), // asset to supply - amountToSupply, // amount being supplied, - mcNexus.signer.address, // beneficiary - our EOA address - 0 // referral code - ] -}) -``` - -### Encode a Trigger Transaction -The trigger transaction is a transaction which will be posted onchain and -which will trigger the full execution of the Fusion transaction. In most -cases, including this tutorial, this will be a transfer of ERC20 tokens -to a Smart Contract Account address: - -#### Encode a Fusion Transaction -Now, we will use the `AbstractJS` utilities to encode a Fusion Transaction - -```ts -const { hash } = await meeClient.executeFusionQuote({ - fusionQuote: await meeClient.getFusionQuote({ - trigger: { - chainId: optimism.id, - tokenAddress: mcUSDC.addressOn(optimism.id), - amount: parseUnits("1", 6) - }, - instructions: [approve, supply], - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - } - }) -}) -``` - -#### Track the Transaction! - -That's it - your single signature, multi-step transaction has been executed! Without needing -to move users to Smart Accounts. - -You can track the execution of the trigger transaction by tracking the `hash` on an EVM explorer. -To track the execution of the additional instructions - you can use the [Biconomy MEE Explorer](https://meescan.biconomy.io) - -:::: - -## Powered by the Modular Execution Environment - -Multichain orchestration and Fusion execution are powered by the Biconomy -Modular Execution Environment (MEE) - -[Learn more about MEE](https://blog.biconomy.io/learn-modular-execution-environment-mee/) - -## Advanced: How Does the Fusion Module Work? - -![Fusion Flow](https://i.imgur.com/dVUmznn.png) -Fusion transactions work by employing a Companion Smart Account. This account is invisible to the user -and is used by the Biconomy MEE Node to execute an arbitrary number of transactions, intents and -cross-chain operations. - -It achieves this by employing the _Fusion Packing Scheme_ which puts the hash of additional instructions -to be executed _after_ the regular `callData` in an EVM transaction. This extra `callData` is ignored by the -contract and the EVM transaction is executed normally. - -This first operation in a Fusion transaction is usually a simple `transfer` function which transfers the necessary -amount of an `ERC20` token to the Companion Account. When the user signs this transaction they are also signing the -hash which was appended after the regular `callData`. AbstractJS then sends all of the -instructions which need to be executed on the Companion account to the The Biconomy MEE Node. - -After the `ERC20` token arrives to the Companion account, The MEE Node then calls the `execute` function -on the Companion smart account to execute additional instructions. The Companion account will not allow any -transactions to be executed which were not _explicitly_ contained in the hash which was appended after the `callData` - -In order to be able to execute those transactions, the `MEE Node` provides the full signed transaction -(called the trigger transaction) as the signature to the Companion smart account. - diff --git a/docs/pages/mee/mee-vs-4337.mdx b/docs/pages/mee/mee-vs-4337.mdx deleted file mode 100644 index 48dda51..0000000 --- a/docs/pages/mee/mee-vs-4337.mdx +++ /dev/null @@ -1,93 +0,0 @@ -# Beyond Account Abstraction: ERC-4337 vs. MEE - -## The Evolution of Blockchain Infrastructure - -ERC-4337 introduced account abstraction, significantly improving blockchain UX. However, as applications grow in complexity and users operate across multiple chains, developers have encountered limitations that Modular Execution Environments (MEE) are designed to solve. - -### Full ERC-4337 Parity -The Modular Execution Environment (MEE) stack has *all* the features that ERC-4337 has _and_ it retains the -same industry-leading security profile while offering significantly more features, less latency and -easier integration. - -MEE is compliant with the following standards: - -- **ERC-4337 UserOps**
-MEE Uses the same data model as ERC-4337

-- **EIP-7702**
-MEE can easily be set as the execution environment for an EIP-7702 enabled EOA

-- **ERC-7579**
-MEE uses smart account validators which are compliant with the most widely used smart account standard.

-- **ERC-7710 / ERC-7715**
-MEE can request execution through an ERC-7715 delegation and claim it on an ERC-7710 compliant contract.

- - -## Key Advantages of MEE Over ERC-4337 - -### 1. True Composability - -**ERC-4337:** Limited to static batching where all calldata must be known upfront. Transactions within a batch cannot use the results of previous steps. - -**MEE:** Enables dynamic execution where each step can reference outputs from previous steps. This allows for conditional execution, runtime calculations, and complex transaction flows even on a single chain. - -### 2. Cross-Chain Orchestration - -**ERC-4337:** Limited to single-chain operations. Cross-chain activities require multiple separate transactions with separate signatures. - -**MEE:** Natively orchestrates operations across chains, handling dependencies and timing considerations automatically. A single signature can authorize a complex flow spanning multiple chains. - -### 3. Universal Gas Abstraction - -**ERC-4337:** Supports paying gas in tokens on a single chain, but each chain's operations require separate gas management. - -**MEE:** Allows paying for gas on any chain using tokens from any other supported chain. A single gas tank can fund operations across all chains. - -### 4. Transaction Scheduling and Automation - -**ERC-4337:** No native support for scheduling or recurring transactions. - -**MEE:** Supports scheduling transactions for future execution and setting up recurring execution patterns, enabling automation of complex workflows. - -## Capability Comparison - -| Capability | ERC-4337 | MEE | -|------------|----------|-----| -| **Transaction Execution** | | | -| Simple batch transactions | ✅ | ✅ | -| Dynamic composable transactions | ❌ | ✅ | -| Output-to-input references | ❌ | ✅ | -| Transaction scheduling | ❌ | ✅ | -| Recurring transactions | ❌ | ✅ | -| **Gas Management** | | | -| Pay gas in tokens (single chain) | ✅ | ✅ | -| Pay gas in tokens (cross-chain) | ❌ | ✅ | -| Unified gas sponsorship | ❌ | ✅ | -| **Wallet Support** | | | -| Smart contract wallets | ✅ | ✅ | -| EOA wallets | ❌** | ✅ | -| **Multi-Chain Support** | | | -| Single-chain operations | ✅ | ✅ | -| Cross-chain orchestration | ❌ | ✅ | -| Bridge completion detection | ❌ | ✅ | -| Chain-agnostic development | ❌ | ✅ | - -** ERC-4337 supports EOA wallets exclusively when paired with EIP-7702. MEE supports EOA wallets by default. - -## Beyond the Technical: Use Cases Enabled by MEE - -MEE enables new user experiences that would be impractical with ERC-4337: - -1. **Cross-Chain DeFi Strategies** - Bridge assets to highest-yielding chains, swap to required assets, and deposit into protocols with a single signature. - -2. **Conditional Asset Management** - Create execution flows based on price conditions, bridge completions, or yield opportunities across multiple chains. - -3. **Autonomous Agent Workflows** - Authorize agents to execute strategies within user-defined boundaries without requiring multiple signatures. - -## Conclusion - -ERC-4337 was a critical stepping stone for blockchain UX. MEE builds directly on this foundation, preserving all benefits while solving fundamental limitations in composability and cross-chain orchestration. - -MEE isn't replacing ERC-4337—it's fulfilling its vision of making blockchain interactions seamless across the increasingly fragmented chain landscape, benefiting both developers and users with simpler, more powerful transaction capabilities - while reatining -all of the features of the ERC-4337 stack. \ No newline at end of file diff --git a/docs/pages/mee/mee.mdx b/docs/pages/mee/mee.mdx deleted file mode 100644 index e5ca38b..0000000 --- a/docs/pages/mee/mee.mdx +++ /dev/null @@ -1,75 +0,0 @@ -# Modular Execution Environments & Supertransactions (MEEs) -MEEs represent a breakthrough in onchain execution, replacing the ERC4337 Bundler & Paymaster stack through Smart Accounts integration. - - -## Smart Accounts -Smart Contract Accounts (SCAs) are programmable blockchain accounts offering custom execution logic, contrasting with -traditional External Owned Accounts (EOAs). They provide enhanced security through validation rules, -automated management with spending limits and recovery mechanisms, batched transactions, and gas fee abstraction. - -SCAs can enforce daily spending limits, require multi-signature approval, and automatically reject blacklisted addresses, making them valuable for both individual and organizational use. - -## Bundlers and Paymasters -The ERC4337 stack's Bundlers and Paymasters have revolutionized onchain UX by enabling gas sponsorship, ERC20 token gas payments, and Account Module functionality. - -If you're interested in using the Biconomy Bundler & Paymaster infra, please click [here](/overview) -### Problems with Bundlers and Paymasters -#### Multichain Execution -While ERC4337 infrastructure exists across hundreds of EVM chains, it lacks interoperability. Bundlers and Paymasters are chain-specific, preventing cross-chain operations. - -#### Intents -Traditional bridge limitations with finality and chain reordering led to the development of Intent-based execution. This system uses Fillers to front capital on destination chains before finality, charging a fee while assuming reorg risk. Current Bundler and Paymaster infrastructure cannot handle Intents or interact with Solvers. - -## Multichain Execution with Transactions and Intents - -Modular Execution Environments (MEEs) are able to execute multiple transactions on multiple chains with a single user signature. They're also able to -combine intent-based and transaction-based execution. - -### Supertransaction - -MEEs are powered by an innovative data model - called a `Supertransaction`. A Supertransaction contains instructions for executing multiple transactions -across different chains. The Supertransaction is executed by one or more MEE Nodes. - -#### Cross-chain gas -The cost of execution for the entire Supertransaction, no matter how many chains it's being -executed on - can be paid on a single chain. This enables native cross-chain gas sponsorships and paying for execution on one chain, with tokens on another. - -#### Merkle Tree -All of the instructions within the Supertransaction can be represented by a single hash - called the Supertransaction hash. This hash is derived by hashing the -individual instructions within the Supertransaction and putting them as leafs of a Merkle Tree. The root hash of that Merkle Tree is the Supertransaction hash. - -![Supertransaction](https://i.imgur.com/AxGcTiJ.jpeg) - -### MEE Node - -An MEE Node is a Node which can execute and orchestrate instructions within a Supertransaction. The MEE Node has -two primary roles: - -#### 1. Execution -The MEE Node acts like a multichain Bundler and Paymaster in one. It's able to execute transactions onchain and pay for users -gas. The Key difference is that the MEE Node can do this across multiple blockchains. - -If there are some instructions within a Supertransaction that are on chains which the specific MEE Node doesn't support, it -can allways collaborate with another MEE Node to execute that part of the Supertransaction. - -This is called _Collaborative -Execution_ and it's what enables Modular Execution Environments, such as the [Biconomy Network](/explained/mee) to effortlessly -scale across thousands for rollups and appchains. - -#### 2. Orchestration -When working in multichain environments, just executing the instructions is not enough. Multichain actions are -_asynchronous_ by default which means that the MEE Node needs to know how to _orchestrate_ the intents and transactions -in the correct sequence. - -The Biconomy MEE Node has a built-in orchestrator which is able to intelligently deduce dependencies between transactions -by checking the necessary conditions for transaction execution. - -:::info[Example] -For example. If a transaction is to supply 1000 USDC to a Morpho Valut on Optimism, but the funds must first arrive via an Intent -which moves the funds from Base, the MEE Node will wait for the execution of the Optimism transaction until the funds have arrived. -::: - -:::success[Scalable Orchestration] -The Biconomy MEE Node is able to orchestrate an arbitrary amount of transactions across an arbitraty amount of chains. Need to orchestrate -a 300 transaction sequence across 15 different chains? The MEE Node can do it automatically. -::: \ No newline at end of file diff --git a/docs/pages/mee/supertransactions.mdx b/docs/pages/mee/supertransactions.mdx deleted file mode 100644 index 11ccc8f..0000000 --- a/docs/pages/mee/supertransactions.mdx +++ /dev/null @@ -1,73 +0,0 @@ -# Supertransactions: A Practical Guide - -## What are Supertransactions? -Supertransactions revolutionize blockchain interactions by allowing users to execute multiple operations across different chains with just one signature. They uniquely combine precise transactions (when you need exact control) with intent-based execution (when you want optimal results), all wrapped into a single, efficient package. - -## Real-World Applications - -### 1. Cross-Chain DeFi Management -**Scenario: Multi-Chain Liquidity Movement** -Moving liquidity across multiple protocols on different chains traditionally requires: -- Withdrawing from your current lending protocol -- Bridging assets to another chain -- Depositing into new protocols -- Multiple signatures and gas fees - -With Supertransactions, this becomes a single-signature operation that: -- Withdraws your assets from a protocol on Optimism -- Automatically finds the best bridge route to another chain -- Places your assets in the target protocol -- All while ensuring the best execution path and lowest fees - -### 2. Portfolio Rebalancing -**Scenario: Immediate Multi-Chain Portfolio Adjustment** -A user wants to execute multiple trades across different chains to achieve a specific portfolio composition: -- Multiple token swaps across different chains -- Bridge operations for moved assets -- Deposits into yield positions -- Multiple wallet signatures - -Using Supertransactions, they can: -- Execute all necessary swaps across chains -- Optimize bridge paths for transfers -- Complete deposits into target protocols -- All with just one signature - -### 3. Treasury Operations -**Scenario: Multi-Chain Asset Distribution** -A project needs to distribute assets across multiple chains simultaneously: -- Send tokens to different addresses across chains -- Set up initial liquidity positions -- Fund operational wallets -- Execute protocol interactions - -One Supertransaction can: -- Distribute tokens to all target addresses -- Establish liquidity positions -- Fund operational accounts -- Complete everything with single approval - -## Key Benefits - -### Efficiency -- Reduced transaction costs through optimized execution -- Minimized signature requirements -- Automated best-path discovery -- Lower bridging fees through route optimization - -### Simplicity -- Complex operations reduced to single actions -- No need to manually coordinate cross-chain activities -- Automated optimization of immediate operations -- Reduced user interaction requirements - -### Flexibility -- Combine precise and intent-based operations -- Execute across any supported chains -- Mix different transaction types as needed -- Optimize execution paths automatically - -## Real Value Proposition -Supertransactions transform what would be multiple manual operations requiring many signatures into seamless, single-approval processes. They eliminate the complexity of immediate cross-chain operations while ensuring optimal execution, making sophisticated DeFi strategies more accessible and efficient. - -Would you like me to add more accurate examples or elaborate on any of these scenarios? \ No newline at end of file diff --git a/docs/pages/mee/tutorials/build-chainabstracted-app.mdx b/docs/pages/mee/tutorials/build-chainabstracted-app.mdx deleted file mode 100644 index b67d6da..0000000 --- a/docs/pages/mee/tutorials/build-chainabstracted-app.mdx +++ /dev/null @@ -1,476 +0,0 @@ -:::warning[In Active Development] -Biconomy Modular Execution Environment is in active development and is planned for production launch at the -end of Q1/2025! Developers can start integrating the MEE Features while the contracts and modules are being -audited. -::: - - -# Build a Chain Abstracted App - -For this tutorial, we will be building a chain abstracted app, powered by the Biconomy Modular Execution Environment! - -## Goals - -We want to build an app with the following features: - -::::steps -#### Unified Balance -User sees a unified balance across all chains - -#### Cross-Chain Transactions with Intents -User can deposit to _any_ AAVE market in a single signature. Intents are used to move the liquidity -around - -#### Pay for Gas With ERC20 Tokens on Any Chain -The user will be able to pay for the execution of all transactions on all chains with on any -chain where they have either native or ERC20 tokens - -#### Withdraw from Multiple AAVE Positions with a Single Signature -The user can withdraw all of their AAVE positions across all chains with a single -signature. -:::: - -The entire interface should be extremely straightforward for the user, with no chain switching, bridging or managing gas. - -## Core concepts - -The app which we build in this guide will leverage all the latest features available in `AbstractJS` SDK and -the Biconomy stack! Some highlights: - -- Using a Unified Multichain Balance -- Triggering [Intents](/mee/tutorials/execute-intent) and Transactions in as single operation -- Executing multiple transactions on multiple chains with a single signature -- Using automatic orchestration provided by the Biconomy MEE Node - - -## Step-by-Step Tutorial -:::tip -This tutorial will use the most verbose coding style, in order to explain all of the concepts. `AbstractJS` comes with -many utilities which would enable this app to be written in less lines of code. -::: -## Building the app - -::::steps -#### Creating a New Project - -For this tutorial we'll be using `bun` to create a new project. - -If you don't have `bun`, you can install it by running: -```bash [Install Bun] -curl -fsSL https://bun.sh/install | bash -``` - -Then create a new project called `chapp-example` -```bash [Create a new project] -mkdir chapp-example & cd ./chapp-example & bun init -``` - -#### Install Required Dependencies: AbstractJS and Viem - -```bash [Install AbstractJS and Viem] -bun add @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -#### Create a TypeScript File - -```bash [Create app.ts] -touch app.ts -``` - -#### Connect to the Smart Account - -Our chain abstracted app will be powered by the Biconomy Nexus smart account. Since we're working -in a multichain environment, `AbstractJS` comes with a helpful utility function to manage instances of -smart accounts across multiple chains. - -In this example, we'll create a smart account which has an EOA wallet -as the owner. In order to easily create an EOA for testing purposes, -we'll create the EOA through a `viem` utility, by providing a private -key. - -```ts [Create EOA signer] -const eoa = privateKeyToAccount('0x... Private Key Goes Here') -``` - -Then, let's connect to our Smart Account with the utility function: - -```ts [Initialize Multichain Smart Account] -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: eoa -}) -``` - -:::tip[Automated Account Managemnet] -You don't have to worry about deploying the user smart accounts. If the -smart account is not deployed on chain where you need it, `AbstractJS` -will automatically encode an instruction which deploys the account and -executes the desired transaction together. -::: - -#### Initialize the `meeClient` - -In order to execute transactions through the Biconomy [MEE Node](/explained/mee), we need to establish a connection -to it. `AbstractJS` makes this easy with a helper function: - -```ts [Connect to MEE Node] -const meeClient = await createMeeClient({ - account: mcNexus -}) -``` - -:::tip[Connecting to nodes] -You can pass an optional `url` paramter in the `createMeeClient` if -you want to connect to a custom MEE Node. The SDK defaults to -`https://mee-node.biconomy.io`, which is a node hosted by Biconomy. -::: - -#### Fund the Smart Account Address - -Fetch the Smart Account address on the chain where you want to -fund your wallet. For example, let's fetch the address for `Optimism` - -```ts -console.log( - mcNexus.deploymentOn(optimism.id).address -) -``` - -:::tip[Address Derivations] -AbstractJS uses the `CREATE2` smart account generation in the background -so the addresses on most chains should be identical. However, -some chains - like `zkSync` - derive their addresses diferently. We -recommend always using the `deploymentOn` function to fetch the -address. -::: - -Then send USDC to the Smart Account address! - -:::tip[Using other tokens] -For the purposes of this tutorial, we'll be working with `USDC`. However, you can work with a different token. -To check which tokens are supported for gas payments, check out the [MEE Node Dashboard](https://mee-node.biconomy.io/dashboard) -::: - -#### Load the Required Smart Contracts - -For this app, we'll need access to three contracts. - -- USDC Token Contract -- aUSDC Token Contract -- AAVE V3 Pool Contract - -:::tip[Multichain Utilities] -Lucikly, `AbstractJS` makes working with smart contract instances -across multiple chains extremely easy with the built-in `MultichainContract` -type. - ---- - -To learn about all of the available multichain utilities, click here -::: - -In order to load the `AaveV3Pool` contract, we can simply call the -`getMultichainContract` utility function and load it up with the -addresses of the AAVE Pool on different chains: - -```ts [Multichain Contract] -const mcAaveV3Pool = getMultichainContract({ - abi: parseAbi([ - "function supply(address asset, uint256 amount, address onBehalfOf, uint16 referralCode)", - "function withdraw(address asset, uint256 amount, address to)" - ]), - deployments: [ - ["0x794a61358D6845594F94dc1DB02A252b5b4814aD", optimism.id], - ["0xA238Dd80C259a72e81d7e4664a9801593F98d1c5", base.id], - ["0x794a61358D6845594F94dc1DB02A252b5b4814aD", polygon.id], - ["0x794a61358D6845594F94dc1DB02A252b5b4814aD", arbitrum.id] - ], -}); -``` - -:::tip[Common Token Exports] -Finding token addresses across many chains is a pain. This is why `AbstractJS` comes -with exports for the 100+ biggest ERC20 tokens. -::: - -```ts [Import and Use USDC] -import { mcuSDC } from "./utils/tokens"; - -const address = mcUSDC.addressOn(optimism.id) - -console.log(address) -``` - -#### Get the Unified Multichain Balance - -Use the built-in `getUnifiedERC20Balance` function to fetch the -unified ERC20 Balance. - -```ts -const unifiedBalance = await getUnifiedERC20Balance({ - account: mcNexus, - mcToken: mcUSD0 -}) -``` -:::: - -## Execute a Cross-Chain Supply With Intents -::::steps -#### Encode an Intent for Moving Funds to the Target Chain - -We'll use a built-in `AbstractJS` function for encoding intents. This function -will make sure that the tokens are transferred from whichever chain they're on -to the target chain. - -:::tip[Intent Solvers and Fillers] -Currently, Biconomy is using Across to provide liquidity to intents. Adding -additional providers is scheduled to be added to the SDK. -::: - -```ts -const supplyAmount = parseUnits('100', 6 ) // 100 USDC - -if(unifiedBalance.balance < supplyAmount) { - console.log("Not enough funds") -} - -const intent = await mcNexus.build({ - type: 'intent', - data: { - mcToken: mcUSDC, - amount: supplyAmount, - chain: optimism - } -}) -``` - -#### Select Chain for Paying Gas -Working on MEE stack gives developers automatic access to cross-chain -gas abstraction - meaning you can pay for gas on any chain, while executing -on any other. - -In practice - this means that no matter how much transactions we encode across -chains - we'll pay the transaction fee only once and only on one chain. - -Here, we will choose the chain with the biggest balance. - -:::tip[Paying in Assets Being Used] -Make sure that you have enough tokens on your account for both the transaction -and the gas. - -If you're using USDC as input into a function and also paying for gas -with USDC - the gas payment transaction is always executed first. So if you're -using the entire balance to pay for gas, the subsequent transactions will fail. -::: - -```ts [Selecting Biggest Balance for Gas] -const payingGasOnChain = unifiedBalance.breakdown.reduce((max, current) => { - return current.balance > max.balance ? current : max; -}).chainId; -``` - -#### Make Sure to Account for Slippage -When using intents and bridges, the amount you receive on the destination -will be less than the amount provided. This is due to the fact that Solvers -take fees for executing these cross-chain transfers. - -:::tip[Proper Solution - Composability Stack] -We are developing the Composability Stack - which is a module developers -can install on accounts to dynamically inject the _exact_ amount of funds -which were received from bridging and/or swapping. - -The Composability stack will be in production together with the production -release of the Biconomy MEE stack. - -[Learn about the Composability Stack](/composability/using-fallback-handlers) -::: - -For now, this tutorial will use a fixed -slippage buffer - a hacky solution - until we add the composability stack -documentation. - -```ts -const slippageBuffer = parseUnits('0.5', 6) -``` - -#### Encode Approve + Execute - -Now we will encode two transactions. - -1. Approve AAVE to Spend USDC on Optimism -2. Execute Supply - -```ts -const approveSupply: Instruction[] = [ - // Approve tx - mcUSDC.on(optimism.id).approve({ - args: [ - mcAaveV3Pool.addressOn(optimism.id), - supplyAmount - ] - }), - // Supply tx - mcAaveV3Pool.on(optimism.id).supply({ - args: [ - mcUSDC.addressOn(optimism.id), // asset to supply - supplyAmount - slippageBuffer, // how much to supply - zeroAddress, // on behalf of - zeroaddress if supplying for oneself - 0 // referral code - ] - }) -] -``` - -#### Execute Supertransaction -Now let's execute the Supertransaction which supplies to AAVE across chains: - -:::tip[Quote + Execute] -The execution process for MEE works by utilizing a Quote + Execute process. - -1. The node gives a Quote for the execution price -2. The developer/user checks the price -3. If not-OK, they reject the tx -4. If OK, they accept the tx - -We will be using the `execute` method which does the Quote + Execute -automatically and accepts the best available quote. If you wish to -have control over the execution price, use different methods. - -[Learn more](/mee/tutorials/execute-simple-supertx) -::: - -```ts -const { hash } = await meeClient.execute({ - instructions: [ - ...intent, - ...approveSupply - ], - feeToken: { - chainId: payingGasOnChain.id, - address: mcUSDC.addressOn(payingGasOnChain.id) - } -}) -``` - -#### Track the Execution of Your Supertransaction - -Use the built-in function to get the link to `MEEScan` - -```ts -console.log( - getMeeScanLink(hash) -) -``` - -#### Wait for the Supertransaction to Execute - -```ts -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash -}) -``` -:::: - -## Unwind AAVE Positions on Multiple Chains With a Single Signature -::::steps -#### Fetch AAVE Positions Across Chains - -We'll use the `getUnifiedERC20Balance` utility to fetch all aUSDC positions across chains. - -```ts [Fetch aUSDC Balances] -const mcAUSDC = getMultichainContract({ - abi: parseAbi([ - "function balanceOf(address owner) view returns (uint256)" - ]), - deployments: [ - ["0x625E7708f30cA75bfd92586e17077590C60eb4cD", optimism.id], - ["0x forced to be brief here - add real address", base.id], - ["0x625E7708f30cA75bfd92586e17077590C60eb4cD", polygon.id], - ["0x625E7708f30cA75bfd92586e17077590C60eb4cD", arbitrum.id] - ], -}); - -const aUSDCPositions = await getUnifiedERC20Balance({ - account: mcNexus, - mcToken: mcAUSDC -}) - -const activePositions = aUSDCPositions.breakdown.filter(p => p.balance > 0n) -``` - -#### Encode Withdrawal Instructions - -For each chain where we have a position, we need to encode two transactions: -1. Approve AAVE Pool to burn our aUSDC -2. Execute the withdrawal - -```ts [Encode Withdrawals] -const withdrawalInstructions = activePositions.flatMap(position => ([ - // Approve tx - mcAUSDC.on(position.chainId).approve({ - args: [ - mcAaveV3Pool.addressOn(position.chainId), - position.balance - ] - }), - // Withdraw tx - mcAaveV3Pool.on(position.chainId).withdraw({ - args: [ - mcUSDC.addressOn(position.chainId), - position.balance, - mcNexus.deploymentOn(position.chainId).address - ] - }) -])) -``` - -#### Select Chain for Paying Gas - -Let's check USDC balances across chains to choose where to pay gas from. - -```ts [Get Unified Balance] -const unifiedBalance = await getUnifiedERC20Balance({ - account: mcNexus, - mcToken: mcUSDC -}) - -const payingGasOnChain = unifiedBalance.breakdown.reduce((max, current) => { - return current.balance > max.balance ? current : max; -}).chainId; -``` - -#### Execute the Multichain Withdrawal - -Now we can execute all of our withdrawal transactions with a single signature: - -```ts [Execute Withdrawals] -const { hash } = await meeClient.execute({ - instructions: withdrawalInstructions, - feeToken: { - chainId: payingGasOnChain.id, - address: mcUSDC.addressOn(payingGasOnChain.id) - } -}) -``` - -#### Track the Execution Progress - -Just like with supplying, we can track our transaction on MEEScan: - -```ts [Get MEEScan Link] -console.log( - getMeeScanLink(hash) -) - -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash -}) -``` - -:::tip[Parallel Execution] -The MEE node will automatically orchestrate the execution of transactions -across different chains in parallel when possible. This means that your -withdrawals will execute as quickly as possible! -::: -:::: \ No newline at end of file diff --git a/docs/pages/mee/tutorials/execute-intent.mdx b/docs/pages/mee/tutorials/execute-intent.mdx deleted file mode 100644 index dfd0b58..0000000 --- a/docs/pages/mee/tutorials/execute-intent.mdx +++ /dev/null @@ -1,184 +0,0 @@ -:::warning[In Active Development] -Biconomy Modular Execution Environment is in active development and is planned for production launch at the -end of Q1/2025! Developers can start integrating the MEE Features while the contracts and modules are being -audited. -::: - -# Execute an Intent - -## About Intents - -`AbstractJS` enables developers to provide extremely quick chain -abstracted experiences to their users by leveraging industry-leading -intent solvers. - -By encoding an intent into a Supertransaction, developers can -move funds from one chain to another in record times (even under -a second), without the user ever needing to see the "bridging" -operation. `AbstractJS` is able to execute multiple intents, moving -funds from multiple chains, in a single operation. - -## Open, Secure and liquid - -:::tip -### No vendor lock-in -Biconomy Modular Execution Environment -leverages a vendor-neutral intent model, meaning that developers can -choose which provider they're working with. `AbstractJS` comes built-in -with plugins for triggering the biggest intent providers, giving -our users best execution prices and the fastest execution speed. -::: - - -:::tip -### Mix-and-match intent providers -AbstractJS enables developers to mix-and-match multiple intent -providers to get the best execution price. - ---- - -For example, -an optimal route to get 1000 USDC on Optimism might include -moving 600 USDC from Base using Across and moving 400 USDC -from Polygon using debridge. AbstractJS can encode both of those providers into a single -Supertransaction and trigger both of them within a single -user action. -::: - -:::tip -### Use battle-tested, liquid protocols -Whether you need to clear $1 or $1M - `AbstractJS` will find the -optimal route for you. Our utility functions quote the most liquid, -secure and battle tested solutions on the market. -::: - -## Guide - -Using Intents in `AbstractJS` is extremely easy, as it comes with -utility functions which enable developers to encode intents in just -a few lines of code. - -This guide will explore a case where the developer will use -intent based execution to: - -- Move USDC to Optimism -- Supply the received amount to AAVE - -For the purposes of this guide, we'll assume that the user -doesn't have any funds on Optimism. - -::::steps -#### Install AbstractJS and viem - -```bash [Install AbstractJS] -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -#### Initialize the infrastructure -In execute intents, users need to initialize the [`MultichainSmartAccount`](/mee/tutorials/manage-multichain-sca) -and connect to the Biconomy [MEE Node](/explained/mee). Connecting to the [MEE Node](/explained/mee) is done by creating an -`meeClient`. To learn more about the setup, read our [Building a Chain Abstracted App](/mee/tutorials/build-chainabstracted-app) guide. - -```ts [Connect the infrastructure] -// Initialize the MultichainSmartAccount -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base, polygon], - transports: [http(), http(), http()], - signer: eoaAccount -}) - -// Connect to the MEE Node -const meeClient = await createMeeClient({ - account: mcNexus -}) -``` - -#### Encode an Intent - -To encode an intent, simply call the `buildIntent` function -provided by the SDK. This function will check where your -user has funds, and encode the optimal set of instructions -to move their funds. - -:::tip[Intent not Needed] -If the user has enough funds on the target chain, the `buildIntent` -function will return an empty instruction set. - ---- - -This behaviour means developers don't have to write if/else -statements which check whether or not an intent should be triggered -::: - -```ts -const intent = await buildIntent(meeClient, { - mcToken: mcUSDC, - amount: parseUnits('100', 6), - chain: optimism -}) -``` - -#### Prepare post-intent actions - -Often times, after an intent has been executed - the user wants to -execute additional actions. For this example, we'll use supplying to -AAVE as an example. - -First, instantiate the AAVE contract. This can be done by using the `AbstractJS` -utility type `MultichainContract` - click here to learn how -`AbstractJS` multichain utilities simplify the modern onchain DevEx - -```ts -const mcAaveV3Pool = getMultichainContract({ - abi: parseAbi([ - "function supply(address asset, uint256 amount, address onBehalfOf, uint16 referralCode)", - ]), - deployments: [ - ["0x794a61358D6845594F94dc1DB02A252b5b4814aD", optimism.id], - ], -}); -``` - -Then, encode the `approve` and `supply` functions to be executed on -the AAVE contract on Optimism: - -```ts -const supplyToAaveOp: Instruction[] = [ - // Approve USDC to AAVE - mcUSDC.on(optimism.id).approve({ - args: [ - mcUSDC.addressOn(optimism.id), - parseUnits('99', 6) - ] - }), - // Call `Supply` on AAVE - mcAAVE.on(optimism.id).supply({ - args: [ - mcUSDC.addressOn(optimism.id), - parseUnits('99', 6), - zeroAddress, - 0 - ] - }) -] -``` - -Then, encode a `Supertransaction` containing the instructions from the -intent and the instructions for supplying to AAVE: - -```ts -const superTx: SuperTransaction = { - instructions: [ - mcNexus.build({ type: "intent", data: { amount: parseUnits('100', 6), mcToken: mcUSDC, toChain: optimism } }), - ...supplyToAaveOp - ], - feeToken: { - chainId: optimism.id, - address: mcUSDC.addressOn(optimism.id) - } -} -``` - -:::: - - diff --git a/docs/pages/mee/tutorials/execute-simple-supertx.mdx b/docs/pages/mee/tutorials/execute-simple-supertx.mdx deleted file mode 100644 index 791adb7..0000000 --- a/docs/pages/mee/tutorials/execute-simple-supertx.mdx +++ /dev/null @@ -1,176 +0,0 @@ -:::warning[In Active Development] -Biconomy Modular Execution Environment is in active development and is planned for production launch at the -end of Q1/2025! Developers can start integrating the MEE Features while the contracts and modules are being -audited. -::: - - -# Execute a Simple Supertransaction - -In this tutorial, we will use the Biconomy Modular Execution Environment to execute a very -simple [Supertransaction](/explained/mee#supertransactions-the-innovation-under-the-hood). - -## Goals - -The goal of this tutorial is to learn the flow of executing -a Supertransaction. This tutorial will not cover the functionalities -which Supertransactions unlock - such as multichain orchestration, -intent execution or cross-chain gas abstraction. - -## Getting Started - -::::steps -#### Install AbstractJS and viem - -```bash [Install] -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -#### Initialize the MEE Infrastructure -Supertransactions are powered by the Biconomy Modular Execution -Environment (MEE). To connect to MEE, we need to initialize -an `meeClient` - -```ts [Initialize Infrastructure] -// Create an account owner - signer -const eoaSigner = privateKeyToAccount("Your private key here") - -// Create a connector to Biconomy Nexus account -// implementations across multiple chains -// with the multichain account utility function -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: eoaSigner -}) - -// Create the connection to the MEE -const meeClient = await createMeeClient({ - account: mcNexus -}) -``` - -#### Encode a Dummy Transaction -For the purposes of this tutorial, we'll encode a dummy -transaction which simply send 0ETH to `0x000000...` - -```ts [Dummy Transaction] -const emptyTx: AbstractCall = { - to: zeroAddress, - value: 0n -} -``` - -#### Encode a Supertransaction -Now we will encode an instance of the Supertransaction -object. The Supertransaction object contains two fields: - -1. **Instructions** - which function calls need to be -executed and on which chains - -2. **Fee Token** - which native or ERC20 token and on which -chain will be used to pay for the Supertransaction - -```ts [Encode Supertransaction] -const supertransaction: Supertransaction = { - // Transactions to be executed within a - // Supertransaction - instructions: [ - mcNexus.build({ type: "default", data: { chainId: optimism.id, calls: [emptyTx] } }), - ], - // Token to pay for the Supertransaction - feeToken: { - chainId: optimism.id, - address: mcUSDC.addressOn(optimism.id) - } -} -``` - -#### Executing the Supertransaction -The way Supertransaction execution goes is as follows: - -1. The user sends the Supertransaction to the MEE Node -2. The MEE node gives back a quote - saying for how much it's willing to execute the Supertransaction -3. The user either confirms or declines the quote - -#### Getting a Quote from the MEE Node - -In order to get the Quote from the MEE Node, we call the -`getQuote` function: - -```ts [Get Quote] -const quote = await meeClient.getQuote(supertransaction) -``` - -#### Checking the Execution Cost - -Check the cost of the execution from the quote given by the -MEE Node: - -```ts [Check Execution Cost] -quote.paymentInfo.tokenValue // execution price in USD (from chainlink feed) -quote.paymentInfo.tokenWeiAmount // execution price in token base units -quote.paymentInfo.tokenAmount // execution price in token decimal units -``` - -#### Execute the Supertransaction - -If you're OK with the quoted execution cost, execute the -Supertransaction. - -```ts [Execute Supertransaction] -const { hash } = await meeClient.executeQuote({ - quote -}) -``` - -#### Get a Tracking Link for the MEE Explorer - -You can track the execution of the Supertransaction by -visiting the [MEE Explorer](https://meescan.biconomy.io) - -```ts [Tracking Link] -console.log("Link: ", getMeeScanLink(hash)) -``` - -#### Wait for the Supertransaction to Execute - -```ts -// Wait for the MEE Node to commit the transactions -// within the Supertransaction onchain -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash -}) -``` -:::: - -## Concise Implementation -The previous implementation went step by step. Now we -will show the concise implementation of this exact same -execution. - -```ts [Concise Implementation] -const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: eoaSigner - }) -}) - -const { hash } = await meeClient.executeQuote({ - quote: await meeClient.getQuote({ - instructions: [ - mcNexus.build({ type: "default", data: { chainId: optimism.id, calls: [{ to: zeroAddress, value: 0n }] } }), - ], - feeToken: { - chainId: optimism.id, - address: mcUSDC.addressOn(optimism.id) - } - }) -}) - -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash -}) -``` \ No newline at end of file diff --git a/docs/pages/mee/tutorials/execute-supertransaction.mdx b/docs/pages/mee/tutorials/execute-supertransaction.mdx deleted file mode 100644 index b63fa17..0000000 --- a/docs/pages/mee/tutorials/execute-supertransaction.mdx +++ /dev/null @@ -1,177 +0,0 @@ -:::warning[In Active Development] -Biconomy Modular Execution Environment is in active development and is planned for production launch at the -end of Q1/2025! Developers can start integrating the MEE Features while the contracts and modules are being -audited. -::: - - -# Execute a Supertransaction - -## About Supertransactions - -A Supertransaction is an innovative transaction data model, developed -for execution through Modular Execution Environments (MEEs). - -## Many chains - single signature - -Supertransactions enable developers to put multiple transactions and intents, to -be executed across multiple chains - into a single data structure and -represent it with a single hash. - -With a single signature from the user, the entire Supertransaction can -be approved and executed by the MEE Node! - -✔️ Fast, intent-based cross-chain execution - -✔️ Full flexibility of regular transactions - -## Automatic Orchestration - -Beyond this, the MEE Node will automatically deduce dependencies -between separate transactions/intents and make sure they're executed -in the correct sequence. - -For an in-depth resource about Supertransactions, visit -[Learn How Supertransactions Work](/explained/mee) - -## Executing a Simple Supertransaction - -In this example, we'll just cover the steps to executing the most -basic Supertransaction possible. It will not use Orchestration, but -instead - just execute two independent transactions on two chains -with a single user signature. - -::::steps - -#### Install required dependencies - -Install `AbstractJS` and other required dependencies - -```bash -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -#### Initialize the Multichain Smart Account - -Supertransactions use instances of Smart Accounts across multiple -chains. In order to simplify the management of multiple Smart Accounts -across multiple chains, AbstractJS comes with a built in utility type -called `MultichainSmartAccount`. Initialize it by running the code -below: - -```ts -const privateKey = "Your Private Key"; -const eoa = privateKeyToAccount(privateKey); - -// This initialized a Multichain instance of -// a Biconomy Nexus Smart Account. -const mcNexus = await toMultichainNexusAccount({ - // Initialize the Mutlichain Account on Optimism and Arbitrum - chains: [optimism, arbitrum], - transports: [http(), http()], - signer: eoa, -}); -``` - -#### Create the MEE Client - -Supertransactions are executed by MEE Nodes - the infrastructure behind -Modular Execution Environments. Create a connection to the MEE Node -in the SDK by running: - -```ts -const meeClient = await createMeeClient({ - account: mcNexus, - url: "https://mee-node.biconomy.io", -}); -``` - -#### Encode a Supertransaction - -```ts -const simpleSupertx: SuperTransaction = { - instructions: [ - // Send 0 USDC on Optimism - mcUSDC.on(optimism.id).transfer({ - args: [zeroAddress, 0n] - }), - // Send 0 USDC on Base - mcUSDC.on(optimism.id).transfer({ - args: [zeroAddress, 0n], - }), - ], - // Pay for gas with USDC on Optimism - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id, - }, -}; -``` - -#### Get a Quote from the MEE Node - -In order to execute a Supertransaction, you must get a quote from -one or more MEE Nodes. Within the quote you will get: - -- Cryptographic execution commitment from the Node -- Cost of execution in the token you specified in the `feeToken` field - -```ts -const quote = await getQuote(meeClient, simpleSupertx); -``` - -You can check the execution price for the quote and decide whether to -continue with the execution. - -```ts -quote.paymentInfo.tokenValue; // Price of execution in USD -quote.paymentInfo.tokenAmount; // Human readable cost (e.g. 1.334 USDC ) -quote.paymentInfo.tokenWeiAmount; // Cost in base units (e.g. 1334000) -``` - -:::tip[Gas Refunds] -The price which you received is the _maximum possible_ price for the -execution of the Supertransaction. The real price will most likely -be lower. The Node refunds all unspent funds to the user. -::: - -#### Sign the Quote and Execute the Supertransaction - -First sign the Supertransaction quote: - -```ts -// This uses the `signer` parameter which we set in the -// `createMeeClient` function to sign the quote -const signedQuote = await signQuote(meeClient, { - quote, -}); -``` - -Then send for execution to the MEE Node: - -```ts -const { hash } = await executeSignedQuote(meeClient, { - signedQuote, -}); -``` - -#### Wait for the Execution receipt - -You can track the Supertransaction execution in the MEE Explorer: - -```ts -console.log( - 'MEE Explorer Link: ', - getMeeScanLink(hash) -) -``` - -To wait for the Supertransaction to complete: - -```ts -const receipt = await waitForSupertransactionReceipt(meeClient, { - hash: hash, -}); -``` - -:::: diff --git a/docs/pages/mee/tutorials/manage-multichain-sca.mdx b/docs/pages/mee/tutorials/manage-multichain-sca.mdx deleted file mode 100644 index 8ce0b96..0000000 --- a/docs/pages/mee/tutorials/manage-multichain-sca.mdx +++ /dev/null @@ -1,22 +0,0 @@ -# Managing Smart Accounts on Multiple Chains - -`AbstractJS` was built from the ground-up to serve the needs of teams working in both single and multi-chain -environments. Until now, using Smart Account SDKs for multichain operations has been quite cumbersome. While -it was theoretically possible to work with Smart Accounts across chains, building such flows made the code -long and difficult to read. - -That's why `AbstractJS` comes with a built-in utility type called a `MultichainAccount`. `MultichainAccount` -manages and keeps track of multiple Smart Account deployments across different chains. It lazily deploys accounts -chain-by-chain, only when they're needed. - -Beyond this, it manages address derivations for chains which don't derive contract addresses in the same way -as Ethereum (namely zkSync and other Elastic Chain chains). - -All of this combines to give developers a pleasurable experience when dealing with Smart Accounts in a multichain -environment. - -:::tip[Single-Chain Friendly] -Like all other `AbstractJS` multichain utilities, `MultichainSmartAccount` behaves as expected in a single chain -environment and can be used by teams who are now working on a single-chain app, which might get the need for -multichain capabilities down the line. -::: \ No newline at end of file diff --git a/docs/pages/mee/tutorials/multichain-transaction-sequence.mdx b/docs/pages/mee/tutorials/multichain-transaction-sequence.mdx deleted file mode 100644 index e69de29..0000000 diff --git a/docs/pages/mee/tutorials/pay-gas-across-chains.mdx b/docs/pages/mee/tutorials/pay-gas-across-chains.mdx deleted file mode 100644 index 95fb9e9..0000000 --- a/docs/pages/mee/tutorials/pay-gas-across-chains.mdx +++ /dev/null @@ -1,129 +0,0 @@ -:::warning[In Active Development] -Biconomy Modular Execution Environment is in active development and is planned for production launch at the -end of Q1/2025! Developers can start integrating the MEE Features while the contracts and modules are being -audited. -::: - - -# Paying for Gas Across Chains - -`AbstractJS` enables developers to use native and ERC20 tokens on any supported chain to pay for gas on -any other supported chain. - -This means that as long as your user has either native tokens or ERC20 tokens on any chain, they can execute -transactions on all of them - -:::tip[Example] -A user has USDC on Optimism and uses that to pay for the execution of a transaction on Arbitrum -::: - -## Guide - -This guide will demonstrate how to use USDC on Optimism to pay for transaction execution on Arbitrum - -::::steps -#### Install AbstractJS and viem - -```bash [Install AbstractJS] -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -#### Initialize the infrastructure -In order to use cross-chain gas features, users need to initialize the `MultichainSmartAccount` -and connect to the Biconomy [MEE Node](/explained/mee). - -To learn more about the setup, read our [Building a Chain Abstracted App](/mee/tutorials/build-chainabstracted-app) guide. - -```ts [Connect the infrastructure] -// Initialize the MultichainSmartAccount -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base, polygon], - transports: [http(), http(), http()], - signer: eoaAccount -}) - -// Connect to the MEE Node -const meeClient = await createMeeClient({ - account: mcNexus -}) -``` - -#### Encode a Supertransaction -Cross-chain gas functionalities in `AbstractJS` are achieved by encoding and executing -Supertransactions - -:::tip[Exported Common Tokens] -Finding token addresses across many chains can be a pain. This is why `AbstractJS` -ships with a library of 100+ common ERC20 token contract constants. Import them -and use in your app: - -```ts -import { mcUSDC } from "abstractjs" -``` -::: - -```ts [Encode a Supertransaction] -// Placeholder call - sends 0 ETH to 0x0000000 -const emptyCall: AbstractCall = { - to: zeroAddress, - value: 0n -} - -const crossChainGasSupertx: Supertransaction = { - instructions: [ - mcNexus.build({ type: "default", data: { chainId: arbitrum.id, calls: [emptyCall] } }), - ], - // Pay for gas with USDC on Optimism - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - } -} -``` - -#### Get the Execution Quote - -Send the Supertransaction to the [MEE Node](/explained/mee) to get the -quote for the execution of your cross-chain gas Supertransaction. - -The quote contains the price for which the MEE Node will -execute the Supertransaction. - -:::tip[Maximum Price] -This is the maximum possible price that the MEE Node will -take. If the onchain execution turns out to be cheaper, the -MEE Node will refund the user. -::: - -```ts [Get Quote] -const quote = await getQuote(meeClient, crossChainGasSupertx) - -console.log( - // Human readable token amount, e.g. 1.3 - quote.paymentInfo.tokenAmount -) -``` - -#### Execute the Supertransaction - -If you're happy with the offered price, sign and execute -the Supertransaction - -```ts [Execute Supertransaction] -const { hash } = await executeQuote(meeClient, { quote }) -``` - -#### Wait for the Execution to Complete - -Track the execution status of the Supertransaction - -```ts [Wait for Receipt] -const receipt = - await waitForSupertransactionReceipt(meeClient, { hash }) - -// Get the link to MEEScan -console.log(getMeeScanLink(hash)) -``` - -To track the transaction go to [MEEScan](https://meescan.biconomy.io) and paste the `hash`. -:::: diff --git a/docs/pages/mee/what-is-mee.mdx b/docs/pages/mee/what-is-mee.mdx deleted file mode 100644 index 07dfc1d..0000000 --- a/docs/pages/mee/what-is-mee.mdx +++ /dev/null @@ -1,90 +0,0 @@ -# What is MEE? Unlocking Next-Level UX for Ethereum & Rollups - -## Overview - -Modular Execution Environment (MEE) is a revolutionary standard from Biconomy that unlocks seamless user experiences on Ethereum and across its growing ecosystem of rollups. By decoupling transaction signing from execution, MEE enables powerful new UX paradigms within both single-chain and multi-chain environments. Crucially, MEE provides significant benefits even when operating on a single chain, while also solving the challenges of cross-chain interaction. - -## Transforming User Experience - -### For End Users - -MEE eliminates the most significant friction points in the Ethereum ecosystem: - -- **Single-Signature Multi-Chain Actions** — Complete complex operations across Ethereum, Arbitrum, Optimism, Base, and more with just one signature -- **No More Native Token Requirements** — Pay for transactions on any rollup using any token from any chain -- **Simplified Onboarding** — New users can interact with multiple rollups without managing separate wallets or bridging tokens first - -### For Developers - -MEE dramatically simplifies building applications in the fragmented rollup ecosystem: - -- **Universal Chain Access** — Connect to all Ethereum rollups through a single endpoint -- **Reduced Integration Complexity** — No need to maintain separate RPC connections, gas estimations, and signing flows for each chain -- **True Composability** — Build complex multi-step transactions where each step can use the results of previous steps -- **Accelerated Time-to-Market** — Launch multi-chain products in a fraction of the time - -## Real-World Use Cases - -### Cross-Rollup DeFi - -An investor can execute an entire multi-rollup strategy with one click: -1. Swap tokens on Optimism -2. Bridge to Arbitrum -3. Enter a liquidity position -4. Set up automated compounding - -All of this happens with a single signature, zero native token requirements, and automatic orchestration between steps. - -### NFT Marketplaces - -Buyers can purchase NFTs across multiple marketplaces on different rollups in a single transaction: -- Buy an NFT on Optimism, another on Base, and a third on Arbitrum -- Pay in any token from any chain -- Complete the entire collection in one signature - -### Gaming & Social Applications - -Games and social apps can span multiple rollups while maintaining a seamless experience: -- Players move between game environments on different rollups without noticing chain switches -- Social platforms can optimize for cost/performance by distributing different functions across rollups -- All while maintaining a single-signature, gasless experience for users - -## Technical Architecture - -MEE operates through "Supertransactions" — instructions that combine multiple actions across different chains into a single approved package. Key features include: - -- **Works with All Wallets** — Compatible with both EOA wallets and smart contract wallets -- **True Composability** — Each step can use the output of previous steps as input -- **Transaction Scheduling** — Set up future or recurring transactions across any rollup -- **Collaborative Execution** — Multiple MEE nodes can contribute to executing parts of a Supertransaction - -## Beyond Account Abstraction - -While account abstraction (ERC-4337) improved single-chain UX, MEE extends these benefits across the entire Ethereum ecosystem: - -- Maintains all ERC-4337 capabilities -- Adds cross-chain orchestration -- Enables dynamic composability between transactions -- Works with traditional EOA wallets - -## Getting Started - -Developers can start building with MEE through Biconomy's AbstractJS SDK, which handles all the complexity of interacting with the MEE infrastructure: - -```javascript -// Example concept of a multi-chain flow with MEE -meeClient.executeQuote({ - instructions: [ - // Actions across Ethereum, Arbitrum, Optimism, etc. - ], - feeToken: { - // Pay gas in any token from any chain - } -}) -``` - -## Conclusion - -As Ethereum's modular ecosystem continues to expand, MEE provides the missing orchestration layer that unites these specialized environments into a cohesive user experience. By abstracting away the complexities of cross-rollup interactions, MEE enables developers to build truly seamless applications and gives users the simplified experience they expect from modern applications. - -MEE isn't just an incremental improvement—it's a fundamental shift in how we build and interact with applications in Ethereum's multi-rollup future. \ No newline at end of file diff --git a/docs/pages/migrations/index.md b/docs/pages/migrations/index.md deleted file mode 100644 index 4c5bb25..0000000 --- a/docs/pages/migrations/index.md +++ /dev/null @@ -1,112 +0,0 @@ -# Account Migration Guide - -This section covers how to migrate between different versions of Biconomy smart accounts. AbstractJS provides migration paths that preserve your users' account addresses, balances, and transaction history while upgrading to newer implementations. - -## Key Migration Concepts - -### Address Preservation - -The most important concept in any smart account migration is **address preservation**. When you migrate a smart account: - -- The account's address remains unchanged -- All assets and tokens stay with the account -- External contracts and services that interact with the account continue to work -- User experience remains seamless with no visible interruption - -### Migration Types - -AbstractJS supports the following migration paths: - -1. [**V2 to Nexus Migration**](/migrations/v2ToNexus): Migrate from Biconomy Smart Account v2 to Nexus accounts -2. [**Nexus to Nexus Migration**](/migrations/nexusToNexus): Upgrade between different versions of Nexus accounts - -## Why User Address Persistence Is Critical - -Smart account addresses are the cornerstone of user identity and asset ownership in blockchain applications. It's **absolutely essential** to maintain these addresses during and after migration for several key reasons: - -### 1. Asset Preservation - -All user assets (tokens, NFTs, etc.) are associated with their account address. If this address changes or access is lost: - -- Users lose access to all their funds and digital assets -- Recovery may be impossible, resulting in permanent loss - -### 2. External Relationship Preservation - -Smart account addresses establish relationships with other contracts and services: - -- Token allowances and approvals are tied to specific addresses -- DAO memberships, governance rights, and voting power -- Access control in permissioned systems - -### 3. Technical Requirements - -After migration, you **must always** use the `accountAddress` parameter when recreating the account instance: - -```typescript -// CORRECT: Specifying accountAddress preserves access to the existing account -const nexusAccount = await toNexusAccount({ - signer: eoaAccount, - chain: baseChain, - transport: http(), - accountAddress: "0xUserExistingAccountAddress" // CRITICAL! -}); - -// INCORRECT: Without accountAddress, a new account is created -// This will result in loss of access to the existing account and its funds! -const newAccount = await toNexusAccount({ - signer: eoaAccount, - chain: baseChain, - transport: http() -}); -``` - -## Best Practices for Migration - -### 1. Store Account Addresses Persistently - -Always store user account addresses in a persistent database or storage: - -- Server-side database for backend applications -- Local storage or secure storage for frontend applications -- Consider multiple backup locations for critical applications - -### 2. Test Before Full Deployment - -- Run the migration on testnets first -- Perform small test transactions after migration -- Verify all functionality works as expected with the migrated account - -### 3. Provide User Guidance - -If your application has end users: - -- Communicate the migration timeline in advance -- Explain that the migration preserves all assets and functionality -- Provide clear instructions for any user-initiated steps - -### 4. Maintain Version Records - -Keep records of: - -- The account version before migration -- The account version after migration -- Timestamps of when migrations occurred - -## Framework Support - -AbstractJS provides comprehensive migration support with automatic handling of: - -- Account implementation upgrades -- Initialization with the correct parameters -- Module installation and configuration -- Compatible validator setup - -## Migration Links - -Choose the appropriate migration path based on your current account type: - -- [Migrate from V2 to Nexus](/migrations/v2ToNexus) -- [Upgrade Nexus Accounts](/migrations/nexusToNexus) - -For additional support with migrations, please refer to the [AbstractJS GitHub repository](https://github.com/bcnmy/abstractjs) or join our [Discord community](https://discord.gg/biconomy). diff --git a/docs/pages/migrations/nexusToNexus.md b/docs/pages/migrations/nexusToNexus.md deleted file mode 100644 index 571ecbe..0000000 --- a/docs/pages/migrations/nexusToNexus.md +++ /dev/null @@ -1,273 +0,0 @@ -# Nexus Account Migration Guide - -This guide explains how to upgrade Nexus smart accounts from older versions to the latest implementation. The migration process preserves your account's address, balance, and history while providing access to new features, security fixes, and performance improvements. - -## Why Upgrade? - -Upgrading your Nexus smart account is recommended for several important reasons: - -1. **Security Improvements**: The latest implementation includes critical security enhancements. -2. **New Features**: Access to the newest account abstraction capabilities. -3. **Performance Improvements**: Enhanced gas efficiency and transaction processing. -4. **Compatibility**: Ensure your smart account remains compatible with the latest AbstractJS SDK. - -## Migration Process Overview - -The migration consists of these key steps: - -1. **Update AbstractJS Package**: Install the latest SDK version -2. **Connect to Existing Account**: Use your existing account address -3. **Upgrade Implementation**: Call `upgradeSmartAccount()` -4. **Verify Upgrade**: Test the account with a transaction -5. **Update Application**: Adjust your application to use the latest features - -## Important Notes for Migration - -> **CRITICAL**: After migration, you **must store your account address** and use it with the `accountAddress` parameter in `toNexusAccount()` for all future interactions. This is how you'll maintain access to your upgraded account and its balances. - -## Step 1: Update AbstractJS Package - -First, update to the latest version of the AbstractJS SDK: - -```bash -# npm -npm update @biconomy/abstractjs - -# yarn -yarn upgrade @biconomy/abstractjs - -# pnpm -pnpm update @biconomy/abstractjs - -# bun -bun update @biconomy/abstractjs -``` - -## Step 2: Connect to Your Existing Account - -When connecting to an account created with an older SDK version, you'll need your existing account address: - -```typescript -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "YOUR_BUNDLER_URL"; - -// First, get your existing account address if you don't already have it stored -// This is crucial - you MUST store this address for future use -const existingAccountAddress = "YOUR_EXISTING_ACCOUNT_ADDRESS"; - -// Connect to your existing account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - accountAddress: existingAccountAddress // Use your existing account address -}); - -const bundlerClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); -``` - -> **IMPORTANT**: You must preserve your existing account address and use it with the `accountAddress` parameter in all future SDK interactions. This is the only way to access your account and its funds after migration. - -## Step 3: Upgrade the Smart Account - -Call the `upgradeSmartAccount()` method to upgrade your account to the latest implementation: - -```typescript -// Upgrade the account to the latest implementation -const hash = await bundlerClient.upgradeSmartAccount(); - -// Wait for the upgrade transaction to be processed -const receipt = await bundlerClient.waitForUserOperationReceipt({ hash }); -console.log("Upgrade successful:", receipt.success); - -// Verify the account has been upgraded by checking the accountId -const accountId = await bundlerClient.accountId(); -console.log("New account ID:", accountId); -``` - -## Step 4: Verify the Upgrade - -After upgrading, verify that your account works correctly by performing a test transaction: - -```typescript -// Test with a simple transaction after upgrade -const testTxHash = await bundlerClient.sendUserOperation({ - calls: [{ - to: "0x0000000000000000000000000000000000000000", - value: 0n, - data: "0x" - }] -}); - -const testReceipt = await bundlerClient.waitForUserOperationReceipt({ - hash: testTxHash -}); -console.log("Test transaction successful:", testReceipt.success); -``` - -## Step 5: Store Your Account Address - -After successful migration, you **MUST store your account address** for future use: - -```typescript -// Get and store your account address -const accountAddress = await bundlerClient.account.getAddress(); -console.log("IMPORTANT - Store this account address:", accountAddress); - -// In your application, store this address securely -// (database, local storage, user profile, etc.) -storeAccountAddress(userIdentifier, accountAddress); -``` - -## Complete Migration Example - -Here's a full example that demonstrates the migration process: - -```typescript -import { privateKeyToAccount } from "viem/accounts"; -import { - createBicoBundlerClient, - toNexusAccount -} from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -async function migrateNexusAccount() { - // Setup - const privateKey = "YOUR_PRIVATE_KEY"; - const account = privateKeyToAccount(`0x${privateKey}`); - const bundlerUrl = "YOUR_BUNDLER_URL"; - - // Your existing account address - CRITICAL for migration - const existingAccountAddress = "YOUR_EXISTING_ACCOUNT_ADDRESS"; - - // Connect to your existing account - const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - accountAddress: existingAccountAddress - }); - - const bundlerClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) - }); - - // Check the account ID before upgrade - const oldAccountId = await bundlerClient.accountId(); - console.log("Account ID before upgrade:", oldAccountId); - - // Verify account is deployed - const isDeployed = await bundlerClient.account.isDeployed(); - if (!isDeployed) { - console.log("Account not deployed. Please deploy the account first."); - return; - } - - console.log("Starting account upgrade..."); - - // Upgrade the account to the latest implementation - const hash = await bundlerClient.upgradeSmartAccount(); - console.log("Upgrade transaction submitted:", hash); - - // Wait for the upgrade transaction to be processed - const receipt = await bundlerClient.waitForUserOperationReceipt({ hash }); - console.log("Upgrade transaction completed. Success:", receipt.success); - - if (!receipt.success) { - console.error("Upgrade failed. Please check gas, balance, and permissions."); - return; - } - - // Verify the account has been upgraded - const newAccountId = await bundlerClient.accountId(); - console.log("Account ID after upgrade:", newAccountId); - - // CRITICAL: Verify and store the account address for future use - const accountAddress = await bundlerClient.account.getAddress(); - console.log("STORE THIS ACCOUNT ADDRESS:", accountAddress); - - // Test the upgraded account with a transaction - console.log("Testing upgraded account with a transaction..."); - - // Example: Simple transaction to verify everything works - try { - const testHash = await bundlerClient.sendUserOperation({ - calls: [{ - to: "0x0000000000000000000000000000000000000000", - value: 0n, - data: "0x" - }] - }); - - const testReceipt = await bundlerClient.waitForUserOperationReceipt({ - hash: testHash - }); - - console.log("Test transaction successful:", testReceipt.success); - console.log("Migration completed successfully!"); - } catch (error) { - console.error("Test transaction failed:", error); - } -} - -migrateNexusAccount().catch(console.error); -``` - -## Post-Migration: Future Account Access - -After migration, **ALL** future interactions with your account must use the `accountAddress` parameter: - -```typescript -// CORRECT WAY to access your account after migration -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - accountAddress: "YOUR_STORED_ACCOUNT_ADDRESS" // This is essential -}); - -// INCORRECT WAY - this will create a new account, not access your existing one -const incorrectAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http() - // Missing accountAddress -}); -``` - -## Troubleshooting - -If you encounter issues during the migration: - -### Upgrade Transaction Fails - -- Ensure the account has sufficient funds for gas -- Verify the account is properly deployed on-chain -- Check that your application is using the latest SDK version - -### Cannot Access Account After Upgrade - -- Make sure you're using the correct account address in the `accountAddress` parameter -- Verify the upgrade transaction completed successfully -- Ensure you're using the exact same address as your pre-migration account - -## Next Steps - -After successfully migrating your Nexus account: - -1. **STORE YOUR ACCOUNT ADDRESS** in your application's persistent storage -2. **Update your application code** to use the `accountAddress` parameter in all future interactions -3. **Test thoroughly** with real transactions to ensure everything works as expected - -By following this migration guide and properly storing your account address, you've successfully upgraded your Nexus account to the latest implementation while preserving its address, balance, and history. diff --git a/docs/pages/migrations/v2ToNexus.md b/docs/pages/migrations/v2ToNexus.md deleted file mode 100644 index 790778b..0000000 --- a/docs/pages/migrations/v2ToNexus.md +++ /dev/null @@ -1,570 +0,0 @@ -# Biconomy SmartAccountV2 to Nexus Migration Guide - -This guide explains how to migrate your BiconomySmartAcccountV2 smart accounts to the newer Nexus smart accounts. The migration process preserves your account's address, balance, and history while upgrading to Nexus's enhanced architecture. - -## Why Migrate? - -Migrating from V2 to Nexus smart accounts provides several benefits: - -1. **Enhanced Security**: Improved security model with modular validators -2. **Better Performance**: More gas-efficient transaction processing -3. **Expanded Features**: Access to the newest account abstraction capabilities -4. **Future Compatibility**: Ensure your smart account remains compatible with the latest AbstractJS SDK - -## Migration Process Overview - -The migration follows these steps: - -1. **Connect to V2 Account**: Connect to your existing V2 smart account -2. **Deploy V2 Account** (if not already deployed): Ensure the account is deployed on-chain -3. **Migrate to Nexus**: Update implementation and initialize the Nexus account -4. **Verify Migration**: Test the migrated account with a transaction -5. **Update Your Application**: Use the Nexus SDK to interact with the migrated account - -## Prerequisites - -Before starting the migration: - -1. Update to the latest version of the AbstractJS SDK: - -```bash -npm install @biconomy/abstractjs -``` - -2. Make sure you have your EOA's private key and the V2 account address - -## Step 1: Connect to Your V2 Account - -First, set up the necessary connections to your V2 smart account: - -```typescript -import { createWalletClient, http } from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { base } from "viem/chains"; -import { - createSmartAccountClient as createV2Client, - BiconomySmartAccountV2, - PaymasterMode -} from "@biconomy/account"; - -// Define configuration variables -const config = { - // Chain and network information - chain: base, - - // EOA credentials - eoaPrivateKey: "YOUR_PRIVATE_KEY", // Replace with your private key - eoaAddress: "YOUR_EOA_ADDRESS", // Replace with your EOA address - - // Biconomy infrastructure URLs - v2BundlerUrl: "YOUR_V2_BUNDLER_URL", // Replace with your V2 bundler URL - nexusBundlerUrl: "YOUR_NEXUS_BUNDLER_URL", // Replace with your Nexus bundler URL - - // API keys - paymasterApiKey: "YOUR_PAYMASTER_API_KEY", // Replace with your Paymaster API key - - // Nexus contract addresses - nexusImplementationAddress: "0x000000008761E87F023f65c49DC9cb1C7EdFEaaf", - nexusBootstrapAddress: "0x000000F5b753Fdd20C5CA2D7c1210b3Ab1EA5903", - emptyHookAddress: "0x0000000000000000000000000000000000000001" -}; - -// Connect to your EOA -const eoaAccount = privateKeyToAccount("0x" + config.eoaPrivateKey); -const client = createWalletClient({ - account: eoaAccount, - chain: config.chain, - transport: http(), -}); - -// Connect to your V2 smart account -const V2Account = await createV2Client({ - signer: client, - biconomyPaymasterApiKey: config.paymasterApiKey, - bundlerUrl: config.v2BundlerUrl, -}); - -// Get V2 account address -const V2AccountAddress = await V2Account.getAccountAddress(); -console.log("V2 Account Address:", V2AccountAddress); -``` - -## Step 2: Check Deployment Status - -Check if your V2 account is already deployed, and deploy it if necessary: - -```typescript -// Check if account is deployed -const isDeployed = await V2Account.isAccountDeployed(); - -if (!isDeployed) { - console.log("Account not deployed, deploying now..."); - - // Deploy the V2 account - const deploymentResponse = await V2Account.sendTransaction([ - { - to: V2AccountAddress, - value: 0n, - data: "0x", - }, - ]); - - const { transactionHash } = await deploymentResponse.waitForTxHash(); - console.log("V2 account deployment transaction hash:", transactionHash); -} else { - console.log("Account already deployed, proceeding with migration"); -} -``` - -## Step 3: Migrate to Nexus - -Now perform the migration by updating the implementation to Nexus and initializing the Nexus account: - -```typescript -import { - encodeFunctionData, - encodeAbiParameters -} from "viem"; - -async function migrateToNexus(V2Account) { - const V2AccountAddress = await V2Account.getAccountAddress(); - - // Step 1: Update implementation to Nexus - console.log("Preparing update implementation to Nexus..."); - const updateImplementationCalldata = encodeFunctionData({ - abi: [ - { - name: "updateImplementation", - type: "function", - stateMutability: "nonpayable", - inputs: [{ type: "address", name: "newImplementation" }], - outputs: [] - } - ], - functionName: "updateImplementation", - args: [config.nexusImplementationAddress], - }); - - const updateImplementationTransaction = { - to: V2AccountAddress, - data: updateImplementationCalldata, - }; - - // Step 2: Initialize Nexus Account - console.log("Preparing initialize Nexus account..."); - const ownerAddress = config.eoaAddress; - - // Prepare initialization data for the validator - const initData = encodeFunctionData({ - abi: [ - { - name: "initNexusWithDefaultValidatorAndOtherModulesNoRegistry", - type: "function", - stateMutability: "nonpayable", - inputs: [ - { type: "bytes", name: "defaultValidatorData" }, - { type: "tuple[]", name: "validators", components: [ - { type: "address", name: "module" }, - { type: "bytes", name: "data" } - ]}, - { type: "tuple[]", name: "executors", components: [ - { type: "address", name: "module" }, - { type: "bytes", name: "data" } - ]}, - { type: "tuple", name: "hook", components: [ - { type: "address", name: "module" }, - { type: "bytes", name: "data" } - ]}, - { type: "tuple[]", name: "fallbacks", components: [ - { type: "address", name: "module" }, - { type: "bytes", name: "data" } - ]}, - { type: "tuple[]", name: "prevalidationHooks", components: [ - { type: "address", name: "module" }, - { type: "bytes", name: "data" }, - { type: "uint256", name: "hookType" } - ]} - ], - outputs: [] - } - ], - functionName: "initNexusWithDefaultValidatorAndOtherModulesNoRegistry", - args: [ - encodeFunctionData({ - abi: [ - { - name: "initialize", - type: "function", - stateMutability: "nonpayable", - inputs: [{ type: "address", name: "owner" }], - outputs: [] - } - ], - functionName: "initialize", - args: [ownerAddress] - }), - [], // validators - [], // executors - { module: config.emptyHookAddress, data: "0x" }, // hook - [], // fallbacks - [] // prevalidationHooks - ] - }); - - // Encode bootstrap data - const initDataWithBootstrap = encodeAbiParameters( - [ - { name: "bootstrap", type: "address" }, - { name: "initData", type: "bytes" }, - ], - [config.nexusBootstrapAddress, initData] - ); - - // Create initializeAccount calldata - const initializeNexusCalldata = encodeFunctionData({ - abi: [ - { - name: "initializeAccount", - type: "function", - stateMutability: "nonpayable", - inputs: [{ type: "bytes", name: "data" }], - outputs: [] - } - ], - functionName: "initializeAccount", - args: [initDataWithBootstrap], - }); - - const initializeNexusTransaction = { - to: V2AccountAddress, - data: initializeNexusCalldata, - }; - - // Send both transactions in a batch - console.log("Sending migration transaction..."); - const migrateToNexusResponse = await V2Account.sendTransaction( - [updateImplementationTransaction, initializeNexusTransaction], - { - paymasterServiceData: { mode: PaymasterMode.SPONSORED }, - } - ); - - const { transactionHash } = await migrateToNexusResponse.waitForTxHash(); - console.log("Migration transaction hash:", transactionHash); - console.log("Migration completed successfully"); - - return V2AccountAddress; // Return the address for the next step -} -``` - -## Step 4: Test Your Migrated Account - -After migration, verify that your account works correctly by creating a test transaction: - -```typescript -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { parseEther } from "viem"; - -async function testMigratedAccount(accountAddress) { - // Connect to the migrated account using Nexus SDK - const eoaAccount = privateKeyToAccount("0x" + config.eoaPrivateKey); - - const nexusAccount = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: eoaAccount, - chain: config.chain, - transport: http(), - // IMPORTANT: Use the same address as your V2 account - accountAddress: accountAddress, - }), - transport: http(config.nexusBundlerUrl), - }); - - console.log("Testing migrated account..."); - - // Send a test transaction - const testHash = await nexusAccount.sendUserOperation({ - calls: [{ - to: config.eoaAddress, - value: parseEther("0.000001"), - }], - }); - - console.log("Test transaction hash:", testHash); - - // Wait for receipt (optional) - const receipt = await nexusAccount.waitForUserOperationReceipt({ hash: testHash }); - console.log("Test transaction successful:", receipt.success); -} -``` - -## Step 5: Update Your Application - -Update your application to use the Nexus SDK for all future interactions: - -```typescript -// IMPORTANT: Always use the same address as your V2 account -const migratedAccountAddress = "YOUR_V2_ACCOUNT_ADDRESS"; - -// Use this pattern for all future SDK interactions -const nexusAccount = await toNexusAccount({ - signer: eoaAccount, - chain: base, - transport: http(), - accountAddress: migratedAccountAddress -}); - -const bundlerClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); -``` - -## Complete Migration Script - -Here's a complete migration script that puts everything together: - -```typescript -import { createWalletClient, http, encodeFunctionData, encodeAbiParameters, parseEther } from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { base } from "viem/chains"; -import { - createSmartAccountClient as createV2Client, - BiconomySmartAccountV2, - PaymasterMode -} from "@biconomy/account"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; - -// Define configuration variables -const config = { - // Chain and network information - chain: base, - - // EOA credentials - eoaPrivateKey: "YOUR_PRIVATE_KEY", // Replace with your private key - eoaAddress: "YOUR_EOA_ADDRESS", // Replace with your EOA address - - // Biconomy infrastructure URLs - v2BundlerUrl: "YOUR_V2_BUNDLER_URL", // Replace with your V2 bundler URL - nexusBundlerUrl: "YOUR_NEXUS_BUNDLER_URL", // Replace with your Nexus bundler URL - - // API keys - paymasterApiKey: "YOUR_PAYMASTER_API_KEY", // Replace with your Paymaster API key - - // Nexus contract addresses - nexusImplementationAddress: "0x000000008761E87F023f65c49DC9cb1C7EdFEaaf", - nexusBootstrapAddress: "0x000000F5b753Fdd20C5CA2D7c1210b3Ab1EA5903", - emptyHookAddress: "0x0000000000000000000000000000000000000001" -}; - -async function main() { - try { - // Step 1: Get V2 Account - console.log("\nStep 1: Getting V2 account address..."); - - const eoaAccount = privateKeyToAccount("0x" + config.eoaPrivateKey); - const client = createWalletClient({ - account: eoaAccount, - chain: config.chain, - transport: http(), - }); - - const V2Account = await createV2Client({ - signer: client, - biconomyPaymasterApiKey: config.paymasterApiKey, - bundlerUrl: config.v2BundlerUrl, - }); - - const V2AccountAddress = await V2Account.getAccountAddress(); - console.log("V2 account address:", V2AccountAddress); - - // Step 2: Deploy V2 Account if needed - const isDeployed = await V2Account.isAccountDeployed(); - - if (!isDeployed) { - console.log("Account not deployed, deploying now..."); - - const deploymentResponse = await V2Account.sendTransaction([ - { - to: V2AccountAddress, - value: 0n, - data: "0x", - }, - ]); - - const { transactionHash } = await deploymentResponse.waitForTxHash(); - console.log("V2 account deployment transaction hash:", transactionHash); - } else { - console.log("Account already deployed, proceeding with migration"); - } - - // Step 3: Migrate to Nexus - console.log("\nStep 3: Migrating to Nexus"); - - // Update implementation to Nexus - const updateImplementationCalldata = encodeFunctionData({ - abi: [ - { - name: "updateImplementation", - type: "function", - stateMutability: "nonpayable", - inputs: [{ type: "address", name: "newImplementation" }], - outputs: [] - } - ], - functionName: "updateImplementation", - args: [config.nexusImplementationAddress], - }); - - const updateImplementationTransaction = { - to: V2AccountAddress, - data: updateImplementationCalldata, - }; - - // Initialize Nexus Account - const ownerAddress = config.eoaAddress; - - // Prepare initialization data for the validator - const initData = encodeFunctionData({ - abi: [ - { - name: "initNexusWithDefaultValidator", type: "function", - stateMutability: "nonpayable", - inputs: [ - { type: "bytes", name: "data" } - ], - outputs: [] - } - ], - functionName: "initNexusWithDefaultValidator", - args: [ownerAddress as `0x${string}`] - }); - - // Encode bootstrap data - const initDataWithBootstrap = encodeAbiParameters( - [ - { name: "bootstrap", type: "address" }, - { name: "initData", type: "bytes" }, - ], - [config.nexusBootstrapAddress, initData] - ); - - // Create initializeAccount calldata - const initializeNexusCalldata = encodeFunctionData({ - abi: [ - { - name: "initializeAccount", - type: "function", - stateMutability: "nonpayable", - inputs: [{ type: "bytes", name: "data" }], - outputs: [] - } - ], - functionName: "initializeAccount", - args: [initDataWithBootstrap], - }); - - const initializeNexusTransaction = { - to: V2AccountAddress, - data: initializeNexusCalldata, - }; - - // Send both transactions in a batch - console.log("Sending migration transaction..."); - const migrateToNexusResponse = await V2Account.sendTransaction( - [updateImplementationTransaction, initializeNexusTransaction], - { - paymasterServiceData: { mode: PaymasterMode.SPONSORED }, - } - ); - - const { transactionHash } = await migrateToNexusResponse.waitForTxHash(); - console.log("Migration transaction hash:", transactionHash); - - // Step 4: Test Nexus Account - console.log("\nStep 4: Testing migrated Nexus account"); - - // Connect to the migrated account using Nexus SDK - const nexusAccount = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: eoaAccount, - chain: config.chain, - transport: http(), - // IMPORTANT: Use the same address as the V2 account - accountAddress: V2AccountAddress, - }), - transport: http(config.nexusBundlerUrl), - }); - - // Send a test transaction - const testHash = await nexusAccount.sendUserOperation({ - calls: [{ - to: config.eoaAddress, - value: parseEther("0.000001"), - }], - }); - - console.log("Test transaction hash:", testHash); - - console.log("\nMigration completed successfully"); - console.log("\nIMPORTANT: Store your account address for future use:", V2AccountAddress); - - } catch (error) { - console.error("Migration failed:", error); - } -} - -main().catch(console.error); -``` - -## Required Configuration - -For the migration script to work, you'll need to set up the following configuration variables: - -```javascript -const config = { - // Chain and network information - chain: base, // or your preferred chain - - // EOA credentials - eoaPrivateKey: "YOUR_PRIVATE_KEY", // Replace with your private key - eoaAddress: "YOUR_EOA_ADDRESS", // Replace with your EOA address - - // Biconomy infrastructure URLs - v2BundlerUrl: "YOUR_V2_BUNDLER_URL", // Replace with your V2 bundler URL - nexusBundlerUrl: "YOUR_NEXUS_BUNDLER_URL", // Replace with your Nexus bundler URL - - // API keys - paymasterApiKey: "YOUR_PAYMASTER_API_KEY", // Replace with your Paymaster API key - - // Nexus contract addresses - These are standard addresses that shouldn't need to change - nexusImplementationAddress: "0x000000004F43C49e93C970E84001853a70923B03", - nexusBootstrapAddress: "0x00000000D3254452a909E4eeD47455Af7E27C289", - emptyHookAddress: "0x0000000000000000000000000000000000000000" -}; -``` - -## Troubleshooting - -If you encounter issues during migration: - -### Migration Transaction Fails - -- Ensure your EOA has sufficient funds for gas -- Verify the V2 account is properly deployed -- Check that all environment variables are set correctly - -### Cannot Access Account After Migration - -- Make sure you're using the exact same address as your V2 account in the `accountAddress` parameter -- Verify the migration transaction completed successfully - -## Next Steps - -After successfully migrating your V2 account to Nexus: - -1. **STORE YOUR ACCOUNT ADDRESS** in your application's persistent storage -2. **Update your application code** to use the `accountAddress` parameter in all future interactions -3. **Test thoroughly** with real transactions to ensure everything works as expected - -By following this migration guide and properly storing your account address, you've successfully upgraded your V2 account to a Nexus account while preserving its address, balance, and history. diff --git a/docs/pages/modules/executors/OwnableExecutor/index.mdx b/docs/pages/modules/executors/OwnableExecutor/index.mdx deleted file mode 100644 index d4f7977..0000000 --- a/docs/pages/modules/executors/OwnableExecutor/index.mdx +++ /dev/null @@ -1,25 +0,0 @@ -# OwnableExecutor Module - -The `OwnableExecutor` is an execution module designed for ERC7579-compliant smart accounts. It allows designated owners to execute transactions on behalf of the account and pay for gas. - -## Key Features - -- Multiple owner management for smart accounts -- Transaction execution by owners -- Batch transaction support - -## Core Functionality - -### Owner Management - -- `onInstall`: Initializes the module with an initial owner -- `addOwner`: Adds a new owner to the account -- `removeOwner`: Removes an existing owner from the account -- `getOwners`: Retrieves the list of owners for an account - -### Transaction Execution - -- `executeOnOwnedAccount`: Allows an owner to execute a single transaction -- `executeBatchOnOwnedAccount`: Enables batch transaction execution by an owner - -For more information about the smart contract please go to [OwnableExcecutor](https://github.com/rhinestonewtf/core-modules/blob/main/src/OwnableExecutor/OwnableExecutor.sol) \ No newline at end of file diff --git a/docs/pages/modules/executors/OwnableExecutor/methods.mdx b/docs/pages/modules/executors/OwnableExecutor/methods.mdx deleted file mode 100644 index 851d7cf..0000000 --- a/docs/pages/modules/executors/OwnableExecutor/methods.mdx +++ /dev/null @@ -1,73 +0,0 @@ -# Ownable Executor SDK Methods - -## `execute` -Executes a transaction on a smart account through the Ownable Executor module. - -**Usage Example** - -```typescript -const userOpReceipt: UserOpReceipt = await ownableExecutorModule.execute( - transaction, - ownedSmartAccountAddress, -); -``` - -**Parameters** - -- execution ([Transaction](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/account/utils/Types.ts#L346) | `Transaction[]`, required) -- ownedAccountAddress (`Address`, required) - -**Returns** - -- `Promise`: A promise of [UserOpReceipt](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/bundler/utils/Types.ts#L23) - -## `addOwner` -Add a new owner to the smart account - -**Usage Example** - -```typescript -const userOpReceipt: UserOpReceipt = await ownableExecutorModule.addOwner(newOwner); -``` - -**Parameters** - -- newOwner (`Address`, required) - -**Returns** - -- `Promise`: A promise of [UserOpReceipt](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/bundler/utils/Types.ts#L23) - -## `removeOwner` -Remove an owner from the smart account - -**Usage Example** - -```typescript -const userOpReceipt: UserOpReceipt = await ownableExecutorModule.removeOwner(ownerToRemove); -``` - -**Parameters** - -- ownerToRemove (`Address`, required) - -**Returns** - -- `Promise`: A promise of [UserOpReceipt](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/bundler/utils/Types.ts#L23) - -## `getOwners` -Get owners of the smart account for Ownable Executor module - -**Usage Example** - -```typescript -const userOpReceipt: UserOpReceipt = await ownableExecutorModule.getOwners(); -``` - -**Parameters** - -- accountAddress (`Address`, optional): Pass this parameter when you want to get the owners of another smart account - -**Returns** - -- `Promise`: A promise of [UserOpReceipt](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/bundler/utils/Types.ts#L23) \ No newline at end of file diff --git a/docs/pages/modules/executors/OwnableExecutor/overview.mdx b/docs/pages/modules/executors/OwnableExecutor/overview.mdx deleted file mode 100644 index d4f7977..0000000 --- a/docs/pages/modules/executors/OwnableExecutor/overview.mdx +++ /dev/null @@ -1,25 +0,0 @@ -# OwnableExecutor Module - -The `OwnableExecutor` is an execution module designed for ERC7579-compliant smart accounts. It allows designated owners to execute transactions on behalf of the account and pay for gas. - -## Key Features - -- Multiple owner management for smart accounts -- Transaction execution by owners -- Batch transaction support - -## Core Functionality - -### Owner Management - -- `onInstall`: Initializes the module with an initial owner -- `addOwner`: Adds a new owner to the account -- `removeOwner`: Removes an existing owner from the account -- `getOwners`: Retrieves the list of owners for an account - -### Transaction Execution - -- `executeOnOwnedAccount`: Allows an owner to execute a single transaction -- `executeBatchOnOwnedAccount`: Enables batch transaction execution by an owner - -For more information about the smart contract please go to [OwnableExcecutor](https://github.com/rhinestonewtf/core-modules/blob/main/src/OwnableExecutor/OwnableExecutor.sol) \ No newline at end of file diff --git a/docs/pages/modules/executors/OwnableExecutor/tutorial.mdx b/docs/pages/modules/executors/OwnableExecutor/tutorial.mdx deleted file mode 100644 index 79ea8e0..0000000 --- a/docs/pages/modules/executors/OwnableExecutor/tutorial.mdx +++ /dev/null @@ -1,137 +0,0 @@ -# Ownable Executor Module tutorial - -This tutorial demonstrates how to install and use a `Ownable Executor Module` on a Nexus Smart Account using the SDK. - -## Setup the smart account - -First, import the necessary dependencies and set up 2 Nexus accounts - -```typescript -import { createWalletClient, http, encodePacked } from "viem"; -import { baseSepolia } from "viem/chains"; -import { createBicoBundlerClient, createOwnableExecutorModule } from "@biconomy/account"; - -const bobWalletClient = createWalletClient({ - bobAccount, - chain: baseSepolia, - transport: http() -}); -const aliceWalletClient = createWalletClient({ - aliceAccount, - chain: baseSepolia, - transport: http() -}); - -const bobSmartAccount = createBicoBundlerClient({ - signer: bobWalletClient, - bundlerUrl: "https://bundler.biconomy.io/api/v2/...", // Your bundler URL -}); -const aliceSmartAccount = createBicoBundlerClient({ - signer: aliceWalletClient, - bundlerUrl: "https://bundler.biconomy.io/api/v2/...", // Your bundler URL -}); -``` - -## Install the module -Now, let's install the `Ownable Executor Module` on Bob's account - -```typescript -// Encode Bob's address -const bobAddress = await bobWalletClient.account.address -const bobInitData = encodePacked(["address"], [bobAddress]); - -// Create the module instance -const ownableExecutorModule = await createOwnableExecutorModule(bobSmartAccount, bobInitData) - -// Install the module on Bob's account -const userOpReceipt = await bobSmartAccount.installModule({ - moduleAddress: ownableExecutorModule.moduleAddress, - type: ownableExecutorModule.type, - data: ownableExecutorModule.data -}); - -// Set the module to be active on the typescript instance -bobSmartAccount.setActiveExecutionModule(ownableExecutorModule) -``` - -## Check if module is installed -After installation, you can verify if the module is installed on the account. -We do not need it to be installed on Alice's account. - -```typescript -const isInstalled = await bobSmartAccount.isModuleInstalled({ - moduleAddress: ownableExecutorModule.moduleAddress, - type: ownableExecutorModule.type -}); -``` - -## Add owner -Now Bob can delegate ownership to Alice to run transactions on behalf his behalf - -```typescript -const userOpReceipt = await ownableExecutorModule.addOwner( - await aliceSmartAccount.getAddress() // Note that an owner can also be an EOA -) - -// We can check if Alice's smart account is now an owner of Bob's account -const owners = await ownableExecutorModule.getOwners() -``` - -## Send a transaction -Now Alice can send a transaction on Bob's behalf - -```typescript -const transaction = { - to: targetContract, - data: "...", - value: 0n -} -// We need to set the execution module we want to use on the account -aliceSmartAccount.setActiveExecutionModule(ownableExecutorModule) -const receipt = await aliceSmartAccount.sendTransactionWithExecutor([transaction], bobSmartAccountAddress); -``` - -We can also execute an action on Bob's account from an EOA if added as an owner, we will have to use viem's `sendTransaction` for this case. - -```typescript -const moduleCalldata = encodeFunctionData({ - abi: parseAbi([ - "function executeOnOwnedAccount(address ownedAccount, bytes callData)" - ]), - functionName: "executeOnOwnedAccount", - args: [ - await bobSmartAccount.getAddress(), - encodePacked( - ["address", "uint256", "bytes"], - [targetContract, BigInt(Number(0)), data] - ) - ] -}) - -const txHash = await aliceWalletClient.sendTransaction({ - account: aliceAccount, // Called by delegated EOA owner - to: ownableExecutorModule.moduleAddress, - data: moduleCalldata, - value: 0n -}) -``` - -Now Alice can send any user operation on behalf of Bob, with no restrictions, for example, if Bob's smart account had $100 in USDC, Alice can easily transfer those out of Bob's account. - -## Remove owner -We can remove Alice from our smart account owners at any time - -```typescript -const receipt = await bobSmartAccount.ownableExecutorModule.removeOwner(aliceSmartAccountAddress); -``` - -## Uninstall the module -We can uninstall the module at any time - -```typescript -const receipt = await bobSmartAccount.uninstallModule({ - moduleAddress: ownableExecutorModule.moduleAddress, - type: ownableExecutorModule.type, - data: ownableExecutorModule.data -}); -``` \ No newline at end of file diff --git a/docs/pages/modules/executors/index.mdx b/docs/pages/modules/executors/index.mdx deleted file mode 100644 index 9651077..0000000 --- a/docs/pages/modules/executors/index.mdx +++ /dev/null @@ -1,6 +0,0 @@ -`Executors` can be called directly or via Nexus.execute. -The most important ability of executors is to perform actions on behalf of the smart account they are installed on by calling ERC-7579' `executeFromExecutor` method. For example, Executors can implement some complex logic of conditionally batching actions together. - -The Biconomy SDK currently supports the following executor modules: - -- [OwnableExecutor](/modules/executors/OwnableExecutor) \ No newline at end of file diff --git a/docs/pages/modules/index.mdx b/docs/pages/modules/index.mdx deleted file mode 100644 index 325382d..0000000 --- a/docs/pages/modules/index.mdx +++ /dev/null @@ -1,141 +0,0 @@ -# Modules - -Modules are designed to extend the functionality of smart contract accounts in a consistent and predictable manner. This guide explains how modules work and how to interact with them in the SDK. - -![Modules](https://i.imgur.com/hoOeSXS.png) - -## General Module Interaction Pattern - -Interacting with a module typically follows these steps: - -{/* 1. **Create the module** -2. **Install the module** -3. **Extend the Nexus client with module-specific actions** -4. **Use the module's functionality** */} - -::::steps -#### Create or Find a Module -Either create a module with custom functionality yourself, or use one of the available modules -from our documentation - -#### Install the Module -Install the module on top of the users Smart Account. - -:::tip[Atomic Install + Execute] -Installing the module can be done in the same transaction which executes some action -which requires the module. E.g. you can install a Session Key module and approve a -session key in the same transaction. -::: - -#### Extend the Smart Account client with module actions -You will need to extend the account client with the functions to interact -with the module. The extension pattern is used to save on the [size of the -SDK bundle](#module-extension-pattern) - -#### Use the functionality provided by the module -Once you've extended the SDK client with the required module functions, you -will be able to access those functions on top of the client object and interact -with your newly installed module. - -:::: - -## Step-by-Step Guide - -### 1. Create the module - -Use the appropriate `to[ModuleName]` function to create a module instance: - -```typescript -const myModule = to[ModuleName]({ - account: nexusClient.account, - signer: eoaAccount, - moduleInitArgs: { - // Module-specific initialization arguments - } -}) -``` - -### 2. Install the module - -Install the module on your Nexus client's smart contract account: - -```typescript -const hash = await nexusClient.installModule({ - module: myModule.moduleInitData -}); - -// Wait for the installation to be confirmed -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }); -``` - -### 3. Extend the Nexus client - -Extend your Nexus client with module-specific actions: - -```typescript -const extendedNexusClient = nexusClient.extend([ModuleName]Actions(myModule)); -``` - -### 4. Use the module's functionality - -Use the extended Nexus client to interact with the module's features: - -```typescript -const result = await extendedNexusClient.[moduleSpecificAction]({ - // Action-specific parameters -}); -``` - -## Example: Multisig Module - -Here's an example of how to use the Smart Sessions module: - -```typescript -// 1. Create the module -const ownableModule = toOwnableValidator({ - account: nexusClient.account, - signer: account, - moduleInitArgs: { - threshold: 1n, - owners: [publicKey] - } -}) - -// 2. Install the module -const hash = await nexusClient.installModule({ - module: ownableModule.moduleInitData -}) - -// 3. Extend the Nexus client -const ownableDanClient = nexusClient - .extend(ownableActions(ownableModule)) - -// 4. Use the module's functionality -const newSignature = await ownableNexusClient.prepareSignatures({ - signatures: ["0x...", "0x..."] -}) -``` - -## Module Extension Pattern - -The SDK uses a module extension pattern to maintain efficient bundle sizes and enable tree-shaking. Here's why: - -- **Tree-shaking Optimization**: If all module actions were included in the base NexusClient, your bundle would include code for every possible module, even ones you don't use. -- **Flexible Integration**: Developers can choose which modules to include, reducing bundle size by only importing needed functionality. -- **Type Safety**: Each module extension adds its own type definitions, providing proper TypeScript support for module-specific actions. - -For example, instead of: -```typescript -// ❌ This would include ALL module code in your bundle -const nexusClient = createBicoBundlerClient({ - // config - modules: [sessionsModule, securityModule, otherModules...] -}); -``` - -We use: -```typescript -// ✅ Only the sessions module code is included -const nexusClient = createBicoBundlerClient({ /* config */ }); -const sessionNexusClient = nexusClient.extend(smartSessionCreateActions(sessionsModule)); -``` diff --git a/docs/pages/modules/validators/index.mdx b/docs/pages/modules/validators/index.mdx deleted file mode 100644 index 69a1781..0000000 --- a/docs/pages/modules/validators/index.mdx +++ /dev/null @@ -1,6 +0,0 @@ -`Validators` validate userOperations. -The validator's address should be encoded into the userOp.nonce field. Nexus decodes this address and forwards the validation flow to the appropriate validator. - -The SDK currently supports the following validation modules: - -- [k1Validator](/modules/validators/k1Validator) \ No newline at end of file diff --git a/docs/pages/modules/validators/k1Validator/index.mdx b/docs/pages/modules/validators/k1Validator/index.mdx deleted file mode 100644 index 015dcb6..0000000 --- a/docs/pages/modules/validators/k1Validator/index.mdx +++ /dev/null @@ -1,27 +0,0 @@ -# K1Validator Overview - -The `K1Validator` is a simple validator module designed for testing Nexus Smart Accounts. It provides basic signature validation functionality and owner management for smart contract accounts. - -## Key Features - -- Validates user operation signatures for smart accounts -- Manages ownership of associated smart accounts -- Supports ERC-1271 signature validation -- Allows ownership transfer - -## Core Functionality - -- Installation and uninstallation as a module -- User operation validation -- ERC-1271 compliant signature checks -- Ownership management and transfer - -## Usage - -This validator can be installed on Nexus Smart Accounts to handle signature validations in testing and development environments. It's designed to be a straightforward implementation for basic validation needs. - -## Security Note - -While functional for testing, this validator may require additional security measures for production use. It includes basic checks like preventing contract addresses from being set as owners. - -The `K1Validator` serves as a practical example of a validator module for ERC-7579 and ERC-4337 compliant smart accounts, demonstrating core concepts of module integration and signature validation in the Nexus Smart Account ecosystem. \ No newline at end of file diff --git a/docs/pages/modules/validators/k1Validator/tutorial.mdx b/docs/pages/modules/validators/k1Validator/tutorial.mdx deleted file mode 100644 index d912f53..0000000 --- a/docs/pages/modules/validators/k1Validator/tutorial.mdx +++ /dev/null @@ -1,51 +0,0 @@ -# k1Validator module tutorial - -## Installing and using a K1Validator Module - -This example demonstrates how to install a K1Validator module on a Nexus Smart Account using the SDK. - -## Setup - -First, import the necessary dependencies and set up your smart account: - -```typescript -import { createWalletClient, http } from "viem"; -import { baseSepolia } from "viem/chains"; -import { createBicoBundlerClient, ModuleType, K1_VALIDATOR } from "@biconomy/account"; - -// Setup your wallet client -const walletClient = createWalletClient({ - account, - chain: baseSepolia, - transport: http() -}); - -// Create your smart account -const smartAccount = createBicoBundlerClient({ ... }); -``` - -Now, let's install the K1Validator module: - -```typescript -// Encode the owner address (usually the signer's address) -const ownerAddress = await walletClient.account.address; -const encodedOwnerAddress = encodePacked(["address"], [ownerAddress]); - -// Install the module -const userOpReceipt = await smartAccount.installModule({ - moduleAddress: K1_VALIDATOR, - type: 'validator', - data: encodedOwnerAddress -}); -``` - -After installation, you can verify if the module is installed - -```typescript -const isInstalled = await smartAccount.isModuleInstalled({ - moduleAddress: K1_VALIDATOR_ADDRESS, - type: 'validator' -}); -``` - -Now we can send user ops and do actions like minting an NFT, the same way we did it in the [Quickstart](/tutorials/quickstart) using the `k1Validator` as the validation module. diff --git a/docs/pages/modules/validators/ownableValidator/index.md b/docs/pages/modules/validators/ownableValidator/index.md deleted file mode 100644 index 5d284ab..0000000 --- a/docs/pages/modules/validators/ownableValidator/index.md +++ /dev/null @@ -1,172 +0,0 @@ -# Ownable (Multisig) Module - -The Ownable module provides multi-signature functionality for smart contract accounts, allowing multiple owners to control an account with configurable signature thresholds. - -## Actions - -### addOwner - -Adds a new owner to the smart contract account. - -#### Usage - -```typescript -import { nexusClient } from "./nexusClient" -import { toOwnableValidator, ownableActions } from "@biconomy/abstractjs" - -const ownableModule = toOwnableValidator({ - account: nexusClient.account, - signer: eoaAccount -}); - -const ownableNexusClient = nexusClient.extend(ownableActions(ownableModule)); - -const hash = await ownableNexusClient.addOwner({ - owner: "0x..." -}); -``` - -#### Parameters - -| Parameter | Type | Description | Required | -|-----------|------|-------------|-----------| -| account | ModularSmartAccount | The smart account to add the owner to. Uses client's account if not provided | No | -| owner | Hex | Address of the new owner | Yes | -| maxFeePerGas | bigint | Maximum fee per gas unit | No | -| maxPriorityFeePerGas | bigint | Maximum priority fee per gas unit | No | -| nonce | bigint | Transaction nonce. Auto-determined if not provided | No | - -#### Response -Returns a promise that resolves to the transaction hash (`Hex`). - -### removeOwner - -Removes an existing owner from the smart contract account. - -#### Usage - -```typescript -const hash = await ownableNexusClient.removeOwner({ - owner: "0x..." -}); -``` - -#### Parameters - -| Parameter | Type | Description | Required | -|-----------|------|-------------|-----------| -| account | ModularSmartAccount | The smart account to remove the owner from. Uses client's account if not provided | No | -| owner | Hex | Address of the owner to remove | Yes | -| maxFeePerGas | bigint | Maximum fee per gas unit | No | -| maxPriorityFeePerGas | bigint | Maximum priority fee per gas unit | No | -| nonce | bigint | Transaction nonce. Auto-determined if not provided | No | - -### getThreshold - -Retrieves the current signature threshold for the account. - -#### Usage - -```typescript -const threshold = await ownableNexusClient.getThreshold(); -``` - -#### Parameters - -| Parameter | Type | Description | Required | -|-----------|------|-------------|-----------| -| account | ModularSmartAccount | The smart account to query. Uses client's account if not provided | No | - -#### Response -Returns a promise that resolves to the current threshold value (`number`). - -### setThreshold - -Updates the signature threshold for the account. - -#### Usage - -```typescript -const hash = await ownableNexusClient.setThreshold({ - threshold: 2n -}); -``` - -#### Parameters - -| Parameter | Type | Description | Required | -|-----------|------|-------------|-----------| -| account | ModularSmartAccount | The smart account to update. Uses client's account if not provided | No | -| threshold | bigint | New threshold value | Yes | -| maxFeePerGas | bigint | Maximum fee per gas unit | No | -| maxPriorityFeePerGas | bigint | Maximum priority fee per gas unit | No | -| nonce | bigint | Transaction nonce. Auto-determined if not provided | No | - -### prepareSignatures - -Combines multiple signatures for a multi-sig transaction. - -#### Usage - -```typescript -const combinedSignature = await ownableNexusClient.prepareSignatures({ - signatures: ["0x...", "0x..."] -}); -``` - -#### Parameters - -| Parameter | Type | Description | Required | -|-----------|------|-------------|-----------| -| account | ModularSmartAccount | The smart account context. Uses client's account if not provided | No | -| signatures | Hex[] | Array of signatures to combine | Yes | - -#### Response -Returns a promise that resolves to the combined signature (`Hex`). - -## Complete Example - -Here's a complete example showing how to set up and use a multi-signature configuration: - -```typescript -import { nexusClient } from "./nexusClient" -import { toOwnableValidator, ownableActions } from "@biconomy/abstractjs" - -// 1. Create and configure the ownable module -const ownableModule = toOwnableValidator({ - account: nexusClient.account, - signer: eoaAccount, - moduleInitArgs: { - threshold: 2n, - owners: [owner1.address, owner2.address] - } -}); - -// 2. Install the module -const installHash = await nexusClient.installModule({ - module: ownableModule.moduleInitData -}); -await nexusClient.waitForUserOperationReceipt({ hash: installHash }); - -// 3. Extend the client with ownable actions -const ownableNexusClient = nexusClient.extend(ownableActions(ownableModule)); - -// 4. Prepare a multi-sig transaction -const userOp = await ownableNexusClient.prepareUserOperation({ - calls: [{ - to: recipient, - value: amount - }] -}); - -// 5. Collect required signatures -const userOpHash = await nexusClient.account.getUserOpHash(userOp); -const signatures = await Promise.all([ - owner1.signMessage({ message: { raw: userOpHash } }), - owner2.signMessage({ message: { raw: userOpHash } }) -]); - -// 6. Combine signatures and execute -userOp.signature = await ownableNexusClient.prepareSignatures({ signatures }); -const uoHash = await nexusClient.sendUserOperation(userOp); -``` diff --git a/docs/pages/modules/validators/passkeyValidator/index.md b/docs/pages/modules/validators/passkeyValidator/index.md deleted file mode 100644 index 9d44a09..0000000 --- a/docs/pages/modules/validators/passkeyValidator/index.md +++ /dev/null @@ -1,68 +0,0 @@ -# Passkey Validator Module Overview - -The `PasskeyValidator` is a WebAuthn-based validator module for ERC-7579 compliant smart accounts that enables passwordless authentication using the FIDO2 standard. It validates signatures generated through browser or device-based authenticators for ERC-4337 user operations. - -## Key Features - -- WebAuthn-based signature validation for user operations -- Supports both registration and authentication flows -- Device-bound cryptographic key management -- Phishing-resistant authentication -- Compatible with hardware security tokens - -## Core Functionality - -- Installation and uninstallation as a module -- Passwordless authentication for user operations using biometrics - -### Authentication Operations -```typescript " -import { toWebAuthnKey, WebAuthnMode } from "@biconomy/passkey"; - -// Create new passkey -const registerWebAuthnKey = await toWebAuthnKey({ - passkeyName: "accountName", - mode: WebAuthnMode.Register -}) - -// Login with existing passkey -const loginWebAuthnKey = await toWebAuthnKey({ - mode: WebAuthnMode.Login -}) -``` - -### Signature Format - -| Field | Type | Description | -|-------|------|-------------| -| authenticatorData | bytes | Raw authenticator data from WebAuthn response | -| clientDataJSON | string | Client data in JSON format containing challenge and origin | -| responseTypeLocation | uint256 | Location identifier for the response type | -| r | uint256 | R component of the ECDSA signature | -| s | uint256 | S component of the ECDSA signature | -| usePrecompiled | bool | Flag to indicate if precompiled contract should be used | - -## Security Features - -- Domain-bound credentials preventing phishing attacks -- No exportable private keys -- Optional hardware token support -- Biometric authentication support -- Challenge-response based authentication - -## Limitations - -- Requires WebAuthn-compatible environment (browser/device) -- Device-specific authentication -- Needs backup/recovery mechanism -- Limited to client-side implementations - -## Security Considerations - -- Store passkey data securely using the device's secure storage -- Implement proper error handling for failed authentications -- Consider implementing multiple passkeys for backup -- Regular validation of installed passkeys -- Proper cleanup during uninstallation - -The `PasskeyValidator` provides a secure, user-friendly authentication mechanism for ERC-7579 compliant smart accounts, leveraging modern WebAuthn standards while maintaining the security requirements of blockchain operations. diff --git a/docs/pages/modules/validators/passkeyValidator/tutorial.mdx b/docs/pages/modules/validators/passkeyValidator/tutorial.mdx deleted file mode 100644 index c47daeb..0000000 --- a/docs/pages/modules/validators/passkeyValidator/tutorial.mdx +++ /dev/null @@ -1,169 +0,0 @@ -# Biconomy Passkey SDK Integration Guide - -This guide demonstrates how to integrate the Biconomy SDK with passkey authentication in a client-side application. - -> ⚠️ **Important**: This functionality only works in client-side applications (browsers) as it requires access to the WebAuthn API. It cannot be implemented in backend services. - - - - -## Setup Environment Variables - -Create a `.env` file with your Biconomy configuration: - -``` -NEXT_PUBLIC_BUNDLER_URL=your_bundler_url -NEXT_PUBLIC_PAYMASTER_URL=your_paymaster_url -``` - -## Step 1: Create Nexus Client - -```typescript " -import { createBicoBundlerClient, createBicoPaymasterClient, toNexusAccount } from '@biconomy/abstractjs' -import { baseSepolia } from 'wagmi/chains' -import { http, useAccount, useWalletClient } from 'wagmi' - -const account = useAccount() -const { data: walletClient } = useWalletClient({ account: account.address }) - -async function initNexusClient() { - if(walletClient) { - const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(process.env.NEXT_PUBLIC_BUNDLER_URL), - paymaster: createBicoPaymasterClient({ paymasterUrl: process.env.NEXT_PUBLIC_PAYMASTER_URL || "" }), - }); - return nexusClient; - } - throw new Error('Wallet client not found') -} -``` - -## Step 2: Register a New Passkey - -```typescript -import { toWebAuthnKey, toPasskeyValidator, WebAuthnMode } from '@biconomy/passkey' -import { NexusClient } from '@biconomy/abstractjs' - -async function registerPasskey(nexusClient: NexusClient, passkeyName: string) { - // Create WebAuthn key - // Ideally "passkeyName" would be set by the user in the UI - const webAuthnKey = await toWebAuthnKey({ - passkeyName: passkeyName, - mode: WebAuthnMode.Register, - }) - - // Create passkey validator - const passkeyValidator = await toPasskeyValidator({ - account: nexusClient.account, - webAuthnKey, - }) - - // Store webAuthnKey for future use - const formattedWebAuthnKey = { - pubX: webAuthnKey.pubX.toString(), - pubY: webAuthnKey.pubY.toString(), - authenticatorId: webAuthnKey.authenticatorId, - authenticatorIdHash: webAuthnKey.authenticatorIdHash, - } - localStorage.setItem('webAuthnKey', JSON.stringify(formattedWebAuthnKey)); - - return passkeyValidator; -} -``` - -## Step 3: Login with Existing Passkey - -```typescript -import { NexusClient } from '@biconomy/abstractjs' -import { toWebAuthnKey, WebAuthnMode, toPasskeyValidator } from '@biconomy/passkey' - -async function loginPasskey(nexusClient: NexusClient) { - const webAuthnKey = await toWebAuthnKey({ - mode: WebAuthnMode.Login, - }) - - const passkeyValidator = await toPasskeyValidator({ - account: nexusClient.account, - webAuthnKey, - }) - - return passkeyValidator; -} -``` - -## Step 4: Install Passkey Validator Module - -```typescript -import type { NexusClient, Module } from '@biconomy/abstractjs' - -async function installPasskeyValidator(nexusClient: NexusClient, passkeyValidator: Module) { - const passkeyValidatorAddress = "0xD990393C670dCcE8b4d8F858FB98c9912dBFAa06" - const userOpHash = await nexusClient?.installModule({ - module: { - address: passkeyValidatorAddress, - type: "validator", - initData: passkeyValidator?.initData - }, - }) - - // Wait for transaction to be confirmed - await nexusClient?.waitForUserOperationReceipt({ hash: userOpHash }); -} -``` - -## Step 5: Using Passkey for Transactions - -```typescript -import { createBicoBundlerClient, createBicoPaymasterClient, type Module, type NexusClient, moduleActivator } from '@biconomy/abstractjs' -import { baseSepolia } from 'wagmi/chains' -import { http, useAccount, useWalletClient } from 'wagmi' -import type { Address } from 'viem' - -const account = useAccount() -const { data: walletClient } = useWalletClient({ account: account.address }) - -async function sendTransactionWithPasskey(nexusClient: NexusClient, passkeyValidator: Module, recipientAddress: Address) { - // Extend NexusClient with passkey validator - nexusClient.extend(moduleActivator(passkeyValidator)); - // Send transaction - const hash = await nexusClient.sendUserOperation({ - calls: [ - { - to: recipientAddress, - value: BigInt(0) // or your desired value - } - ], - }); - - // Wait for confirmation - const receipt = await nexusClient.waitForUserOperationReceipt({ hash }); - return receipt; -} -``` - -## Step 6: Uninstall Passkey Validator (Optional) - -```typescript -import { type NexusClient, type Module, createBicoBundlerClient, moduleActivator } from '@biconomy/abstractjs' - -async function uninstallPasskeyValidator(nexusClient: NexusClient, passkeyValidator: Module) { - nexusClient.extend(moduleActivator(passkeyValidator)); - const userOpHash = await nexusClient?.uninstallModule({ - module: { - address: passkeyValidator.address, - type: "validator", - deInitData: "0x" - } - }); - - await nexusClient?.waitForUserOperationReceipt({ hash: userOpHash }); - - // Clear stored passkey data - localStorage.removeItem('webAuthnKey'); -} -``` \ No newline at end of file diff --git a/docs/pages/modules/validators/smartSessions/grantingSmartSessions.md b/docs/pages/modules/validators/smartSessions/grantingSmartSessions.md deleted file mode 100644 index 328a2f1..0000000 --- a/docs/pages/modules/validators/smartSessions/grantingSmartSessions.md +++ /dev/null @@ -1,212 +0,0 @@ -# Granting Smart Sessions - -The Smart Sessions module provides two key actions when using `smartSessionCreateActions`: `grantPermission` and `trustAttesters`. - -> **Important**: The k1Validator module must be the active nexus module for creating smart sessions. This is automatically handled when you extend your client with `smartSessionCreateActions`. - -## grantPermission - -Creates a new session with specified permissions and rules. - -### Usage - - -:::code-group - -```typescript [example.ts] -import { usersNexusClient } from "./client" -import { smartSessionCreateActions } from "@biconomy/abstractjs" - -const response = await usersNexusClient.grantPermission({ - sessionRequestedInfo: [{ - sessionPublicKey: "0x...", - actionPoliciesInfo: [{ - contractAddress: "0x...", - functionSelector: "0x...", - sudo: true - }] - }] -}); - -``` - -```ts [client.ts] filename="client.ts" -import { OneOf, Address, Hex, http } from "viem" -import { ActionPolicyInfo, CreateSessionDataParams, toSmartSessionsValidator, smartSessionCreateActions } from "@biconomy/sdk-canary" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}); - -// ---cut--- -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}) - -// Install the smart sessions module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) - -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }) - -// Extend the Nexus client with smart session creation actions -export const usersNexusClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) -) -``` - -::: - -### Parameters - -> **Note**: For a detailed reference of all available configuration options and their types, see the [Smart Session Types](/modules/validators/smartSessions/policies) documentation. This will help you understand how different parameters map to policies and how they can be combined. - -```typescript -import { type Address } from "viem" - -enum ParamCondition { - EQUAL = 0, - GREATER_THAN = 1, - LESS_THAN = 2, - GREATER_THAN_OR_EQUAL = 3, - LESS_THAN_OR_EQUAL = 4, - NOT_EQUAL = 5 -} - -type Usage = { - /** Maximum number of times this rule can be used */ - limit: bigint - /** Current usage count (typically starts at 0) */ - used: bigint -} - -type Rule = { - /** Type of comparison to perform */ - condition: ParamCondition - /** Position of parameter in calldata. - * - * Example: transferWithMessage(address to, uint256 amount, string message)... - * - * const rules = [ - * { offsetIndex: 0, ... }, // 'to' parameter - * { offsetIndex: 1, ... }, // 'amount' parameter - * { offsetIndex: 2, ... } // offset to message data - * ] - */ - offsetIndex: number - /** Whether to track usage count */ - isLimited: boolean - /** Value to compare against */ - ref: string | number | bigint - /** Usage tracking configuration (required if isLimited is true) */ - usage?: Usage -} - -type ActionPolicy = { - /** Target contract address */ - contractAddress: Address - /** Function selector to allow */ - functionSelector: string - /** Array of validation rules for the function parameters */ - rules: Rule[] -} - -type SessionConfig = { - /** Public key for the session */ - sessionPublicKey: string - /** Array of permission policies */ - actionPoliciesInfo: ActionPolicy[] -} - -type GrantPermissionParams = { - /** Array of session configurations */ - sessionRequestedInfo: SessionConfig[] -} -``` - -### Response - -Returns a promise that resolves to a transaction hash. - -## trustAttesters - -Adds trusted attesters for session validation. - -### Usage - - -:::code-group - -```typescript [example.ts] -import { usersNexusClient } from "./client" -import { smartSessionCreateActions } from "@biconomy/abstractjs" -import { MOCK_ATTESTER_ADDRESS, REGISTRY_ADDRESS } from "@rhinestone/module-sdk" - -const response = await usersNexusClient.trustAttesters({ - attesters: [MOCK_ATTESTER_ADDRESS], - registryAddress: REGISTRY_ADDRESS -}); -``` - -```ts [client.ts] filename="client.ts" -import { OneOf, Address, Hex, http } from "viem" -import { ActionPolicyInfo, CreateSessionDataParams, toSmartSessionsValidator, smartSessionCreateActions } from "@biconomy/sdk-canary" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -// ---cut--- -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}) - -// Install the smart sessions module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) - -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }) - -// Extend the Nexus client with smart session creation actions -export const usersNexusClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) -) -``` -::: - -### Parameters - -- `attesters`: Array of attester addresses to trust - -### Response - -Returns a promise that resolves to a transaction hash. - - diff --git a/docs/pages/modules/validators/smartSessions/index.md b/docs/pages/modules/validators/smartSessions/index.md deleted file mode 100644 index 8196c6a..0000000 --- a/docs/pages/modules/validators/smartSessions/index.md +++ /dev/null @@ -1,74 +0,0 @@ -# Smart Sessions - -Smart sessions enable powerful UX improvements for web3 applications by allowing users to delegate specific permissions to session keys. This creates a more seamless user experience while maintaining security through granular controls. - -![Smart Session](https://i.imgur.com/gN0Xhm6.png) - - -## Smart Sessions Explained - -You can think of smart sessions as giving some signers/keys special granular access to your smart account. They can -execute transactions on that account, but they can't execute *any* transaction - only the transactions they were -explicitly approved to execute. - -These fall into a few broad categories: - -| Restriction Type | Description | -|-----------------|-------------| -| **How much they can execute** | Set the maximum amount of transactions a key can execute. | -| **When they can execute** | Set time restrictions which prevent the signers from executing in any times beyond the ones approved by you. | -| **How much funds they can use** | Set restrictions on how much tokens the signer can use in total or in a single call. | -| **Which contracts they can call** | Set restrictions saying which *exact* contracts the signer is allowed to call. | - -All of these permissions can be combined with eachother to create powerful guardrails for signers - primarily bots or -AI agents. - -:::tip[Example of a complex session] -A bot signer is allowed to: -- Execute 20 transactions -- Execute between 8AM - 8PM on Weekdays -- Call only Uniswap and AAVE Contracts -- Can spend maximum of 5000 USDC -::: - - -## Why Sessions Matter - -Smart sessions solve several critical UX challenges in web3: - -1. **Reduced Transaction Friction**: Instead of requiring users to sign every transaction, session keys can handle repeated actions automatically within defined parameters. - -2. **Enhanced Security**: Rather than storing a user's primary wallet key in a browser, applications can use temporary session keys with limited permissions and expiration dates. - -3. **Granular Control**: Users can grant very specific permissions to session keys, such as: - - Maximum transaction amounts - - Specific contract interactions - - Time-based restrictions - - Usage limits - - Parameter-based rules - -## Real World Examples - -Smart sessions enable seamless experiences like: - -- **Gaming**: Players can pre-authorize common in-game actions without constant signing -- **DeFi**: Trading apps can execute trades within user-defined limits -- **NFT Markets**: Marketplaces can list/delist items without repeated signatures -- **Social Platforms**: Apps can post content or interact with smart contracts seamlessly - -## Technical Benefits - -1. **Gas Optimization**: Session keys can batch multiple transactions and optimize gas usage -2. **Flexible Implementation**: Supports various validation schemes (time-based, value-limited, etc.) -3. **Composable Security**: Combine multiple policies to create sophisticated permission systems -4. **Standards Compliant**: Built on established standards like ERC-7579 for maximum compatibility - -## User Experience Impact - -- **Reduced Cognitive Load**: Users don't need to understand every transaction detail -- **Familiar Web2 Feel**: Actions feel instant and seamless like traditional web applications -- **Maintained Security**: Users retain full control through granular permissions -- **Better Error Handling**: Applications can handle failed transactions more gracefully - -Smart sessions represent a crucial evolution in web3 UX, bridging the gap between blockchain security and seamless user experiences. - diff --git a/docs/pages/modules/validators/smartSessions/policies/index.md b/docs/pages/modules/validators/smartSessions/policies/index.md deleted file mode 100644 index 2bf1438..0000000 --- a/docs/pages/modules/validators/smartSessions/policies/index.md +++ /dev/null @@ -1,99 +0,0 @@ -# Smart Session Policies - -Smart Sessions provide a powerful way to delegate specific permissions to session keys with fine-grained control. These policies act as a security framework that allows you to precisely define what actions session keys can perform, under what conditions, and for how long. - -## What are Smart Session Policies? - -Smart Session policies are rules and constraints that govern: -- Which contract functions can be called -- What parameters are allowed -- How much value can be transferred -- When the permissions are valid -- Which blockchain networks are authorized - -These policies enable secure delegation of account capabilities while maintaining strict control over potential risks. - -## Key Benefits - -- **🔐 Enhanced Security**: Grant minimal permissions required for specific operations -- **⚡ Better UX**: Enable seamless interactions without compromising security -- **🎯 Precise Control**: Define exact conditions under which operations can occur -- **⏱️ Time-Bound Access**: Automatically expire permissions after a set duration -- **🌐 Cross-Chain Safety**: Specify which networks permissions are valid on - -## Policy Components - -Each policy consists of several potential components: -- **Contract Address**: The target smart contract -- **Function Selectors**: Specific functions that can be called -- **Rules**: Parameter-level constraints -- **Time Bounds**: Valid duration for the permissions -- **Value Limits**: Maximum amounts that can be transferred -- **Network Restrictions**: Specific blockchain networks where the policy is valid - -## Session Creation Parameters - -### Session Creation Parameters -| Property | Type | Required | Description | -|----------|------|----------|-------------| -| `sessionPublicKey` | `Hex` | Yes | Public key for the session (required for K1 algorithm validators) | -| `sessionValidatorAddress` | `Address` | No | Address of the session validator | -| `sessionValidatorType` | `string` | No | Type of the session validator (usually "simple K1 validator") | -| `salt` | `Hex` | No | Optional salt for the session | -| `sessionValidUntil` | `number` | No | Timestamp until which the session is valid | -| `sessionValidAfter` | `number` | No | Timestamp after which the session becomes valid | -| `chainIds` | `bigint[]` | No | Chain IDs where the session should be enabled | -| `actionPoliciesInfo` | `ActionPolicyInfo[]` | Yes | Array of action policy data for the session | - -### Action Policy Configuration -| Property | Type | Required | Description | -|----------|------|----------|-------------| -| `contractAddress` | `Address` | Yes | The smart contract address this policy applies to | -| `validUntil` | `number` | No | Timestamp when the session expires | -| `validAfter` | `number` | No | Timestamp when the session becomes active | -| `valueLimit` | `bigint` | No | Maximum amount of native tokens (ETH) per transaction | -| `tokenLimits` | `Array` | No | Array of ERC20 token spending limits | -| `usageLimit` | `bigint` | No | Maximum number of times this policy can be used | -| `sudo` | `boolean` | No | If true, grants unlimited permissions (not compatible with rules) | -| `functionSelector` | `string` | One of these required | Specific function to allow | -| `rules` | `Rule[]` | One of these required | Array of parameter rules | -| `abi` | `Abi` | One of these required | Full contract ABI | - -### Parameter Conditions -| Condition | Value | Description | -|-----------|-------|-------------| -| `EQUAL` | 0 | Exact match comparison | -| `GREATER_THAN` | 1 | Value must be greater than reference | -| `LESS_THAN` | 2 | Value must be less than reference | -| `GREATER_THAN_OR_EQUAL` | 3 | Value must be greater than or equal to reference | -| `LESS_THAN_OR_EQUAL` | 4 | Value must be less than or equal to reference | -| `NOT_EQUAL` | 5 | Value must not match reference | - -### Rule Configuration -| Property | Type | Required | Description | -|----------|------|----------|-------------| -| `condition` | `ParamCondition` | Yes | Type of comparison to perform | -| `offsetIndex` | `number` | Yes | Position of parameter in calldata | -| `isLimited` | `boolean` | Yes | Whether to track usage count | -| `ref` | `string \| number \| bigint` | Yes | Value to compare against | -| `usage` | `Usage` | If `isLimited` is true | Usage tracking configuration | - -### Usage Configuration -| Property | Type | Description | -|----------|------|-------------| -| `limit` | `bigint` | Maximum number of times this rule can be used | -| `used` | `bigint` | Current usage count (typically starts at 0) | - - -### Token Limit Structure -| Property | Type | Description | -|----------|------|-------------| -| `token` | `Address` | Token contract address | -| `limit` | `bigint` | Maximum amount that can be spent | - - -## Best Practices - -1. **Principle of Least Privilege**: Always grant the minimum permissions necessary. -2. **Time Constraints**: Consider adding time range policies to limit session duration. -3. **Combine Policies**: Use multiple policies together for enhanced security. diff --git a/docs/pages/modules/validators/smartSessions/policies/spendingLimitPolicy.md b/docs/pages/modules/validators/smartSessions/policies/spendingLimitPolicy.md deleted file mode 100644 index ae59652..0000000 --- a/docs/pages/modules/validators/smartSessions/policies/spendingLimitPolicy.md +++ /dev/null @@ -1,110 +0,0 @@ -### Spending Limits Policy - -The spending limits policy provides fine-grained control over ERC20 token transfers, allowing you to set both per-transaction and cumulative spending limits, as well as restrict transfers to specific addresses. - -⚠️ **Security Consideration**: Always whitelist recipient addresses and set conservative token limits to protect against unauthorized transfers. - -:::code-group - -```ts [spendingLimits.ts] filename="spendingLimits.ts" -import { usersNexusClient } from "./client.ts"; -import { parseUnits, toFunctionSelector } from "viem"; -import { ParamCondition } from "@biconomy/sdk-canary"; - -const createSessionsResponse = await usersNexusClient.grantPermission({ - sessionRequestedInfo: [ - { - sessionPublicKey, - actionPoliciesInfo: [ - { - functionSelector: toFunctionSelector("transfer(address,uint256)"), - contractAddress: USDC_ADDRESS, - rules: [ - { - condition: ParamCondition.EQUAL, - offsetIndex: 0, // recipient parameter - isLimited: false, - ref: WHITELISTED_ADDRESS - }, - { - condition: ParamCondition.LESS_THAN, - offsetIndex: 1, // amount parameter - isLimited: true, - ref: parseUnits("1000", 6), // 1000 USDC per tx - usage: { - limit: parseUnits("5000", 6), // 5000 USDC total - used: 0n - } - } - ], - tokenLimits: [ - { - token: USDC_ADDRESS, - limit: parseUnits("5000", 6) // 5000 USDC total limit - } - ] - } - ] - } - ] -}) -``` -```ts [client.ts] filename="client.ts" - -import { OneOf, Address, Hex, http } from "viem" -import { ActionPolicyInfo, CreateSessionDataParams, toSmartSessionsValidator, smartSessionCreateActions } from "@biconomy/sdk-canary" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -// ---cut--- -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}) - -// Install the smart sessions module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) - -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }) - -// Extend the Nexus client with smart session creation actions -export const usersNexusClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) -) -``` - -::: - -## Common Use Cases - -- **Token Allowances**: Set maximum spending limits for ERC20 tokens -- **Whitelisted Transfers**: Restrict transfers to approved addresses only -- **Budget Management**: Implement departmental spending controls -- **DeFi Risk Management**: Limit exposure in DeFi protocols -- **Automated Payments**: Control recurring token payments -- **Treasury Operations**: Manage organizational token distributions - -## Best Practices - -1. **Whitelist Recipients**: Always specify allowed recipient addresses -2. **Dual Limits**: Implement both per-transaction and cumulative limits -3. **Token Decimals**: Carefully account for token decimal places when setting limits -4. **Usage Tracking**: Monitor cumulative usage against total limits -5. **Multiple Tokens**: Set appropriate limits for each token type -6. **Regular Reviews**: Periodically audit spending patterns and adjust limits -7. **Combine Policies**: Use with time-based restrictions for enhanced security \ No newline at end of file diff --git a/docs/pages/modules/validators/smartSessions/policies/sudoPolicy.md b/docs/pages/modules/validators/smartSessions/policies/sudoPolicy.md deleted file mode 100644 index ae5d280..0000000 --- a/docs/pages/modules/validators/smartSessions/policies/sudoPolicy.md +++ /dev/null @@ -1,91 +0,0 @@ -### Sudo Policy - -The sudo policy grants unlimited permissions for specified contract addresses and function selectors. This is the most permissive policy and should be used with caution. It can be used when you need to grant complete access to specific contract functions, similar to admin privileges. - -⚠️ **Security Consideration**: This provides the highest level of access and should only be used when necessary and there is a good deal of trust in the session key grantee. - -:::code-group - -```ts [sudo.ts] filename="sudo.ts" -import { usersNexusClient } from "./client.ts"; - -const createSessionsResponse = await usersNexusClient.grantPermission({ - sessionRequestedInfo: [ - { - sessionPublicKey, - // sessionValidUntil: number - // sessionValidAfter: number - // chainIds: bigint[] - actionPoliciesInfo: [ - { - abi: CounterAbi, // Providing the full contract ABI will parse it to individual function selectors under the hood - contractAddress: "0x...", - sudo: true - } - ] - } - ] -}) -``` - -```ts [client.ts] filename="client.ts" - -import { OneOf, Address, Hex, http } from "viem" -import { ActionPolicyInfo, CreateSessionDataParams, toSmartSessionsValidator, smartSessionCreateActions } from "@biconomy/sdk-canary" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) - -// ---cut--- -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}) - -// Install the smart sessions module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) - -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }) - -// Extend the Nexus client with smart session creation actions -export const usersNexusClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) -) -``` - -::: - -## Common Use Cases - -- **Emergency Response**: Grant full access to trusted parties during incidents -- **Contract Administration**: Allow comprehensive management of protocol settings -- **System Maintenance**: Enable complete access for upgrades and maintenance -- **Development Testing**: Provide unrestricted access in test environments -- **Protocol Governance**: Enable execution of governance decisions -- **Multi-sig Operations**: Grant full access to trusted multi-sig participants - -## Best Practices - -1. **Time-Bound Access**: Always combine with time range policies to limit exposure -2. **Strict Monitoring**: Implement comprehensive logging for all sudo operations -3. **Limited Scope**: Restrict sudo access to specific contracts rather than global access -4. **Regular Audits**: Frequently review and rotate sudo permissions -5. **Emergency Revocation**: Maintain ability to quickly revoke sudo access if compromised -6. **Documentation**: Keep detailed records of why sudo access was granted -7. **Test Environment**: Validate sudo operations in test environment first - diff --git a/docs/pages/modules/validators/smartSessions/policies/timeRangePolicy.md b/docs/pages/modules/validators/smartSessions/policies/timeRangePolicy.md deleted file mode 100644 index a62b5db..0000000 --- a/docs/pages/modules/validators/smartSessions/policies/timeRangePolicy.md +++ /dev/null @@ -1,86 +0,0 @@ -### Time Range Policy - -The time range policy allows you to set temporal boundaries for session key permissions. This ensures that session keys can only be used within specific time windows, providing an additional layer of security through time-based access control. - -⚠️ **Security Consideration**: Always set reasonable time bounds and consider your application's specific needs when determining session validity periods. - -:::code-group - -```ts [timeRange.ts] filename="timeRange.ts" -import { usersNexusClient } from "./client.ts"; - -const createSessionsResponse = await usersNexusClient.grantPermission({ - sessionRequestedInfo: [ - { - sessionPublicKey, - sessionValidAfter: 0, // Applies to all userOperations - sessionValidUntil: Date.now() + (365 * 24 * 60 * 60 * 1000), // 1 year from now, applies to all userOperations - actionPoliciesInfo: [ - { - abi: DailyTaskAbi, - contractAddress: "0x...", - // Session valid for 7 days starting tomorrow - validAfter: Date.now() + (1 * 24 * 60 * 60 * 1000), // Starts tomorrow - validUntil: Date.now() + (7 * 24 * 60 * 60 * 1000), // Ends after 7 days - } - ] - } - ] -}); -``` - -```ts [client.ts] filename="client.ts" -// @errors: 8010 -import { Address, Hex, http } from "viem"; -import { ActionPolicyInfo, CreateSessionDataParams, toSmartSessionsValidator, smartSessionCreateActions } from "@biconomy/sdk-canary"; -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) - -// ---cut--- -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}) - -// Install the smart sessions module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) - -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }) - -// Extend the Nexus client with smart session creation actions -export const usersNexusClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) -) -``` - -::: - -## Common Use Cases - -- **Business Hours Access**: Restrict session usage to working hours -- **Time-Limited Trials**: Grant temporary access for evaluation periods -- **Scheduled Maintenance**: Allow access only during maintenance windows -- **Periodic Tasks**: Enable automated actions at specific times - -## Best Practices - -1. Always set both `validAfter` and `validUntil` for bounded session lifetimes -2. Use daily time windows for recurring access patterns -3. Combine with other policies for comprehensive security -4. Consider timezone implications when setting time bounds diff --git a/docs/pages/modules/validators/smartSessions/policies/universalActionPolicy.md b/docs/pages/modules/validators/smartSessions/policies/universalActionPolicy.md deleted file mode 100644 index a2d9f66..0000000 --- a/docs/pages/modules/validators/smartSessions/policies/universalActionPolicy.md +++ /dev/null @@ -1,102 +0,0 @@ -### Universal Action Policy - -The universal action policy allows for controlled access to specific contract functions with optional parameter-based rules. Below is an example that restricts a function call to a specific parameter value. - -⚠️ **Security Consideration**: Always set appropriate time bounds and carefully consider which contract functions to expose. - -:::code-group - -```ts [universalAction.ts] filename="universalAction.ts" -import { usersNexusClient } from "./client.ts"; -import { parseUnits, toFunctionSelector } from "viem"; - -const createSessionsResponse = await usersNexusClient.grantPermission({ - sessionRequestedInfo: [ - { - sessionPublicKey, - actionPoliciesInfo: [ - { - functionSelector: toFunctionSelector("transfer(address,uint256)"), - contractAddress: USDC_ADDRESS, - rules: [ - { - condition: ParamCondition.EQUAL, - offsetIndex: 0, // recipient parameter - isLimited: false, - ref: WHITELISTED_ADDRESS - }, - { - condition: ParamCondition.LESS_THAN, - offsetIndex: 1, // amount parameter - isLimited: true, - ref: parseUnits("1000", 6), // 1000 USDC per tx - usage: { - limit: parseUnits("5000", 6), // 5000 USDC total - used: 0n - } - } - ], - } - ] - } - ] -}); -``` -```ts [client.ts] filename="client.ts" -import { OneOf, Address, Hex, http } from "viem" -import { ActionPolicyInfo, CreateSessionDataParams, toSmartSessionsValidator, smartSessionCreateActions } from "@biconomy/sdk-canary" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) - -// ---cut--- -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}) - -// Install the smart sessions module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) - -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }) - -// Extend the Nexus client with smart session creation actions -export const usersNexusClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) -) -``` -::: - -## Common Use Cases - -- **Token Allowances**: Set maximum spending limits for ERC20 tokens -- **Whitelisted Transfers**: Restrict transfers to approved addresses only -- **Budget Management**: Implement departmental spending controls -- **DeFi Risk Management**: Limit exposure in DeFi protocols -- **Automated Payments**: Control recurring token payments -- **Treasury Operations**: Manage organizational token distributions - -## Best Practices - -1. **Whitelist Recipients**: Always specify allowed recipient addresses -2. **Dual Limits**: Implement both per-transaction and cumulative limits -3. **Token Decimals**: Carefully account for token decimal places when setting limits -4. **Usage Tracking**: Monitor cumulative usage against total limits -5. **Multiple Tokens**: Set appropriate limits for each token type -6. **Regular Reviews**: Periodically audit spending patterns and adjust limits -7. **Combine Policies**: Use with time-based restrictions for enhanced security \ No newline at end of file diff --git a/docs/pages/modules/validators/smartSessions/policies/usageLimitPolicy.md b/docs/pages/modules/validators/smartSessions/policies/usageLimitPolicy.md deleted file mode 100644 index e795cf1..0000000 --- a/docs/pages/modules/validators/smartSessions/policies/usageLimitPolicy.md +++ /dev/null @@ -1,90 +0,0 @@ -### Usage Limit Policy - -The usage limit policy allows you to restrict how many times a session key can be used. This provides a simple but effective way to limit the total number of operations a session can perform, regardless of the operation type. - -⚠️ **Security Consideration**: Set conservative usage limits based on expected legitimate usage patterns to minimize potential abuse. - -:::code-group - -```ts [usageLimit.ts] filename="usageLimit.ts" -import { usersNexusClient } from "./client.ts"; -import { parseEther } from "viem"; - -const createSessionsResponse = await usersNexusClient.grantPermission({ - sessionRequestedInfo: [ - { - sessionPublicKey, - actionPoliciesInfo: [ - { - contractAddress: "0x123", - functionSelector: "0x456", - // Limit total usage to 100 transactions - usageLimit: BigInt(100), - // Optional: Combine with other policies - validUntil: BigInt(Date.now() + 7 * 24 * 60 * 60 * 1000) // 7 days - } - ] - } - ] -}); -``` - -```ts [client.ts] filename="client.ts" -// @filename: types.d.ts -declare module "@biconomy/sdk-canary" { - export function toSmartSessionsValidator(config: any): any; - export function smartSessionCreateActions(module: any): any; -} - -import { OneOf, Address, Hex, http } from "viem" -import { ActionPolicyInfo, CreateSessionDataParams, toSmartSessionsValidator, smartSessionCreateActions, createBicoBundlerClient, toNexusAccount } from "@biconomy/sdk-canary" -import { privateKeyToAccount } from "viem/accounts"; -import { baseSepolia } from "viem/chains"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) - -// ---cut--- -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}) - -// Install the smart sessions module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) - -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }) - -// Extend the Nexus client with smart session creation actions -export const usersNexusClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) -) -``` - -::: - -## Common Use Cases - -- **Limited Trial Access**: Grant a fixed number of operations for evaluation purposes -- **Batch Operations**: Allow a specific number of automated transactions -- **Risk Management**: Cap total possible operations for security -- **Resource Control**: Limit API or service usage through smart contract calls - -## Best Practices - -1. **Set Reasonable Limits**: Choose usage limits that balance functionality with security -2. **Combine with Time Bounds**: Add time restrictions to prevent rapid consumption of usage quota -3. **Monitor Usage**: Track usage patterns to adjust limits appropriately -4. **Consider Operation Types**: Set different limits for different function calls based on risk \ No newline at end of file diff --git a/docs/pages/modules/validators/smartSessions/policies/valueLimitPolicy.md b/docs/pages/modules/validators/smartSessions/policies/valueLimitPolicy.md deleted file mode 100644 index 863dfe0..0000000 --- a/docs/pages/modules/validators/smartSessions/policies/valueLimitPolicy.md +++ /dev/null @@ -1,90 +0,0 @@ -### Value Limit Policy - -The value limit policy allows you to set maximum transaction value limits for native token (ETH) transfers. This provides granular control over how much ETH can be spent in a single transaction or across all transactions within the session. - -⚠️ **Security Consideration**: While more restrictive than sudo, ensure limits are set appropriately for your use case to minimize potential losses. - -:::code-group - -```ts [valueLimit.ts] filename="valueLimit.ts" -import { usersNexusClient } from "./client.ts"; -import { parseEther } from "viem"; - -const createSessionsResponse = await usersNexusClient.grantPermission({ - sessionRequestedInfo: [ - { - sessionPublicKey, - // sessionValidUntil: number - // sessionValidAfter: number - // chainIds: bigint[] - actionPoliciesInfo: [ - { - abi: PaymentAbi, // Using the full contract ABI will parse it to individual function selectors under the hood - contractAddress: "0x...", - valueLimit: parseEther("1.0") // 1 ETH limit per transaction - } - ] - } - ] -}) -``` -```ts [client.ts] filename="client.ts" - -import { OneOf, Address, Hex, http } from "viem" -import { ActionPolicyInfo, CreateSessionDataParams, toSmartSessionsValidator, smartSessionCreateActions } from "@biconomy/sdk-canary" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) - -// ---cut--- -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}) - -// Install the smart sessions module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) - -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }) - -// Extend the Nexus client with smart session creation actions -export const usersNexusClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) -) -``` - -::: - -## Common Use Cases - -- **DeFi Operations**: Limit maximum trade sizes or liquidity provisions -- **Recurring Payments**: Cap periodic payment amounts -- **Treasury Management**: Control spending limits for organizational funds -- **Gas Fee Management**: Set upper bounds for transaction fees -- **Automated Trading**: Implement safety limits for trading bots -- **Subscription Services**: Cap maximum payment amounts for subscriptions - -## Best Practices - -1. **Conservative Limits**: Start with lower limits and adjust based on usage patterns -2. **Multiple Tiers**: Implement different limits for different operation types -3. **Cumulative Tracking**: Consider both per-transaction and total session limits -4. **Market Volatility**: Account for potential price fluctuations when setting limits -5. **Regular Reviews**: Periodically assess and adjust limits based on needs -6. **Emergency Stops**: Include mechanisms to pause operations if unusual patterns detected -7. **Combine with Time Limits**: Use time-based restrictions to further control exposure \ No newline at end of file diff --git a/docs/pages/modules/validators/smartSessions/usingSmartSessions.md b/docs/pages/modules/validators/smartSessions/usingSmartSessions.md deleted file mode 100644 index fe3bb93..0000000 --- a/docs/pages/modules/validators/smartSessions/usingSmartSessions.md +++ /dev/null @@ -1,78 +0,0 @@ -# Using Smart Sessions Actions - -> **Important**: The smartSessionValidation module must be the active nexus module for using smart sessions. This is automatically handled when you extend your client with `smartSessionUseActions`. - -Once a session has been created, you can use it to execute transactions on behalf of the account that granted the permissions. The Smart Sessions module provides the `usePermission` action through `smartSessionUseActions`. - -## usePermission - -Executes a transaction using the granted session permissions. - -### Usage - -:::code-group - -```typescript [example.ts] -import { nexusClient } from "./nexusClient" -import { smartSessionUseActions } from "@biconomy/abstractjs" -import { encodeFunctionData } from "viem" - -// Initialize the module for using permissions -const usePermissionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: sessionKey, // The session key granted permission - moduleData: sessionData.moduleData // This is the module data returned from the createSessions step -}); - -// Extend the client with session usage capabilities -const sessionClient = nexusClient - .extend(smartSessionUseActions(usePermissionsModule)); - -// Use the session to make a transaction -const userOpHash = await sessionClient.usePermission({ - calls: [{ - to: targetContract, - data: encodeFunctionData({ - abi: contractABI, - functionName: "transfer", - args: [recipientAddress, amount] - }) - }] -}); - -// Wait for the transaction to be mined -const receipt = await sessionClient.waitForUserOperationReceipt({ hash: userOpHash }); -``` - -```typescript [nexusClient.ts] filename="nexusClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -### Parameters - -- `calls`: Array of transaction calls to execute - - `to`: `Address` - Target contract address - - `data`: `Hex` - Encoded function call data - - `value?`: `bigint` - Optional ETH value to send with the call - -### Response - -Returns a promise that resolves to a user operation hash. This hash can be used with `waitForUserOperationReceipt` to track the transaction status. \ No newline at end of file diff --git a/docs/pages/multichain-gas-abstraction/for-eoa.mdx b/docs/pages/multichain-gas-abstraction/for-eoa.mdx deleted file mode 100644 index fa2850e..0000000 --- a/docs/pages/multichain-gas-abstraction/for-eoa.mdx +++ /dev/null @@ -1,177 +0,0 @@ -# Tutorial: Paying for Gas With ERC-20 Tokens From an EOA Account - -This tutorial demonstrates how to execute a transaction on Base while paying for gas fees with USDC on Optimism. We'll use Fusion execution to create a simple transaction that users can sign without needing native tokens for gas. - -## Overview - -In blockchain applications, users typically need to hold native tokens on each chain they interact with. With Biconomy's Fusion execution, users can: -- Execute transactions on one chain (Base) while paying for gas with tokens on another chain (Optimism) -- Use ERC20 tokens like USDC instead of native tokens for gas fees -- Create seamless cross-chain experiences without managing multiple gas tokens - -## Prerequisites - -- Node.js installed -- A wallet with some USDC on Optimism -- Basic understanding of EVM transactions - -## Steps to Implement Fusion Execution - -:::steps -#### Setting Up Your Environment - -First, let's import the necessary dependencies and set up our account: - -```javascript -import { createMeeClient, executeFusionQuote, getMeeScanLink, mcUSDC, toMultichainNexusAccount, waitForSupertransactionReceipt, type Instruction, type Trigger } from "@biconomy/abstractjs-canary"; -import { http, zeroAddress } from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { base, optimism } from "viem/chains"; -``` - -#### Initialize Accounts and Client - -Now we'll set up the EOA (Externally Owned Account) and create a Nexus account for orchestration: - -```javascript -const eoa = privateKeyToAccount('0xEOA_ADDRESS') -const oNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - transports: [http()], - signer: eoa, -}) -const meeClient = await createMeeClient({ - account: oNexus -}) -``` - -In this code: -- We create an EOA from a private key (in production, use environment variables) -- We create a Nexus account that can operate on both Optimism and Base -- We initialize the MEE client which will handle orchestration - -#### Define the Trigger Transaction - -The trigger transaction is what the user will actually sign. Since USDC supports ERC20Permit, we can use it directly for gas payment: - -```javascript -// We'll use the fact that USDC supports ERC20Permit -// to enable the Biconomy Stack to use it to pay for gas. -const trigger: Trigger = { - // Amount refers to the amount of USDC our instructions - // would use. In this case it'll be zero, since we're not - // doing anything useful in our instructions, but if you're - // going to be using USDC in your instructions, just set this - // to the amount of USDC the instructions will need - amount: 0n, - chainId: optimism.id, - tokenAddress: mcUSDC.addressOn(optimism.id) -} -``` - -This trigger defines: -- Which token to use (USDC on Optimism) -- How much of that token our instructions need (0 in this example) -- Which chain the trigger executes on (Optimism) - -#### Define the Instruction - -Next, we define what we want to execute. In this example, we're creating a simple instruction that doesn't do anything useful - it just sends 0 ETH to the zero address on Base: - -```javascript -const instruction: Instruction = { - // One instruction can contain multiple - // function calls. This will be a demo - // instruction that does nothing - it just - // sends 0 ETH to 0x000.... - calls: [{ - to: zeroAddress, - value: 0n - }], - // The chain where the instruction will be executed - chainId: base.id -} -``` - -Note that while our trigger is on Optimism, the instruction executes on Base - demonstrating cross-chain functionality. - -#### Get a Quote for Execution - -Now we need to get a quote for executing our instruction using USDC on Optimism as the fee token: - -```javascript -const fusionQuote = await meeClient.getFusionQuote({ - trigger: trigger, - // Important: Fee token *has* to be the same as the trigger - // token, when using this flow! - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - }, - instructions: [instruction] -}) -``` - -Important note: When using this flow, the fee token must be the same as the trigger token. - -#### Execute the Transaction - -With our quote ready, we can now execute the transaction: - -```javascript -const { hash } = await meeClient.executeFusionQuote({ - fusionQuote -}) -``` - -This creates the transaction that the user will sign. When the user signs this transaction, it will: -1. Approve the usage of USDC on Optimism for fees -2. Execute the instruction on Base - -#### Wait for Completion and Track Status - -Finally, we wait for the transaction to complete and get a link to track it: - -```javascript -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash -}) -// Get link to https://meescan.biconomy.io explorer -// which will allow you to track it -const meeScanLink = getMeeScanLink(hash) -``` - -The `waitForSupertransactionReceipt` function will pause execution until the transaction is confirmed. The `getMeeScanLink` function provides a URL to Biconomy's explorer where you can track the transaction's status. -::: - -## Making Smart Contract Account Invisible -For a truly seamless user experience, you can include a transfer instruction as the final step in your instructions array. This automatically returns any resulting assets (tokens, NFTs, positions) from the smart account back to the user's original EOA. Users simply sign one transaction from their familiar wallet and later receive the end results directly there, without ever needing to know about or interact with the intermediary smart account that facilitated the cross-chain operations. - -## How It Works Behind the Scenes - -When executing this cross-chain flow: - -1. The user signs a transaction with USDC on Optimism -2. The Biconomy infrastructure uses this to pay for gas fees -3. The system handles the cross-chain orchestration -4. The instruction is executed on Base -5. All of this happens without the user needing to hold ETH on Base - -## Real-World Applications - -While this example is simple, you can use this pattern to: - -- Allow users to interact with Base dApps without holding ETH on Base -- Enable cross-chain DeFi interactions using only USDC on Optimism -- Create multi-chain experiences with simplified token management -- Reduce onboarding friction for new users - -## Next Steps - -To extend this example for real applications: -- Replace the empty instruction with meaningful contract interactions on Base -- Add proper error handling -- Implement a UI for users to interact with -- Consider adding multiple instructions across different chains - -By leveraging cross-chain Fusion execution with ERC20 gas payments, you can create a much smoother user experience that eliminates one of the major friction points in blockchain applications. \ No newline at end of file diff --git a/docs/pages/multichain-gas-abstraction/for-sca.mdx b/docs/pages/multichain-gas-abstraction/for-sca.mdx deleted file mode 100644 index 1f23464..0000000 --- a/docs/pages/multichain-gas-abstraction/for-sca.mdx +++ /dev/null @@ -1,140 +0,0 @@ -# Paying for Gas with ERC20 Tokens on Smart Accounts - -## Introduction - -When your funds are already on a Biconomy smart account, you can pay for transaction gas fees using ERC20 tokens like USDC instead of native tokens like ETH. This guide demonstrates how to execute transactions from a funded smart account using USDC to cover gas costs. - -:::warning[Fund Account] -This approach requires your smart account to already be funded with the ERC20 tokens you wish to use for gas payment. You must transfer these tokens to the smart account before attempting the transaction execution shown in this guide. -::: - -## Implementation - -```javascript -import { - createMeeClient, - toMultichainNexusAccount, - toFeeToken, - mcUSDC -} from "@biconomy/abstractjs"; -import { http, encodeFunctionData } from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { optimism } from "viem/chains"; - -const main = async () => { - // Initialize EOA, smart account, and client - const eoa = privateKeyToAccount("0x...your_private_key..."); - const smartAccount = await toMultichainNexusAccount({ - signer: eoa, - chains: [optimism], - transports: [http()] - }); - const meeClient = await createMeeClient({ - account: smartAccount - }); - - // Define the transaction you want to execute - const targetContractAddress = "0x123...your_target_contract"; - const transactionInstruction = await smartAccount.build({ - type: "default", - data: { - chainId: optimism.id, - calls: [{ - to: targetContractAddress, - data: encodeFunctionData({ - abi: [/* Your contract ABI */], - functionName: "yourFunction", - args: [/* Your arguments */] - }) - }] - } - }); - - // Execute the transaction using USDC on the smart account for gas - const { hash } = await meeClient.execute({ - // Specify USDC as the token to use for gas payment - feeToken: toFeeToken({ - chainId: optimism.id, - mcToken: mcUSDC - }), - // The transaction to execute - instructions: [transactionInstruction] - }); - - console.log(`Transaction started: ${hash}`); - - // Wait for transaction to complete - const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - console.log(`Transaction completed: ${receipt}`); -}; - -main().catch(console.error); -``` - -## How It Works - -1. **Pre-funded Smart Account**: Your smart account must already have USDC tokens. This is a prerequisite before executing this flow. - -2. **Transaction Definition**: Define the transaction you want to execute on Optimism. - -3. **Fee Token Selection**: Specify USDC as the token to pay for gas instead of ETH. - -4. **Direct Execution**: Unlike Fusion execution, this directly uses the smart account's funds without requiring a separate user transaction. - -## Checking Smart Account Balance - -Before executing transactions, verify your smart account has sufficient tokens: - -```javascript -import { getUnifiedERC20Balance } from "@biconomy/abstractjs"; - -// Check balance of USDC on the smart account -const balance = await getUnifiedERC20Balance({ - account: smartAccount, - mcToken: mcUSDC -}); - -console.log(`Smart Account USDC Balance: ${balance.unified}`); -``` - -## Funding Your Smart Account - -If your smart account needs USDC, fund it first with a standard transfer: - -```javascript -// Example code to fund your smart account with USDC -const fundingTx = await eoa.sendTransaction({ - to: mcUSDC.addressOn(optimism.id), - data: encodeFunctionData({ - abi: erc20Abi, - functionName: "transfer", - args: [smartAccount.addressOn(optimism.id), usdcAmount] - }) -}); -``` - -## Key Differences from Fusion Execution - -| Direct Smart Account Execution | Fusion Execution | -|--------------------------------|------------------| -| Requires pre-funding smart account | User signs from EOA, no pre-funding needed | -| No user transaction required | Requires user to sign a transaction | -| Simpler code flow | More setup code required | -| Requires user to manually fund account | Automatically handles fund transfer | - -## When to Use This Approach - -This approach is best for: - -- Applications where users regularly interact with the same smart account -- Scenarios where smart accounts are already funded with tokens -- Backend systems or automated processes that manage smart accounts -- Applications that want to minimize transaction steps for repeat users - -## Limitations - -- Smart account must be pre-funded with the ERC20 token used for gas -- Users need to perform a separate funding transaction before this flow -- Requires users to understand they have a smart account - -For scenarios where users shouldn't need to know about smart accounts or pre-fund them, consider using the Fusion execution approach instead. \ No newline at end of file diff --git a/docs/pages/multichain-gas-abstraction/overview.mdx b/docs/pages/multichain-gas-abstraction/overview.mdx deleted file mode 100644 index 2789ed8..0000000 --- a/docs/pages/multichain-gas-abstraction/overview.mdx +++ /dev/null @@ -1,48 +0,0 @@ -# Multichain Gas Abstraction - -The Biconomy stack has two main ways to abstract away gas complexity from users: - -- Enabling users to pay for gas with ERC-20 tokens (e.g. USDC, WETH, ...) -- Enabling apps to sponsor gas for users - -Both of these methods are _natively multichain_ - -## Multichain ERC-20 Gas Payments - -This method enables the user to pay for gas on one chain, with ERC-20 tokens from any -chain. - -:::tip[Example] -The User pays for the execution of a transaction on Base, with USDC on Optimism -::: - -```ts -const receipt = await meeClient.execute({ - feeToken: { - address: '0xUSDC', - chainId: optimism.id - }, - instructions: [ - { - chainId: base.id, - // Empty demo transaction, sending - // 0 ETH to 0x000... on Base - calls: [{ - to: zeroAddress, - value: 0n - }] - } - ] -}) -``` - -:::info[Native Token] -If you want to use the native token (e.g. ETH) on one chain to pay for the execution -of another chain, you can set the `feeToken.address` to `0x000...`. -::: - -## Multichain Gas Sponsorships - -:::info[Coming Soon] -Documentation for transaction sponsorships is currently under development. -::: \ No newline at end of file diff --git a/docs/pages/multichain-gas-abstraction/sponsoring-gas.mdx b/docs/pages/multichain-gas-abstraction/sponsoring-gas.mdx deleted file mode 100644 index 27c0f75..0000000 --- a/docs/pages/multichain-gas-abstraction/sponsoring-gas.mdx +++ /dev/null @@ -1,14 +0,0 @@ -# Sponsoring Gas Across Multiple Chains - -The Biconomy stack enables developers to sponsor user transactions, enabling a seamless -gas-free user experience for all users. - -Built as an upgrade to our five years of providing gas abstraction infrastructure, the -current gas sponsorship solution is our most advanced yet. - -## In Development - -The documentation for multichain transaction sponsoring is in developmnet. - -You can reference the [Sponsoring Gas](/tutorials/gasless) article if you'd wish to use our -legacy solution - using ERC-4337 Bundlers & Paymasters. \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/comprehensive.mdx b/docs/pages/multichain-orchestration/comprehensive.mdx deleted file mode 100644 index 402cf37..0000000 --- a/docs/pages/multichain-orchestration/comprehensive.mdx +++ /dev/null @@ -1,612 +0,0 @@ -# Zero-to-Hero Guide: Composable Multichain Orchestration - -This guide will walk you through building a complete multichain orchestration flow using Biconomy's AbstractJS SDK. You'll learn both the fundamental concepts and practical implementation details to create complex cross-chain transactions that users can execute with a single signature. - -## What is Multichain Orchestration? - -Multichain orchestration is a powerful pattern that allows users to perform complex sequences of actions across multiple blockchains with just a single signature. Traditional blockchain interactions require users to sign separate transactions for each step in a process (approve, transfer, bridge, swap, etc.), often across different chains with different gas tokens. - -Biconomy's orchestration stack solves this by: -- Combining multiple transactions into a single user operation -- Handling cross-chain coordination automatically -- Processing transactions in the correct sequence -- Adapting to runtime conditions and token amounts - -## Overview of Our Example - -In this guide, we'll build a DeFi workflow that demonstrates these capabilities: - -1. Transfers USDC from a user's EOA (Externally Owned Account) on Base chain -2. Bridges the USDC to Optimism chain -3. Swaps USDC to USDT on Optimism using Uniswap -4. Deposits USDT into Aave to receive aUSDT (interest-bearing tokens) -5. Returns the aUSDT tokens to the user's original EOA - -All of this happens with just one signature from the user, eliminating the need for multiple transactions, approvals, and chain-switching. - -:::info -This flow demonstrates the power of Biconomy's orchestration stack: cross-chain transfers, token swaps, and DeFi protocol interactions - all bundled into a seamless user experience. -::: - -## Prerequisites - -Before you begin, make sure you have: - -- **Development Environment**: Node.js installed on your machine -- **Blockchain Knowledge**: Basic understanding of EVM blockchains, tokens, and DeFi concepts -- **Test Wallet**: A private key for testing on testnets (never use production keys in code) -- **Test Tokens**: Some test USDC on Base testnet (you can get these from testnet faucets) - -:::warning -Never hardcode private keys in production code. This guide uses hardcoded keys for simplicity, but in a real application, you should use environment variables or secure key management solutions. -::: - -## Setup - -First, let's install the necessary dependencies: - -```bash -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -Next, create a new file called `orchestration.js` and import the required dependencies: - -```javascript -import { - AavePoolAbi, - createMeeClient, - getFusionQuote, - mcAaveV3Pool, - mcUniswapSwapRouter, - mcUSDC, - mcUSDT, - runtimeERC20BalanceOf, - toFeeToken, - toMultichainNexusAccount, - UniswapSwapRouterAbi, - greaterThanOrEqualTo -} from "@biconomy/abstractjs"; - -import { - encodeFunctionData, - erc20Abi, - http, - parseUnits -} from "viem"; - -import { privateKeyToAccount } from "viem/accounts"; -import { base, optimism } from "viem/chains"; -``` - -## Core Concepts - -Before we start coding, let's understand some key concepts that power Biconomy's orchestration system: - -### Multichain Nexus Account - -A Multichain Nexus Account is a specialized smart contract account that: -- Works across multiple blockchains with a single identity -- Orchestrates transaction sequences in the correct order -- Acts as a central coordination point for cross-chain operations -- Handles token transfers and protocol interactions on behalf of the user - -In our architecture, the Nexus Account receives funds from the user's EOA, performs all the necessary operations across chains, and returns the final assets to the user. - ---- - -### Instructions - -Instructions are the building blocks of an orchestration sequence. Each instruction defines: -- Which blockchain it should execute on -- What actions to perform (token approvals, swaps, bridge calls, etc.) -- What parameters to use for each action -- Any dependencies or conditions that must be met before execution - -Instructions can be simple (like a token approval) or complex (like multiple contract interactions in sequence). - ---- - -### Triggers - -A trigger is the user-signed transaction that initiates the entire orchestration sequence. In Biconomy's system, this is typically: -- A token transfer from the user's EOA to the Nexus Account, or -- A token approval that allows the Nexus Account to transfer tokens from the user's EOA - -The trigger includes cryptographic proof of the user's consent to the entire orchestration sequence, not just the initial transaction. - ---- - -### Modular Execution Environment (MEE) - -The MEE is Biconomy's infrastructure that: -- Monitors for trigger transactions on-chain -- Executes instructions in the correct sequence -- Handles cross-chain coordination -- Manages gas payments and transaction confirmation - -## Step by Step Instructions - -::::steps -#### Initialize Accounts and Client - -Let's set up the EOA account and create a multichain Nexus account to handle the orchestration: - -```javascript -// Generate an account from private key (use environment variables in production) -const eoa = privateKeyToAccount( - "0x3e478f4e7c4be62e616d4b347de5431a4a6774899db4a72702b58e0cb92a1e00" // Replace with your test key -); - -// Log the address (useful for loading test tokens) -console.log(`EOA Address: ${eoa.address}`); - -// Create a multichain Nexus account -// This creates a smart contract account that can operate across multiple chains -const oNexus = await toMultichainNexusAccount({ - signer: eoa, // The EOA that controls this Nexus account - chains: [base, optimism], // The chains this account will operate on - transports: [http(), http()] // Network providers for each chain -}); - -// Log the orchestrator account address -console.log("Orchestrator Account address:", oNexus.addressOn(base.id)); - -// Initialize the MEE client -// This gives us access to Biconomy's Modular Execution Environment -const meeClient = await createMeeClient({ - account: oNexus, -}); -``` - -:::note -The Nexus account serves as the orchestrator for our transaction sequence. When using Fusion execution mode, this account operates behind the scenes - users only interact with their familiar EOA wallet, while the Nexus account handles all the complex cross-chain operations. -::: - -#### Define the Amount and Trigger - -Now we'll define how much USDC we'll use and set up the trigger transaction: - -```javascript -// Amount of USDC to use (adjust as needed) -// parseUnits converts 2.5 to the proper decimal representation (USDC uses 6 decimals) -const amountConsumed = parseUnits("2.5", 6); // Equals 2,500,000 in raw units - -// Define the trigger transaction -// This is the transaction the user will actually sign - a transfer of USDC from their EOA -// to the Nexus account. This single transaction will kick off the entire orchestration sequence. -const transferToNexusTrigger = { - tokenAddress: mcUSDC.addressOn(base.id), // The USDC token address on Base chain - amount: amountConsumed, // How much USDC to transfer - chainId: base.id, // Which chain this trigger executes on -}; -``` - -:::info[Understanding Triggers] -The trigger transaction is special because it contains not just the initial token transfer, but also a cryptographic commitment to the entire orchestration sequence. - -Behind the scenes, Biconomy: -1. Hashes all the instructions into a Merkle tree -2. Appends the Merkle root to the transaction data -3. When the user signs this transaction, they're implicitly authorizing the entire sequence - -This allows a single user signature to securely authorize multiple cross-chain operations. -::: - -#### Prepare the Bridge Transaction - -We'll use the Across bridge to move USDC from Base to Optimism: - -```javascript -// First, let's prepare the bridge transaction details -const callDepositAcrossSpokePool = await oNexus.buildComposable({ - type: 'default', - data: { - // Encode a call to Across Spoke Pool - } -}) - -// Approve the bridge contract to spend USDC -const approveUsdcSpendToAcross = await oNexus.buildComposable({ - type: 'approve', - data: { - tokenAddress: mcUSDC.addressOn(base.id), - amount: amountConsumed, - chainId: base.id, - spender: callDepositAcrossSpokePool.to - } -}) -``` - -#### Define Execution Constraints - -A key challenge in cross-chain operations is that you can't know exactly how many tokens will arrive after a bridge or swap due to fees, slippage, and price movements. Execution constraints solve this problem: - -```javascript -// Allow for up to 20% slippage from the bridge -// This means the next steps will only proceed if at least 80% of the original amount arrives -const executionConstraints = [ - greaterThanOrEqualTo((amountConsumed * 80n) / 100n), -]; -``` - -:::info[Understanding Execution Constraints] -Execution constraints are conditions that must be met for an instruction to execute. They provide: - -1. **Safety**: Prevent execution when conditions aren't favorable (e.g., too much slippage) -2. **Sequencing**: Ensure operations happen in the correct order (e.g., wait for bridged funds) -3. **Adaptability**: Allow the system to work with varying token amounts at runtime - -In our example, we're creating a constraint that ensures we received at least 80% of our original USDC amount after bridging. If less than that arrives, the subsequent operations won't execute - protecting the user from excessive slippage. - -Constraints can be combined and customized for different scenarios, like minimum balances, price conditions, or time-based restrictions. -::: - -#### Define Swap Instructions - -Now, let's prepare instructions to swap USDC to USDT on Optimism using Uniswap. This involves two steps: approving Uniswap to spend our USDC, then executing the swap. - -```javascript -// Approve Uniswap to spend the USDC that arrives on Optimism -const approveUniswapToSpendUSDC = await oNexus.buildComposable({ - type: "approve", // This is a token approval instruction - data: { - chainId: optimism.id, // Execute on Optimism chain - tokenAddress: mcUSDC.addressOn(optimism.id), // The token to approve - spender: mcUniswapSwapRouter.addressOn(optimism.id), // Who can spend the token - - // How much to approve - this is where runtime values come in! - amount: runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(optimism.id, true), - tokenAddress: mcUSDC.addressOn(optimism.id), - constraints: executionConstraints, - }), - }, -}); - -// Swap USDC to USDT on Uniswap -const swapUSDCtoUSDTOnUniswap = await oNexus.buildComposable({ - type: "default", // For complex protocol interactions - data: { - chainId: optimism.id, // Execute on Optimism chain - abi: UniswapSwapRouterAbi, // The contract ABI for function encoding - to: mcUniswapSwapRouter.addressOn(optimism.id), // Uniswap router address - functionName: "exactInputSingle", // The specific function to call - args: [ - { - tokenIn: mcUSDC.addressOn(optimism.id), // From USDC - - // Use exactly how much USDC we have at runtime - amountIn: runtimeERC20BalanceOf({ - tokenAddress: mcUSDC.addressOn(optimism.id), - targetAddress: oNexus.addressOn(optimism.id, true), - constraints: executionConstraints, - }), - - tokenOut: mcUSDT.addressOn(optimism.id), // To USDT - recipient: oNexus.addressOn(optimism.id, true), // Recipient of USDT - amountOutMinimum: 0n, // In production, set appropriate slippage - fee: 100, // 0.01% pool fee - sqrtPriceLimitX96: 0n, // No price limit - }, - ], - }, -}); -``` - -:::info[Understanding Runtime Values] -One of the most powerful features of Biconomy's orchestration is runtime value injection. - -**What it solves**:
When bridging or swapping tokens, you never know exactly how many tokens you'll receive due to fees, slippage, and price movement. Traditional approaches would require overestimating, underestimating, or complex offchain calculations. - -**How it works**:
The `runtimeERC20BalanceOf` function creates a placeholder that gets replaced with the actual token balance at execution time. This means: - -1. You don't need to predict exact amounts -2. You can use 100% of whatever tokens are available -3. The system adapts to actual on-chain conditions -4. No tokens get stuck or leftover in intermediate accounts - -In our example, we're approving and swapping whatever amount of USDC actually arrives on Optimism after bridging, subject to our minimum constraints. -::: - -## Step 6: Define Aave Deposit Instructions - -Next, let's prepare instructions to deposit USDT into Aave: - -```javascript -// Approve Aave to spend the USDT received from the swap -const approveAAVEtoSpendUSDT = await oNexus.buildComposable({ - type: "approve", - data: { - chainId: optimism.id, - tokenAddress: mcUSDT.addressOn(optimism.id), - spender: mcAaveV3Pool.addressOn(optimism.id), - amount: runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(optimism.id, true), - tokenAddress: mcUSDT.addressOn(optimism.id), - constraints: executionConstraints, - }), - }, -}); - -// Supply USDT to Aave -const supplyUsdtToAAVE = await oNexus.buildComposable({ - type: "default", - data: { - abi: AavePoolAbi, - to: mcAaveV3Pool.addressOn(optimism.id), - chainId: optimism.id, - functionName: "supply", - args: [ - mcUSDT.addressOn(optimism.id), - runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(optimism.id, true), - tokenAddress: mcUSDT.addressOn(optimism.id), - constraints: executionConstraints, - }), - oNexus.addressOn(optimism.id, true), - 0, - ], - }, -}); -``` - -#### Return aUSDT to the User - -Finally, let's return the aUSDT tokens to the user's EOA: - -```javascript -// Define the aUSDT token address on Optimism -const aUSDTOptimismAddress = "0x6ab707Aca953eDAeFBc4fD23bA73294241490620"; - -// Transfer aUSDT back to the user's EOA -const moveAusdtBackToEOA = await oNexus.buildComposable({ - type: "transfer", - data: { - amount: runtimeERC20BalanceOf({ - tokenAddress: aUSDTOptimismAddress, - targetAddress: oNexus.addressOn(optimism.id, true), - constraints: [greaterThanOrEqualTo(parseUnits("0.3", 1))], - }), - chainId: optimism.id, - recipient: eoa.address, - tokenAddress: aUSDTOptimismAddress, - }, -}); -``` - -#### Get a Quote and Execute - -With all our instructions defined, we need to get a quote for execution costs and then execute the transaction sequence: - -```javascript -// Get a quote for executing the entire sequence -const quote = await meeClient.getFusionQuote({ - // The trigger transaction that the user will sign - trigger: transferToNexusTrigger, - - // Specify which token to use for paying execution fees - // This allows users to pay for all gas fees using USDC instead of ETH/native tokens - feeToken: toFeeToken({ - chainId: base.id, - mcToken: mcUSDC, - }), - - // The sequence of instructions to execute - // These will be executed in order, with dependencies and constraints respected - instructions: [ - approveUsdcSpendToAcross, - callDepositAcrossSpokePool, - approveUniswapToSpendUSDC, - swapUSDCtoUSDTOnUniswap, - approveAAVEtoSpendUSDT, - supplyUsdtToAAVE, - moveAusdtBackToEOA, - ], -}); - -console.log(`Got Quote: ${quote.quote.hash}`); -console.log(`Execution cost: ${quote.quote.paymentInfo.tokenValue}`); - -// Execute the Fusion quote -// This generates the trigger transaction for the user to sign -const { hash } = await meeClient.executeFusionQuote({ - fusionQuote: quote, -}); - -console.log(`Started execution: ${hash}`); - -// Wait for the entire transaction sequence to complete -// This might take a few minutes since it involves cross-chain operations -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -console.log(`Successful execution: ${receipt}`); -``` - -:::info[Understanding Fusion Execution] -Fusion execution is the process that ties everything together: - -1. **Quote Generation**: First, we get a quote that estimates the cost of executing all instructions -2. **Fusion Transaction Creation**: The system creates a special transaction that embeds proof of the entire instruction sequence -3. **User Signature**: The user signs just this one transaction -4. **Execution**: Once signed, the MEE nodes detect the transaction on-chain and execute all instructions in sequence -5. **Cross-Chain Coordination**: The system automatically handles waiting for bridges, coordinating across chains, and ensuring instructions execute in order -6. **Result Delivery**: Finally, the system ensures the end result (aUSDT in our case) is delivered back to the user's original wallet - -This entire process happens without requiring the user to switch chains, approve multiple transactions, or manually track the progress. From the user's perspective, they simply sign one transaction and later receive the final result. -::: -:::: - -## Complete Code Example - -Here's the complete code for our orchestration flow: - -```javascript -import { - AavePoolAbi, - createMeeClient, - getFusionQuote, - mcAaveV3Pool, - mcUniswapSwapRouter, - mcUSDC, - mcUSDT, - runtimeERC20BalanceOf, - toFeeToken, - toMultichainNexusAccount, - UniswapSwapRouterAbi, - greaterThanOrEqualTo -} from "@biconomy/abstractjs"; - -import { - encodeFunctionData, - erc20Abi, - http, - parseUnits -} from "viem"; - -import { privateKeyToAccount } from "viem/accounts"; -import { base, optimism } from "viem/chains"; - -const main = async () => { - // Generate an account from private key (use environment variables in production) - const eoa = privateKeyToAccount( - "0x3e478f4e7c4be62e616d4b347de5431a4a6774899db4a72702b58e0cb92a1e00" // Replace with your test key - ); - - console.log(`EOA Address: ${eoa.address}`); - - // Create a multichain Nexus account - const oNexus = await toMultichainNexusAccount({ - signer: eoa, - chains: [base, optimism], - transports: [http(), http()] - }); - - console.log("Orchestrator Account address:", oNexus.addressOn(base.id)); - - // Initialize the MEE client - const meeClient = await createMeeClient({ - account: oNexus, - }); - - // Amount of USDC to use - const amountConsumed = parseUnits("2.5", 6); - - // Define the trigger transaction - const transferToNexusTrigger = { - tokenAddress: mcUSDC.addressOn(base.id), - amount: amountConsumed, - chainId: base.id, - }; - - // [Bridge configuration code goes here] - - // Define execution constraints - const executionConstraints = [ - greaterThanOrEqualTo((amountConsumed * 80n) / 100n), - ]; - - // [Instructions code goes here] - - // Get a quote for executing the entire sequence - const quote = await meeClient.getFusionQuote({ - trigger: transferToNexusTrigger, - feeToken: toFeeToken({ - chainId: base.id, - mcToken: mcUSDC, - }), - instructions: [ - bridgeUsdcFromBaseToOptimism, - approveUniswapToSpendUSDC, - swapUSDCtoUSDTOnUniswap, - approveAAVEtoSpendUSDT, - supplyUsdtToAAVE, - moveAusdtBackToEOA, - ], - }); - - console.log(`Got Quote: ${quote.quote.hash}`); - console.log(`Execution cost: $${quote.quote.paymentInfo.tokenValue}`); - - // Execute the quote - const { hash } = await meeClient.executeFusionQuote({ - fusionQuote: quote, - }); - - console.log(`Started execution: ${hash}`); - - // Wait for the transaction to complete - const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - console.log(`Successful execution: ${receipt}`); -}; - -main().catch(console.error); -``` - -## How It All Works Together - -Let's summarize the complete flow of our orchestration: - -1. **User Experience**: The user signs just one transaction from their EOA wallet - a simple USDC transfer -2. **Behind The Scenes**: - - The USDC is transferred to the Nexus account on Base - - The Nexus account bridges the USDC to Optimism - - Once funds arrive on Optimism, they're approved and swapped to USDT - - The USDT is then approved and deposited into Aave - - The resulting aUSDT tokens are sent back to the user's original EOA - -From the user's perspective, this entire multi-step, cross-chain process appears as a single, seamless operation. - -## Architecture Overview - -The system components work together as follows: - -1. **User's EOA**: The externally owned account that initiates the transaction -2. **Nexus Account**: The smart contract account that orchestrates all operations -3. **MEE Nodes**: Biconomy's infrastructure that monitors and executes instructions -4. **Runtime Values**: Dynamic values calculated at execution time -5. **Execution Constraints**: Rules that determine when operations can proceed -6. **Fusion Execution**: The mechanism that ties everything into a single user signature - -This architecture enables powerful, user-friendly experiences that abstract away the complexities of blockchain interactions. - -## What's Next? - -You've just built a complex multichain orchestration flow that allows users to: - -1. Start with USDC on Base -2. End with an interest-bearing aUSDT position on Optimism -3. Complete the entire operation with a single signature - -Next, you can: - -- **Explore Additional Patterns**: - - Intent-based swaps using 1inch or CoW Protocol - - Dollar-cost averaging across multiple chains - - Zapping into LP positions across chains - - Debt management across lending protocols - -- **Customize User Experiences**: - - Add front-end interfaces to your orchestration flows - - Implement dynamic routing based on gas costs or exchange rates - - Create protocol-specific optimizations - -## Troubleshooting Guide - -### Insufficient Funds -- **Symptom**: Transaction reverts or fails to execute -- **Cause**: Not enough tokens for operations or fees -- **Solution**: Ensure your account has sufficient token balances and some native tokens for gas - -### Bridge Delays -- **Symptom**: Orchestration seems stuck after the bridge step -- **Cause**: Cross-chain bridges can take from 5-30 minutes depending on the provider -- **Solution**: Be patient and monitor bridge status on the destination chain - -### Slippage Errors -- **Symptom**: Transactions after bridging fail to execute -- **Cause**: Constraints too strict for actual received amounts -- **Solution**: Adjust your `executionConstraints` to allow for more slippage if needed - -### Invalid Function Calls -- **Symptom**: Contract calls revert with error messages -- **Cause**: Incorrect ABI, function parameters, or token addresses -- **Solution**: Double-check all contract ABIs and verify token addresses on each chain \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/eip7702.mdx b/docs/pages/multichain-orchestration/eip7702.mdx deleted file mode 100644 index cf3eba3..0000000 --- a/docs/pages/multichain-orchestration/eip7702.mdx +++ /dev/null @@ -1,92 +0,0 @@ -# Orchestrating with EIP-7702 Delegated EOAs - -[EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) -enables developers to set smart account code to their EOA address. - -This means that apps can set the Orchestrator smart account to their EOA address -and get the best of both EOA Orchestration and Smart Account Orchestration - -### Key Benefits -The key benefits of EIP-7702 powered Orchestration: - -- Users don't have to deposit funds to a new Smart Account (no onboarding friction) -- Users get all the benefits of smart account based orchestration such as: - - Chain Abstraction - - Unified Token Balances - - Multi-Chain Gas - -### Key Drawbacks -The key drawback of the EIP-7702 orchestration is that it's not available for any -users using extension/external wallets. These wallets (such as MetaMask, -Rabby, Trust, ...) don't allow for EIP-7702 delegations to be set to EOAs -under their control. The EIP-7702 delegation is set by signing and posting -a Type 4 EVM transaction, which these wallets will reject. - -## Who Can Leverage EIP-7702 Orchestration? -EIP-7702 orchestration is available to apps building on Embedded wallets such -as Privy, Dynamic, etc... Since embedded wallets will allow the app to delegate -the EOA to the orchestrator smart account, apps can easily leverage this -functionality. - -## Using EIP-7702 Orchestration - -Leveraging EIP-7702 orchestration is done in two steps: - -:::steps -### Delegate -Sign an authorization message which will set the Nexus smart account -code to your wallet. - -Delegation is done by signign an EIP-7702 delegation message which will -delegate the account to the **Nexus 1.2.0.** implementation address. Nexus -1.2.0. is our EIP-7702 compliant version of the Nexus smart accounts. - - -```ts -// This is the address of the EOA to which -// address we'll be "installing" the smart account to. -const eoa = privateKeyToAccount('0xPrivateKey') - -// Create an instance of a viem wallet client and extend it with the -// required eip7702 actions. -const walletClient = createWalletClient({ - chain: odysseyTestnet, - account: eoa, - transport: http(), -}).extend(eip7702Actions()) - -const authorization = await walletClient.signAuthorization({ - // Address of the Nexus Proxy Singleton - contractAddress: '0x000000004F43C49e93C970E84001853a70923B03' -}) -``` - - -### Initialize the account -Afer the EIP-7702 delegation has been set, you can use the same orchestration -as you would for smart accounts, with the only difference beign that you'd -need to override the `accountAddress` parameter when initializing the -account. - - -```ts -// Override the accountAddress parameter to be the same -// as your EOA address. -const oNexus = await toMultichainNexusAccount({ - signer: eoa, - accountAddress: eoa.address, - chains: [optimism, polygon, base] -}) -``` - -To learn how to use orcehstration with smart accounts (including EIP-7702), -read the [Smart Account Orchestration](/multichain-orchestration/sca) guide. - -### Execute - -After you've sucessfully delegated to the EIP-7702 powered contract, execute your transactions by -following [this guide](/eip7702/wallet-guide) - - -::: - diff --git a/docs/pages/multichain-orchestration/eoa.mdx b/docs/pages/multichain-orchestration/eoa.mdx deleted file mode 100644 index c31e701..0000000 --- a/docs/pages/multichain-orchestration/eoa.mdx +++ /dev/null @@ -1,160 +0,0 @@ -# Orchestration with Native EOA Accounts - -Biconomy orchestration for EOA accounts is done by leveraging an passthrough -smart account comined with a trigger transaction from the EOA. - -The flow is as follows: - -:::steps -#### Approve Spend -The trigger transaction approves the "passthrough" orchestrator smart -account to spend funds from the EOA. The trigger transaction can be any -EVM function call, but is usually a call to `approve` function on an ERC-20 -token _or_ an NFT transfer from the EOA to the orchestrator account. - -#### Orchestrate -The orchestration starts once the "trigger" transaction has been included onchain. -This is when the relayer nodes will start to execute desired function calls, -bridge/solver triggers, etc... on the orchestrator smart account. - -This is where most of the execution happens, as the orchestration step can -include multiple function calls across multiple chains and multiple transactions. - -#### Return to EOA -As the last step of the orchestration, it's common to encode function -calls which return all of the assets that were the result of the orchestration -back to the EOA. - -This ensures that the user never has to access the smart account manually, nor -do they even need to know about the orchestrator account address. -::: - -## Trigger Types -To trigger the native EOA account to start the orchestration, we use one of two -separate types of triggers: - -### Onchain Transaction Trigger -The onchain transaction trigger takes the hash of the orchestration instructions -and appends it after the useful `callData` of the transaction. - -- The key benefit of the onchain transaction trigger is that it's general -purpose and the trigger transaction can be any EVM function call. - -- The key drawback of the onchain transaction trigger is that the user has to -have native gas tokens on their EOA to pay for the first "trigger" transaction. - - -### ERC20Permit Trigger -The ERC20Permit trigger uses the [ERC-2612](https://eips.ethereum.org/EIPS/eip-2612) -signature to approve the orchestrator smart account to spend some tokens. It -packs the hash of the orchestration instructions in the `DateTime` field of the ERC20Permit -signature. - -- The key benefit of the ERC20Permit approach is that it's gasless. This means -that the user can encode a full multichain orchestration sequence, without having -any native gas tokens. - -- The key drawback of the ERC20Permit approach is that it only works with tokens -which implement the `ERC-2612` standard. While this standard is common, it's by -no means ubiquitous. - -## Selecting the Trigger Type - -The `AbstractJS` SDK will automatically check whether the token you're using -as the trigger supports `ERC-2612` or no. If it supports it, it will use the -ERC20Permit trigger, otherwise it'll use the onchain transaction trigger. - -## Quick Code Reference - -Here's a condensed code example showing the essential steps for implementing EOA-based orchestration: - -```javascript -import { createMeeClient, toMultichainNexusAccount, runtimeERC20BalanceOf, toFeeToken } from "@biconomy/abstractjs"; -import { privateKeyToAccount } from "viem/accounts"; -import { base, optimism } from "viem/chains"; -import { http, parseUnits } from "viem"; - -// 1. Initialize accounts and client -const eoa = privateKeyToAccount("0x...your_private_key..."); -const oNexus = await toMultichainNexusAccount({ - signer: eoa, - chains: [base, optimism], - transports: [http(), http()] -}); -const meeClient = await createMeeClient({ account: oNexus }); - -// 2. Define trigger - this is what the user signs -const trigger = { - tokenAddress: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base - amount: parseUnits("10", 6), - chainId: base.id -}; - -// 3. Build instructions - what happens after the trigger -const instructions = [ - // Bridge from Base to Optimism - await oNexus.buildComposable({ - type: "default", - data: // Encode call to bridge here! - }), - - // Use funds on destination chain with runtime values - await oNexus.buildComposable({ - type: "default", - data: { - chainId: optimism.id, - abi: someProtocolAbi, - to: "0xProtocolAddress", - functionName: "deposit", - args: [ - // Use whatever amount arrived after bridging - runtimeERC20BalanceOf({ - tokenAddress: "0xTokenOnOptimism", - targetAddress: oNexus.addressOn(optimism.id), - constraints: [/* minimum amount constraints */] - }) - ] - } - }), - - // Return results to user's EOA - await oNexus.buildComposable({ - type: "transfer", - data: { - chainId: optimism.id, - tokenAddress: "0xResultTokenAddress", - recipient: eoa.address, - amount: runtimeERC20BalanceOf({ - tokenAddress: "0xResultTokenAddress", - targetAddress: oNexus.addressOn(optimism.id) - }) - } - }) -]; - -// 4. Get quote and execute -const quote = await meeClient.getFusionQuote({ - trigger: trigger, - feeToken: toFeeToken({ - chainId: base.id, - tokenAddress: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" // USDC - }), - instructions: instructions -}); - -// 5. Execute - this creates the transaction for user to sign -const { hash } = await meeClient.executeFusionQuote({ fusionQuote: quote }); - -// 6. Wait for orchestration to complete -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -``` - -### Key Patterns to Remember - -1. **Trigger Transaction**: Usually an approval or transfer from EOA to Nexus -2. **Runtime Values**: Use `runtimeERC20BalanceOf()` to handle dynamic amounts -3. **Return Assets**: Always include a final step to return assets to the user's EOA -4. **Constraints**: Add constraints when bridging or swapping to handle slippage -5. **Chain IDs**: Specify the correct chainId for each instruction - -For complete implementations, refer to our examples on [GitHub](https://github.com/bcnmy/biconomy-client-sdk/tree/main/examples). \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/instruction-builders/composable.mdx b/docs/pages/multichain-orchestration/instruction-builders/composable.mdx deleted file mode 100644 index b8a5ce1..0000000 --- a/docs/pages/multichain-orchestration/instruction-builders/composable.mdx +++ /dev/null @@ -1,31 +0,0 @@ -# Default Composable Instruction Builder - -The composable instruction builder is used to make function calls which will -inject dynamic runtime parameters. - -The builder accepts the `abi` of the contract being called, the `chainId` -where the contract is deployed and the `contractAddress`. - -```ts -const composableInstruction = await oNexus.buildComposable({ - type: 'default', - data: { - abi: erc20Abi, - functionName: 'transfer', - chainId: optimism.id, - to: '0xTargetTokenAddress', - args: [ - '0xRecipientAddress', - - // This is dynamically injecting the runtime balance - // of TargetToken into the amount parameter. For - // example, this can be used to send the *exact* value - // received from a bridge or a solver to some address - runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(optimism.id, true), - tokenAddress: '0xTargetTokenAddress' - }) - ] - } -}) -``` \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/instruction-builders/default.mdx b/docs/pages/multichain-orchestration/instruction-builders/default.mdx deleted file mode 100644 index 4a3d1cd..0000000 --- a/docs/pages/multichain-orchestration/instruction-builders/default.mdx +++ /dev/null @@ -1,42 +0,0 @@ -# Default Instruction Builder -The instruction builder with the type "default" is the most basic instruction -builder. It enables developers to encode multiple _calls_ into a single instruction. - -Every call is the type of `{ to, value, data }` - -## Using Default Builder - -```ts -import { toMultichainNexusAccount } from "@biconomy/abstractjs" -import { http, parseEther } from "viem" -import { privateKeyToAccount } from "viem/accounts" -import { base, optimism } from "viem/chains" - -const oNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - transports: [http(), http()], - signer: privateKeyToAccount('0xSigner') -}) - -const defaultInstruction = await oNexus.build({ - type: 'default', - data: { - // Execute on Optimism - chainId: optimism.id, - - calls: [ - // Send 0.05 ETH to Recipient A - { - to: '0xRecipient_A', - value: parseEther('0.05') - }, - - // Send 0.03 ETH to Recipient B - { - to: '0xRecipient_B', - value: parseEther('0.03') - } - ] - } -}) -``` \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/instruction-builders/multichain.mdx b/docs/pages/multichain-orchestration/instruction-builders/multichain.mdx deleted file mode 100644 index ed480bc..0000000 --- a/docs/pages/multichain-orchestration/instruction-builders/multichain.mdx +++ /dev/null @@ -1,34 +0,0 @@ -# Multichain Instruction Builder -The multichain instruction builder creates the identical instruction to be -executed on all the chains with which the `MultichainSmartAccount` object has been initialized. - -## Using Multichain Builder - -```ts -const multichainInstruction = await oNexus.build({ - type: 'multichain', - data: { - type: '', // the type of multichain instruction being executed - parameters: { - // Type safe parameters depending on the type - } - } -}) -``` - -One example of using the multichain instruction builder would be -installing the Session Keys module to all the chains: - -```ts -const sessionsModule = toSmartSessionsModule({ - signer: privateKeyToAccount('0xPrivateKey') -}) - -const multichainInstruction = await oNexus.build({ - type: 'multichain', - data: { - type: 'toInstallModuleCalls', - parameters: toInstallData(sessionsModule) - } -}) -``` \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/instruction-builders/overview.mdx b/docs/pages/multichain-orchestration/instruction-builders/overview.mdx deleted file mode 100644 index a15d38e..0000000 --- a/docs/pages/multichain-orchestration/instruction-builders/overview.mdx +++ /dev/null @@ -1,66 +0,0 @@ -# Instruction Builders Overview - -The orchestration in the Biconomy stack is done by orchestrating a series of -`Instruction` objects. Every instruction object is a `{ to, value, data }` tuple -which will make an onchain function call. - -You can encode these Instructions manually, but in order to simplify creating -common Instructions, we've exposed several instruction builders. - -The instruction builder is created by creating the multichain Nexus -account instance: - -```ts -const oNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - transports: [http(), http()], - signer: privateKeyToAccount('0xSigner') -}) -``` - -Then you will have the `.buildComposable` method exposed on this account instance. This -will encode composable Instructions which can use advanced features like -[Runtime Parameter Injection](/multichain-orchestration/runtimeinjection) - -```ts -const instruction = await oNexus.buildComposable({ - type: '' // The type of helper you're using - data: {} // Type safe data for that type of helper -}) -``` - -Alternatively, if you only need to execute static `callData`, you can use the -`.build` helper or the `.buildComposable` helper with the type `rawCallData` - -```ts -const instruction = await oNexus.build({ - type: 'default', - data: { - calls: [{ - to: '0xTarget', - data: encodeFunctionData(...) // Here you can use any callData encoder - }], - chainId: optimism.id - } -}) -``` - -```ts -const instruction = await oNexus.buildComposable({ - type: 'rawCallData', - data: { - calls: [{ - to: '0xTarget', - data: encodeFunctionData(...) // Here you can use any callData encoder - }], - chainId: optimism.id - } -}) -``` - -:::warning[No Mixing] -Do NOT mix-and-match instructions built with `.build` with instructions built with -`.buildComposable` -::: - -Learn about how to use different types of helpers in their docs \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/instruction-builders/rawcalldata.mdx b/docs/pages/multichain-orchestration/instruction-builders/rawcalldata.mdx deleted file mode 100644 index 1469102..0000000 --- a/docs/pages/multichain-orchestration/instruction-builders/rawcalldata.mdx +++ /dev/null @@ -1,16 +0,0 @@ -# Raw CallData Builder -The raw calldata builder will execute the exact callData provided from the outside. This builder -is useful when working with already prepared callData. - -## Using Raw CallData Builder - -```ts -const instruction = await oNexus.buildComposable({ - type: 'rawCalldata', - data: { - calldata: '0xCallData', - chainId: , - to: '0xContractAddress', - } -}) -``` \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/overview.mdx b/docs/pages/multichain-orchestration/overview.mdx deleted file mode 100644 index 395a345..0000000 --- a/docs/pages/multichain-orchestration/overview.mdx +++ /dev/null @@ -1,154 +0,0 @@ -# Multichain Orchestration Overview - -### Limitations of EOAs & Bundlers -The EVM blockchain execution stack has been severely limited by the idea that -one user signature equals exactly one onchain function call. The most notable -example of this has been the notorious _approve + execute_ flow, which is a more -than familiar nuisance for all EVM users. - -While this basic case is slowly being resolved by the introduction of `batchExecute` -calls on smart accounts and standards like ERC-5792 or EIP-7702, modern blockchain -apps require much more complex actions than a simple batch of static function calls. - -### Blockchain is becoming multichain -With the proliferation of multiple EVM L2s/L3s and non-Ethereum L1s - modern apps work -in an environment where user accounts and balances, protocol contracts and liquidity -are spread across many independent blockchains. - -### Challenges of controling for dynamic runtime conditions -Additionally, the exact `callData` for all function calls is not always known ahead of -time, since it can be influenced by slippages incurred by swaps, bridges, intents -or by some other runtime conditions. - -### Biconomy MEE - The ultimate onchain execution stack -These, and many other challenges drove us to build the ultimate transaction execution -stack. Multi-chain native and fully composable (able to control for runtime conditions), -Biconomy orchestration is built to enable modern blockchain developers to build -fully chain abstracted experiences and one-click flows. - -## Why Multichain Orchestration? - -By using Biconomy multichain orchestration developers can get: - -- Single signature complex & multi-chain DeFi flows. -- Unified multi-chain user balances. -- Single signature onboarding to chains. -- Scheduled actions (e.g. dollar cost averaging). -- Comining multiple bridges/solvers or GMPs into a single execution flow. -- Cross-chain composability. - -## The Biconomy Multichain Orchestration Solution - -- **Single Signature, Multi-Chain Execution**
-The new Biconomy stack enables developers to encode complex multi-chain, -multi-transaction sequences which the user approves with a *single signature*.

- - -- **Standardized Stack & Comprehensive Coverage**
-The orchestration stack enables developers to use _any token_ and interact with -_any protocol_. The developers can use the _shortcuts_ available within the -AbstractJS SDK.

- - -- **Gas Abstracted**
-The user can pay for the execution of the entire sequence of operations with -native tokens or ERC20 tokens _on any chain_.

- -- **Asynchronous**
-The Biconomy orchestration stack can execute asynchronous actions, such as -triggering bridges, solvers, waiting for oracles, etc...

- -- **Composable**
-Biconomy orchestration is fully composable, meaning that you can _inject_ -the output of one function call into _any_ paramter of the next function call, -without writing smart contracts and even across multiple chains.

- -- **EOA & Smart Account Support**
-Multichain orchestration works nativelly for all accounts - both native EOAs, -smart accounts and EIP-7702 enabled EOAs.

- -- **Non-Custodial**
-The execution is fully trustless and non-custodial, with all premission validation done onchain -by validator contracts.

- -## Example - -:::tip[Example Case] - Imagine a user has 1000 USDC on Optimism, but wants to supply USDT to a lending - protocol on Base. Then they want to take the lending position and put it into - a yield booster. With the Biconomy orchestration stack, this can all be executed - by the user, from their EOA account, with a single signature. -::: - -:::info -Want to build this yourself? Check the [Orchestration QuickStart Guide](/multichain-orchestration/quickstart). -::: - -_How does it work?_ - -::::steps -#### Encode all Orchestration Instructions -The developer uses the Biconomy AbstractJS SDK or our API to encode all of the -instructions needed to achieve the desired action. In this case, they would include: - -:::steps -#### Move Funds Cross-Chain -Using a bridge or a solver to move the USDC from Optimism to Base - -#### Swap -Swapping the _exact_ amount of USDC which was received from the bridge -to USDT by using Uniswap on Base - -#### Supply -Supplying the _exact_ amount of USDT received from Uniswap to a lending protocol -on Base - -#### Boost Yield -Taking the _exact_ amount of "lending position" tokens and supplying them to -a yield booster protocol on Base. -::: - -#### Get a Quote for Execution from the Modular Execution Environment -The set of nodes which execute the orchestration steps are called the -"Modular Execution Environment" or "MEE" for short. The developer sends -the request for orchestration to MEE and gets back a _quote_ on the total -price of execution for all steps. - -Along with the price, the node will return the _hash_ of the instructions being -executed. This hash is generated by building a Merkle Tree from the instructions -data - the hash is the Root Hash of the Merkle Tree. - -This data structure is called a **Supertransaction**. - -#### Approve the Orchestrator Smart Account to Spend USDC from the EOA -The user signs the transaction which will _approve_ the orchestration -smart account to spend 999 USDC from their EOA. The app prompts the wallet -for the user to sign the transaction and posts the transaction onchain. This -is the only signature that the user needs to do. - -This transaction is a mostly _normal_ EVM `approve` call, save -for the fact that, while encoding the transaction, the developer needs to -_append_ the hash of the orchestration instructions after the useful -callData of the EVM function call. When using the Biconomy _AbstractJS_ SDK, -this is encoded automatically. - -This means that, in a single signature, the user is permitting both the transfer -of USDC to the orchestrator smart account _and_ all of the additional instructions. - -#### Send Instructions & Tx Hash to the Relayer Node -Call the `/execute` endpoint of the MEE Node (done automatically by -the AbstractJS SDK) and provide it with the Tx Hash of the trigger transaction. -This will start the orchestration procedure. - -#### Wait for Completion -Usually, the last step of the orchestration is to send _all_ of the funds which -the user received back to the EOA which triggered the orchestration (but potentially -on a different chain). This means that the existence of the orchestration smart -account can be completely hidden from the user in the UI. - -All the user knows is that they used their EOA to sign a _single_ transaction, -which then triggered a complex multichain sequence which resulted in some other -desired token on their EOA. - -:::: - diff --git a/docs/pages/multichain-orchestration/quickstart.mdx b/docs/pages/multichain-orchestration/quickstart.mdx deleted file mode 100644 index 92c0c19..0000000 --- a/docs/pages/multichain-orchestration/quickstart.mdx +++ /dev/null @@ -1,264 +0,0 @@ -# QuickStart: Asynchronous Composable Orchestration -This will be a short, zero-to-hero guide for building an orchestration flow. It will -demonstrate the following features of the Biconomy stack:

-- **Orchestration**
-The ability for the Biconomy stack to properly sequence multiple transactions across one or -more chains.

-- **Single-Signature Executeion**
-The ability to execute multiple transactions across multiple chains with a single -user signature.

-- **Application-Layer Composability**
-The ability to use the output or a state-change of one onchain function call as the -input for the next one. For example, using the *exact* amount received from a DEX at -runtime, as the input for the *supply* function of a lending platform in the next -step.

-- **Asynchronous Execution**
-The ability to wait for briges, solver or any other asynchronous actions to complete. -E.g. the transaction on Optimism cannot continue until tokens have been bridged from -Base to Optimsim.

- -- **Multichain Gas Abstraction**
-With the Biconomy stack, you can pay for execution of transactions on _any_ chain -with ERC-20 tokens on any other chain. Additionally, when executing multiple transactions -across multiple chains - the user pays only one fee on only one chain. - -## Example Case -In this example case, we'll: -:::steps -#### Bridge -Call Across bridge to move USDC from Optimism to Base. -Function calls being executed: -- Call `approve` on USDC contract on Optimism (approve spend to Across) -- Call `depositV3` on Across Spoke Pool contract -#### Swap -Use the *exact* amount received from Across to swap to USDT on Base -- Call `approve` on USDC contract on Base (approve spend to Uniswap) -- Call `swap` on Uniswap on Base -::: - -:::tip[Simple Demo Case] -While bridge + swap is an interesting application of the Biconomy stack, the real -power comes in orchestrating multiple instructions - for example "swap on source chain, -bridge to destination, swap on destination, then supply to lending protocol". - -Read our comprehensive [Zero-to-Hero Guide](/multichain-orchestration/comprehensive) to -learn how to execute more complex transaction sequences. -::: - -## Prerequisites - -- Node.js installed -- Private key for testing (never use production keys in test code) -- Some USDC on Optimism in your account - -::::steps -#### Setup - -First, install the required packages: - -```bash -npm install @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -Create a new file and add the basic imports: - -```javascript -import { - createMeeClient, - toMultichainNexusAccount, - runtimeERC20BalanceOf, - greaterThanOrEqualTo, - mcUSDC, - mcUSDT -} from "@biconomy/abstractjs"; -import { http, parseUnits, encodeFunctionData, erc20Abi } from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { optimism, base } from "viem/chains"; -``` - -#### Initialize Smart Account - -Set up a multichain smart account on both Optimism and Base: - -```javascript -// Set up account (use environment variables in production) -const eoa = privateKeyToAccount("0x...your_private_key..."); - -// Create multichain smart account -const smartAccount = await toMultichainNexusAccount({ - signer: eoa, - chains: [optimism, base], - transports: [http(), http()] -}); - -// Initialize the orchestration client -const meeClient = await createMeeClient({ - account: smartAccount -}); - -console.log("Smart account address on Optimism:", smartAccount.addressOn(optimism.id)); -console.log("Smart account address on Base:", smartAccount.addressOn(base.id)); -``` - -#### Important: Fund the Account -This example is using _Smart Account_ based orchestration. In order for smart account based orchestration -to work, you need to put funds into the smart account. - -:::info[Note] -The Biconomy stack supports orchestration from Native EOAs as well. -Read the [Native EOA Guide](/multichain-orchestration/eoa). -::: - -#### Define Bridge Instruction - -```javascript -// Import the Across bridge helper function -import { prepareAcrossBridgeTransaction } from "./across-encoder"; - -// Define the amount to bridge -const amountToBridge = parseUnits("5", 6); // 5 USDC - - -// Build the bridge instruction -const bridgeInstruction = await smartAccount.buildComposable({ - type: "default", - data: // Encode call to bridge instructions here -}); -``` - -#### Define Runtime Value Injection - -Runtime value injection allows function parameters to be determined at execution time rather than when creating the transaction. This is essential for cross-chain operations where exact amounts can't be known in advance due to bridge fees, slippage, or other factors. - -When using `runtimeERC20BalanceOf`, the system will: -1. Read the actual token balance at execution time -2. Inject this value into the function parameters -3. Apply any constraints to ensure sufficient value - -```javascript -// Define execution constraints (minimum amount to accept from bridge) -const executionConstraints = [ - greaterThanOrEqualTo((amountToBridge * 90n) / 100n) // Accept 10% slippage -]; - -// Approve USDC spend to Uniswap on Base using the approve instruction builder -const approveUsdcToUniswap = await smartAccount.buildComposable({ - type: "approve", - data: { - chainId: base.id, - tokenAddress: mcUSDC.addressOn(base.id), - spender: uniswapRouter, - // Use the exact amount received from the bridge - amount: runtimeERC20BalanceOf({ - targetAddress: smartAccount.addressOn(base.id), - tokenAddress: mcUSDC.addressOn(base.id), - constraints: executionConstraints - }) - } -}); -``` - -#### Define Swap Instruction - -```javascript -import { parseAbi } from 'viem' - -const uniswapRouterAbi = parseAbi([ - "function exactInputSingle((address tokenIn, address tokenOut, uint24 fee, address recipient, uint256 amountIn, uint256 amountOutMinimum, uint160 sqrtPriceLimitX96)) returns (uint256 amountOut)" -]); - -// Uniswap router address on Base -const uniswapRouter = "0x2626664c2603336E57B271c5C0b26F421741e481"; - -// Execute swap on Uniswap -const swapOnUniswap = await smartAccount.buildComposable({ - type: "default", - data: { - chainId: base.id, - abi: uniswapRouterAbi, - to: uniswapRouter, - functionName: "exactInputSingle", - args: [{ - tokenIn: mcUSDC.addressOn(base.id), - tokenOut: mcUSDT.addressOn(base.id), - fee: 500, // 0.05% fee tier - recipient: smartAccount.addressOn(base.id), - // Use the exact amount of USDC received from the bridge - amountIn: runtimeERC20BalanceOf({ - targetAddress: smartAccount.addressOn(base.id), - tokenAddress: mcUSDC.addressOn(base.id), - constraints: executionConstraints - }), - amountOutMinimum: 0n, // For demo purposes, set proper slippage in production - sqrtPriceLimitX96: 0n // No price limit - }] - } -}); -``` - -#### Execute the Orchestration - -```javascript -// Execute the orchestration sequence -const { hash } = await meeClient.execute({ - // Pay for execution with USDC on Optimism - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - }, - // The sequence of instructions to execute - instructions: [ - bridgeInstruction, - approveUsdcToUniswap, - swapOnUniswap - ] -}); - -console.log(`Orchestration started: ${hash}`); - -``` - -#### Wait for Execution Result - -```ts -// Wait for the entire orchestration to complete -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -console.log("Orchestration completed successfully!"); - -``` - -:::: - -## How It Works - -1. **Smart Account Initialization**:
-We create a multichain smart account that can operate on both Optimism and Base. - -2. **Bridge Execution**: - - The bridge instruction runs on Optimism - - It approves USDC spending and calls Across bridge - -3. **Asynchronous Waiting**: - - After the bridge instruction completes, the system automatically waits for funds to arrive on Base - - No manual monitoring or intervention required - -4. **Runtime Value Injection**: - - When funds arrive on Base, the exact received amount is automatically injected into the next instructions - - The `runtimeERC20BalanceOf` function reads the actual token balance at execution time - - This handles any slippage from the bridge operation - -5. **Constraint Enforcement**: - - The execution constraints ensure the swap only proceeds if a minimum amount was received - - If less than 90% of the expected amount arrives, the swap won't execute - -6. **Swap Execution**: - - Once sufficient funds are available on Base, the USDC is approved for Uniswap - - The swap executes using exactly the amount received from the bridge - -## Key Points - -- The entire orchestration is executed with a single signature from the smart account -- No need to manually monitor bridge status or handle cross-chain coordination -- Runtime values automatically adapt to actual on-chain conditions -- Execution constraints provide safety guardrails for the operation -- The orchestration handles the asynchronous nature of bridges transparently \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/runtimeinjection.mdx b/docs/pages/multichain-orchestration/runtimeinjection.mdx deleted file mode 100644 index 03fff2e..0000000 --- a/docs/pages/multichain-orchestration/runtimeinjection.mdx +++ /dev/null @@ -1,231 +0,0 @@ -## Overview - -When building multi-step transactions, especially across chains, you often need to use values that: -- Result from previous operations -- Change based on market conditions -- Depend on the exact amount received from bridges or swaps - -Runtime injection solves this by creating placeholders that get filled with actual values during execution. - -## Support - -You can use runtime value injection in _most_ Instruction builders. If the parameter accepts the -`RuntimeValue` type, you can use them. - -## Limitations - -- Runtime values can only be used within parameters, not to determine which functions to call -- All constraints must be satisfied or the instruction will not execute -- Runtime values can't reference external APIs or off-chain data - -Runtime parameter injection allows function call parameters to be determined at execution time rather than when the transaction is created. This is crucial for cross-chain operations where exact token amounts can't be known in advance. - - -## Basic Usage - -```javascript -import { runtimeERC20BalanceOf, greaterThanOrEqualTo } from "@biconomy/abstractjs"; - -// Use the exact token balance at execution time -const swapInstruction = await oNexus.buildComposable({ - type: "default", - data: { - // ...other parameters - args: [{ - amountIn: runtimeERC20BalanceOf({ - tokenAddress: "0xTokenAddress", - targetAddress: nexusAddress, - constraints: [greaterThanOrEqualTo(minAmount)] - }), - // Other arguments... - }] - } -}); -``` - -## Available Runtime Functions - -| Function | Purpose | -|----------|---------| -| `runtimeERC20BalanceOf` | Injects the balance of an ERC20 token at execution time | -| `runtimeEncodeAbiParameters` | Builds a `bytes` object, encoding several runtime and/or static params together. | - -### runtimeERC20BalanceOf -This method allows injecting the ERC20 token balance of a given address as argument. -This is useful to transfer the all the tokens of a given account w/o even knowing the amount of those tokens. -#### Example usage -
- -``` -const instructions: Instruction[] = await mcNexus.buildComposable({ - type: "default", - data: { - to: testnetMcUSDC.addressOn(chain.id), - abi: erc20Abi, - functionName: "transfer", - args: [ - b0b, - runtimeERC20BalanceOf({ - targetAddress: a11ce, - tokenAddress: testnetMcUSDC.addressOn(chain.id) - }) - ], - chainId: chain.id - } - }) -``` -This example transfers the amount equal to b0b's USDC balance to a11ce. -
- -### runtimeEncodeAbiParameters -This function is useful, when some method requires an arg which is `bytes`, that is built out of several elements abi.encoded together. -This function allows those elements to be runtime injected into the ABI encoding. It can be useful for methods similar to [Uniswap Router's `execute`](https://docs.uniswap.org/contracts/universal-router/technical-reference#command-inputs) method. -#### Example usage -
- -``` -const instructions: Instruction[] = await mcNexus.buildComposable({ - type: "default", - data: { - to: fooContractAddress, - abi: FOO_CONTRACT_ABI as Abi, - functionName: "foo", - args: [ - bar, - baz, - // qux - runtimeEncodeAbiParameters( - [ - { name: "x", type: "uint256" }, - { name: "y", type: "uint256" }, - { name: "z", type: "bool" } - ], - [ - 420n, - runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chain.id, true), - tokenAddress: testnetMcUSDC.addressOn(chain.id), - constraints: [] - }), - true - ] - ), - corge, - waldo - ], - chainId: chain.id - } - }) -``` -In this example `qux` argument is expected to be `abi.encode(x,y,z)` and we inject the runtime value as the `y` argument, - -
- - -:::info -The composability stack is _general purpose_, which means you can inject the output of _any_ function -call, not only `balanceOf`. The `runtimeERC20BalanceOf` is a helper function which helps to inject the -balance of some ERC20 token, which is the most common case. The _AbstractJS_ SDK will be expended with more -helper functions, which will be documented in the table above. -::: - -## Constraints - -Constraints define conditions that must be met for execution to proceed. They serve several critical purposes in cross-chain orchestration: - -### Handling Slippage - -When bridging or swapping tokens, you never receive exactly the amount you expect due to fees, price movements, and slippage. Constraints ensure operations only proceed when acceptable amounts are received: - -```javascript -// Only proceed if at least 90% of expected amount received (10% max slippage) -const constraints = [ - greaterThanOrEqualTo((expectedAmount * 90n) / 100n) -]; -``` - -### Enforcing Transaction Sequencing - -Constraints create implicit dependencies between instructions. For example, a swap on the destination chain won't execute until sufficient tokens have arrived from the bridge, creating a natural sequence: - -```javascript -// This instruction will wait until the bridged amount has arrived -// and only execute if the minimum amount constraint is satisfied -const swapAfterBridge = await oNexus.buildComposable({ - // ... - args: [{ - amountIn: runtimeERC20BalanceOf({ - tokenAddress: usdcOnOptimism, - targetAddress: nexusAddress, - constraints: [greaterThanOrEqualTo(minAmount)] - }) - }] -}); -``` - -### Protecting User Assets - -Constraints act as safety mechanisms, preventing transactions from executing under unfavorable conditions. If bridge slippage is too high or an exchange rate becomes unfavorable, the constraint will prevent execution rather than proceeding with suboptimal parameters. - -## Cross-Chain Example - -This example bridges tokens from Base to Optimism, then swaps the exact received amount: - -```javascript -// Bridge USDC from Base to Optimism -const bridgeInstruction = await oNexus.buildComposable({ - // Bridge configuration... -}); - -// Swap on Optimism using whatever amount was received -const swapInstruction = await oNexus.buildComposable({ - type: "default", - data: { - chainId: optimism.id, - // ...swap configuration - args: [{ - amountIn: runtimeERC20BalanceOf({ - tokenAddress: usdcOnOptimism, - targetAddress: nexusOnOptimism, - constraints: [greaterThanOrEqualTo(minAmountToAccept)] - }), - // Other swap parameters... - }] - } -}); -``` - -## Best Practices - -1. **Add Constraints**: Always use constraints to handle minimum acceptable values -2. **Use for Uncertain Amounts**: Apply runtime injection when amounts depend on external factors -3. **Combine with Transfer**: Use with the transfer instruction to return all tokens to the user -4. **Error Handling**: Plan for constraint failures by providing alternative paths - -## How Runtime Injection Works - -Runtime parameter injection is built on Biconomy's Composability Stack, which uses smart account fallback handlers to dynamically modify transactions during execution. - -### Architecture Overview - -When you use `runtimeERC20BalanceOf` in your code: - -1. The function call is encoded as a special "composable execution" call -2. The smart account's fallback handler intercepts this transaction -3. At execution time, the handler: - - Reads the current token balance from the blockchain - - Injects this value into the transaction parameters - - Forwards the modified transaction to the target contract - -This architecture eliminates the need to write custom smart contracts for basic composability patterns like using token balances or handling cross-chain values. - -![ComposerFallbackHandler](https://i.imgur.com/zESn9BO.png) - -### Under The Hood - -The fallback handler calls the `executeComposable` function with parameters that determine: -- Which values to read from the blockchain -- Where to inject these values in the function call -- How to handle return values - -This all happens transparently when you use the AbstractJS SDK, letting you focus on building your application logic rather than transaction composition mechanics. \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/sca.mdx b/docs/pages/multichain-orchestration/sca.mdx deleted file mode 100644 index ad4c1b3..0000000 --- a/docs/pages/multichain-orchestration/sca.mdx +++ /dev/null @@ -1,171 +0,0 @@ -# Orchestration with Smart Accounts -Executing orchestration flows with smart accounts is the most powerful way of -leveraging the orchestration flows. This means that the user funds are already -in the Nexus _multichain smart account_ before starting orchestration. - -### Key Benefits of Smart Account Based Orchestration - -- **Chain Abstraction / Unified Balances**
-Since the orchestration validator has access to an instance of a smart account -across multiple chains, it's able to trigger multiple chains at once to bridge -one or more tokens to a desired destination chain.

- -- **Multi-Chain Gas**
-When using smart account based orchestration, users can pay for execution with -native tokens or ERC20 tokens across any supported chain.

- -### Key Drawbacks of Smart Account Based Orchestration - -- **Depositing Assets**
-The users must deposit the assets into the Smart Account before using it. For users -who come from EOA wallets, this creates additional onboarding friction.

- -- **Fragmenting Liquidity**
-Unlike EOAs, Smart Accounts are not portable and users can have multiple Smart Account -addresses across multiple apps. This means that the user balances get fragmented easily -as they interact with more apps.

- -:::tip[Using EOA Based Orchestration] -The Biconomy stack supports orchestration from both Smart Accounts and EOAs. Read the -EOA Orchestration Guide to use the EOA based system. -::: - -## Guide - -In order to run multi-chain orchestration, you need to execute the following -steps: - -:::steps -#### Initialize the multichain (or single chain) smart account -Create an instance of the `MultichainSmartAccount` object in your -code. You can do this by calling the `toMultichainNexusAccount` function. - -```ts -const oNexus = await toMultichainNexusAccount({ - signer: eoa, - chains: [optimism, base], - transports: [http(), http()] -}); -``` -#### Create a connection to the Modular Execution Environment (MEE) -Initialize an `MEE Client` which will create the connection to an -MEE Node. The default connection is to the [Biconomy Network](https://blog.biconomy.io/launching-biconomy-network-the-application-layer-to-make-a-thousand-chains-feel-like-one-2/). - -```ts -const meeClient = await createMeeClient({ account: oNexus }); -``` - -#### Encode the orchestration instructions -The instructions are an array of EVM `[to, value, data]` tuples. For this -example, we'll just encode empty calls to `0x0000...` - -```ts -const optimismCall = await oNexus.build({ - type: "default", - data: { - chainId: optimism.id, - calls: [{ to: zeroAddress, value: 0n, data: "0x" }], - }, -}); - -const baseCall = await oNexus.build({ - type: "default", - data: { - chainId: base.id, - calls: [{ to: zeroAddress, value: 0n, data: "0x" }], - }, -}); -``` - -#### Choose how you want to pay for the orchestration fee -One of the key features of the Biconomy stack is the ability to pay for the -execution of all instructions across all chains with a single token on a -single chain. - -Simply put the token address (or `0x0000...`) for native token and the -chainId. - -```ts -const feeToken = { - address: zeroAddress, - chainId: optimism.id -} -``` - -#### Get the execution quote -Call the `getQuote` function which will send your instructions to the -modular execution environment. The reponse will contain two crucial -pieces of info - quoted fee for the orchestration and the hash of -all the instructions. - -```ts -const quote = await meeClient.getQuote({ - feeToken: { address: zeroAddress, chainId: optimism.id }, - instructions: [optimismCall, baseCall], -}) -``` - -#### Accept the quoted execution fee and execute -If you're okay with the quoted execution cost, you can call `executeQuote` -which will get the user to sign the execution and start executing the -flow: - -```ts -const { hash } = await meeClient.executeQuote({ - quote -}) -``` -::: - - -## Code Example - -```ts -import { - createMeeClient, - toMultichainNexusAccount -} from "@biconomy/abstractjs"; -import { http, zeroAddress } from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { base, optimism } from "viem/chains"; - -const main = async () => { - // Setup EOA and Nexus account - const eoa = privateKeyToAccount("0x3e478f4e7c4be62e616d4b347de5431a4a6774899db4a72702b58e0cb92a1e00"); - const oNexus = await toMultichainNexusAccount({ - signer: eoa, - chains: [optimism, base], - transports: [http(), http()] - }); - const meeClient = await createMeeClient({ account: oNexus }); - - // Create empty calls on each chain - const optimismCall = await oNexus.build({ - type: "default", - data: { - chainId: optimism.id, - calls: [{ to: zeroAddress, value: 0n, data: "0x" }], - }, - }); - - const baseCall = await oNexus.build({ - type: "default", - data: { - chainId: base.id, - calls: [{ to: zeroAddress, value: 0n, data: "0x" }], - }, - }); - - // Execute both calls (pays fees with ETH on Optimism) - const { hash } = await meeClient.execute({ - feeToken: { address: zeroAddress, chainId: optimism.id }, - instructions: [optimismCall, baseCall], - }); - - // Wait for completion - const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - console.log(`Completed: ${hash}`); -}; - -main().catch(console.error); -``` \ No newline at end of file diff --git a/docs/pages/multichain-orchestration/supertransaction.mdx b/docs/pages/multichain-orchestration/supertransaction.mdx deleted file mode 100644 index e69de29..0000000 diff --git a/docs/pages/multichain-orchestration/zerotohero.mdx b/docs/pages/multichain-orchestration/zerotohero.mdx deleted file mode 100644 index 24d1f0c..0000000 --- a/docs/pages/multichain-orchestration/zerotohero.mdx +++ /dev/null @@ -1,771 +0,0 @@ -# LLM Prompt - -Use this prompt in an LLM to start working with Biconomy. - -```ts -import { - AavePoolAbi, - acrossEncodeBridgingUserOp, - buildBridgeInstructions, - createMeeClient, - getFusionQuote, - getUnifiedERC20Balance, - greaterThanOrEqualTo, - mcAaveV3Pool, - mcAUSDC, - mcUniswapSwapRouter, - mcUSDC, - mcUSDT, - runtimeERC20BalanceOf, - toFeeToken, - toMultichainNexusAccount, - UniswapSwapRouterAbi, - type Instruction, - type Trigger, -} from "@biconomy/abstractjs"; -import { - concatHex, - encodeAbiParameters, - encodeFunctionData, - erc20Abi, - http, - parseEther, - parseUnits, - zeroAddress, - type Chain, -} from "viem"; -import { privateKeyToAccount } from "viem/accounts"; -import { arbitrum, base, optimism, otimDevnet, polygon } from "viem/chains"; -import { prepareAcrossBridgeTransaction } from "./across-encoder"; - -import { createInterface } from "readline"; -import { resolve } from "path"; -import { waitForTransactionReceipt } from "viem/actions"; - -// Generate an address from a Private Key -const eoa = privateKeyToAccount( - "0x3e478f4e7c4be62e616d4b347de5431a4a6774899db4a72702b58e0cb92a1e00" -); - -const aUSDTOptimismAddress = "0x6ab707Aca953eDAeFBc4fD23bA73294241490620"; -const usdtOnOptimism = "0x94b008aA00579c1307B0EF2c499aD98a8ce58e58"; - -const rl = createInterface({ - input: process.stdin, - output: process.stdout, -}); - -// rl.question( -// ` -// Select flow: -// 1. Execute multichain orchestration -// 2. Return funds to EOA on Base -// `, -// async (answer) => { -// if (answer === "1") { -// await main(); -// } else if (answer === "2") { -// await sendBackToEOA(); -// } -// resolve(answer); -// } -// ); - -/* This is a quickstart project, showing developers how to use the - * AbstractJS SDK and a Modular Execution Environment (Biconomy Network) - * to create a seamless multi-chain, multi-transaction flow which the user - * approves with just a single signature! - * - * This flow will: - * - * 1. Transfer the user funds from their EOA to an Orchestrator Nexus Smart Account - * - * 2. Approve the bridging contract on Base (the source chain) - * - * 3. Call the bridging contract on Base (the source chain) - * - * 4. Wait for the funds to arrive on Optimism (the destination chain) - * - * 5. Call a Swap on the Uniswap instance of the destination chain, swapping - * from USDC to USDT. - * - * Note: The call to the Uniswap Swap function will leverage the Biconomy - * Composability Stack - which means that the developer will not provide - * a hardcoded value of how much will be swapped (e.g. swapping 10 USDC). - * Since the developer can't know *exactly* how much they'll receive from - * the bridge they've used - they need to encode the _runtime balance_ of - * whichever token they're using. AbstractJS SDK and the Biconomy Composability - * stack make this effortless. - * - * 6. Call the supply function on the AAVE contract on the destination chain. - * Again, by leveraging the Composability stack, we'll inject the exact amount - * which was received from the swap on Uniswap - into the "amount" field of the - * AAVE _supply_ function. - * - * 7. Transfer all of the resulting aUSDT tokens back to the EOA of the user. By doing - * this as the last step, the user will have the experience of providing USDC from - * their EOA on Base and receiving aUSDT (an AAVE position) on Optimism - all from - * their EOA and in a single signature. - * - * Note: The Fusion Execution by Biconomy - enables all EOA accounts to get many smart - * account features. - */ -const main = async () => { - // Log the address to the console. Useful for loading up tokens. - console.log(`EOA Address: ${eoa.address}`); - - /* Instantiate the Nexus account on all the chains where need to orchestrate - * the transaction sequence. - * - * Few notes: - * 1. This account is invisible to the users: Since we'll be using the Biconomy - * Fusion execution mode. This account will not be directly accessed by the - * users. Instead, it will be used as a passthrough account - which orchestrates - * the transaction sequence and then returns all resulting funds back to - * EOA address, once everything is done. - * - * 2. This will not initialize the account. The SDK uses a lazy initialization - * where the account initialization and the userful transaction are done - * atomically. - */ - const oNexus = await toMultichainNexusAccount({ - signer: eoa, - chains: [base, optimism, arbitrum, polygon], - transports: [http(), http(), http(), http()], - }); - - /* This is the address of the orchestrator Nexus account. While this account - * is invisible to the user, it's useful to have it availble as we'll - * pass the address of this account to all the function calls - */ - console.log("Orchestrator Account address:", oNexus.addressOn(base.id)); - - /* Here we are instantiating the MEE Orchestration client. This is setting - * up the connection with the Biconomy Network and its associated Modular - * Execution Environment. - */ - const meeClient = await createMeeClient({ - account: oNexus, - }); - - /* The amount of funds we'll use for this orchestration process - * Hardcoded in this example, but can be done better by fetching the balance of - * USDC on Base. - */ - const amountConsumed = parseUnits("2.5", 6); - - /* The transaction which will *trigger* the orchestration! This transaction is a - * transfer of USDC from your EOA to the Orchestrator Smart Account. - * However, instead of being a regular ERC20 Transfer transaction, this transaction - * has the hash of all the instructions needed for the orchestration appended - * to it! - * - * This is done in two ways (handled automatically by the SDK): - * - * 1. If the token being transferred supports ERC20Permit - then the transaction - * can be gasless. Our SDK will encode a signature to approve the Orchestrator - * account to spend the specified amount of funds from the EOA. The hash of - * orchestration instructions will be encoded in the last field of the ERC20Permit - * signature. - * - * 2. If the token doesn't support ERC20Permit, then the SDK will encode an `approve` - * transaction call for the specified token. This will allow the Orchestrator to - * spend the specified amount of tokens, but will not be gasless. The user will - * have to have some native token (to cover the cost of this transfer). For all the - * other instructions, gas can be abstracted away. In this case, the hash of the - * orchestration instructions is appended after the useful callData in the - * transaction. - * - * By signing the transaction or the ERC20Permit, the user is approving both the - * transfer from the EOA to the Orchestrator Smart Account *and* all the additional - * instructions. All validation for this is done onchain! - */ - const transferToNexusTrigger: Trigger = { - tokenAddress: mcUSDC.addressOn(base.id), - amount: amountConsumed, - chainId: base.id, - }; - - /* ---------------------------------------------------------------------- - * Encoding instructions: Here we will start encoding the orchestration - * instructions. At the end we will push all of the encoded orchestration - * steps into the meeClient and execute the Orchestration on the Biconomy - * Network! - * ------------------------------------------------------------------------ - */ - - /* Biconomy Network orchestration works with any bridge/solver/protocol - * which can be triggered by making an onchain function call. In this example - * we're encoding a call to a `depositV3` function on the Across Spoke Pool - * contract! You can check the full fucntion encoding in this project in the - * across encoder file. - */ - const callDepositAcrossSpokePool = await prepareAcrossBridgeTransaction({ - depositor: oNexus.addressOn(base.id, true), - recipient: oNexus.addressOn(optimism.id, true), - originChainId: base.id, - destinationChainId: optimism.id, - inputAmount: amountConsumed, - inputToken: mcUSDC.addressOn(base.id), - outputToken: mcUSDC.addressOn(optimism.id), - }); - - const acrossSpokePoolAddress = callDepositAcrossSpokePool.to; - - /* In order for the Across to be able to "pull" funds when we call the deposit - * function, we need to encode an approval for USDC (token we're using) to the - * Across Spoke Pool contract - */ - const approveUsdcSpendToAcross = { - to: mcUSDC.addressOn(base.id), - data: encodeFunctionData({ - abi: erc20Abi, - functionName: "approve", - args: [acrossSpokePoolAddress, amountConsumed], - }), - }; - - /* Here we're encoding our first instruction within the supertransaction. - * One instruction can include multiple function calls (on the same chain). - * Additionally, one Supertransaction can contain multiple Instructions. - * All of these function calls are executed with a single user signature - * and automatically orchestrated by the Biconomy Network. - * - * We're using the `.build` helper on the Nexus account object - * to help us encode these instructions. This one will encode an - * approve + execute flow for using Across to bridge USDC from Base to - * Optimism - */ - const bridgeUsdcFromBaseToOptimism = await oNexus.buildComposable({ - type: "default", - data: { - chainId: base.id, - calls: [approveUsdcSpendToAcross, callDepositAcrossSpokePool], - }, - }); - - /* The Biconomy orchestrator uses transaction simulations to decide - * when the next step of the orchestration can proceed. In order to - * prevent orchestration from beign executed before the funds - * arrive from the bridge, we can set execution contraints when - * using dynamic parameter injection (which will be explained in the next - * step). - * - * We simply set the minimal conditions which must be met for every step - * to proceed. In this case, we want to proceed when funds arrive from the - * bridge. We are allowing for a 5% slippage tolerance (very high, but this - * is a demo). - * - * This means that if we bridged 1000 USDC, when at least 950 has arrived - * to the destination chain, the execution will proceed. - * - * A lot of the times, you don't have to specify explicit constraints and the - * orchestration will be implicit. E.g. in the approve + execute flow, execute - * can't proceed before approve, since simulations for the execute step - * will fail until an approval has been granted. - * - * Constraints are primarily used in cases where you don't know the explict - * amount you'll receive and serve as useful metadata for the Orchestrator. - */ - const executionConstraints = [ - greaterThanOrEqualTo((amountConsumed * 80n) / 100n), - ]; - - /* The next instruction is an approval instruction on the destination chain. - * Since Biconomy is providing _asynchronous_ orchestration, this means our - * relayers (called ACOrN Nodes) are able to wait for bridging to finish - * before proceeding with the next instruction. - * - * For this instruction, we're using the helper of type 'approve'. For developer - * convenience, we've encoded helpers for common function calls, such as ERC20 - * transfer, ERC20 approve, etc... - */ - const approveUniswapToSpendUSDC = await oNexus.buildComposable({ - type: "approve", - data: { - chainId: optimism.id, - tokenAddress: mcUSDC.addressOn(optimism.id), - spender: mcUniswapSwapRouter.addressOn(optimism.id), - - /* This is the first usage of the Composability stack in this - * code example. You can note that in the previous parameters, - * we've used exact values, while here we're injecting - * the runtime balance of an ERC20 token (in this case, USDC). - * - * Why is this important? Since, in a previous step, we've used a - * bridge to get the assets on the destination chain - we can't know - * for sure exactly how much we've received. This is because every - * bridge incurrs a slippage and the exact values are unknown until - * runtime. - * - * This is where the Biconomy Composability Stack comes into play. You - * will notice that many parameters in function calls support a RuntimeValue - * type! This means that we can tell the orchestrator to inject the - * exact value which is available on the account currently at runtime - * into the `amount` field of the `approve` function call. - * - * This will approve the *exact* amount received from the bridge to - * the uniswap router contract! - */ - amount: runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(optimism.id, true), - tokenAddress: mcUSDC.addressOn(optimism.id), - constraints: executionConstraints, - }), - }, - }); - - /* Here, we are again executing a composable function call! - * The core difference is that now we're not using the helper, - * but are actually using the default 'composable' type which can - * accept _any_ ABI! Here we're passing it the UniswapSwapRouterAbi - * and the address of the Uniswap router on Optimism. This Abi, as - * well as the address of the Uniswap router - has been exposed - * by AbstractJS as a convenience. You can always create your own - * contracts and use your own ABIs! - */ - const swapUSDCtoUSDTOnUniswap = await oNexus.buildComposable({ - type: "composable", - - data: { - chainId: optimism.id, - abi: UniswapSwapRouterAbi, - to: mcUniswapSwapRouter.addressOn(optimism.id), - functionName: "exactInputSingle", - args: [ - { - tokenIn: mcUSDC.addressOn(optimism.id), // Swap From USDC - - // Take the exact balance of USDC and input that into `amountIn` - // on Uniswap, again using the composability stack just as in the - // last instruction. - amountIn: runtimeERC20BalanceOf({ - tokenAddress: mcUSDC.addressOn(optimism.id), - targetAddress: oNexus.addressOn(optimism.id, true), - constraints: executionConstraints, - }), - - tokenOut: usdtOnOptimism, // Swap into USDT - recipient: oNexus.addressOn(optimism.id, true), - - amountOutMinimum: 0n, // Accept any slippage on pool (for demo purposes) - fee: 100, // Pay 0.01% Fee - sqrtPriceLimitX96: 0n, - }, - ], - }, - }); - - const approveAAVEtoSpendUSDT = await oNexus.buildComposable({ - type: "approve", - data: { - chainId: optimism.id, - tokenAddress: usdtOnOptimism, - spender: mcAaveV3Pool.addressOn(optimism.id), - amount: runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(optimism.id)!, - tokenAddress: mcUSDT.addressOn(optimism.id), - - /* Note: Usually, here we would have to set - * custom slippage contraints (since it's a new token after - * the swap), but we chose two stablecoins intentionally - * for this demo so we can reuse constraints! - */ - constraints: executionConstraints, - }), - }, - }); - - /* After approval is finished, we'll proceed to supply USDT - * to the AAVE contract on the destiantion chain! - */ - const supplyUsdtToAAVE = await oNexus.build({ - type: "composable", - data: { - abi: AavePoolAbi, - to: mcAaveV3Pool.addressOn(optimism.id), - chainId: optimism.id, - functionName: "supply", - args: [ - // Supply the USDT we received from the swap to - // AAVE on destination chain - mcUSDT.addressOn(optimism.id), - runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(optimism.id)!, - tokenAddress: usdtOnOptimism, - constraints: executionConstraints, - }), - - oNexus.addressOn(optimism.id), - 0, - ], - }, - }); - - /* After supplying to AAVE, the users will get the a{Token} which - * represents their position in the AAVE protocol. In our case this - * is the aUSDT token. This is the address of the token on - * Optimism - */ - const aUSDTOptimismAddress = "0x6ab707Aca953eDAeFBc4fD23bA73294241490620"; - - /* This instruction is using the `withdrawal` helper in the - * AbstractJS SDK and is encoding a call to transfer the `tokenAddress` - * token back to the `owner` EOA of the Nexus smart account. - * - * You can encode this action manually by simply calling the ERC20 - * transfer function directly, this is just used as a helper shorthand. - */ - const moveUSDTBackToEOA = await oNexus.build({ - type: "transfer", - data: { - amount: runtimeERC20BalanceOf({ - tokenAddress: aUSDTOptimismAddress, - targetAddress: oNexus.addressOn(optimism.id, true), - constraints: [greaterThanOrEqualTo(parseUnits("0.3", 1))], - }), - chainId: optimism.id, - recipient: eoa.address, - tokenAddress: aUSDTOptimismAddress, - }, - }); - - console.log("HERE"); - - const quote = await meeClient.getFusionQuote({ - trigger: transferToNexusTrigger, - feeToken: toFeeToken({ - chainId: base.id, - mcToken: mcUSDC, - }), - instructions: [ - bridgeUsdcFromBaseToOptimism, - approveUniswapToSpendUSDC, - swapUSDCtoUSDTOnUniswap, - approveAAVEtoSpendUSDT, - supplyUsdtToAAVE, - moveUSDTBackToEOA, - ], - }); - - console.log(`Got Quote: ${quote.quote.hash}`); - - console.log(`Execution cost: $${quote.quote.paymentInfo.tokenValue}`); - - rl.question("Do you wish to proceed? (Y/N) ", async (answer) => { - if (answer === "Y") { - const { hash } = await meeClient.executeFusionQuote({ - fusionQuote: quote, - }); - - console.log(`Started execution: ${hash}`); - - const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - - console.log(`Successful execution of Supertransaction: ${receipt}`); - } - rl.close(); - resolve(answer); - }); -}; - -const createNexusAndMeeClient = async (chains: Chain[]) => { - const oNexus = await toMultichainNexusAccount({ - chains: chains, - signer: eoa, - transports: chains.map((x) => http()), - }); - - const meeClient = await createMeeClient({ - account: oNexus, - }); - - return { - oNexus: oNexus, - meeClient: meeClient, - }; -}; - -/* Use this function to send funds back to EOA so you can reuse them - * for testing if they get stuck on the SCA! - */ -const sendBackToEOA = async () => { - const oNexus = await toMultichainNexusAccount({ - signer: eoa, - chains: [base, optimism, arbitrum, polygon], - transports: [http(), http(), http(), http()], - }); - - console.log("Orchestrator Account address:", oNexus.addressOn(base.id)); - - const meeClient = await createMeeClient({ - account: oNexus, - }); - - const balance = await getUnifiedERC20Balance({ - account: oNexus, - mcToken: mcUSDC, - }); - - const amountToReceive = - balance.breakdown.filter((chain) => chain.chainId).at(0)?.balance! - - parseUnits("0.5", 6); - - const bridgeAllToBase = await (async () => { - if (amountToReceive > parseUnits("3", 6)) { - return await oNexus.build({ - type: "intent", - data: { - toChain: base, - amount: amountToReceive, - mcToken: mcUSDC, - }, - }); - } else { - return []; - } - })(); - - const withdraw = await oNexus.build({ - type: "withdrawal", - data: { - amount: runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(base.id, true), - tokenAddress: mcUSDC.addressOn(base.id), - constraints: [greaterThanOrEqualTo(parseUnits("0.5", 6))], - }), - chainId: base.id, - tokenAddress: mcUSDC.addressOn(base.id), - }, - }); - - const { hash } = await meeClient.execute({ - feeToken: toFeeToken({ - chainId: optimism.id, - mcToken: mcUSDC, - }), - instructions: [bridgeAllToBase, withdraw], - }); - - console.log(`Returned funds to base: ${hash}`); -}; - -const sendETHToEOAOnBase = async () => { - const oNexus = await toMultichainNexusAccount({ - chains: [base, optimism], - signer: eoa, - transports: [http(), http()], - }); - - const meeClient = await createMeeClient({ - account: oNexus, - }); - - const transferToEOAETH: Instruction = { - calls: [ - { - to: eoa.address, - value: parseEther("0.00003"), - gasLimit: 100000n, - }, - ], - chainId: optimism.id, - }; - - const { hash } = await meeClient.execute({ - instructions: [transferToEOAETH], - feeToken: { - address: zeroAddress, - chainId: optimism.id, - }, - }); - - console.log(`Moved dust back to EOA: ${hash}`); -}; - -/* This is a demonstration of manually encoding a Fusion transaction. - * It serves to show how Fusion transactions work under the hood and will - * be useful for anyone when debugging as the flow here can be split into - * multiple distinct steps, which the executeFusion utility function abstracts - * away into a single call - */ -const unwindPosition = async () => { - - - const { oNexus, meeClient } = await createNexusAndMeeClient([ - optimism, - base, - arbitrum, - polygon, - ]); - - console.log(` - EOA Address: ${eoa.address}; - SCA Address: ${oNexus.addressOn(optimism.id)} - `); - - /* The amount of funds we'll be unwinding from the EOA! In a real - * scenario, you'd get these funds by calling some balanceOf or the - * amount of position. - */ - const amount = parseUnits("3", 6); - - /* Using the utility function to encode an "approve" call. Will execute this - * call on the EOA, this is why we're extracting the triggerCall from the returned - * object, as it contains the [to,value,data] tuple which we'll send to the - * wallet. - * - * Here, we're encoding an approval transaction, which approves the oNexus - * account to consume the aUSDT tokens on the users EOA. - */ - const [ - { - calls: [triggerCall], - }, - ] = await oNexus.build({ - type: "approve", - data: { - amount: amount, - chainId: optimism.id, - spender: oNexus.addressOn(optimism.id, true), - tokenAddress: aUSDTOptimismAddress, - }, - }); - - /* Here, we are encoding all the additional instructions which - * need to happen after the approval has been granted to the oNexus - * account. The first one is using `transferFrom` to move the tokens - * from the EOA to oNexus. Then we're calling a composable flow which - * will withdraw the aUSDT tokens from AAVE back into USDT! - * - * We could also put additional instructions there like we did in the - * other functions in this Quickstart guide, like an encoding for bridging, etc... - * - * IMPORTANT NOTE: - * This is a different type of Fusion transaction than the - * transaction in the other examples - due to the fact that we're using Fusion - * to transfer the aUSDT token - which the Biconomy MEE client _doesn't_ accept - * as a "fee token". So in order to ensure execution, the user should have - * some balance of any supported fee token on any chain - already on their - * oNexus account. - * - * Additionally, while the aUSDT token supports the ERC20Permit endpoint - */ - const instructionQuote = await meeClient.getQuote({ - feeToken: { - address: zeroAddress, - chainId: base.id, - }, - instructions: [ - oNexus.build({ - type: "transferFrom", - data: { - amount: amount, - chainId: optimism.id, - recipient: oNexus.addressOn(optimism.id, true), - sender: eoa.address, - tokenAddress: aUSDTOptimismAddress, - }, - }), - oNexus.build({ - type: "composable", - data: { - abi: AavePoolAbi, - to: mcAaveV3Pool.addressOn(optimism.id), - chainId: optimism.id, - functionName: "withdraw", - args: [ - usdtOnOptimism, - runtimeERC20BalanceOf({ - targetAddress: oNexus.addressOn(optimism.id, true), - tokenAddress: usdtOnOptimism, - }), - oNexus.addressOn(optimism.id, true), - ], - }, - }), - ], - }); - - - /* We trigger the Fusion transaction just like any other normal - * EVM transaction, by sending the [to, value, data] onchain. The difference - * here being that the additional instructions required for the Fusion transaction - * are appended to the data field. - */ - const walletClient = oNexus.deploymentOn(optimism.id, true).walletClient; - const call = { - ...triggerCall, - /* This is where we append the additional instructions for this - * type of Fusion transaction (ONCHAIN FUSION). Since Solidity - * contracts ignore all the data after what their ABI has provided - * them, we can safely pack additional metadata after it. - * - * We'll show later how this metadata is validated on the oNexus - * account. - */ - data: concatHex([triggerCall.data!, instructionQuote.hash]), - }; - - // @ts-ignore - const txHash = await walletClient.sendTransaction(call); - - /* We're sending the "approve spend for oNexus" transaction, along with - * the appended metadata to the chain! - */ - const { transactionHash } = await waitForTransactionReceipt(walletClient, { - hash: txHash, - confirmations: 1, - }); - - - console.log(`Transaction hash: ${transactionHash}`); - - /* Here, we are giving instructions to the MEE Node - * on how to fetch the valid signature that's posted - * onchain in the previous instruction (sendTransaction). - * - * You can see we're sending three pieces of info: - * - * 1. MAGIC PREFIX - this tells the MEE node what type of - * transaction this is and helps it do the right steps - * to validate it. It also serves as metadata for the - * smart contract which is validating the orchestration - * to know how to check that the contained instructions - * were infact approved by the user. - * - * 2. TX HASH & ChainID - this tells the MEE Node which transaction contains - * the signed payload. The MEE Node will fetch this transaction and use the - * payload to validate the orchestration instructions. This is because the - * transaction contains the metadata at the end of the data parameter. Since - * the entire transaction is signed, the metadata is signed implicitly together - * with the approve transaction. The MEE node can then use that to - * "prove" to the oNexus validator (on every chain) that the user actually - * approved certain instructions. - */ - const signature = concatHex([ - "0x177eee01", // PREFIX FOR ONCHAIN FUSION TX - encodeAbiParameters( - [{ type: "bytes32" }, { type: "uint256" }], - [txHash, BigInt(optimism.id)] - ), - ]); - - /* This is sending all the orchestration instructions, together with - * the signature with metadata - allowing the node to start orchestrating - * all the instructions as soon as the approve transaction is included onchain. - */ - const res = await meeClient.executeSignedQuote({ - signedQuote: { - ...instructionQuote, - signature: signature, - }, - }); - - console.log(`Executing unwind: ${res.hash}`); -}; - -// sendETHToEOAOnBase() -// main(); -// unwindPosition(); -``` \ No newline at end of file diff --git a/docs/pages/multichain-smart-sessions/grant.mdx b/docs/pages/multichain-smart-sessions/grant.mdx deleted file mode 100644 index 99efc16..0000000 --- a/docs/pages/multichain-smart-sessions/grant.mdx +++ /dev/null @@ -1,77 +0,0 @@ -# Granting Smart Sessions Permissions - -Grant specific permissions to validators across multiple chains using Smart Sessions. - -## Installation and Setup - -```typescript -import { - toSmartSessionsModule, - toNexusAccount, - createBicoBundlerClient, - getSudoPolicy -} from '@biconomy/abstractjs'; - -// Initialize your signer -const signer = yourSignerAccount; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer, - chain, - transport: http(rpcUrl) -}); - -// Create client with your Nexus account -const nexusClient = createBicoBundlerClient({ - chain, - transport: http(rpcUrl), - account: nexusAccount, -}); -``` - -## Install Smart Sessions Module - -First, you need to install the Smart Sessions module on your account: - -```typescript -const smartSessionsModule = toSmartSessionsModule({ signer }); - -// Install the module on the Nexus client's smart contract account -const hash = await nexusClient.installModule({ - module: smartSessionsModule -}); - -// Wait for the module installation transaction to be mined -const { success } = await nexusClient.waitForUserOperationReceipt({ hash }); -``` - -## Grant Permission Example - -Once the module is installed, you can grant permissions: - -```typescript -// Extend client with Smart Sessions actions -const smartSessionsClient = nexusClient.extend(smartSessionActions()); - -// Grant permission to a specific address (redeemer) -const sessionDetails = await smartSessionsClient.grantPermission({ - redeemer: redeemerAddress, // Address that will use the permission - actions: [ - { - actionTarget: targetContractAddress, // Target contract address - actionTargetSelector: "0x273ea3e3", // Function selector (e.g., increment()) - actionPolicies: [getSudoPolicy()] // getSpendingLimitsPolicy, getUsageLimitPolicy, getValueLimitPolicy - } - ] -}); - -// Save the sessionDetails for later use when redeeming the permission. -// Can be saved against a users smart account address on local storage or database -// for later redemption -console.log('Permission granted:', sessionDetails); -``` - -## Multi-chain Permission Usage - -Coming Soon \ No newline at end of file diff --git a/docs/pages/multichain-smart-sessions/overview.mdx b/docs/pages/multichain-smart-sessions/overview.mdx deleted file mode 100644 index 7f2aabf..0000000 --- a/docs/pages/multichain-smart-sessions/overview.mdx +++ /dev/null @@ -1,39 +0,0 @@ -# Smart Sessions Overview - -Smart Sessions allow users to delegate specific permissions to external validators, enabling controlled and secure access to your smart account's functionality. This feature now supports operations across multiple blockchain networks. - -## Key Concepts - -- **Permission Granting**: Account owners can grant specific permissions to other addresses (redeemers) -- **Permission Redemption**: Redeemers can execute transactions on behalf of the account owner within the scope of granted permissions -- **Action Targeting**: Permissions can be limited to specific contract addresses and function selectors -- **Policy Control**: Fine-grained control through action policies like `getSudoPolicy()`, `getTimeLockPolicy()`, `getSpendingLimitsPolicy()`, `getUsageLimitPolicy()`, `getValueLimitPolicy()` -- **Multi-chain Support**: Grant and redeem permissions across different blockchain networks - -## How It Works - -The Smart Sessions module follows a three-step process: - -1. **Installation**: The module is installed on your Nexus account -2. **Grant**: The account owner grants specific permissions to a redeemer address -3. **Redemption**: The redeemer uses the granted permissions to execute transactions - -## Technical Architecture - -Smart Sessions is implemented as a validator module within the ERC7579-compatible Nexus accounts. Key components include: - -- **Smart Sessions Module**: Created with `toSmartSessionsModule()` -- **Session Actions**: Extended functionality via `smartSessionActions()` -- **Session Management**: Methods for granting and using permissions -- **Emulated Accounts**: Allowing redeemers to act on behalf of the original account - -## Usage Modes - -When redeeming permissions, two modes are available: - -- `ENABLE_AND_USE`: Used for the first redemption of a permission -- `USE`: Used for subsequent redemptions of the same permission - -## Multi-chain Capabilities - -Coming Soon \ No newline at end of file diff --git a/docs/pages/multichain-smart-sessions/redeem.mdx b/docs/pages/multichain-smart-sessions/redeem.mdx deleted file mode 100644 index 255812c..0000000 --- a/docs/pages/multichain-smart-sessions/redeem.mdx +++ /dev/null @@ -1,91 +0,0 @@ -# Redeeming Smart Sessions Permissions - -After permissions have been granted, validators can redeem them to execute transactions across multiple chains. - -## Setup for Permission Redemption - -```typescript -import { - toNexusAccount, - createBicoBundlerClient, - smartSessionActions -} from '@biconomy/abstractjs'; -import { http } from 'viem'; - -// Initialize the redeemer's account -const redeemerAccount = yourRedeemerAccount; // The account that received permission - -// Create a Nexus account pointing to the original account address -const emulatedAccount = await toNexusAccount({ - accountAddress: nexusAccount.address, // The address that granted the permission - signer: redeemerAccount, - chain, - transport: http(rpcUrl) -}); - -// Create a client for the emulated account -const emulatedClient = createBicoBundlerClient({ - account: emulatedAccount, - transport: http(bundlerUrl), - mock: true // Set to false in production -}); - -// Extend the client with Smart Sessions actions -const smartSessionsClient = emulatedClient.extend(smartSessionActions()); -``` - -## Using a Permission - -```typescript -// Use the permission with the sessionDetails received during grant -const userOpHash = await smartSessionsClient.usePermission({ - sessionDetails, // The session details object returned from grantPermission - calls: [ - { - to: targetContractAddress, // The target contract address - data: "0x273ea3e3" // The function selector (e.g., increment()) - } - ], - mode: "ENABLE_AND_USE" // Use "ENABLE_AND_USE" for the first usage, "USE" for subsequent uses -}); - -// Wait for the transaction to be processed -const receipt = await emulatedClient.waitForUserOperationReceipt({ - hash: userOpHash -}); - -// Check if the transaction was successful -if (!receipt.success) { - throw new Error("Smart sessions module validation failed"); -} - -console.log("Permission used successfully:", receipt); -``` - -## Subsequent Permission Usage - -After the first usage, you can use the permission again with `USE` mode: - -```typescript -// Use the permission again without enabling it -const secondUserOpHash = await smartSessionsClient.usePermission({ - sessionDetails, - calls: [ - { - to: targetContractAddress, - data: "0x273ea3e3" - } - ], - mode: "USE" // Only "USE" for subsequent usages -}); - -const secondReceipt = await emulatedClient.waitForUserOperationReceipt({ - hash: secondUserOpHash -}); - -console.log("Permission used again successfully:", secondReceipt); -``` - -## Multi-chain Permission Usage - -Coming Soon \ No newline at end of file diff --git a/docs/pages/overview.mdx b/docs/pages/overview.mdx deleted file mode 100644 index 1c05d46..0000000 --- a/docs/pages/overview.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -id: overview -title: SDK Overview ---- - -## What is Nexus? -Nexus is the next generation smart account solution, built on the ERC-7579 standard, representing a significant upgrade from [Biconomy Smart Account v2](/smartAccountsV2/quickstart-react). It offers enhanced modularity, security, and scalability to meet the evolving needs of developers. - -:::info -Learn more about Nexus Architecture here: [Nexus wiki](https://github.com/bcnmy/nexus/wiki) -::: - -## Key Features -**Modular**
-Nexus implements the 7579 modular interface, which works with a growing list of open sourced modules to tap into permissionless innovation. You can choose from a wide range of third party modules to easily plug-in new capabilities. - ---- - -**EIP-7702 Ready**
-The Nexus v1.2.0. is our production-grade release targeting EIP-7702 execution. Available on all chains which -have enabled the "Pectra" fork features (e.g. ETH Sepolia, BNB Chain, Ithaca Odyssey, ...) - ---- - -**Secure**
-Nexus has been rigorously audited and tested, ensuring that dapps integrating it can trust its smart account implementation. [Audits](/contractsAndAudits) by leading firms Spearbit and Cyfrin provide top-tier security assurances. Backed by 92% score from the industry leader [@DefiSafety](https://www.defisafety.com/app/pqrs/603)! - ---- - -**Standardized**
-Nexus is compliant with multiple standards, including ERC-7579 for modularity and ERC-7484 for third-party module security, ensuring seamless interoperability across providers. - ---- - -**Efficient**
-Nexus is extremely gas-efficient, helping to significantly reduce transaction costs. Nexus is **up to 25% cheaper** -than competing Smart Account solutions. [With Benchmarks to prove it](https://github.com/bcnmy/aa-benchmarks) - ---- - - -Nexus is designed to scale with the growing needs of developer use cases, providing them with high flexibility and future-proofing their accounts with new modules development. - -## Getting Started -To begin on your journey with Nexus, check out our [Quick Start Guide](/tutorials/quickstart). - diff --git a/docs/pages/sdk-reference/bundler-client/account/index.md b/docs/pages/sdk-reference/bundler-client/account/index.md deleted file mode 100644 index a4ea793..0000000 --- a/docs/pages/sdk-reference/bundler-client/account/index.md +++ /dev/null @@ -1,119 +0,0 @@ -# Nexus Account - -The Nexus Account is a smart contract account that enables powerful account abstraction features and cross-chain functionality within the AbstractJS SDK. - -## Overview - -The Nexus Account provides a seamless way to interact with smart contracts across multiple chains while leveraging account abstraction capabilities (ERC-4337). It serves as the foundation for executing transactions through both the Bundler Client and MEE Client. - -## Modularity & Benefits - -Nexus implements the ERC-7579 modular smart account standard with five key module types: - -- **Validator Modules**: Handle transaction authorization and signature validation -- **Executor Modules**: Execute custom transaction logic across protocols -- **Hook Modules**: Perform checks before and after transaction execution -- **Fallback Modules**: Handle specialized contract interactions -- **Prevalidation Hooks**: Process transaction details before validation - -This modular architecture delivers significant advantages: - -### User Experience -- Gasless transactions with any token for gas fees -- Batch multiple operations in single transactions -- Transaction automation and session keys - -### Security -- Custom validation rules and multi-signature support -- Account recovery mechanisms -- Spending limits and transaction guards - -### Cross-Chain -- Interact with multiple blockchains using a single account -- Build complex workflows with runtime-resolved values -- Seamless asset transfers between networks - -The modular design ensures Nexus accounts can adapt to evolving blockchain ecosystems while maintaining security and user-friendliness. - -## Key Features - -| Feature | Description | -|---------|-------------| -| Account Abstraction | Based on ERC-4337 standard for gasless transactions and batch operations | -| Cross-Chain Support | Works seamlessly across multiple blockchain networks | -| Modular Architecture | Supports customizable validation modules and executor modules | -| Composability | Enables complex cross-chain transactions through runtime values | -| EIP-1271 Signatures | Native support for contract-based signatures verification | -| Delegation | Ability to delegate transaction authorization via EIP-7702 | - -## Creating a Nexus Account - -```typescript -import { toNexusAccount } from '@biconomy/abstractjs'; -import { createWalletClient, http } from 'viem'; -import { mainnet } from 'viem/chains'; - -// Create a basic Nexus account with default settings -const nexusAccount = await toNexusAccount({ - chain: mainnet, - transport: http(), - signer: yourSigner // EOA, private key, or other signer -}); - -// Create a Nexus account with custom settings -const customNexusAccount = await toNexusAccount({ - chain: mainnet, - transport: http(), - signer: yourSigner, - index: 1n, // Optional salt for account address derivation - validators: [customValidator], // Custom validator modules - executors: [customExecutor], // Custom executor modules - hook: customHook, // Custom hook module - fallbacks: [customFallback] // Custom fallback modules -}); -``` - -## Core Methods - -| Method | Description | -|--------|-------------| -| `getAddress()` | Gets the counterfactual address of the account | -| `getInitCode()` | Gets the initialization code required for account deployment | -| `encodeExecute(call)` | Encodes a single transaction call | -| `encodeExecuteBatch(calls)` | Encodes multiple transaction calls for batch execution | -| `encodeExecuteComposable(calls)` | Encodes calls for composable execution with runtime values | -| `signMessage(message)` | Signs a message using the account's active module | -| `signTypedData(data)` | Signs typed data (EIP-712) with the account | -| `getNonce()` | Gets the current nonce for the account | -| `getModule()` | Gets the active validation module | -| `setModule(validationModule)` | Sets a new active validation module | -| `toDelegation()` | Creates authorization data for EOA to smart account delegation | -| `unDelegate()` | Revokes previous delegation | -| `isDelegated()` | Checks if the account is currently delegated | - -## Important Notes - -1. When using composable transactions with runtime values (such as `runtimeERC20BalanceOf`), you must use `encodeExecuteComposable()` method. - -2. The account can be used with both the Bundler Client for regular transactions and the MEE Client for cross-chain operations. - -3. For security-sensitive operations, you can configure custom validation modules that implement different signature validation schemes. - -## Bundler Client Methods - -The Nexus Account can be used with the Bundler Client to perform various operations. See the following method references for detailed information: - -- [sendUserOperation](../methods/sendUserOperation.md) - Submit a custom User Operation -- [sendTokenPaymasterUserOp](../methods/sendTokenPaymasterUserOp.md) - Send a transaction with ERC-20 token for gas -- [waitForUserOperationReceipt](../methods/waitForUserOperationReceipt.md) - Wait for a User Operation to be confirmed -- [estimateUserOperationGas](../methods/more/estimateUserOperationGas.md) - Estimate gas for a User Operation -- [getUserOperation](../methods/more/getUserOperation.md) - Retrieve information about a User Operation -- [getUserOperationReceipt](../methods/more/getUserOperationReceipt.md) - Get the receipt for a User Operation -- [prepareUserOperation](../methods/more/prepareUserOperation.md) - Prepare a User Operation without sending it -- [prepareTokenPaymasterUserOp](../methods/prepareTokenPaymasterUserOp.md) - Prepare a User Operation with token paymaster -- [getSupportedEntryPoints](../methods/more/getSupportedEntryPoints.md) - Get the supported EntryPoints -- [getChainId](../methods/more/getChainId.md) - Get the current chain ID -- [debugUserOperation](../methods/debugUserOperation.md) - Debug a User Operation -- [upgradeSmartAccount](../methods/upgradeSmartAccount.md) - Upgrade your Nexus Account implementation - -For a complete overview of all available methods, see the [methods index](../methods/index.md). diff --git a/docs/pages/sdk-reference/bundler-client/index.md b/docs/pages/sdk-reference/bundler-client/index.md deleted file mode 100644 index f5cba22..0000000 --- a/docs/pages/sdk-reference/bundler-client/index.md +++ /dev/null @@ -1,173 +0,0 @@ -# Bundler Client - -The Bundler Client is a key component in the AbstractJS SDK that provides an interface to interact with ERC-4337 bundlers for sending and managing User Operations in account abstraction implementations. - -## Overview - -A Bundler Client enables smart contract wallets to execute transactions through the ERC-4337 protocol, allowing for features like gasless transactions, batched operations, and custom authorization logic. This client extends the standard bundler functionality with Biconomy-specific enhancements. - -## Import - -```ts -import { createBicoBundlerClient, http } from '@biconomy/abstractjs' -``` - -## Usage - -Initialize a Bundler Client with your desired Chain and Transport options: - -```ts -import { createBicoBundlerClient, http } from '@biconomy/abstractjs' -import { mainnet } from 'viem/chains' - -const bundlerClient = createBicoBundlerClient({ - chain: mainnet, - apiKey: 'YOUR_API_KEY_HERE' // Optional -}) -``` - -## Configuration - -The `createBicoBundlerClient` function accepts the following parameters: - -```ts -type BicoBundlerClientConfig = { - /** - * Whether to use the test bundler. Conditionally used by the `getGasFeeValues` decorator. - */ - mock?: boolean - - /** - * The chain to use for the bundler client - */ - chain?: Chain - - /** - * Optional paymaster configuration - */ - paymaster?: BundlerClientConfig["paymaster"] - - /** - * Optional paymaster context - */ - paymasterContext?: unknown - - /** - * Optional user operation configuration - */ - userOperation?: BundlerClientConfig["userOperation"] -} & OneOf< - | { transport: Transport } - | { bundlerUrl: string } - | { apiKey?: string } -> -``` - -You must provide one of the following: -- A custom `transport` instance -- A `bundlerUrl` endpoint -- An `apiKey` (which will use Biconomy's bundler endpoint) -- A `chain` (which will use Biconomy's default bundler endpoint) - -## Key Features - -The Bundler Client provides several actions for working with User Operations: - -### Standard Bundler Actions - -- **estimateUserOperationGas**: Estimates gas costs for a User Operation -- **sendUserOperation**: Sends a User Operation to the bundler -- **getUserOperationReceipt**: Gets the receipt of a User Operation -- **supportedEntryPoints**: Gets the entry points supported by the bundler -- **getUserOperationByHash**: Gets a User Operation by its hash - -### Biconomy-Specific Actions - -- **getGasFeeValues**: Gets recommended gas fee values (slow, standard, fast) -- **getUserOperationStatus**: Gets the status of a User Operation -- **waitForUserOperationReceipt**: Waits for a User Operation receipt -- **waitForConfirmedUserOperationReceipt**: Waits for a confirmed User Operation receipt - -### ERC-7579 Actions - -The client also includes ERC-7579 support for modular smart accounts. - -### Smart Account Actions - -Additional actions for working with smart accounts are available. - -## Example - -Here's an example of sending a User Operation and waiting for its receipt: - -```ts -import { createBicoBundlerClient, http } from '@biconomy/abstractjs' -import { mainnet } from 'viem/chains' -import { toNexusAccount } from '@biconomy/abstractjs' - -// Create a Nexus Account -const nexusAccount = await toNexusAccount({ - signer: account, // Your signer account - chain: mainnet, - transport: http() -}) - -// Create a Bundler Client -const bundlerClient = createBicoBundlerClient({ - chain: mainnet, - account: nexusAccount -}) - -// Get gas fees -const gasFees = await bundlerClient.getGasFeeValues() - -// Send a user operation -const hash = await bundlerClient.sendUserOperation({ - ...gasFees.fast, - calls: [ - { - to: '0xYourAddress', - value: 1n - } - ], - account: nexusAccount -}) - -// Wait for the receipt -const receipt = await bundlerClient.waitForUserOperationReceipt({ hash }) -console.log('Transaction successful:', receipt.success) -``` - -## Gas Buffer Configuration - -You can add a buffer to the gas estimates to ensure your transactions don't fail due to gas estimation inaccuracies: - -```ts -const userOperation = await bundlerClient.prepareUserOperation({ - gasBuffer: { - factor: 1.2, // 20% buffer - fields: ["preVerificationGas", "verificationGasLimit"] - }, - calls: [ - { - to: account.address, - value: 1n - } - ] -}) -``` - -## Aliases - -For backward compatibility, the following aliases are provided: - -```ts -import { - createBicoBundlerClient, - createNexusClient, - createNexusSessionClient -} from '@biconomy/abstractjs' - -// All of these are equivalent to createBicoBundlerClient -``` - diff --git a/docs/pages/sdk-reference/bundler-client/methods.md b/docs/pages/sdk-reference/bundler-client/methods.md deleted file mode 100644 index fb98d47..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods.md +++ /dev/null @@ -1,386 +0,0 @@ -# Nexus client methods - -## sendTransaction - -This method is used to submit a User Operation object to the User Operation pool of the client. It signs the UserOperation using smart account owner and submits it to the bundler for on-chain processing. - -### Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" -import { contractABI } from "./abi" -import { parseEther } from "viem"; - -const hash = await bicoBundlerClient.sendUserOperation({ // [!code focus:13] - calls: [ - { - to: '0xf5715961C550FC497832063a98eA34673ad7C816', - value: parseEther('0.0001'), - }, - { - abi: contractABI, - functionName: 'mint', - to: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2', - } - ], -}); -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) - -``` - -```typescript [abi.ts] filename="abi.ts" - -export const contractABI = [ - //... - { - inputs: [], - name: "mint", - outputs: [], - stateMutability: "nonpayable", - type: "function", - } -]; -``` - -::: - -### Parameters -- calls `{ data: Hex, to: Address, value: bigint }[]` : The calls to execute in the User Operation. -- paymaster `Address | true | PaymasterClient | PaymasterAction` (optional) - -### Response -- `Promise` The transaction hash. - - -## waitForUserOperationReceipt - -Waits for the User Operation to be included on a Block (one confirmation), and then returns the User Operation receipt. - -### Usage -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -const receipt = await bicoBundlerClient.waitForUserOperationReceipt({ // [!code focus:3] - hash: '0x315a882b82eb33250b919da6ebb2dd890df39ca0840e4026cbbad595b9a07e86' -}) -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -### Parameters -- hash `'0x${string}'`: A Transaction hash. -- pollingInterval (optional) `number`: Polling frequency (in ms) -- retryCount (optional) `number`: The number of times to retry. Default value is 6. -- timeout (optional) `number`: Optional timeout (in ms) to wait before stopping polling. Default value is 5000. - -### Response -- receipt `Promise`: The User Operation receipt. - - -## estimateUserOperationGas - -Estimates the gas values for a User Operation to be executed successfully. - -### Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -const gas = await bicoBundlerClient.estimateUserOperationGas({ // [!code focus:12] - calls: [ - { - to: '0xf5715961C550FC497832063a98eA34673ad7C816', - value: parseEther('0.0001'), - }, - { - abi: contractABI, - functionName: 'contractFunction', - to: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2', - } - ], -}); -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - signer: account, - chain: baseSepolia, - transport: http(), - bundlerTransport: http(bundlerUrl), -}); -``` - -::: - -### Parameters -- calls `{ data: Hex, to: Address, value: bigint }[]` : The calls to execute in the User Operation. -- paymaster `Address | true | PaymasterClient | PaymasterAction` (optional) - -### Response -- `Promise` The estimated gas values. - -```typescript -{ - callGasLimit: bigint; - preVerificationGas: bigint; - verificationGasLimit: bigint; - paymasterVerificationGasLimit: bigint | undefined; - paymasterPostOpGasLimit: bigint | undefined; -} -``` - - - - - -## getUserOperation - -Retrieves information about a User Operation given a hash. - -### Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -const receipt = await bicoBundlerClient.getUserOperation({ // [!code focus:3] - hash: '0x315a882b82eb33250b919da6ebb2dd890df39ca0840e4026cbbad595b9a07e86' -}) -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - signer: account, - chain: baseSepolia, - transport: http(), - bundlerTransport: http(bundlerUrl), -}); -``` - -::: - -### Parameters -- hash `'0x${string}'`: A User Operation hash. - -### Response -- userOperation `Promise`: User Operation information. - -```typescript - -type GetUserOperationReturnType = { - /** The block hash the User Operation was included on. */ - blockHash: Hash - /** The block number the User Operation was included on. */ - blockNumber: bigint - /** The EntryPoint which handled the User Operation. */ - entryPoint: Address - /** The hash of the transaction which included the User Operation. */ - transactionHash: Hash - /** The User Operation. */ - userOperation: UserOperation -} - -``` - -## getUserOperationReceipt - -Returns the User Operation Receipt given a User Operation hash. - -### Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -const receipt = await bicoBundlerClient.getUserOperationReceipt({ // [!code focus:3] - hash: '0x315a882b82eb33250b919da6ebb2dd890df39ca0840e4026cbbad595b9a07e86' -}) -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}); -``` - -::: -### Parameters -- hash `'0x${string}'`: A User Operation hash. - -### Response -- receipt `Promise`: User Operation receipt. - - -## getSupportedEntryPoints - -Returns the EntryPoints that the nexus client supports. - -### Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -const entrypointAddresses = await bicoBundlerClient.getSupportedEntryPoints() // [!code focus:1] -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -})``` - -::: - -### Response -- addresses `Promise`: The EntryPoints that the nexus client supports. - - - -## getChainId - -Returns the chain ID associated with the nexus client - - -### Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -const chainId = await bicoBundlerClient.getChainId() // [!code focus:1] -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -### Response -- chain Id `Promise`: The current chain ID. - - - - - - - - - - - - - - - diff --git a/docs/pages/sdk-reference/bundler-client/methods/debugUserOperation.md b/docs/pages/sdk-reference/bundler-client/methods/debugUserOperation.md deleted file mode 100644 index b9ff83a..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/debugUserOperation.md +++ /dev/null @@ -1,105 +0,0 @@ -# debugUserOperation - -This method helps debug User Operations by providing detailed information about the operation, including packed format, RPC parameters, and optional Tenderly simulation links. Under the hood, it sends a user operation in the same way as sendUserOperation, but with additional debugging information. - - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -// Debug a user operation -const debug = await bicoBundlerClient.debugUserOperation({ - calls: [{ - to: '0x70997970c51812dc3a010c7d01b50e0d17dc79c8', - value: parseEther('0.1'), - data: '0x' - }] -}) -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -## Parameters - -The method accepts the same parameters as `sendUserOperation`, including: - -- `calls` `{ data?: Hex, to: Address, value?: bigint }[]`: Array of transactions to execute -- `entryPointAddress` `Address` (optional): Override the default EntryPoint address -- All other standard User Operation parameters (gas limits, nonce, etc.) - -## Response - -The method provides detailed debug information in the console: -1. Packed User Operation format -2. RPC parameters sent to the bundler -3. Tenderly simulation URL (if environment variables are configured) -4. User Operation hash -5. Detailed error information if the operation fails - -## Enhanced Error Handling - -The debug output includes enhanced error information powered by the [aa-errors repository](https://github.com/bcnmy/aa-errors). When an error occurs, you'll receive: - -- Error name and code -- Detailed description of the error -- Potential causes -- Suggested solutions - -For example, if your smart account lacks funds, you might see: - -```json -{ - "name": "SmartAccountInsufficientFundsError", - "code": "aa21", - "description": "You are not using a paymaster, and the sender address did not have enough native tokens to cover the gas costs associated with the user operation.", - "causes": [ - "Your smart wallet does not have funds to send transaction." - ], - "solutions": [ - "If you are not using a paymaster, verify that the sender address has enough native tokens to cover the required prefund.", - "Send some native tokens in your smart wallet to be able to resolve the error.", - "If you are looking to use a paymaster to cover the gas fees, verify that the paymasterAndData field is set." - ] -} -``` - -## Tenderly Integration - -To enable Tenderly simulation links, set the following environment variables: -```bash -TENDERLY_API_KEY=your_api_key -TENDERLY_ACCOUNT_SLUG=your_account_slug -TENDERLY_PROJECT_SLUG=your_project_slug -``` - -When enabled, you'll get access to Tenderly's simulation interface, which is particularly useful for debugging and testing aa23 errors. - -![Tenderly simulation interface showing transaction parameters and state overrides](/tenderly-simulation.png) - -## Related Methods - -- [sendUserOperation](./sendUserOperation.md) - For production use -- [prepareUserOperation](./more/prepareUserOperation.md) - For preparing operations without sending \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/index.md b/docs/pages/sdk-reference/bundler-client/methods/index.md deleted file mode 100644 index bca397d..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/index.md +++ /dev/null @@ -1,46 +0,0 @@ -# Methods - -The Nexus client provides a comprehensive set of methods for interacting with smart accounts. The methods are categorized into different types based on their functionality. - -## Transaction Methods - -- [debugUserOperation](/sdk-reference/bundler-client/methods/debugUserOperation): Debug a user operation -- [sendTokenPaymasterUserOp](/sdk-reference/bundler-client/methods/sendTokenPaymasterUserOp): Send a user operation using ERC-20 tokens for gas payment -- [sendTransaction](/sdk-reference/bundler-client/methods/more/sendTransaction): Send a transaction from the smart account -- [sendUserOperation](/sdk-reference/bundler-client/methods/sendUserOperation): Send a user operation to the bundler -- [upgradeSmartAccount](/sdk-reference/bundler-client/methods/upgradeSmartAccount): Upgrade the smart account to a new implementation - -## Preparation Methods - -- [prepareTokenPaymasterUserOp](/sdk-reference/bundler-client/methods/prepareTokenPaymasterUserOp): Prepare a user operation using ERC-20 tokens for gas payment -- [prepareUserOperation](/sdk-reference/bundler-client/methods/more/prepareUserOperation): Prepare a user operation -- [prepareUserOperationWithoutSignature](/sdk-reference/bundler-client/methods/more/prepareUserOperationWithoutSignature): Prepare a user operation without adding a signature - -## Signing Methods - -- [signMessage](/sdk-reference/bundler-client/methods/more/signMessage): Sign a message with the smart account -- [signTypedData](/sdk-reference/bundler-client/methods/more/signTypedData): Sign typed data with the smart account - -## Status & Information Methods - -- [getGasFeeValues](/sdk-reference/bundler-client/methods/more/getGasFeeValues): Get estimated gas fee values -- [getUserOperationReceipt](/sdk-reference/bundler-client/methods/more/getUserOperationReceipt): Get the receipt of a user operation -- [waitForUserOperationReceipt](/sdk-reference/bundler-client/methods/waitForUserOperationReceipt): Wait for a user operation receipt - -## Network Methods - -- [getChainId](/sdk-reference/bundler-client/methods/more/getChainId): Get the chain ID - -## ERC-7579 Methods - -- [accountId](/sdk-reference/bundler-client/methods/more/accountId): Get the account ID -- [getActiveHook](/sdk-reference/bundler-client/methods/more/getActiveHook): Get the active hook -- [getFallbackBySelector](/sdk-reference/bundler-client/methods/more/getFallbackBySelector): Get the fallback by selector -- [getInstalledExecutors](/sdk-reference/bundler-client/methods/more/getInstalledExecutors): Get installed executors -- [getInstalledModules](/sdk-reference/bundler-client/methods/more/getInstalledModules): Get all installed modules -- [getInstalledValidators](/sdk-reference/bundler-client/methods/more/getInstalledValidators): Get installed validators -- [installModule](/sdk-reference/bundler-client/methods/more/installModule): Install a module -- [isModuleInstalled](/sdk-reference/bundler-client/methods/more/isModuleInstalled): Check if a module is installed -- [supportsExecutionMode](/sdk-reference/bundler-client/methods/more/supportsExecutionMode): Check if an execution mode is supported -- [supportsModule](/sdk-reference/bundler-client/methods/more/supportsModule): Check if a module is supported -- [uninstallModule](/sdk-reference/bundler-client/methods/more/uninstallModule): Uninstall a module diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/accountId.md b/docs/pages/sdk-reference/bundler-client/methods/more/accountId.md deleted file mode 100644 index 8f9743e..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/accountId.md +++ /dev/null @@ -1,72 +0,0 @@ -# accountId - -The `accountId` function retrieves the unique identifier for an ERC-7579 compliant smart account. This ID can be used to identify the account across different chains and implementations. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const id = await nexusClient.accountId(); -``` - -## Parameters - -The function accepts an optional object with the following properties: - -```typescript -type AccountIdParameters = { - account?: TSmartAccount -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | - -## Return Value - -The function returns a promise that resolves to a string representing the account's unique identifier. - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Get the account ID -const accountId = await nexusClient.accountId(); -console.log("Account ID:", accountId); -``` - -## Implementation Details - -The function attempts to call the `accountId` function on the smart account contract. If the account is not yet deployed, it simulates the call through the factory to retrieve the account ID that would be assigned upon deployment. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/debugUserOperation.md b/docs/pages/sdk-reference/bundler-client/methods/more/debugUserOperation.md deleted file mode 100644 index abf1036..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/debugUserOperation.md +++ /dev/null @@ -1,108 +0,0 @@ -# debugUserOperation - -The `debugUserOperation` function helps developers debug and simulate a user operation before actually sending it to the network. It provides detailed logs, Tenderly simulation links, and error information. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const hash = await nexusClient.debugUserOperation({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x" - } - ] -}); -``` - -## Parameters - -The function accepts the same parameters as `sendUserOperation`: - -```typescript -type DebugUserOperationParameters = SendUserOperationParameters -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| calls | `Call[]` | Array of transactions to execute. | -| maxFeePerGas | `bigint` | Optional. The maximum fee per gas to pay for the transaction. | -| maxPriorityFeePerGas | `bigint` | Optional. The maximum priority fee per gas to pay for the transaction. | -| nonce | `bigint` | Optional. The nonce to use for the transaction. | -| signature | `Hex` | Optional. The signature to use for the user operation. If not provided, it will be generated. | -| entryPointAddress | `Address` | Optional. The entry point address to use. | - -## Return Value - -The function returns a promise that resolves to the hash of the user operation as a hexadecimal string. - -```typescript -Promise -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Debug a user operation -try { - const hash = await nexusClient.debugUserOperation({ - calls: [ - { - to: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", - value: 1n, - data: "0x" - } - ] - }); - - console.log("User operation hash:", hash); -} catch (error) { - console.error("Debug error:", error); -} -``` - -## Implementation Details - -The function prepares a user operation, signs it, and logs detailed information including: - -1. The packed user operation in JSON format -2. The RPC parameters being sent to the bundler -3. A Tenderly simulation URL that can be used to inspect the operation in detail -4. Any errors that occur during the process, with detailed debugging information - -If the operation fails, the function will attempt to generate a Tenderly simulation URL for the failed operation to help with debugging. - -This function is primarily intended for development and debugging purposes, not for production use. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/estimateUserOperationGas.md b/docs/pages/sdk-reference/bundler-client/methods/more/estimateUserOperationGas.md deleted file mode 100644 index cfd85b5..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/estimateUserOperationGas.md +++ /dev/null @@ -1,130 +0,0 @@ -# estimateUserOperationGas - -Estimates the gas values for a User Operation to be executed successfully. - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" -import { parseEther } from "viem" - -// Estimate gas for a user operation -const gas = await bicoBundlerClient.estimateUserOperationGas({ - calls: [{ - to: '0x70997970c51812dc3a010c7d01b50e0d17dc79c8', - value: parseEther('1') - }] -}) -``` - -```typescript [bicoBundlerClient.ts] -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -## Returns - -```typescript -{ - callGasLimit: bigint; - preVerificationGas: bigint; - verificationGasLimit: bigint; - paymasterVerificationGasLimit: bigint | undefined; - paymasterPostOpGasLimit: bigint | undefined; -} -``` - -The estimated gas values for the User Operation. - -## Parameters - -### calls - -- **Type:** `{ data?: Hex, to: Address, value?: bigint }[]` -- **Required:** Yes - -The calls to execute in the User Operation. - -```typescript -const gas = await bicoBundlerClient.estimateUserOperationGas({ - calls: [{ - to: '0x70997970c51812dc3a010c7d01b50e0d17dc79c8', - value: parseEther('1') - }] -}) -``` - -### Contract Calls - -The `calls` property also accepts Contract Calls using the `abi`, `functionName`, and `args` properties: - -```typescript -const gas = await bicoBundlerClient.estimateUserOperationGas({ - calls: [{ - abi: wagmiAbi, - functionName: 'mint', - to: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2', - }] -}) -``` - -### Optional Parameters - -- `callGasLimit` `bigint`: Amount of gas to allocate for the main execution call -- `maxFeePerGas` `bigint`: Maximum fee per gas for User Operation execution -- `maxPriorityFeePerGas` `bigint`: Maximum priority fee per gas -- `nonce` `bigint`: Nonce for the User Operation -- `verificationGasLimit` `bigint`: Gas to allocate for verification -- `preVerificationGas` `bigint`: Extra gas to pay the Bundler - -### Paymaster Configuration - -You can configure a paymaster in several ways: - -```typescript -// Using a paymaster address -const gas = await bicoBundlerClient.estimateUserOperationGas({ - calls: [{ - to: '0x...', - value: parseEther('1') - }], - paymaster: '0x942fD5017c0F60575930D8574Eaca13BEcD6e1bB', - paymasterData: '0xdeadbeef' -}) - -// Using a paymaster client -const gas = await bicoBundlerClient.estimateUserOperationGas({ - calls: [{ - to: '0x...', - value: parseEther('1') - }], - paymaster: paymasterClient, - paymasterContext: { - policyId: 'abc123' - } -}) -``` - -## Related Methods - -- [sendUserOperation](/sdk-reference/bundler-client/methods/sendUserOperation) -- [prepareUserOperation](/sdk-reference/bundler-client/methods/more/prepareUserOperation) \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getActiveHook.md b/docs/pages/sdk-reference/bundler-client/methods/more/getActiveHook.md deleted file mode 100644 index a7ce816..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getActiveHook.md +++ /dev/null @@ -1,85 +0,0 @@ -# getActiveHook - -The `getActiveHook` function retrieves the address of the active hook module on an ERC-7579 compliant smart account. Hook modules can intercept and modify transactions before they are executed. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const activeHook = await nexusClient.getActiveHook(); -``` - -## Parameters - -The function accepts an optional object with the following properties: - -```typescript -type GetActiveHookParameters = { - account?: TSmartAccount -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | - -## Return Value - -The function returns a promise that resolves to the address of the active hook as a hexadecimal string. If no hook is active, it returns the zero address (`0x0000000000000000000000000000000000000000`). - -```typescript -Promise -``` - -## Example - -```typescript -import { http, isHex } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Get the active hook -const activeHook = await nexusClient.getActiveHook(); -console.log("Active hook address:", activeHook); - -// Check if a hook is set -if (isHex(activeHook) && activeHook !== '0x0000000000000000000000000000000000000000') { - console.log("The account has an active hook module"); -} else { - console.log("No hook module is currently active"); -} -``` - -## Implementation Details - -The function makes a view call to the `getActiveHook` method on the smart account contract, which returns the address of the currently active hook module. - -The hook module (if any) will be executed before any transaction executed by the account, allowing for pre-execution checks, modifications, or rejections of transactions. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getChainId.md b/docs/pages/sdk-reference/bundler-client/methods/more/getChainId.md deleted file mode 100644 index 47aef8d..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getChainId.md +++ /dev/null @@ -1,51 +0,0 @@ -# getChainId - -Returns the chain ID associated with the bundler. - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -// Get chain ID -const chainId = await bicoBundlerClient.getChainId() -// Returns: 84532 (for Base Sepolia) -``` - -```typescript [bicoBundlerClient.ts] -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - - -const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -## Returns - -```typescript -number -``` - -Returns the current chain ID that the bundler is operating on. - -## Related Methods - -- [getSupportedEntryPoints](/sdk-reference/bundler-client/methods/more/getSupportedEntryPoints) -- [sendUserOperation](/sdk-reference/bundler-client/methods/sendUserOperation) \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getFallbackBySelector.md b/docs/pages/sdk-reference/bundler-client/methods/more/getFallbackBySelector.md deleted file mode 100644 index 7d7c082..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getFallbackBySelector.md +++ /dev/null @@ -1,96 +0,0 @@ -# getFallbackBySelector - -The `getFallbackBySelector` function retrieves the fallback handler address and function selector for a specific function selector on an ERC-7579 compliant smart account. Fallback handlers allow the smart account to delegate function calls that it doesn't natively support to external contracts. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const [fallbackAddress, functionSelector] = await nexusClient.getFallbackBySelector({ - selector: "0xcb5baf0f" -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type GetFallbackBySelectorParameters = { - account?: TSmartAccount -} & { - selector: Hex -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| selector | `Hex` | The 4-byte function selector to look up. | - -## Return Value - -The function returns a promise that resolves to a tuple containing: - -1. The address of the fallback handler as a hexadecimal string -2. The function selector to call on the fallback handler as a hexadecimal string - -```typescript -Promise<[Hex, Hex]> -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Get a fallback handler for a specific function selector -const functionSelector = "0xcb5baf0f"; // Example selector -const fallbackSelector = await nexusClient.getFallbackBySelector({ selector: functionSelector }); - -console.log("Fallback handler address:", fallbackSelector[0]); -console.log("Fallback function selector:", fallbackSelector[1]); - -// Check if a fallback exists -if (fallbackSelector[0] !== '0x0000000000000000000000000000000000000000') { - console.log("A fallback handler exists for this function"); -} else { - console.log("No fallback handler exists for this function"); -} -``` - -## Implementation Details - -The function makes a view call to the `getFallbackBySelector` method on the smart account contract, passing the function selector as an argument. The contract returns the address of the fallback handler and the function selector that should be called on that handler. - -When the smart account receives a call to a function it doesn't support, it can delegate the call to a fallback handler if one is configured for that function selector. This mechanism enables smart accounts to support arbitrary functionalities through modular extensions. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getGasFeeValues.md b/docs/pages/sdk-reference/bundler-client/methods/more/getGasFeeValues.md deleted file mode 100644 index 850d136..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getGasFeeValues.md +++ /dev/null @@ -1,88 +0,0 @@ -# getGasFeeValues - -The `getGasFeeValues` function returns live gas prices that can be used to send a user operation. It provides different gas price tiers (slow, standard, and fast) with corresponding `maxFeePerGas` and `maxPriorityFeePerGas` values for each tier. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const bicoBundlerClient = createBicoBundlerClient({ - bundlerUrl: "https://bundler.biconomy.io/api/v3/5/your-api-key", - account: nexusAccount -}); - -const gasFees = await bicoBundlerClient.getGasFeeValues(); -``` - -## Return Value - -The function returns a promise that resolves to an object containing gas fee suggestions for different speed tiers: - -```typescript -type GetGasFeeValuesReturnType = { - slow: { - maxFeePerGas: bigint - maxPriorityFeePerGas: bigint - } - standard: { - maxFeePerGas: bigint - maxPriorityFeePerGas: bigint - } - fast: { - maxFeePerGas: bigint - maxPriorityFeePerGas: bigint - } -} -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account and bundler client -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create bundler client -const bicoBundler = createBicoBundlerClient({ - bundlerUrl, - account: nexusAccount -}); - -// Get gas fee values -const gasFees = await bicoBundler.getGasFeeValues(); -console.log("Fast gas fees:", gasFees.fast); -console.log("Standard gas fees:", gasFees.standard); -console.log("Slow gas fees:", gasFees.slow); - -// Use these values in a transaction -const calls = [{ to: recipientAddress, value: 1n }]; -const hash = await bicoBundler.sendUserOperation({ - maxFeePerGas: gasFees.standard.maxFeePerGas, - maxPriorityFeePerGas: gasFees.standard.maxPriorityFeePerGas, - calls, - account: nexusAccount -}); -``` - -## Implementation Details - -The function works by checking if the client is using Pimlico or Biconomy's bundler and calls the appropriate RPC method: -- For Pimlico: `pimlico_getUserOperationGasPrice` -- For Biconomy: `biconomy_getGasFeeValues` - -The returned hex values are then converted to BigInt for use in your user operations. diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledExecutors.md b/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledExecutors.md deleted file mode 100644 index a7ed535..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledExecutors.md +++ /dev/null @@ -1,97 +0,0 @@ -# getInstalledExecutors - -The `getInstalledExecutors` function retrieves the list of executor modules currently installed on an ERC-7579 compliant smart account. Executors are modules that handle the execution logic for transactions. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const [executors, nextCursor] = await nexusClient.getInstalledExecutors(); -``` - -## Parameters - -The function accepts an optional object with the following properties: - -```typescript -type GetInstalledExecutorsParameters = { - account?: TSmartAccount -} & { - pageSize?: bigint - cursor?: Hex -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| pageSize | `bigint` | Optional. The number of executors to return per page. Default is 100. | -| cursor | `Hex` | Optional. The address from which to start retrieving executors. Default is the sentinel address. | - -## Return Value - -The function returns a promise that resolves to a tuple containing: - -1. An array of executor addresses as hexadecimal strings -2. A cursor for pagination as a hexadecimal string - -```typescript -Promise -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Get the installed executors -const [executors, nextCursor] = await nexusClient.getInstalledExecutors({ - pageSize: 10n -}); - -console.log("Installed executors:", executors); -console.log("Next cursor:", nextCursor); - -// To get the next page of executors -if (nextCursor !== '0x0000000000000000000000000000000000000001') { - const [nextExecutors, newCursor] = await nexusClient.getInstalledExecutors({ - pageSize: 10n, - cursor: nextCursor - }); - console.log("Next page of executors:", nextExecutors); -} -``` - -## Implementation Details - -The function calls the `getExecutorsPaginated` method on the smart account contract, which returns a paginated list of executor addresses. The pagination system uses a cursor-based approach, where the cursor represents the last address processed. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledModules.md b/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledModules.md deleted file mode 100644 index 20258e5..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledModules.md +++ /dev/null @@ -1,65 +0,0 @@ -# getInstalledModules - -The `getInstalledModules` method retrieves a list of all modules that are currently installed on the smart account. These modules extend the functionality of the smart account and provide additional features. - -## Usage - -```ts -const modules = await nexusClient.getInstalledModules(); -``` - -## Parameters - -The `getInstalledModules` method does not accept any parameters. - -## Returns - -The `getInstalledModules` method returns an array of `Module` objects, each containing: - -| Property | Type | Description | -| --- | --- | --- | -| `module` | `Address` | The address of the module | -| `moduleType` | `number` | The type of the module (0 = Validator, 1 = Executor, 2 = Hook, 3 = Fallback) | -| `data` | `Hex` | Additional data associated with the module | - -## Example - -```ts -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; -import { privateKeyToAccount } from "viem/accounts"; - -// Setup account and client -const account = privateKeyToAccount("0xYourPrivateKey"); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f14"; - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}); - -// Get all installed modules -const modules = await nexusClient.getInstalledModules(); - -// Display information about each module -modules.forEach((module, index) => { - console.log(`Module ${index + 1}:`); - console.log(` Address: ${module.module}`); - console.log(` Type: ${module.moduleType}`); - console.log(` Data: ${module.data}`); -}); -``` - -## Notes - -- This method is specifically for ERC-7579 compatible smart accounts that support modular architecture. -- The module types correspond to the ERC-7579 specification: 0 = Validator, 1 = Executor, 2 = Hook, 3 = Fallback. -- Validators are modules that check if a user operation is valid. -- Executors are modules that execute operations on behalf of the smart account. -- Hooks are modules that are called before or after specific operations. -- Fallbacks are modules that handle function calls that do not match any other function signature. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledValidators.md b/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledValidators.md deleted file mode 100644 index 91471ec..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getInstalledValidators.md +++ /dev/null @@ -1,97 +0,0 @@ -# getInstalledValidators - -The `getInstalledValidators` function retrieves the list of validator modules currently installed on an ERC-7579 compliant smart account. Validators are modules that verify transaction signatures and permissions. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const [validators, nextCursor] = await nexusClient.getInstalledValidators(); -``` - -## Parameters - -The function accepts an optional object with the following properties: - -```typescript -type GetInstalledValidatorsParameters = { - account?: TSmartAccount -} & { - pageSize?: bigint - cursor?: Hex -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| pageSize | `bigint` | Optional. The number of validators to return per page. Default is 100. | -| cursor | `Hex` | Optional. The address from which to start retrieving validators. Default is the sentinel address. | - -## Return Value - -The function returns a promise that resolves to a tuple containing: - -1. An array of validator addresses as hexadecimal strings -2. A cursor for pagination as a hexadecimal string - -```typescript -Promise -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Get the installed validators -const [validators, nextCursor] = await nexusClient.getInstalledValidators({ - pageSize: 10n -}); - -console.log("Installed validators:", validators); -console.log("Next cursor:", nextCursor); - -// To get the next page of validators -if (nextCursor !== '0x0000000000000000000000000000000000000001') { - const [nextValidators, newCursor] = await nexusClient.getInstalledValidators({ - pageSize: 10n, - cursor: nextCursor - }); - console.log("Next page of validators:", nextValidators); -} -``` - -## Implementation Details - -The function calls the `getValidatorsPaginated` method on the smart account contract, which returns a paginated list of validator addresses. The pagination system uses a cursor-based approach, where the cursor represents the last address processed. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getSupportedEntryPoints.md b/docs/pages/sdk-reference/bundler-client/methods/more/getSupportedEntryPoints.md deleted file mode 100644 index eed798c..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getSupportedEntryPoints.md +++ /dev/null @@ -1,51 +0,0 @@ -# getSupportedEntryPoints - -Returns an array of EntryPoint contract addresses that are supported by the bundler. - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -// Get supported entry points -const entryPoints = await bicoBundlerClient.getSupportedEntryPoints() -// Returns: ["0x0000000071727De22E5E9d8BAf0edAc6f37da032"] -``` - -```typescript [bicoBundlerClient.ts] -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -## Returns - -```typescript -readonly Address[] -``` - -Returns an array of EntryPoint contract addresses that the bundler supports. These addresses can be used when configuring your smart account client or when sending User Operations. - -## Related Methods - -- [sendUserOperation](/sdk-reference/bundler-client/methods/sendUserOperation) -- [prepareUserOperation](/sdk-reference/bundler-client/methods/more/prepareUserOperation) -- [getChainId](/sdk-reference/bundler-client/methods/more/getChainId) \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperation.md b/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperation.md deleted file mode 100644 index 831b56f..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperation.md +++ /dev/null @@ -1,77 +0,0 @@ -# getUserOperation - -Retrieves information about a User Operation given a hash. - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -// Get user operation details -const userOp = await bicoBundlerClient.getUserOperation({ - hash: '0x4ca7ee652d57678f26e887c149ab0735f41de37bcad58c9f6d3ed5824f15b74d' -}) -``` - -```typescript [bicoBundlerClient.ts] -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -## Returns - -```typescript -{ - blockHash: Hash, - blockNumber: bigint, - entryPoint: Address, - transactionHash: Hash, - userOperation: UserOperation -} -``` - -Returns an object containing: -- `blockHash`: Hash of the block containing the User Operation -- `blockNumber`: Block number where the User Operation was included -- `entryPoint`: Address of the EntryPoint contract used -- `transactionHash`: Hash of the transaction that included the User Operation -- `userOperation`: The full User Operation details - -## Parameters - -### hash - -- **Type:** `'0x${string}'` -- **Required:** Yes - -The User Operation hash to query. - -```typescript -const result = await bicoBundlerClient.getUserOperation({ - hash: '0x4ca7ee652d57678f26e887c149ab0735f41de37bcad58c9f6d3ed5824f15b74d' -}) -``` - -## Related Methods - -- [sendUserOperation](/sdk-reference/bundler-client/methods/sendUserOperation) -- [waitForUserOperationReceipt](/sdk-reference/bundler-client/methods/waitForUserOperationReceipt) \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperationReceipt.md b/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperationReceipt.md deleted file mode 100644 index 36dae62..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperationReceipt.md +++ /dev/null @@ -1,34 +0,0 @@ -# Get User Operation Receipt - -Returns the User Operation Receipt given a User Operation hash. - -**Usage Example** - -```typescript -const receipt = await smartAccount.getUserOperationReceipt({ - hash: '0x4ca7ee652d57678f26e887c149ab0735f41de37bcad58c9f6d3ed5824f15b74d' -}); - -// Example response -{ - blockHash: '0xaf1dadb8a98f1282e8f7b42cc3da8847bfa2cf4e227b8220403ae642e1173088', - blockNumber: 15132008n, - sender: '0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266', - status: 'success', - // ... other receipt details -} -``` - -**Parameters** - -- hash (`0x${string}`, required): A User Operation hash. - -**Returns** - -- `Promise`: The User Operation receipt containing details such as: - - `blockHash`: The hash of the block where the operation was included - - `blockNumber`: The number of the block where the operation was included - - `sender`: The address that sent the operation - - `status`: The status of the operation ('success' | 'reverted') - -[Reference: Viem getUserOperationReceipt](https://viem.sh/account-abstraction/actions/bundler/getUserOperationReceipt) \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperationStatus.md b/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperationStatus.md deleted file mode 100644 index 2a39ccb..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/getUserOperationStatus.md +++ /dev/null @@ -1,106 +0,0 @@ -# getUserOperationStatus - -The `getUserOperationStatus` function allows you to check the status of a previously submitted user operation. It provides information about whether the operation is confirmed, pending, or rejected, along with relevant details about the transaction. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const bicoBundlerClient = createBicoBundlerClient({ - bundlerUrl: "https://bundler.biconomy.io/api/v3/5/your-api-key", - account: nexusAccount -}); - -// After sending a user operation and receiving a hash -const userOpHash = "0x..."; // The hash returned from sendUserOperation -const status = await bicoBundlerClient.getUserOperationStatus({ - hash: userOpHash -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type GetUserOperationStatusParameters = { - /** The hash of the User Operation. */ - hash: Hex -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| hash | `Hex` | The hash of the user operation to check. This is the hash returned by the `sendUserOperation` function. | - -## Return Value - -The function returns a promise that resolves to an object containing the status information: - -```typescript -type GetUserOperationStatusReturnType = { - state: "CONFIRMED" | "PENDING" | "REJECTED" - message: string - transactionHash: string - userOperationReceipt: UserOperationReceipt -} -``` - -| Property | Type | Description | -| --- | --- | --- | -| state | `"CONFIRMED" \| "PENDING" \| "REJECTED"` | The current state of the user operation. | -| message | `string` | A descriptive message about the current status. | -| transactionHash | `string` | The transaction hash if the operation has been included in a blockchain transaction. | -| userOperationReceipt | `UserOperationReceipt` | A receipt containing details about the operation execution. | - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account and bundler client -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create bundler client -const bicoBundler = createBicoBundlerClient({ - bundlerUrl, - account: nexusAccount -}); - -// Send a user operation -const calls = [{ to: recipientAddress, value: 1n }]; -const hash = await bicoBundler.sendUserOperation({ - calls, - account: nexusAccount -}); - -// Check the status of the user operation -console.log("Checking user operation status..."); -const status = await bicoBundler.getUserOperationStatus({ hash }); - -console.log("User operation state:", status.state); -console.log("Status message:", status.message); - -if (status.state === "CONFIRMED") { - console.log("Transaction confirmed with hash:", status.transactionHash); - console.log("Receipt:", status.userOperationReceipt); -} -``` - -## Implementation Details - -The function makes a request to the Biconomy bundler's API using the `biconomy_getUserOperationStatus` RPC method, passing the user operation hash as a parameter. The bundler then returns the current status of that operation along with relevant details. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/installModule.md b/docs/pages/sdk-reference/bundler-client/methods/more/installModule.md deleted file mode 100644 index 8627367..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/installModule.md +++ /dev/null @@ -1,117 +0,0 @@ -# installModule - -The `installModule` function installs a module on an ERC-7579 compliant smart account. Modules can be validators, executors, or hooks that extend the functionality of the smart account. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http, encodePacked } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const hash = await nexusClient.installModule({ - module: { - type: 'validator', - address: validatorAddress, - initData: '0x' - } -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type InstallModuleParameters = { - account?: TSmartAccount -} & { - module: ModuleMeta - maxFeePerGas?: bigint - maxPriorityFeePerGas?: bigint - nonce?: bigint -} & Partial, "callData">> -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| module | `ModuleMeta` | The module to install, containing type, address, and initialization data. | -| maxFeePerGas | `bigint` | Optional. The maximum fee per gas to pay for the transaction. | -| maxPriorityFeePerGas | `bigint` | Optional. The maximum priority fee per gas to pay for the transaction. | -| nonce | `bigint` | Optional. The nonce to use for the transaction. | - -The `ModuleMeta` type includes: - -```typescript -type ModuleMeta = { - type: 'validator' | 'executor' | 'hook' | 'fallback' - address: Address - initData?: Hex -} -``` - -## Return Value - -The function returns a promise that resolves to the hash of the user operation as a hexadecimal string. - -```typescript -Promise -``` - -## Example - -```typescript -import { http, encodePacked } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Install a custom validator module -const validatorAddress = "0x1234567890123456789012345678901234567890"; -const hash = await nexusClient.installModule({ - module: { - type: 'validator', - address: validatorAddress, - initData: encodePacked(["address"], [account.address]) - } -}); - -// Wait for the transaction to be confirmed -const receipt = await nexusClient.waitForUserOperationReceipt({ hash }); -console.log("Module installation success:", receipt.success); -``` - -## Implementation Details - -The function creates a transaction that calls the `installModule` method on the smart account contract with the module type, address, and initialization data as parameters. - -If the module being installed is the smart sessions module, additional setup may be performed: -- Adds the module address as a safe sender to the validator if a validator address is available. -- Checks for and potentially sets up trusted attesters if they haven't been configured yet. - -The function then sends the transaction as a user operation through the bundler network. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/isModuleInstalled.md b/docs/pages/sdk-reference/bundler-client/methods/more/isModuleInstalled.md deleted file mode 100644 index b90101d..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/isModuleInstalled.md +++ /dev/null @@ -1,108 +0,0 @@ -# isModuleInstalled - -The `isModuleInstalled` function checks whether a specific module is installed on an ERC-7579 compliant smart account. This can be used to verify that a validator, executor, or hook is available before attempting to use it. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const isInstalled = await nexusClient.isModuleInstalled({ - module: { - type: 'validator', - address: validatorAddress, - initData: '0x' - } -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type IsModuleInstalledParameters = { - account?: TSmartAccount -} & { - module: ModuleMeta -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| module | `ModuleMeta` | The module to check, containing type, address, and initialization data. | - -The `ModuleMeta` type includes: - -```typescript -type ModuleMeta = { - type: 'validator' | 'executor' | 'hook' | 'fallback' - address: Address - initData?: Hex -} -``` - -## Return Value - -The function returns a promise that resolves to a boolean indicating whether the module is installed. - -```typescript -Promise -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - validatorAddress: "0x1234567890123456789012345678901234567890" -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Check if a specific validator is installed -const isK1ValidatorInstalled = await nexusClient.isModuleInstalled({ - module: { - type: "validator", - address: nexusAccount.validatorAddress, - initData: "0x" - } -}); - -console.log("Is K1 validator installed:", isK1ValidatorInstalled); -``` - -## Implementation Details - -The function makes a view call to the smart account contract to check if the module with the given type and address is installed. It checks the appropriate registry based on the module type: - -- For validators, it looks in the validator registry -- For executors, it looks in the executor registry -- For hooks, it looks in the hooks registry -- For fallbacks, it checks the fallback handlers - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/prepareTokenPaymasterUserOp.md b/docs/pages/sdk-reference/bundler-client/methods/more/prepareTokenPaymasterUserOp.md deleted file mode 100644 index bc1a2e4..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/prepareTokenPaymasterUserOp.md +++ /dev/null @@ -1,118 +0,0 @@ -# prepareTokenPaymasterUserOp - -The `prepareTokenPaymasterUserOp` function prepares a user operation that can pay for gas fees using ERC-20 tokens instead of the native blockchain token. This is useful for enabling gasless transactions where users can pay with stablecoins or other tokens. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const userOp = await nexusClient.prepareTokenPaymasterUserOp({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x" - } - ], - feeTokenAddress: "0x036cbd53842c5426634e7929541ec2318f3dcf7e" // USDC on Base Sepolia -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type PrepareTokenPaymasterUserOpParameters = { - /** Array of transactions to be executed */ - calls: Transaction[] - /** Token used for paying for the gas */ - feeTokenAddress: Address - /** Optional custom approval amount for the token paymaster. If not provided, max uint256 will be used */ - customApprovalAmount?: bigint -} - -type Transaction = { - to: Address - data: `0x${string}` - value: bigint -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| calls | `Transaction[]` | Array of transactions to be executed. | -| feeTokenAddress | `Address` | The address of the ERC-20 token to use for paying gas fees. | -| customApprovalAmount | `bigint` | Optional. The amount to approve for the token paymaster. If not provided, unlimited approval (max uint256) will be used. | - -## Return Value - -The function returns a promise that resolves to a user operation object without a signature, which can later be signed and sent. - -```typescript -Promise, "signature">> -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// USDC token address on Base Sepolia -const baseSepoliaUSDCAddress = "0x036cbd53842c5426634e7929541ec2318f3dcf7e"; - -// Create a user operation that uses USDC for gas payment -const userOp = await nexusClient.prepareTokenPaymasterUserOp({ - calls: [ - { - to: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", - value: 1n, - data: "0x" - } - ], - feeTokenAddress: baseSepoliaUSDCAddress, - customApprovalAmount: 10000000n // Approve 10 USDC (assuming 6 decimals) -}); - -// Now you can send the user operation -const hash = await nexusClient.sendUserOperation(userOp); -console.log("User operation hash:", hash); -``` - -## Implementation Details - -The function creates a user operation that includes two parts: -1. An ERC-20 approval transaction that allows the token paymaster contract to spend tokens on behalf of the smart account -2. The original transactions provided in the `calls` parameter - -The token approval is automatically added as the first transaction in the batch. By default, the function approves the maximum possible amount (unlimited approval), but this can be customized using the `customApprovalAmount` parameter. - -This function is commonly used in conjunction with a properly configured paymaster context that specifies ERC-20 token payment. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/prepareUserOperation.md b/docs/pages/sdk-reference/bundler-client/methods/more/prepareUserOperation.md deleted file mode 100644 index 882fd2b..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/prepareUserOperation.md +++ /dev/null @@ -1,64 +0,0 @@ -# prepareUserOperation - -This method prepares a User Operation for execution by filling in missing properties. It's useful when you want to construct a User Operation before sending it. - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" -import { parseEther } from "viem" - -// Prepare a user operation -const userOperation = await bicoBundlerClient.prepareUserOperation({ - calls: [{ - to: '0x70997970c51812dc3a010c7d01b50e0d17dc79c8', - value: parseEther('1') - }] -}) -``` - -```typescript [bicoBundlerClient.ts] -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -## Parameters - -- `calls` `{ data?: Hex, to: Address, value?: bigint }[]`: Array of transactions to execute -- `callGasLimit` `bigint` (optional): Amount of gas to allocate for the main execution call -- `maxFeePerGas` `bigint` (optional): Maximum fee per gas for User Operation execution -- `maxPriorityFeePerGas` `bigint` (optional): Maximum priority fee per gas -- `nonce` `bigint` (optional): Nonce for the User Operation -- `paymaster` `Address | true | PaymasterClient` (optional): Paymaster configuration for gas sponsorship -- `paymasterData` `Hex` (optional): Call data to execute on the Paymaster contract -- `signature` `Hex` (optional): Signature for the User Operation -- `verificationGasLimit` `bigint` (optional): Gas to allocate for verification -- `preVerificationGas` `bigint` (optional): Extra gas to pay the Bundler - -## Returns - -Returns a prepared `UserOperation` object that can be used with `sendUserOperation`. - -## Related Methods - -- [sendUserOperation](/sdk-reference/bundler-client/methods/sendUserOperation) -- [debugUserOperation](/sdk-reference/bundler-client/methods/debugUserOperation) \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/prepareUserOperationWithoutSignature.md b/docs/pages/sdk-reference/bundler-client/methods/more/prepareUserOperationWithoutSignature.md deleted file mode 100644 index 8b0c362..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/prepareUserOperationWithoutSignature.md +++ /dev/null @@ -1,145 +0,0 @@ -# prepareUserOperationWithoutSignature - -The `prepareUserOperationWithoutSignature` function prepares a user operation without adding a signature. This allows for additional modifications to the user operation before it is signed and sent to the network. It also supports applying gas buffers to ensure transactions don't fail due to gas estimation issues. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// This is exposed through the prepareUserOperation method -const userOp = await nexusClient.prepareUserOperation({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x" - } - ], - gasBuffer: { - factor: 1.2, - fields: ["preVerificationGas", "verificationGasLimit"] - } -}); -``` - -## Parameters - -The function accepts all the same parameters as the standard `prepareUserOperation` function, plus an optional `gasBuffer` parameter: - -```typescript -type PrepareUserOperationParameters< - account extends SmartAccount | undefined, - accountOverride extends SmartAccount | undefined = undefined, - const calls extends readonly unknown[] = readonly unknown[], - const request extends PrepareUserOperationRequest = PrepareUserOperationRequest -> & GasBufferFactor - -type GasBufferFactor = { - gasBuffer?: { - /** The factor to multiply the gas limit by */ - factor: number - /** The fields to apply the gas buffer to */ - fields: GasBufferFields[] - } -} - -type GasBufferFields = "preVerificationGas" | "verificationGasLimit" | "callGasLimit" | "maxFeePerGas" | "maxPriorityFeePerGas" | "paymasterVerificationGasLimit" | "paymasterPostOpGasLimit" -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| calls | `Call[]` | Array of transactions to execute. | -| gasBuffer | `GasBufferFactor` | Optional. Configuration for applying a safety margin to gas estimates. | -| maxFeePerGas | `bigint` | Optional. The maximum fee per gas to pay for the transaction. | -| maxPriorityFeePerGas | `bigint` | Optional. The maximum priority fee per gas to pay for the transaction. | -| nonce | `bigint` | Optional. The nonce to use for the transaction. | - -## Return Value - -The function returns a promise that resolves to a user operation object without a signature, which can later be signed and sent. - -```typescript -Promise, "signature">> -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Prepare a user operation with gas buffer -const userOp = await nexusClient.prepareUserOperation({ - calls: [ - { - to: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", - value: 1n, - data: "0x" - } - ], - gasBuffer: { - factor: 1.2, // Apply a 20% buffer - fields: ["preVerificationGas", "verificationGasLimit"] - } -}); - -// You can now make additional modifications to the user operation -const modifiedUserOp = { - ...userOp, - // Custom modifications -}; - -// Then send it -const hash = await nexusClient.sendUserOperation(modifiedUserOp); -console.log("User operation hash:", hash); -``` - -## Implementation Details - -The function extends the standard `prepareUserOperation` functionality by: - -1. Preparing the user operation using the standard `prepareUserOperation` action -2. If a `gasBuffer` is specified, applying the buffer factor to the specified gas fields -3. Removing the signature from the user operation (if it exists) - -This is useful when you need to: -- Apply custom gas buffers to ensure transactions don't fail due to gas estimation inaccuracies -- Make additional modifications to the user operation before sending it -- Create complex transaction workflows that require manual adjustments to the user operation - -The gas buffer can be applied to any of the following fields: -- `preVerificationGas` -- `verificationGasLimit` -- `callGasLimit` -- `maxFeePerGas` -- `maxPriorityFeePerGas` -- `paymasterVerificationGasLimit` -- `paymasterPostOpGasLimit` \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/sendTokenPaymasterUserOp.md b/docs/pages/sdk-reference/bundler-client/methods/more/sendTokenPaymasterUserOp.md deleted file mode 100644 index eb2a93a..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/sendTokenPaymasterUserOp.md +++ /dev/null @@ -1,123 +0,0 @@ -# sendTokenPaymasterUserOp - -The `sendTokenPaymasterUserOp` function allows you to send transactions and pay for gas fees using ERC-20 tokens instead of the native blockchain token. This is a convenient way to enable gasless transactions where users can pay with stablecoins or other tokens. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const hash = await nexusClient.sendTokenPaymasterUserOp({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x" - } - ], - feeTokenAddress: "0x036cbd53842c5426634e7929541ec2318f3dcf7e" // USDC on Base Sepolia -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type SendTokenPaymasterUserOpParameters = { - calls: Transaction[] - feeTokenAddress: Address - customApprovalAmount?: bigint -} - -type Transaction = { - to: Address - data: `0x${string}` - value: bigint -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| calls | `Transaction[]` | Array of transactions to be executed. | -| feeTokenAddress | `Address` | The address of the ERC-20 token to use for paying gas fees. | -| customApprovalAmount | `bigint` | Optional. The amount to approve for the token paymaster. If not provided, unlimited approval (max uint256) will be used. | - -## Return Value - -The function returns a promise that resolves to the hash of the user operation as a hexadecimal string. - -```typescript -Promise -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v3/84532/your-paymaster-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client with paymaster configuration -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl), - paymaster: createBicoPaymasterClient({ - transport: http(paymasterUrl) - }), - paymasterContext: toBiconomyTokenPaymasterContext({ - feeTokenAddress: "0x036cbd53842c5426634e7929541ec2318f3dcf7e" // USDC on Base Sepolia - }) -}); - -// Send a transaction paying for gas with USDC -const hash = await nexusClient.sendTokenPaymasterUserOp({ - calls: [ - { - to: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", - value: 1n, - data: "0x" - } - ], - feeTokenAddress: "0x036cbd53842c5426634e7929541ec2318f3dcf7e", // USDC on Base Sepolia - customApprovalAmount: 10000000n // Approve 10 USDC (assuming 6 decimals) -}); - -// Wait for the transaction to be confirmed -const receipt = await nexusClient.waitForUserOperationReceipt({ hash }); -console.log("Transaction success:", receipt.success); -``` - -## Implementation Details - -The function combines the steps of preparing and sending a token paymaster user operation: - -1. It creates a combined transaction array that includes: - - An ERC-20 approval transaction to grant the token paymaster contract permission to spend tokens - - The original transactions specified in the `calls` parameter - -2. It prepares the user operation with these transactions using `prepareTokenPaymasterUserOp` - -3. It sends the prepared user operation to the network using `sendUserOperation` - -By default, the function approves the maximum possible amount (unlimited approval), but this can be customized using the `customApprovalAmount` parameter. This function requires that the client is configured with a proper paymaster and paymaster context. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/sendTransaction.md b/docs/pages/sdk-reference/bundler-client/methods/more/sendTransaction.md deleted file mode 100644 index 7f36686..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/sendTransaction.md +++ /dev/null @@ -1,178 +0,0 @@ -# sendTransaction - -The `sendTransaction` function creates, signs, and sends a transaction using a smart account. This function supports both single transactions and batched calls, and can leverage sponsorship (gas abstraction) if a paymaster is configured. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Single transaction -const hash = await nexusClient.sendTransaction({ - to: recipientAddress, - value: 1000000000000000n, // 0.001 ETH - data: "0x" -}); - -// Batched transactions -const hash = await nexusClient.sendTransaction({ - calls: [ - { - to: recipientAddress, - value: 1000000000000000n, - data: "0x" - }, - { - to: contractAddress, - value: 0n, - data: "0x..." // encoded contract call - } - ] -}); -``` - -## Parameters - -The function accepts either a single transaction or a batch of transactions: - -### Single Transaction - -```typescript -type SendTransactionParameters = { - to: Address - value?: bigint - data?: Hex - account?: SmartAccount - maxFeePerGas?: bigint - maxPriorityFeePerGas?: bigint - nonce?: bigint -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| to | `Address` | The recipient address. | -| value | `bigint` | Optional. The amount of ether to send in wei. | -| data | `Hex` | Optional. The call data for the transaction. | -| account | `SmartAccount` | Optional. The smart account to use. If not provided, the client's account will be used. | -| maxFeePerGas | `bigint` | Optional. The maximum fee per gas to pay for the transaction. | -| maxPriorityFeePerGas | `bigint` | Optional. The maximum priority fee per gas to pay for the transaction. | -| nonce | `bigint` | Optional. The nonce to use for the transaction. | - -### Batched Transactions - -```typescript -type SendTransactionParameters = SendUserOperationParameters -``` - -Which includes: - -| Parameter | Type | Description | -| --- | --- | --- | -| calls | `Call[]` | Array of transactions to execute. | -| account | `SmartAccount` | Optional. The smart account to use. If not provided, the client's account will be used. | -| maxFeePerGas | `bigint` | Optional. The maximum fee per gas to pay for the transaction. | -| maxPriorityFeePerGas | `bigint` | Optional. The maximum priority fee per gas to pay for the transaction. | -| nonce | `bigint` | Optional. The nonce to use for the transaction. | - -## Return Value - -The function returns a promise that resolves to the transaction hash as a hexadecimal string. - -```typescript -Promise -``` - -## Example - -```typescript -import { http, parseEther, encodeFunctionData } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Example 1: Simple ETH transfer -const transferHash = await nexusClient.sendTransaction({ - to: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", - value: parseEther("0.001"), - data: "0x" -}); - -console.log("Transfer transaction hash:", transferHash); - -// Example 2: Contract interaction -const contractAddress = "0x..."; // Your contract address -const contractABI = [...]; // Your contract ABI -const encodedCallData = encodeFunctionData({ - abi: contractABI, - functionName: "setMessage", - args: ["Hello from Biconomy!"] -}); - -const contractHash = await nexusClient.sendTransaction({ - to: contractAddress, - value: 0n, - data: encodedCallData -}); - -console.log("Contract transaction hash:", contractHash); - -// Example 3: Batch transactions -const batchHash = await nexusClient.sendTransaction({ - calls: [ - { - to: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", - value: parseEther("0.001"), - data: "0x" - }, - { - to: contractAddress, - value: 0n, - data: encodedCallData - } - ] -}); - -console.log("Batch transaction hash:", batchHash); -``` - -## Implementation Details - -The function handles both single transactions and batched transactions: - -1. For a single transaction (when `to` is present in the parameters): - - It converts the single transaction into a user operation with a single call - - It sends the user operation using `sendUserOperation` - -2. For batched transactions (when `calls` is present in the parameters): - - It directly forwards the parameters to `sendUserOperation` - -3. After the user operation is sent, it waits for the operation receipt using `waitForUserOperationReceipt` - -4. It returns the actual transaction hash from the receipt rather than the user operation hash - -This function is particularly useful for smart accounts since it abstracts away the complexities of user operations while providing the familiar transaction sending interface. When a paymaster is configured on the client, transactions can be sponsored (gasless) or paid with ERC-20 tokens. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/signMessage.md b/docs/pages/sdk-reference/bundler-client/methods/more/signMessage.md deleted file mode 100644 index f4fe225..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/signMessage.md +++ /dev/null @@ -1,103 +0,0 @@ -# signMessage - -The `signMessage` function allows a smart account to sign a message according to [EIP-191 format](https://eips.ethereum.org/EIPS/eip-191). It creates a signature that can be used for verifying the identity of the smart account. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const signature = await nexusClient.signMessage({ - message: "Hello, Biconomy!" -}); - -console.log(signature); // '0x...' -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type SignMessageParameters = { - message: string | Uint8Array - account?: SmartAccount -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| message | `string \| Uint8Array` | The message to sign. Can be a string or byte array. | -| account | `SmartAccount` | Optional. The smart account to use for signing. If not provided, the client's account will be used. | - -## Return Value - -The function returns a promise that resolves to the signature as a hexadecimal string. - -```typescript -Promise -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Sign a message -try { - const message = "I am verifying my ownership of this smart account"; - const signature = await nexusClient.signMessage({ - message - }); - - console.log("Message:", message); - console.log("Signature:", signature); - - // This signature can now be verified by third parties to confirm - // that the message was signed by this smart account -} catch (error) { - console.error("Error signing message:", error); -} -``` - -## Implementation Details - -The function performs the following operations: - -1. It checks if an account exists (either provided in the parameters or using the client's account) -2. It parses the account to ensure it's a valid smart account -3. It delegates the signing operation to the smart account's `signMessage` method - -The signature is created using the Ethereum-specific personal signature format: -`keccak256("\x19Ethereum Signed Message:\n" + len(message) + message))` - -This format prefixes the message with the string "\x19Ethereum Signed Message:\n" followed by the length of the message, which helps prevent malicious DApps from tricking users into signing transactions that look like regular messages. - -Smart accounts can implement their own method of signing messages that may differ from EOA (Externally Owned Account) signatures, depending on their architecture and implementation. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/signTypedData.md b/docs/pages/sdk-reference/bundler-client/methods/more/signTypedData.md deleted file mode 100644 index 11205d2..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/signTypedData.md +++ /dev/null @@ -1,73 +0,0 @@ -# signTypedData - -Signs typed data in EIP-712 format using a smart account. - -## Usage - -```typescript -import { createNexusClient, createEOA } from "@biconomy/abstractjs"; - -const client = createNexusClient({ - chain: 'base-sepolia', - eoa: createEOA({ - privateKey: '0xYOUR_PRIVATE_KEY' - }) -}); - -const domain = { - name: 'Ether Mail', - version: '1', - chainId: 1, - verifyingContract: '0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC' -}; - -const types = { - Person: [ - { name: 'name', type: 'string' }, - { name: 'wallet', type: 'address' } - ], - Mail: [ - { name: 'from', type: 'Person' }, - { name: 'to', type: 'Person' }, - { name: 'contents', type: 'string' } - ] -}; - -const message = { - from: { - name: 'Cow', - wallet: '0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826' - }, - to: { - name: 'Bob', - wallet: '0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB' - }, - contents: 'Hello, Bob!' -}; - -const signature = await client.signTypedData({ - domain, - types, - primaryType: 'Mail', - message -}); -``` - -## Parameters - -- `account` (optional): The smart account instance to use for signing. Defaults to the client's account. -- `domain`: The domain object containing name, version, chainId, and verifyingContract. -- `message`: The structured data to sign. -- `primaryType`: The primary type of the message. -- `types`: Type definitions for the structured data. - -## Return Value - -- `string`: The signature as a hexadecimal string. - -## Implementation Details - -The function calculates an Ethereum-specific signature in [EIP-712 format](https://eips.ethereum.org/EIPS/eip-712) using the formula: -`sign(keccak256("\x19\x01" ‖ domainSeparator ‖ hashStruct(message)))`. - -It internally validates the typed data and uses the smart account's `signTypedData` method to generate the signature. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/supportsExecutionMode.md b/docs/pages/sdk-reference/bundler-client/methods/more/supportsExecutionMode.md deleted file mode 100644 index 29e7ae3..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/supportsExecutionMode.md +++ /dev/null @@ -1,116 +0,0 @@ -# supportsExecutionMode - -The `supportsExecutionMode` function checks whether an ERC-7579 compliant smart account supports a specific execution mode such as `call` or `delegatecall`. This allows you to verify that the account can execute transactions in a certain way before attempting to do so. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const supportsDelegateCall = await nexusClient.supportsExecutionMode({ - type: 'delegatecall' -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type SupportsExecutionModeParameters< - TSmartAccount extends SmartAccount | undefined, - callType extends CallType = CallType -> = { - account?: TSmartAccount -} & ExecutionMode - -type ExecutionMode = { - type: callType - revertOnError?: boolean - selector?: Hex - data?: Hex -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| type | `CallType` | The type of execution to check support for. Valid values are 'call', 'delegatecall', 'staticcall', or 'create'. | -| revertOnError | `boolean` | Optional. Whether the execution should revert on error. Default is false. | -| selector | `Hex` | Optional. The function selector to check support for. | -| data | `Hex` | Optional. Additional data for the check. | - -## Return Value - -The function returns a promise that resolves to a boolean indicating whether the specified execution mode is supported. - -```typescript -Promise -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Check support for different execution modes -const supportsCall = await nexusClient.supportsExecutionMode({ type: "call" }); -const supportsDelegateCall = await nexusClient.supportsExecutionMode({ type: "delegatecall" }); -const supportsStaticCall = await nexusClient.supportsExecutionMode({ type: "staticcall" }); -const supportsCreate = await nexusClient.supportsExecutionMode({ type: "create" }); - -console.log("Supports call:", supportsCall); -console.log("Supports delegatecall:", supportsDelegateCall); -console.log("Supports staticcall:", supportsStaticCall); -console.log("Supports create:", supportsCreate); - -// Check support for a specific execution mode with additional parameters -const supportsSpecificExecution = await nexusClient.supportsExecutionMode({ - type: "call", - revertOnError: true, - selector: "0xcb5baf0f" -}); - -console.log("Supports specific execution:", supportsSpecificExecution); -``` - -## Implementation Details - -The function makes a view call to the `supportsExecutionMode` method on the smart account contract, passing an encoded representation of the execution mode as an argument. The execution mode is encoded as a byte string that includes the call type, whether to revert on error, and optional selector and data fields. - -The call type is encoded as a numeric value: -- 'call' → 0 -- 'delegatecall' → 1 -- 'staticcall' → 2 -- 'create' → 3 - -The returned boolean indicates whether the smart account implementation supports the specified execution mode. This check is important because different smart account implementations might support different sets of execution modes. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/supportsModule.md b/docs/pages/sdk-reference/bundler-client/methods/more/supportsModule.md deleted file mode 100644 index aa714b7..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/supportsModule.md +++ /dev/null @@ -1,95 +0,0 @@ -# supportsModule - -The `supportsModule` function checks whether an ERC-7579 compliant smart account supports a specific type of module (validator, executor, hook, or fallback). This allows you to verify that the account can work with a certain type of module before attempting to install one. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const supportsValidators = await nexusClient.supportsModule({ - type: 'validator' -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type SupportsModuleParameters = { - account?: TSmartAccount -} & { - type: 'validator' | 'executor' | 'hook' | 'fallback' -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| type | `string` | The type of module to check support for. Valid values are 'validator', 'executor', 'hook', or 'fallback'. | - -## Return Value - -The function returns a promise that resolves to a boolean indicating whether the specified module type is supported. - -```typescript -Promise -``` - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Check support for different module types -const supportsValidator = await nexusClient.supportsModule({ type: "validator" }); -const supportsExecutor = await nexusClient.supportsModule({ type: "executor" }); -const supportsHook = await nexusClient.supportsModule({ type: "hook" }); -const supportsFallback = await nexusClient.supportsModule({ type: "fallback" }); - -console.log("Supports validators:", supportsValidator); -console.log("Supports executors:", supportsExecutor); -console.log("Supports hooks:", supportsHook); -console.log("Supports fallbacks:", supportsFallback); -``` - -## Implementation Details - -The function makes a view call to the `supportsModule` method on the smart account contract, passing the appropriate module type ID as an argument. The module type ID is determined using the following mapping: - -- 'validator' → 1 -- 'executor' → 2 -- 'hook' → 3 -- 'fallback' → 4 - -The returned boolean indicates whether the smart account implementation supports the specified module type. This check is important because different smart account implementations might support different sets of module types. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/uninstallModule.md b/docs/pages/sdk-reference/bundler-client/methods/more/uninstallModule.md deleted file mode 100644 index 0c29477..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/uninstallModule.md +++ /dev/null @@ -1,119 +0,0 @@ -# uninstallModule - -The `uninstallModule` function removes a module from an ERC-7579 compliant smart account. This can be used to remove validators, executors, or hooks that are no longer needed. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -const hash = await nexusClient.uninstallModule({ - module: { - type: 'validator', - address: validatorAddress, - initData: '0x' - } -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type UninstallModuleParameters = { - account?: TSmartAccount -} & { - module: ModuleMeta - maxFeePerGas?: bigint - maxPriorityFeePerGas?: bigint - nonce?: bigint -} & Partial, "callData">> -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| account | `SmartAccount` | Optional. The smart account instance to use. If not provided, the client's account will be used. | -| module | `ModuleMeta` | The module to uninstall, containing type, address, and initialization data. | -| maxFeePerGas | `bigint` | Optional. The maximum fee per gas to pay for the transaction. | -| maxPriorityFeePerGas | `bigint` | Optional. The maximum priority fee per gas to pay for the transaction. | -| nonce | `bigint` | Optional. The nonce to use for the transaction. | - -The `ModuleMeta` type includes: - -```typescript -type ModuleMeta = { - type: 'validator' | 'executor' | 'hook' | 'fallback' - address: Address - initData?: Hex -} -``` - -## Return Value - -The function returns a promise that resolves to the hash of the user operation as a hexadecimal string. - -```typescript -Promise -``` - -## Example - -```typescript -import { http, encodePacked } from "viem"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Uninstall a validator module -const validatorAddress = "0x1234567890123456789012345678901234567890"; -const hash = await nexusClient.uninstallModule({ - module: { - type: 'validator', - address: validatorAddress, - initData: encodePacked(["address"], [account.address]) - } -}); - -// Wait for the transaction to be confirmed -const receipt = await nexusClient.waitForUserOperationReceipt({ hash }); -console.log("Module uninstallation success:", receipt.success); -``` - -## Implementation Details - -The function creates a transaction that calls the `uninstallModule` method on the smart account contract with the module type and address as parameters. - -The function determines the appropriate method to call based on the module type: -- For validators, it calls `uninstallValidator` -- For executors, it calls `uninstallExecutor` -- For hooks, it calls `uninstallHook` -- For fallbacks, it calls `uninstallFallback` - -The function then sends the transaction as a user operation through the bundler network. - -This function is part of the ERC-7579 standard for smart accounts, which provides a standardized way to interact with modular smart accounts. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/more/waitForConfirmedUserOperationReceipt.md b/docs/pages/sdk-reference/bundler-client/methods/more/waitForConfirmedUserOperationReceipt.md deleted file mode 100644 index 8c97b70..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/more/waitForConfirmedUserOperationReceipt.md +++ /dev/null @@ -1,118 +0,0 @@ -# waitForConfirmedUserOperationReceipt - -The `waitForConfirmedUserOperationReceipt` function allows you to wait for a user operation to be confirmed on the blockchain and receive its receipt. This is useful for ensuring that a transaction has been included in a block before proceeding with subsequent operations. - -## Usage - -```typescript -import { createBicoBundlerClient } from "@biconomy/abstractjs"; -import { http } from "viem"; - -const bicoBundlerClient = createBicoBundlerClient({ - bundlerUrl: "https://bundler.biconomy.io/api/v3/5/your-api-key", - account: nexusAccount -}); - -// After sending a user operation and receiving a hash -const userOpHash = "0x..."; // The hash returned from sendUserOperation -const receipt = await bicoBundlerClient.waitForConfirmedUserOperationReceipt({ - hash: userOpHash -}); -``` - -## Parameters - -The function accepts an object with the following properties: - -```typescript -type GetUserOperationStatusParameters = { - /** The hash of the User Operation. */ - hash: Hex -} -``` - -| Parameter | Type | Description | -| --- | --- | --- | -| hash | `Hex` | The hash of the user operation to wait for. This is the hash returned by the `sendUserOperation` function. | - -## Return Value - -The function returns a promise that resolves to a `UserOperationReceipt` object containing information about the confirmed operation: - -```typescript -type UserOperationReceipt = { - userOpHash: Hex - entryPoint: Address - sender: Address - nonce: bigint - paymaster?: Address - actualGasUsed: bigint - actualGasCost: bigint - success: string - reason?: string - logs: Log[] - receipt: TransactionReceipt -} -``` - -The receipt contains details about the user operation such as the sender, gas used, cost, success status, and the transaction receipt. - -## Example - -```typescript -import { http } from "viem"; -import { createBicoBundlerClient, toNexusAccount, createBicoBundlerClient } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; - -// Set up your account -const privateKey = "YOUR_PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/your-api-key"; - -// Create Nexus account -const nexusAccount = await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), -}); - -// Create client -const nexusClient = createBicoBundlerClient({ - account: nexusAccount, - transport: http(bundlerUrl) -}); - -// Send a user operation -const recipientAddress = "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"; // Example address -const hash = await nexusClient.sendUserOperation({ - calls: [ - { - to: recipientAddress, - value: 1n - } - ] -}); - -// Wait for the user operation to be confirmed -console.log("Waiting for user operation to be confirmed..."); -const receipt = await nexusClient.waitForConfirmedUserOperationReceipt({ - hash -}); - -// Check the receipt information -console.log("User operation confirmed!"); -console.log("Success:", receipt.success); -console.log("Gas used:", receipt.actualGasUsed.toString()); -console.log("Gas cost:", receipt.actualGasCost.toString()); -``` - -## Implementation Details - -The function repeatedly checks the status of a user operation using the `getUserOperationStatus` function until it reaches a final state: - -1. If the operation is `CONFIRMED`, it returns the user operation receipt. -2. If the operation is `REJECTED`, it throws an error with the failure message. -3. If the operation is still `PENDING`, it waits for the configured polling interval and checks again. - -This provides a convenient way to wait for user operations to complete without manually implementing polling logic. \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/prepareTokenPaymasterUserOp.md b/docs/pages/sdk-reference/bundler-client/methods/prepareTokenPaymasterUserOp.md deleted file mode 100644 index 868b759..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/prepareTokenPaymasterUserOp.md +++ /dev/null @@ -1,65 +0,0 @@ - # prepareTokenPaymasterUserOp - -This method prepares a user operation with token paymaster configuration, including ERC20 token approval. It handles: -1. Checking current token allowance of Smart Account -2. Creating an approval transaction for the token paymaster if needed -3. Preparing the user operation with the approval and user transactions - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -const userOp = await bicoBundlerClient.prepareTokenPaymasterUserOp({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x" - } - ], - feeTokenAddress: "0x...", // ERC20 token address - customApprovalAmount: usdcFeeAmount // optional -}) -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - - -::: - -## Parameters - -- `calls` `{ to: Address, data: Hex, value: bigint }[]`: Array of transactions to be executed -- `feeTokenAddress` `Address`: Token address used for paying for the gas -- `customApprovalAmount` `bigint` (optional): Custom approval amount for the token paymaster. If not provided, max uint256 will be used - -## Response - -- `Promise, "signature">>`: Returns a prepared user operation without signature (will be signed by the Smart Account when sent) - -## Error Handling - -The method will throw an error if: -- Client account is not properly configured -- Paymaster context is not properly configured \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/sendTokenPaymasterUserOp.md b/docs/pages/sdk-reference/bundler-client/methods/sendTokenPaymasterUserOp.md deleted file mode 100644 index 2cc7422..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/sendTokenPaymasterUserOp.md +++ /dev/null @@ -1,72 +0,0 @@ -# sendTokenPaymasterUserOp - -This method combines the preparation and sending of a user operation that uses token paymaster for gas payment. It handles the entire flow of: -1. Preparing the user operation with token paymaster configuration -2. Adding token approval if needed -3. Signing and sending the operation - -## Usage - -:::code-group - -```typescript [example.ts] -import { createBicoBundlerClient } from "./bicoBundlerClient" - -const hash = await bicoBundlerClient.sendTokenPaymasterUserOp({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x" - } - ], - feeTokenAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC address -}) -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}) -``` - -::: - -## Parameters - -- `calls` `{ to: Address, data: Hex, value: bigint }[]`: Array of transactions to be executed -- `feeTokenAddress` `Address`: The ERC20 token address to be used for paying gas fees -- `customApprovalAmount` `bigint` (optional): Custom approval amount for the token paymaster -- `maxFeePerGas` `bigint` (optional): Maximum fee per gas unit -- `maxPriorityFeePerGas` `bigint` (optional): Maximum priority fee per gas unit - -## Response - -- `Promise`: Returns the transaction hash of the submitted user operation - -## Error Handling - -The method will throw an error if: -- The client account is not properly configured -- The paymaster context is missing or invalid -- Token approval fails -- User operation submission fails - -## Related Methods - -- [prepareTokenPaymasterUserOp](./prepareTokenPaymasterUserOp.md) - If you need more control over the preparation step -- [sendTransaction](./more/sendTransaction.md) - For sending transactions without token paymaster \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/sendUserOperation.md b/docs/pages/sdk-reference/bundler-client/methods/sendUserOperation.md deleted file mode 100644 index e3acec8..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/sendUserOperation.md +++ /dev/null @@ -1,113 +0,0 @@ -# sendUserOperation {#sendtransaction} - -Broadcasts a User Operation to the Bundler. This method allows you to execute one or more transactions through your Smart Account. - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" -import { parseEther } from 'viem' - -// Simple ETH transfer -const hash = await bicoBundlerClient.sendUserOperation({ - calls: [{ - to: '0x70997970c51812dc3a010c7d01b50e0d17dc79c8', - value: parseEther('1') - }] -}) - -// Multiple calls including contract interaction -const hash2 = await bicoBundlerClient.sendUserOperation({ - calls: [ - { - to: '0x70997970c51812dc3a010c7d01b50e0d17dc79c8', - value: parseEther('1') - }, - { - abi: wagmiAbi, - functionName: 'mint', - to: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2', - } - ] -}) -``` -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}); -``` - -::: - -## Parameters - -### Required Parameters -- `calls` `({ data?: Hex, to: Address, value?: bigint } | { abi: Abi, functionName: string, args: unknown[], to: Address, value?: bigint })[]`: Array of transactions to execute - -### Optional Parameters -- `maxFeePerGas` `bigint`: Maximum fee per gas for User Operation execution -- `maxPriorityFeePerGas` `bigint`: Maximum priority fee per gas -- `callGasLimit` `bigint`: Amount of gas to allocate for the main execution call -- `verificationGasLimit` `bigint`: Amount of gas to allocate for the verification step -- `preVerificationGas` `bigint`: Extra gas to pay the Bundler -- `nonce` `bigint`: Nonce for the User Operation -- `paymaster` `Address | true | PaymasterClient | PaymasterAction`: Paymaster configuration for gas sponsorship -- `paymasterData` `Hex`: Call data to execute on the Paymaster contract (when paymaster is an address) -- `paymasterVerificationGasLimit` `bigint`: Gas limit for paymaster validation -- `paymasterPostOpGasLimit` `bigint`: Gas limit for paymaster post-operation code -- `signature` `Hex`: Custom signature for the User Operation - -## Response - -- `Promise`: Returns the User Operation hash - -## Paymaster Configuration - -The `paymaster` parameter supports multiple configurations: - -```typescript -// Using a Paymaster address -const hash = await bicoBundlerClient.sendUserOperation({ - calls: [...], - paymaster: '0x942fD5017c0F60575930D8574Eaca13BEcD6e1bB', - paymasterData: '0xdeadbeef' -}) - -// Using a Paymaster Client -const hash = await bicoBundlerClient.sendUserOperation({ - calls: [...], - paymaster: paymasterClient, - paymasterContext: { - policyId: 'abc123' - } -}) -``` - -## Error Handling - -The method will throw an error if: -- The client account is not properly configured -- User operation preparation fails -- Bundler rejects the operation -- Gas estimation fails - -## Related Methods - -- [waitForUserOperationReceipt](./waitForUserOperationReceipt.md) - Wait for operation confirmation -- [prepareUserOperation](./more/prepareUserOperation.md) - Prepare operation without sending \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/upgradeSmartAccount.md b/docs/pages/sdk-reference/bundler-client/methods/upgradeSmartAccount.md deleted file mode 100644 index 3df95cd..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/upgradeSmartAccount.md +++ /dev/null @@ -1,164 +0,0 @@ -# upgradeSmartAccount - -This method upgrades a Nexus smart account to a new implementation, allowing an easy path to migration to the latest features, security fixes, and performance improvements while preserving your account's address, balance, and history. - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient"; - -// Upgrade the smart account to the latest implementation -const upgradeHash = await bicoBundlerClient.upgradeSmartAccount(); - -// Wait for the upgrade transaction to be confirmed -const receipt = await bicoBundlerClient.waitForUserOperationReceipt({ hash: upgradeHash }); -console.log("Upgrade successful:", receipt.success); -``` - -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - oldVersion: "0.0.33", // Specify the SDK version your users account was created with. Remember to store this in your application to access the upgraded account & balances moving forward - }), - transport: http(bundlerUrl), -}); -``` - -::: - -## Parameters - -- `implementationAddress` `Hex` (optional): Custom implementation address. If not provided, the latest default implementation will be used. -- `initData` `Hex` (optional): Initialization data to pass to the new implementation. Default is "0x". -- `maxFeePerGas` `bigint` (optional): Maximum fee per gas for User Operation execution. -- `maxPriorityFeePerGas` `bigint` (optional): Maximum priority fee per gas. -- `nonce` `bigint` (optional): Nonce for the User Operation. -- Other standard User Operation parameters are also supported. - -## Response - -- `Promise`: Returns the User Operation hash of the upgrade transaction. - -## Updating the AbstractJS Package - -:::warning[Important] -Before upgrading smart accounts, you should update the AbstractJS package to the latest version using your package manager. This ensures you have access to the latest implementation addresses and features. -::: - -:::code-group -```bash [npm] -npm update @biconomy/abstractjs -``` -```bash [yarn] -yarn upgrade @biconomy/abstractjs -``` -```bash [pnpm] -pnpm update @biconomy/abstractjs -``` -```bash [bun] -bun update @biconomy/abstractjs -``` -::: - -After updating the package, you should also update your application code to use any new APIs or handle any breaking changes in the latest version. - -## Migrating from Older Versions - -### Using the `oldVersion` Parameter - -When migrating from an older version of a Nexus smart account, the `oldVersion` parameter in `toNexusAccount` is crucial for connecting to accounts created with previous implementations. - -:::tip[Important for Migrations] -You must specify the `oldVersion` parameter when initializing your account to ensure you can access the correct account address and funds from older versions. -::: - -```typescript [migration-example.ts] -// Connect to an older version of the smart account -const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - oldVersion: "0.0.33", // Specify the SDK version your users account was created with. Remember to store this in your application to access the upgraded account & balances moving forward - }), - transport: http(bundlerUrl), -}); - -// Now upgrade to the latest version -const upgradeHash = await bicoBundlerClient.upgradeSmartAccount(); -``` - -## Migration Process - -1. **Update AbstractJS package**: Use your package manager to update to the latest version: `npm update @biconomy/abstractjs` -2. **Connect to existing account**: Use the `oldVersion` parameter to connect to the old account -3. **Upgrade implementation**: Call `upgradeSmartAccount()` to update it to the latest version -4. **Verify upgrade**: Test that the account works correctly after upgrading -5. **Update application**: Modify any code that depends on specific implementation details -6. **Store the version**: Store the users oldVersion in your application to access the upgraded account & balances moving forward - -## Advanced Usage - -### Custom Implementation and Parameters - -```typescript -import { parseGwei } from "viem"; - -// Upgrade with custom parameters -const upgradeHash = await bicoBundlerClient.upgradeSmartAccount({ - implementationAddress: '0x1234567890123456789012345678901234567890', - initData: '0x1234', - maxFeePerGas: parseGwei('20'), - maxPriorityFeePerGas: parseGwei('2'), -}); -``` - -### Verification After Upgrade - -```typescript -// Check the account ID after upgrade -const accountId = await bicoBundlerClient.accountId(); -console.log("New account ID:", accountId); - -// Test with a simple transaction -const testTxHash = await bicoBundlerClient.sendUserOperation({ - calls: [{ - to: "0x0000000000000000000000000000000000000000", - value: 0n, - data: "0x", - }], -}); -``` - -## Troubleshooting - -If the upgrade transaction fails, check: -- The account has sufficient funds for gas -- The account is deployed on-chain -- The implementation address is valid (if custom) -- You're using the correct `oldVersion` parameter if migrating from an older version -- You've updated to the latest AbstractJS package - -## When to Upgrade - -Consider upgrading your smart account when: -- A new implementation is released with security fixes -- New features are added that you want to utilize -- Performance improvements are available -- You need to migrate from an older version to maintain compatibility - -[Upgrade Smart Account SDK Test](https://github.com/bcnmy/abstractjs/blob/develop/src/sdk/clients/decorators/smartAccount/upgradeSmartAccount.test.ts) \ No newline at end of file diff --git a/docs/pages/sdk-reference/bundler-client/methods/waitForUserOperationReceipt.md b/docs/pages/sdk-reference/bundler-client/methods/waitForUserOperationReceipt.md deleted file mode 100644 index 0acae67..0000000 --- a/docs/pages/sdk-reference/bundler-client/methods/waitForUserOperationReceipt.md +++ /dev/null @@ -1,45 +0,0 @@ -# waitForUserOperationReceipt - -Waits for the User Operation to be included on a Block (one confirmation), and then returns the User Operation receipt. - -## Usage - -:::code-group - -```typescript [example.ts] -import { bicoBundlerClient } from "./bicoBundlerClient" - -const receipt = await bicoBundlerClient.waitForUserOperationReceipt({ - hash: '0x315a882b82eb33250b919da6ebb2dd890df39ca0840e4026cbbad595b9a07e86' -}) -``` -```typescript [bicoBundlerClient.ts] filename="bicoBundlerClient.ts" -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const bicoBundlerClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}); -``` - -::: - -## Parameters -- hash `'0x${string}'`: A Transaction hash. -- pollingInterval (optional) `number`: Polling frequency (in ms) -- retryCount (optional) `number`: The number of times to retry. Default value is 6. -- timeout (optional) `number`: Optional timeout (in ms) to wait before stopping polling. Default value is 5000. - -## Response -- receipt `Promise`: The User Operation receipt. \ No newline at end of file diff --git a/docs/pages/sdk-reference/index.mdx b/docs/pages/sdk-reference/index.mdx deleted file mode 100644 index 9487745..0000000 --- a/docs/pages/sdk-reference/index.mdx +++ /dev/null @@ -1,41 +0,0 @@ -# SDK Reference - -## Bundler Client vs MEE Client - -| Feature | MEE Client | 4337 Bundler Client | -|---------|-----------|---------------------| -| Cross-chain execution | ✅ | ❌ | -| Cross-chain gas payment | ✅ | ❌ | -| Transaction orchestration | ✅ | ❌ | -| Runtime composability | ✅ | ❌ | -| Intent-based execution | ✅ | ❌ | -| Support for EOAs | ✅ | ❌ | -| Single-chain gas abstraction | ✅ | ✅ | -| Batched transactions (same chain) | ✅ | ✅ | - -### When to Use MEE Client - -Choose the MEE Client when: -- Your application spans multiple blockchains -- You need cross-chain orchestration with a single signature -- You want to pay gas fees using tokens from any chain -- You need runtime composability between chains -- You're building complex DeFi workflows that operate across networks - -Unlike the traditional ERC-4337 Bundler Client which is limited to single-chain operations, the MEE Client is designed for cross-chain applications. The MEE Client is more complex and depends on the MEE infrastructure for cross-chain coordination. - -Choose MEE Client when building applications that: -- Span multiple blockchains -- Require complex transaction sequences -- Need to support both EOA and Smart Account users - -### When to Use Bundler Client - -Choose the Bundler Client when: -- Your application operates on a single blockchain -- You need standard ERC-4337 account abstraction features -- Performance on a single chain is prioritized -- You need direct control over transaction bundling - -The Bundler Client is limited to operations within a single chain - it cannot execute cross-chain transactions or pay for gas using tokens from different chains. - diff --git a/docs/pages/sdk-reference/mee-client/account/index.md b/docs/pages/sdk-reference/mee-client/account/index.md deleted file mode 100644 index 0adc9f0..0000000 --- a/docs/pages/sdk-reference/mee-client/account/index.md +++ /dev/null @@ -1,272 +0,0 @@ -# MultichainNexusAccount - -The `MultichainNexusAccount` is a powerful abstraction that allows you to manage a single smart account identity across multiple blockchains. It's the foundation for cross-chain operations with the MEE Client. - -## What is MultichainNexusAccount? - -A MultichainNexusAccount provides: - -- **Unified Identity**: The same smart account deployed across multiple networks -- **Consistent Address**: Same address on all EVM chains (except special cases like zkSync) -- **Unified Balances**: View and manage token balances across all chains -- **Cross-Chain Tools**: Bridge assets and execute transactions between chains -- **Instruction Building**: Create various types of instructions for the MEE Client - -## Creating a MultichainNexusAccount - -To create a MultichainNexusAccount, use the `toMultichainNexusAccount` function: - -```typescript -import { toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { optimism, base } from "viem/chains"; -import { privateKeyToAccount } from "viem/accounts"; -import { http } from "viem"; - -// Create your signer (could be any EOA - MetaMask, private key, etc.) -const eoaSigner = privateKeyToAccount("0x..." /* private key */); - -// Initialize multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base], // Which chains to support - transports: [http(), http()], // Transport for each chain (must match chains array) - signer: eoaSigner // The EOA that controls this account -}); -``` - -### Configuration Parameters - -| Parameter | Type | Required | Default | Description | -|-----------|------|----------|---------|-------------| -| chains | `Chain[]` | Yes | - | Array of chains the account will interact with | -| transports | `Transport[]` | Yes | - | Array of transports for each chain (must match the order of chains) | -| signer | `Account` | Yes | - | The signer account that controls the smart account | - -## Available Methods - -The `MultichainNexusAccount` provides several powerful methods to interact with blockchain networks and build cross-chain transactions. - -### Transaction Building Methods - -These methods help you create different types of instructions for cross-chain operations: - -- [**buildComposable**](/sdk-reference/mee-client/account/methods/buildComposable) - Create composable transactions with runtime parameter injection - -### Balance & Information Methods - -These methods provide information about your account and balances: - -- [**getUnifiedERC20Balance**](/sdk-reference/mee-client/account/methods/more/getUnifiedERC20Balance) - Get token balances across all chains -- **getAddress** - Get your account address on a specific chain -- **addressOn** - Get your account address on a specific chain (alternative syntax) -- **deploymentOn** - Get full deployment information for a specific chain - -### Bridge-Related Methods - -These methods provide information about bridging operations: - -- **queryBridge** - Query available bridge options for a particular token and chain pair -- [**waitForTransactionReceipts**](/sdk-reference/mee-client/account/methods/more/waitForTransactionReceipts) - Wait for multiple transaction receipts across different chains - -### Account Management Methods - -These methods handle account delegation and management: - -- [**isDelegated**](/sdk-reference/mee-client/account/methods/more/isDelegated) - Check if the eoa is delegated to a nexus account -- [**unDelegate**](/sdk-reference/mee-client/account/methods/more/unDelegate) - Remove delegation permissions from the eoa - -## Basic Usage Examples - -### Retrieving Account Addresses - -```typescript -// Get address on Base -const baseAddress = mcNexus.addressOn(base.id); -console.log(`My account address on Base: ${baseAddress}`); - -// Get full deployment info on Optimism -const optimismDeployment = mcNexus.deploymentOn(optimism.id); -console.log(`Deployment status: ${await optimismDeployment.isDeployed() ? 'Deployed' : 'Not deployed'}`); -``` - -### Checking Token Balances - -```typescript -import { mcUSDC } from "@biconomy/abstractjs"; - -// Get total USDC balance across all chains -const balance = await mcNexus.getUnifiedERC20Balance(mcUSDC); - -console.log(`Total USDC balance: ${balance.balance}`); - -// Get breakdown by chain -balance.breakdown.forEach(chainBalance => { - console.log(`Chain ${chainBalance.chainId}: ${chainBalance.balance} USDC`); -}); -``` - -### Cross-Chain Transaction Example - -Here's a simple example showing how to use multiple methods together for a cross-chain operation: - -```typescript -import { mcUSDC } from "@biconomy/abstractjs"; -import { parseUnits, formatUnits } from "viem"; -import { optimism, base } from "viem/chains"; - -// 1. Check USDC balance -const balance = await mcNexus.getUnifiedERC20Balance(mcUSDC); -console.log(`Total USDC balance: ${formatUnits(balance.balance, 6)}`); - -// 2. Bridge 10 USDC from Optimism to Base -const bridgeInstructions = await mcNexus.buildBridgeInstructions({ - mcToken: mcUSDC, - amount: parseUnits("10", 6), - fromChain: optimism, - toChain: base -}); - -// 3. Create a contract call on Base -const contractCallInstructions = await mcNexus.buildContractCallInstructions({ - chainId: base.id, - target: "0x1234...", - callData: "0x..." -}); - -// 4. Execute both instructions in a single transaction -const quote = await meeClient.getQuote({ - instructions: [...bridgeInstructions, ...contractCallInstructions], - account: mcNexus -}); - -const tx = await meeClient.executeQuote(quote); -console.log(`Transaction hash: ${tx.hash}`); -``` - -## Advanced Composable Transactions - -Composable transactions are a powerful feature that enables runtime parameter injection between transactions, even across different chains: - -```typescript -// Example of a cross-chain composable transaction sequence -const swapAndStakeComposable = await mcNexus.buildComposable({ - // First part: Bridge tokens - bridge: { - fromChain: optimism, - toChain: base, - mcToken: mcUSDC, - amount: parseUnits("100", 6), // 100 USDC - }, - // Second part: Use result in a contract call - contractCall: { - chainId: base.id, - target: stakingContractAddress, - functionName: "stake", - abi: stakingAbi, - // No need to specify args here - they will be injected at runtime - // using the exact amount received from the bridge - } -}); - -// Execute the composable transaction via the MEE client -const { hash } = await meeClient.executeQuote({ - quote: await meeClient.getQuote({ - instructions: [swapAndStakeComposable], - account: mcNexus - }) -}); - -// Wait for the transaction to complete -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -console.log(`Transaction status: ${receipt.transactionStatus}`); -``` - -Key benefits of composable transactions: - -- **Dynamic Parameters**: Use outputs from one transaction as inputs to another -- **Cross-Chain Values**: Reference values across different blockchains -- **Zero Slippage**: Supply exact amounts received from bridges or swaps -- **Complex Workflows**: Build sophisticated DeFi strategies with guaranteed execution conditions -- **Predictable Results**: Avoid failed transactions due to incorrect hard-coded amounts - -## Common Patterns and Uses - -### Deploy Account When Needed - -Smart accounts are deployed on-demand when transactions are executed. You don't need to explicitly deploy them: - -```typescript -// The account doesn't need to be pre-deployed -// It will be deployed when the first transaction is executed -const quote = await meeClient.getQuote({ - instructions: [myFirstTransaction], - feeToken: { address: mcUSDC.addressOn(optimism.id), chainId: optimism.id } -}); -const { hash } = await meeClient.executeQuote({ quote }); -``` - -### Funding Your Account - -You can fund your smart account just like any other address: - -```typescript -// Get your account address on the desired chain -const myAccountOnOptimism = mcNexus.addressOn(optimism.id); -console.log(`Send tokens to: ${myAccountOnOptimism}`); -``` - -### Managing Delegations - -Check if your account is delegated and manage permissions: - -```typescript -// Check if account is delegated on any chain -const delegationStatus = await mcNexus.isDelegated(); - -if (delegationStatus.isDelegated) { - console.log("Account is delegated on at least one chain"); - - // Remove delegations on all chains - const result = await mcNexus.unDelegate(); - - // Wait for transactions to be mined - await mcNexus.waitForTransactionReceipts({ - transactionHashes: result.transactionHashes - }); - - console.log("All delegations removed"); -} -``` - -## Technical Details - -### Return Value - -| Property | Type | Description | -|----------|------|-------------| -| `deployments` | `ModularSmartAccount[]` | Array of account deployments across different chains | -| `signer` | `Signer` | The signer associated with this multichain account | -| `deploymentOn` | `(chainId: number, strictMode?: boolean) => ModularSmartAccount \| undefined` | Function to get deployment for a specific chain | -| `addressOn` | `(chainId: number, strictMode?: boolean) => Hex \| undefined` | Function to get address for a specific chain | - -### Error Handling - -Throws an error if: -- Invalid chain configuration is provided -- Signer is not connected -- Account deployment fails on any chain - -### Type Definitions - -```typescript -type MultichainNexusParams = Partial> & { - chains: Chain[] - signer: Signer -} - -type MultichainSmartAccount = { - deployments: ModularSmartAccount[] - signer: Signer - deploymentOn: (chainId: number, strictMode?: boolean) => ModularSmartAccount | undefined - addressOn: (chainId: number, strictMode?: boolean) => Hex | undefined -} -``` \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/account/methods/build.md b/docs/pages/sdk-reference/mee-client/account/methods/build.md deleted file mode 100644 index 8fb8d73..0000000 --- a/docs/pages/sdk-reference/mee-client/account/methods/build.md +++ /dev/null @@ -1,420 +0,0 @@ -# build - -The `build` method creates transaction instructions for the MEE Client, serving as the primary way to construct operations that will be executed across multiple blockchains as part of supertransactions. - -## What is the `build` Method? - -The `build` method is a fundamental building block in the AbstractJS SDK that transforms your desired actions into standardized instruction objects that the MEE (Modular Execution Environment) can understand and execute. It serves as the bridge between your application logic and the cross-chain execution infrastructure. - -## Why is `build` Important? - -The `build` method is critical for several reasons: - -- **Creates Standardized Instructions**: Transforms your application-specific operations into a universal format that the MEE Client can process. - -- **Supports Multiple Action Types**: Provides a consistent interface for creating different types of operations (transfers, approvals, intents, etc.). - -- **Enables Supertransactions**: The instructions created by `build` are the components that make up supertransactions - cross-chain operations executed with a single signature. - -- **Abstracts Complexity**: Handles the technical details of encoding contract calls, managing chain-specific parameters, and preparing instructions for execution. - -- **Supports Modularity**: Built instructions can be combined, sequenced, and customized to create complex cross-chain workflows. - -## When to Use `build` vs `buildComposable` - -### Use `build` When: - -- You need to create standard blockchain operations with known parameters -- You're working with static values that won't change between creation and execution -- You want to bridge tokens from one chain to another using intents -- You're performing basic operations like transfers, approvals, or withdrawals -- You need to create a batch of transactions on the same chain -- You're creating instructions for immediate execution with `getQuote` and `executeQuote` - -Example: -```typescript -// Bridge tokens from Optimism to Base using an intent -const bridgeIntent = await mcAccount.build({ - type: "intent", - data: { - amount: parseUnits("5", 6), // Fixed, known amount - mcToken: mcUSDC, - toChain: base - } -}); - -// Execute the intent as a supertransaction -const quote = await meeClient.getQuote({ - instructions: [bridgeIntent], - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - } -}); - -const { hash } = await meeClient.executeQuote({ quote }); -``` - -### Use `buildComposable` When: - -- You need runtime values that are determined at execution time -- Your operations depend on results from other operations -- You're working with values that may change between creation and execution -- You need advanced constraints or conditional logic -- You're creating complex cross-chain workflows with interdependencies - -## Real-World Use Cases for `build` - -1. **Token Bridging**: Create intent instructions to move tokens from one chain to another. - -2. **Multi-Step DeFi Operations**: Bundle multiple operations (approval, swap, liquidity provision) on a single chain. - -3. **Cross-Chain Portfolio Rebalancing**: Move tokens between chains based on predetermined allocation. - -4. **NFT Minting and Trading**: Create instructions to mint, approve, and trade NFTs across multiple marketplaces. - -5. **Cross-Chain DAO Governance**: Submit proposals and vote on multiple chains with a single user action. - -## Building Supertransactions - -A supertransaction is a powerful abstraction that allows a single user signature to execute operations across multiple blockchains. The process of creating a supertransaction involves: - -1. **Building Instructions**: Use `build` (or `buildComposable` for advanced cases) to create the instructions for each operation. - -2. **Gathering Instructions**: Collect all instructions into an array. - -3. **Getting a Quote**: Pass the instructions to `meeClient.getQuote()` along with fee payment details. - -4. **Executing the Quote**: Call `meeClient.executeQuote()` with the quote to execute the supertransaction. - -Example of a complete supertransaction workflow: - -```typescript -// 1. Build instructions for operations on different chains -const optimismTransfer = await mcAccount.build({ - type: "transfer", - data: { - chainId: optimism.id, - tokenAddress: mcUSDC.addressOn(optimism.id), - amount: parseUnits("10", 6), - recipient: recipientAddress - } -}); - -const baseSwap = await mcAccount.build({ - type: "default", - data: { - chainId: base.id, - calls: [{ - to: swapRouterAddress, - data: encodeSwapFunction(/* swap parameters */), - value: 0n - }] - } -}); - -// 2. Combine instructions -const instructions = [optimismTransfer, baseSwap]; - -// 3. Get quote for the supertransaction -const quote = await meeClient.getQuote({ - instructions, - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - } -}); - -// 4. Execute the supertransaction -const { hash } = await meeClient.executeQuote({ quote }); - -// 5. Wait for receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -``` - -This workflow demonstrates how `build` serves as the foundation for creating powerful cross-chain experiences with minimal user interaction. - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| baseParams | `BaseInstructionsParams` | Yes | Base configuration for building instructions | -| baseParams.account | `BaseMultichainSmartAccount` | Yes | The multichain smart account to check balances for | -| baseParams.currentInstructions | `Instruction[]` | No | Array of existing instructions to append to | -| parameters | `BuildInstructionTypes` | Yes | The build action configuration | -| parameters.type | `"default" \| "intent" \| "transfer" \| "transferFrom" \| "approve" \| "withdrawal"` | Yes | The type of build action | -| parameters.data | Various (see below) | Yes | Action-specific parameters based on the type | - -### Build Action Types - -#### Default Instructions (`type: "default"`) -```typescript -type BuildDefaultParameters = { - calls: { - to: Address - value?: bigint - gasLimit?: bigint - data?: Hex - }[] - chainId: number -} -``` - -#### Bridge Intent (`type: "intent"`) -```typescript -type BuildIntentParameters = { - amount: bigint - mcToken: MultichainToken - toChain: Chain -} -``` - -#### Transfer (`type: "transfer"`) -```typescript -type BuildTransferParameters = { - chainId: number - tokenAddress: Address - amount: bigint - gasLimit?: bigint - recipient?: Address -} -``` - -#### Transfer From (`type: "transferFrom"`) -```typescript -type BuildTransferFromParameters = { - chainId: number - tokenAddress: Address - amount: bigint - gasLimit?: bigint - sender: Address - recipient: Address -} -``` - -#### Approve (`type: "approve"`) -```typescript -type BuildApproveParameters = { - chainId: number - tokenAddress: Address - amount: bigint - gasLimit?: bigint - spender: Address -} -``` - -#### Withdrawal (`type: "withdrawal"`) -```typescript -type BuildWithdrawalParameters = { - chainId: number - tokenAddress: Address - amount: bigint - gasLimit?: bigint - recipient?: Address -} -``` - -## Returns - -Promise resolving to an array of `Instruction` containing: - -| Property | Type | Description | -|----------|------|-------------| -| chainId | `number` | Chain ID where the instruction will be executed | -| calls | `Call[]` | Array of contract calls to execute | -| calls[].to | `Address` | Target contract address | -| calls[].value | `bigint` | Amount of native tokens to send | -| calls[].gasLimit | `bigint` | Gas limit for the call | -| calls[].data | `Hex` | Encoded call data | - -## Examples - -### Bridge Intent Example -```typescript -const bridgeInstructions = await mcAccount.build({ - type: "intent", - data: { - amount: parseUnits("1", 6), // 1 USDC - mcToken: mcUSDC, - toChain: optimism - } -}); -``` - -### Token Transfer Example -```typescript -const transferInstructions = await mcAccount.build({ - type: "transfer", - data: { - chainId: optimism.id, - tokenAddress: mcUSDC.addressOn(optimism.id), - amount: parseUnits("1", 6), - recipient: "0x..." - } -}); -``` - -### Token Approval Example -```typescript -const approvalInstructions = await mcAccount.build({ - type: "approve", - data: { - chainId: optimism.id, - tokenAddress: mcUSDC.addressOn(optimism.id), - amount: parseUnits("1", 6), - spender: "0x..." - } -}); -``` - -### Default Transaction Example -```typescript -const defaultInstructions = await mcAccount.build({ - type: "default", - data: { - calls: [{ - to: "0x...", - value: 0n, - gasLimit: 50000n - }], - chainId: optimism.id - } -}); -``` - -## Error Handling - -The method will throw an error if: -- Unknown build action type is provided -- Invalid instruction parameters are provided -- Required parameters are missing -- Chain ID is invalid -- Token address is invalid - -## Type Definitions - -### BuildInstructionTypes -```typescript -type BuildInstructionTypes = - | BuildDefaultInstruction - | BuildIntentInstruction - | BuildTransferInstruction - | BuildTransferFromInstruction - | BuildApproveInstruction - | BuildWithdrawalInstruction -``` - -### BuildDefaultInstruction -```typescript -type BuildDefaultInstruction = { - type: "default" - data: BuildDefaultParams -} -``` - -### BuildIntentInstruction -```typescript -type BuildIntentInstruction = { - type: "intent" - data: BuildIntentParameters -} -``` - -### BuildTransferInstruction -```typescript -type BuildTransferInstruction = { - type: "transfer" - data: BuildTransferParameters -} -``` - -### BuildTransferFromInstruction -```typescript -type BuildTransferFromInstruction = { - type: "transferFrom" - data: BuildTransferFromParameters -} -``` - -### BuildApproveInstruction -```typescript -type BuildApproveInstruction = { - type: "approve" - data: BuildApproveParameters -} -``` - -### BuildWithdrawalInstruction -```typescript -type BuildWithdrawalInstruction = { - type: "withdrawal" - data: BuildWithdrawalParameters -} -``` - -### BuildDefaultParams -```typescript -type BuildDefaultParams = { - calls: { - to: Address - value?: bigint - gasLimit?: bigint - data?: Hex - }[] - chainId: number -} -``` - -### BuildIntentParameters -```typescript -type BuildIntentParameters = { - amount: bigint - mcToken: MultichainToken - toChain: Chain -} -``` - -### BuildTransferParameters -```typescript -type BuildTransferParameters = { - chainId: number - tokenAddress: Address - amount: bigint - gasLimit?: bigint - recipient?: Address -} -``` - -### BuildTransferFromParameters -```typescript -type BuildTransferFromParameters = { - chainId: number - tokenAddress: Address - amount: bigint - gasLimit?: bigint - sender: Address - recipient: Address -} -``` - -### BuildApproveParameters -```typescript -type BuildApproveParameters = { - chainId: number - tokenAddress: Address - amount: bigint - gasLimit?: bigint - spender: Address -} -``` - -### BuildWithdrawalParameters -```typescript -type BuildWithdrawalParameters = { - chainId: number - tokenAddress: Address - amount: bigint - gasLimit?: bigint - recipient?: Address -} -``` diff --git a/docs/pages/sdk-reference/mee-client/account/methods/buildComposable.md b/docs/pages/sdk-reference/mee-client/account/methods/buildComposable.md deleted file mode 100644 index cbd9725..0000000 --- a/docs/pages/sdk-reference/mee-client/account/methods/buildComposable.md +++ /dev/null @@ -1,399 +0,0 @@ -# buildComposable - -The `buildComposable` method creates advanced transactions with runtime parameter injection, allowing values to be determined at execution time rather than when building the transaction. - -## What is Composability? - -Composability in blockchain transactions refers to the ability to create complex operations by combining simpler ones in ways that allow them to interact with each other. In the context of the AbstractJS SDK, composability takes this concept further by enabling: - -1. **Runtime Value Resolution**: Instead of hardcoding values that might change between transaction creation and execution, composable transactions can use values determined at the exact moment of execution. - -2. **Cross-Chain Data Flow**: Values and results from one chain can be used as inputs on another chain, enabling true cross-chain applications. - -3. **Transaction Dependencies**: Later transactions can use the outputs from earlier ones, creating chains of dependent operations that would be impossible with traditional transactions. - -4. **Conditional Execution Logic**: Transactions can adapt to the current state of the blockchain at execution time, rather than using potentially outdated information. - -## Why is Composability Important? - -Composability solves several critical problems in blockchain development: - -- **Reduced Transaction Failures**: By using real-time values instead of hardcoded ones, transactions are less likely to fail due to changed conditions. - -- **Improved Capital Efficiency**: Exact amounts can be used in subsequent transactions, eliminating the need for over-allocation of funds as a safety buffer. - -- **Enhanced UX**: Users don't need to sign multiple transactions or manually coordinate between chains, as composable transactions can handle complex sequences automatically. - -- **DeFi Optimization**: Creates opportunity for zero-slippage cross-chain operations by precisely using outputs from one transaction as inputs to another. - -- **Developer Productivity**: Complex multi-step operations can be created as a single logical unit, reducing code complexity and error potential. - -## When to Use `buildComposable` vs `build` - -### Use `build` When: - -- You need simple, static transactions with known values -- Your transactions don't depend on outputs from other operations -- You're performing basic operations within a single chain -- You're using pre-determined amounts that won't change - -Example: -```typescript -// Simple static transaction - good for build() -const simpleTx = await mcNexus.build({ - type: "default", - data: { - chainId: optimism.id, - calls: [{ - to: "0xContract", - value: parseEther("0.1"), // Static, known value - data: "0xCalldata" - }] - } -}); -``` - -### Use `buildComposable` When: - -- You need runtime values that can't be known in advance -- Your transaction depends on the results of previous transactions -- You're working with token balances that may change -- You need to reference values across chains -- You need to encode complex data that includes runtime components - -Example: -```typescript -// Dynamic transaction with runtime values - needs buildComposable() -const dynamicTx = await mcNexus.buildComposable({ - type: "default", - data: { - to: mcUSDC.addressOn(chainId), - abi: erc20Abi, - functionName: "transfer", - args: [ - recipient, - runtimeERC20BalanceOf({ // Use current balance at execution time - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId) - }) - ], - chainId: chainId - } -}); -``` - -## Real-World Use Cases - -Composable transactions shine in these scenarios: - -1. **Bridge & Use Pattern**: Bridge tokens to a destination chain and immediately use them without knowing the exact received amount in advance. - -2. **Swap & Stake Workflows**: Swap tokens on a DEX and stake the exact result without needing a safety buffer. - -3. **Asset Rebalancing**: Move funds between chains based on current balances to maintain desired ratios. - -4. **Cross-Chain Arbitrage**: Execute multi-step trading strategies across different chains based on real-time amounts. - -5. **Gas Optimization**: Pay for gas with tokens on one chain while executing transactions on another. - -## Overview - -Composable transactions enable: -- Using real-time token balances instead of hardcoded amounts -- Referencing outputs from previous transactions -- Adding validation constraints to ensure safe execution -- Creating complex cross-chain workflows - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| type | `string` | Yes | The type of composable action (`"default"`, `"transfer"`, `"approval"`, `"batch"`, `"rawCalldata"`, `"transferFrom"`, `"approve"`) | -| data | `object` | Yes | Type-specific configuration parameters | - -### Type-Specific Data Parameters - -Depending on the `type` parameter, the `data` object requires different fields: - -#### `"default"` -- `to`: `Address` - The target contract address -- `abi`: `Abi` - The ABI of the contract -- `functionName`: `string` - The function to call -- `args`: `Array` - Function arguments, can include runtime values -- `chainId`: `number` - The chain ID for execution -- `gasLimit?`: `bigint` - Optional gas limit -- `value?`: `bigint` - Optional native token value - -#### `"transfer"` -- `recipient`: `Address` - The recipient address -- `tokenAddress`: `Address` - The token contract address -- `amount`: `bigint` or runtime value - Amount to transfer -- `chainId`: `number` - The chain ID for execution - -#### `"batch"` -- `instructions`: `Instruction[]` - Array of instructions to execute in batch - -#### `"rawCalldata"` -- `to`: `Address` - The target contract address -- `calldata`: `string` - The encoded calldata -- `chainId`: `number` - The chain ID for execution - -## Runtime Functions - -| Function | Purpose | -|----------|---------| -| [`runtimeERC20BalanceOf`](/sdk-reference/mee-client/helpers/runtimeERC20BalanceOf) | Gets token balance at execution time | -| [`runtimeEncodeAbiParameters`](/sdk-reference/mee-client/helpers/runtimeEncodeAbiParameters) | Encodes complex data with runtime values | - -## Examples - -### Basic Token Transfer - -This example shows a simple ERC20 transfer using the current balance at execution time: - -```typescript -const transferInstruction = await mcNexus.buildComposable({ - type: "transfer", - data: { - recipient: recipientAddress, - tokenAddress: mcUSDC.addressOn(chainId), - amount: runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId) - }), - chainId: chainId - } -}); -``` - -### Contract Interaction with Runtime Values - -This example shows calling a contract function with runtime parameters: - -```typescript -const approveInstruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: mcUSDC.addressOn(chainId), - abi: erc20Abi, - functionName: "approve", - args: [ - uniswapRouterAddress, - runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId), - constraints: [greaterThanOrEqualTo(parseUnits("0.01", 6))] - }) - ], - chainId: chainId - } -}); -``` - -### Passing Runtime Values in Arrays - -This example shows how to use runtime values inside complex data structures: - -```typescript -const complexInstruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: contractAddress, - abi: CONTRACT_ABI, - functionName: "transferFundsWithRuntimeParamInsideArray", - args: [ - [address1, address2], // First array argument (static) - [ - runtimeERC20BalanceOf({ // Second array argument (dynamic) - targetAddress: address1, - tokenAddress: mcUSDC.addressOn(chainId), - constraints: [greaterThanOrEqualTo(parseUnits("0.01", 6))] - }) - ] - ], - chainId: chainId - } -}); -``` - -### Encoding Complex Parameters - -This example shows encoding complex types with runtime values: - -```typescript -const encodedParamsInstruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: contractAddress, - abi: CONTRACT_ABI, - functionName: "foo", - args: [ - param1, - param2, - runtimeEncodeAbiParameters( - [ - { name: "x", type: "uint256" }, - { name: "y", type: "uint256" }, - { name: "z", type: "bool" } - ], - [ - 420n, // Static value - runtimeERC20BalanceOf({ // Dynamic value - targetAddress: accountAddress, - tokenAddress: tokenAddress, - constraints: [] - }), - true // Static value - ] - ), - param4, - param5 - ], - chainId: chainId - } -}); -``` - -### Using Raw Calldata - -This example shows how to use pre-encoded calldata: - -```typescript -const rawCalldata = encodeFunctionData({ - abi: erc20Abi, - functionName: "approve", - args: [spenderAddress, amount] -}); - -const rawCalldataInstruction = await mcNexus.buildComposable({ - type: "rawCalldata", - data: { - to: tokenAddress, - calldata: rawCalldata, - chainId: chainId - } -}); -``` - -### Batching Multiple Instructions - -This example shows how to batch multiple instructions together: - -```typescript -// Create multiple instructions -const transferInstruction = await mcNexus.buildComposable({ - type: "transfer", - data: { - recipient: recipientAddress, - tokenAddress: mcUSDC.addressOn(chainId), - amount: amount, - chainId: chainId - } -}); - -const contractInstruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: contractAddress, - abi: CONTRACT_ABI, - functionName: "foo", - args: [param1, param2], - chainId: chainId - } -}); - -// Batch them together -const batchedInstructions = await mcNexus.buildComposable({ - type: "batch", - data: { - instructions: [...transferInstruction, ...contractInstruction] - } -}); -``` - -### Complete DeFi Example: Approve and Swap - -This example shows a typical DeFi flow of approving and swapping tokens using runtime values: - -```typescript -// 1. Approve tokens for Uniswap -const approveInstruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: inToken.addressOn(chainId), - abi: erc20Abi, - functionName: "approve", - args: [ - uniswapRouterAddress, - runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: inToken.addressOn(chainId) - }) - ], - chainId: chainId - } -}); - -// 2. Swap tokens on Uniswap -const swapInstruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: uniswapRouterAddress, - abi: UniswapSwapRouterAbi, - functionName: "exactInputSingle", - args: [{ - tokenIn: inToken.addressOn(chainId), - tokenOut: outToken.addressOn(chainId), - fee: 3000, - recipient: mcNexus.addressOn(chainId), - deadline: BigInt(Math.floor(Date.now() / 1000) + 3600), - amountIn: runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: inToken.addressOn(chainId) - }), - amountOutMinimum: parseUnits("0.0001", 18), - sqrtPriceLimitX96: 0n - }], - chainId: chainId - } -}); - -// Execute both instructions -const { hash } = await meeClient.executeQuote({ - quote: await meeClient.getQuote({ - instructions: [approveInstruction, swapInstruction], - feeToken: { - address: feeToken.addressOn(chainId), - chainId: chainId - } - }) -}); -``` - -## Using Constraints - -You can add constraints to runtime values to ensure they meet specific conditions: - -```typescript -runtimeERC20BalanceOf({ - targetAddress: accountAddress, - tokenAddress: tokenAddress, - constraints: [ - greaterThanOrEqualTo(parseUnits("0.01", 6)) // Ensure balance is at least 0.01 USDC - ] -}) -``` - -Available constraints include: -- `greaterThanOrEqualTo(value)` -- `lessThanOrEqualTo(value)` -- `equalTo(value)` -- `notEqualTo(value)` - -## When to Use Composable Transactions - -Composable transactions are ideal for: -- Working with actual token balances at execution time -- Creating multi-step DeFi workflows that depend on previous steps -- Ensuring transactions have appropriate failsafes through constraints -- Building cross-chain operations that require dynamic parameters \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/account/methods/more/addressOn.md b/docs/pages/sdk-reference/mee-client/account/methods/more/addressOn.md deleted file mode 100644 index 200dd32..0000000 --- a/docs/pages/sdk-reference/mee-client/account/methods/more/addressOn.md +++ /dev/null @@ -1,48 +0,0 @@ -# addressOn - -The `addressOn` method retrieves the smart account address for a specific chain. It can operate in strict or non-strict mode to handle cases where deployments don't exist. - -## Parameters - -| Parameter | Type | Description | -|-----------|------|-------------| -| `chainId` | `number` | The ID of the chain to query | -| `strictMode` | `boolean` | (Optional) Whether to throw an error if no deployment exists for the specified chain | - -## Returns - -| Return Type | Description | -|------------|-------------| -| `Hex` | When strictMode is true or deployment exists | -| `Hex \| undefined` | When strictMode is false and deployment may not exist | - -## Example - -```typescript -// Get address with strict mode (throws if not found). Type safely returns the address -const optimismAddress = account.addressOn(10, true); - -// Get address without strict mode (returns undefined if not found) -const baseAddress = account.addressOn(8453); - -// Use the address -if (baseAddress) { - console.log(`Account address on Base: ${baseAddress}`); -} -``` - -## Error Handling - -Throws an error if: -- `strictMode` is true and no deployment exists for the specified chain -- Invalid chain ID is provided - -## Type Definitions - -### AddressOnFunction -```typescript -type AddressOnFunction = { - (chainId: number, strictMode: true): Hex - (chainId: number, strictMode?: false): Hex | undefined -} -``` diff --git a/docs/pages/sdk-reference/mee-client/account/methods/more/deploymentOn.md b/docs/pages/sdk-reference/mee-client/account/methods/more/deploymentOn.md deleted file mode 100644 index edc4381..0000000 --- a/docs/pages/sdk-reference/mee-client/account/methods/more/deploymentOn.md +++ /dev/null @@ -1,60 +0,0 @@ -# deploymentOn - -The `deploymentOn` method retrieves deployment information for a smart account on a specific chain. It can operate in strict or non-strict mode to handle cases where deployments don't exist. - -## Parameters - -| Parameter | Type | Description | -|-----------|------|-------------| -| `chainId` | `number` | The ID of the chain to query | -| `strictMode` | `boolean` | (Optional) Whether to throw an error if no deployment exists for the specified chain | - -## Returns - -| Return Type | Description | -|------------|-------------| -| `ModularSmartAccount` | When strictMode is true or deployment exists | -| `ModularSmartAccount \| undefined` | When strictMode is false and deployment may not exist | - -## Example - -```typescript -// Get deployment with strict mode (throws if not found). Type safely returns the ModularSmartAccount -const optimismDeployment = account.deploymentOn(10, true); - -// Get deployment without strict mode (returns undefined if not found) -const baseDeployment = account.deploymentOn(8453); - -// Use the deployment -if (baseDeployment) { - const address = baseDeployment.address; - const chainId = baseDeployment.client.chain?.id; -} -``` - -## Error Handling - -Throws an error if: -- `strictMode` is true and no deployment exists for the specified chain -- Invalid chain ID is provided - -## Type Definitions - -### ModularSmartAccount -```typescript -type ModularSmartAccount = { - address: Hex - client: SmartAccountClient - entryPoint: Address - factoryAddress: Address - initCode: Hex -} -``` - -### DeploymentOnFunction -```typescript -type DeploymentOnFunction = { - (chainId: number, strictMode: true): ModularSmartAccount - (chainId: number, strictMode?: false): ModularSmartAccount | undefined -} -``` diff --git a/docs/pages/sdk-reference/mee-client/account/methods/more/getUnifiedERC20Balance.md b/docs/pages/sdk-reference/mee-client/account/methods/more/getUnifiedERC20Balance.md deleted file mode 100644 index 659f7b4..0000000 --- a/docs/pages/sdk-reference/mee-client/account/methods/more/getUnifiedERC20Balance.md +++ /dev/null @@ -1,133 +0,0 @@ -# getUnifiedERC20Balance - -The `getUnifiedERC20Balance` method retrieves the total balance of a specific ERC20 token across all chains where your multichain smart account is deployed. - -## Overview - -One of the key benefits of using a multichain smart account is the ability to view and manage assets across multiple blockchains as a single unified portfolio. The `getUnifiedERC20Balance` method simplifies token balance management by aggregating token balances from all chains into a single view. - -## Method Signature - -```typescript -function getUnifiedERC20Balance(parameters: { - mcToken: MultichainToken, - account: BaseMultichainSmartAccount -}): Promise -``` - -## Parameters - -| Parameter | Type | Description | -|-----------|------|-------------| -| `mcToken` | `MultichainToken` | The multichain token to check balance for. Use predefined tokens like `mcUSDC` or create custom ones with `createMultichainToken`. | - -## Returns - -A `Promise` that resolves to a `UnifiedERC20Balance` object containing: - -| Property | Type | Description | -|----------|------|-------------| -| `balance` | `bigint` | The total token balance across all chains | -| `decimals` | `number` | Number of decimal places for the token | -| `breakdown` | `Array<{ chainId: number, balance: bigint, decimals: number }>` | Detailed breakdown of token balances by chain | -| `mcToken` | `MultichainToken` | The multichain token reference | - -## Decimal Validation - -The method validates that the token has the same number of decimals across all chains. If there's a mismatch in the token's decimal places between chains, the function will throw an error. This ensures consistency when aggregating balances. - -## Examples - -### Basic Usage - -```typescript -import { mcUSDC } from "@biconomy/abstractjs"; -import { formatUnits } from "viem"; - -// Get USDC balance across all chains -const balance = await mcAccount.getUnifiedERC20Balance(mcUSDC); - -console.log(`Total USDC balance: ${formatUnits(balance.balance, 6)}`); -``` - -### With Balance Breakdown - -```typescript -import { mcUSDC } from "@biconomy/abstractjs"; -import { formatUnits } from "viem"; - -// Get USDC balance with breakdown by chain -const balance = await mcAccount.getUnifiedERC20Balance(mcUSDC); - -console.log(`Total USDC balance: ${formatUnits(balance.balance, balance.decimals)}`); - -// Display breakdown by chain -balance.breakdown.forEach(chainBalance => { - console.log(`Chain ${chainBalance.chainId}: ${formatUnits(chainBalance.balance, chainBalance.decimals)} USDC`); -}); -``` - -### With Custom Token - -```typescript -import { createMultichainToken } from "@biconomy/abstractjs"; -import { formatUnits } from "viem"; -import { optimism, base, arbitrum } from "viem/chains"; - -// Create a custom multichain token definition -const mcDAI = createMultichainToken({ - name: "DAI", - symbol: "DAI", - decimals: 18, - addresses: { - [optimism.id]: "0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1", - [base.id]: "0x50c5725949A6F0c72E6C4a641F24049A917DB0Cb", - [arbitrum.id]: "0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1" - } -}); - -// Get unified DAI balance -const daiBalance = await mcAccount.getUnifiedERC20Balance(mcDAI); - -console.log(`Total DAI balance: ${formatUnits(daiBalance.balance, 18)}`); -``` - -## Error Handling - -The method may throw errors in the following cases: - -- If the token address is not defined for a chain in your multichain account -- If the token has different decimal places across chains -- If there are network connectivity issues when querying balances -- If there are contract errors when trying to read balances (e.g., invalid ERC20 implementation) - -Example with error handling: - -```typescript -try { - const balance = await mcAccount.getUnifiedERC20Balance(mcUSDC); - console.log(`Total USDC balance: ${formatUnits(balance.balance, 6)}`); -} catch (error) { - console.error("Failed to get unified balance:", error); -} -``` - -## Implementation Details - -The method works by: -1. Finding all chains where both the token and account are deployed -2. Querying the token balance for each chain -3. Verifying that the token has the same number of decimals on all chains -4. Aggregating the balances into a single total - -## Use Cases - -- Creating a consolidated portfolio view in a wallet interface -- Determining where to bridge tokens from for the most efficient operations -- Building rebalancing strategies across chains -- Implementing unified token accounting for DeFi applications - -## Related Methods - -- [`buildBridgeInstructions`](#TODO): For moving tokens between chains -- [`queryBridge`](#TODO): For getting information about potential bridge operations \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/account/methods/more/isDelegated.md b/docs/pages/sdk-reference/mee-client/account/methods/more/isDelegated.md deleted file mode 100644 index b113f8f..0000000 --- a/docs/pages/sdk-reference/mee-client/account/methods/more/isDelegated.md +++ /dev/null @@ -1,76 +0,0 @@ -# isDelegated - -The `isDelegated` method checks if your account is delegated across all chains where it's deployed. - -## Overview - -Delegation allows another address to control your smart account. This method provides a convenient way to check if your account has delegation active across all chains where it's deployed. - -## Method Signature - -```typescript -function isDelegated(parameters: IsDelegatedParameters): Promise -``` - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| `account` | `BaseMultichainSmartAccount` | Yes | The multichain smart account to check delegation status for | - -## Returns - -A `Promise` that resolves to a `boolean`: -- `true` if the account is delegated on ALL checked chains -- `false` if the account is not delegated on ANY checked chain - -## Examples - -### Basic Usage - -```typescript -// Check if account is delegated on all chains -const delegated = await isDelegated({ - account: mcAccount -}); - -if (delegated) { - console.log("Account is delegated on all chains"); -} else { - console.log("Account is not delegated on at least one chain"); -} -``` - -### Using as Account Method - -If the method is available as an instance method on your account object: - -```typescript -// Check if account is delegated -const delegated = await mcAccount.isDelegated(); - -if (delegated) { - console.log("Account is delegated on all chains"); -} else { - console.log("Account is not delegated on at least one chain"); -} -``` - -## Implementation Details - -The `isDelegated` method works by: - -1. Checking the delegation status on each chain where the account is deployed -2. Only returning `true` if the account is delegated on ALL chains (using `every()` method) -3. Otherwise returning `false` if any chain has no delegation - -## Use Cases - -- Security checks to ensure expected delegations are active across all chains -- Verification before executing sensitive transactions -- UI indicators showing account control status -- Pre-transaction checks in applications handling user funds - -## Related Methods - -- [`unDelegate`](/sdk-reference/mee-client/account/methods/more/unDelegate) - Remove delegation permissions from the account \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/account/methods/more/unDelegate.md b/docs/pages/sdk-reference/mee-client/account/methods/more/unDelegate.md deleted file mode 100644 index db00695..0000000 --- a/docs/pages/sdk-reference/mee-client/account/methods/more/unDelegate.md +++ /dev/null @@ -1,79 +0,0 @@ -# unDelegate - -The `unDelegate` method removes your multichain nexus delegations from your eoa - -## Overview - -If you have previously delegated your account to another address, this method allows you to revoke those permissions. It's an important security feature that lets you regain exclusive control of your account. - -## Method Signature - -```typescript -function unDelegate(parameters?: UnDelegateParameters): Promise -``` - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| `chainIds` | `number[]` | No | Optional array of chain IDs to remove delegations from. If not provided, removes delegations from all chains where the account is deployed | - -## Returns - -A `Promise` that resolves to a `UnDelegatePayload` object with the following properties: - -| Property | Type | Description | -|----------|------|-------------| -| `transactionHashes` | `Record` | Object mapping chain IDs to transaction hashes for each undelegation transaction | - -## Examples - -### Remove Delegations on All Chains - -```typescript -// Remove delegations on all chains where the account is deployed -const result = await mcAccount.unDelegate(); - -console.log("Undelegation transactions submitted:"); -for (const [chainId, hash] of Object.entries(result.transactionHashes)) { - console.log(`Chain ${chainId}: ${hash}`); -} - -// Wait for transactions to be mined -await mcAccount.waitForTransactionReceipts({ - transactionHashes: result.transactionHashes -}); - -console.log("All undelegation transactions confirmed"); -``` - -### Remove Delegations on Specific Chains - -```typescript -import { optimism, base } from "viem/chains"; - -// Remove delegations only on specific chains -const result = await mcAccount.unDelegate({ - chainIds: [optimism.id, base.id] -}); - -// Check if transactions were submitted -if (result.transactionHashes[optimism.id]) { - console.log(`Undelegation on Optimism: ${result.transactionHashes[optimism.id]}`); -} - -if (result.transactionHashes[base.id]) { - console.log(`Undelegation on Base: ${result.transactionHashes[base.id]}`); -} -``` - -## Security Considerations - -- Always verify the success of undelegation operations using `isDelegated` after transactions are confirmed -- Consider removing delegations before executing high-value transactions if they're no longer needed -- Monitor for unexpected delegation changes as part of security best practices - -## Related Methods - -- [`isDelegated`](/sdk-reference/mee-client/account/methods/more/isDelegated) - Check if the account is delegated -- [`waitForTransactionReceipts`](/sdk-reference/mee-client/account/methods/more/waitForTransactionReceipts) - Wait for transaction receipts across multiple chains \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/account/methods/more/waitForTransactionReceipts.md b/docs/pages/sdk-reference/mee-client/account/methods/more/waitForTransactionReceipts.md deleted file mode 100644 index e783657..0000000 --- a/docs/pages/sdk-reference/mee-client/account/methods/more/waitForTransactionReceipts.md +++ /dev/null @@ -1,147 +0,0 @@ -# waitForTransactionReceipts - -The `waitForTransactionReceipts` method waits for transaction receipts from multiple transactions across different chains. - -## Overview - -When executing cross-chain operations that result in transactions on multiple blockchains, this method provides a convenient way to wait for all transactions to be mined and confirmed, returning their receipts once complete. - -## Method Signature - -```typescript -function waitForTransactionReceipts( - parameters: WaitForTransactionReceiptParameters -): Promise -``` - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| `transactionHashes` | `Record` | Yes | Object mapping chain IDs to transaction hashes to wait for | -| `timeout?` | `number` | No | Optional timeout in milliseconds (default varies by chain) | -| `confirmations?` | `number` | No | Optional number of confirmations to wait for (default: 1) | - -## Returns - -A `Promise` that resolves to a `WaitForTransactionReceiptPayload` object with the following properties: - -| Property | Type | Description | -|----------|------|-------------| -| `receipts` | `Record` | Object mapping chain IDs to transaction receipts | - -## Examples - -### Basic Usage - -```typescript -import { optimism, base } from "viem/chains"; -import { type Hex } from "viem"; - -// Example: Wait for transactions after undelegation -const undelegateResult = await mcAccount.unDelegate(); - -// Wait for all transaction receipts -const receipts = await mcAccount.waitForTransactionReceipts({ - transactionHashes: undelegateResult.transactionHashes -}); - -// Process the receipts -for (const [chainId, receipt] of Object.entries(receipts.receipts)) { - console.log(`Transaction on chain ${chainId}:`); - console.log(` Status: ${receipt.status === 'success' ? 'Successful' : 'Failed'}`); - console.log(` Block number: ${receipt.blockNumber}`); - console.log(` Gas used: ${receipt.gasUsed}`); -} -``` - -### With Custom Confirmation Settings - -```typescript -// Wait for multiple transactions with custom settings -const receipts = await mcAccount.waitForTransactionReceipts({ - transactionHashes: { - [optimism.id]: "0x1234...", // Transaction hash on Optimism - [base.id]: "0xabcd..." // Transaction hash on Base - }, - timeout: 60000, // 60 second timeout - confirmations: 3 // Wait for 3 confirmations -}); - -// Check if all transactions were successful -const allSuccessful = Object.values(receipts.receipts).every( - receipt => receipt.status === 'success' -); - -console.log(`All transactions successful: ${allSuccessful}`); -``` - -### Parallel Operation While Waiting - -```typescript -// Start waiting for transactions -const receiptPromise = mcAccount.waitForTransactionReceipts({ - transactionHashes: { - [optimism.id]: optimismTxHash, - [base.id]: baseTxHash - } -}); - -// Do other operations while waiting -console.log("Waiting for transactions to confirm..."); -await performOtherTasks(); - -// Now get the receipts when they're ready -const receipts = await receiptPromise; -console.log("All transactions confirmed!"); -``` - -## Error Handling - -The method may throw errors in the following cases: -- If a transaction fails during execution -- If the timeout is reached before all receipts are available -- If there are network connectivity issues -- If an invalid transaction hash is provided - -Example with error handling: - -```typescript -try { - const receipts = await mcAccount.waitForTransactionReceipts({ - transactionHashes: txHashes, - timeout: 120000 // 2 minutes - }); - - console.log("All transactions confirmed!"); - - // Check for failures - for (const [chainId, receipt] of Object.entries(receipts.receipts)) { - if (receipt.status !== 'success') { - console.error(`Transaction on chain ${chainId} failed!`); - // Handle the failure... - } - } -} catch (error) { - console.error("Error waiting for transaction receipts:", error); - - // Check if it's a timeout error - if (error.message.includes("timeout")) { - console.log("Transactions are taking longer than expected to confirm..."); - // Maybe provide retry option to user - } -} -``` - -## Use Cases - -- Waiting for complex cross-chain operations to complete -- Ensuring delegations or undelegations are confirmed -- Synchronizing UI state with on-chain transaction status -- Implementing robust error handling for multi-chain transactions -- Verifying successful account deployment across multiple chains - -## Related Methods - -- [`unDelegate`](/sdk-reference/mee-client/account/methods/more/unDelegate) - Remove delegation permissions (produces transaction hashes to wait for) -- [`isDelegated`](/sdk-reference/mee-client/account/methods/more/isDelegated) - Check if account is delegated (useful after waiting for undelegation transactions) \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/helpers/getMultichainContract.md b/docs/pages/sdk-reference/mee-client/helpers/getMultichainContract.md deleted file mode 100644 index ffd45a3..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/getMultichainContract.md +++ /dev/null @@ -1,204 +0,0 @@ -# getMultichainContract - -Creates a contract instance that can encode function calls and read state across multiple chains. The SDK provides several pre-configured multichain contracts like mcUSDC, mcUniswapSwapRouter, and mcAaveV3Pool that can be used out of the box. This is a simple in-memory dictionary used to index similar contracts that have been previously deployed to different chains. - -## Parameters - -| Property | Type | Required | Description | -|----------|------|----------|-------------| -| abi | Abi | Yes | The contract's ABI | -| deployments | [Address, number][] | Yes | Array of tuples containing [address, chainId] for each deployment | - -## Returns - -Returns a `MultichainContract` instance with the following methods: - -| Method | Description | -|--------|-------------| -| `on(chainId)` | Returns a chain-specific contract instance with methods for each contract function | -| `build(params)` | Builds an instruction for function execution | -| `addressOn(chainId)` | Gets contract address for a specific chain | -| `read(params)` | Reads contract state across multiple chains | - -## Basic Example - -```typescript -import { getMultichainContract } from "@biconomy/abstractjs"; -import { erc20Abi } from "viem"; -import { optimism, base } from "viem/chains"; - -// Create a multichain contract instance -const mcUSDC = getMultichainContract({ - abi: erc20Abi, - deployments: [ - ["0x7F5c764cBc14f9669B88837ca1490cCa17c31607", optimism.id], // Optimism USDC - ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", base.id] // Base USDC - ] -}); - -// Get contract address on a specific chain -const optimismUSDCAddress = mcUSDC.addressOn(optimism.id); -console.log("USDC on Optimism:", optimismUSDCAddress); -``` - -## Creating Instructions - -The `on` method provides a chain-specific contract instance with methods for each function in the ABI: - -```typescript -// Create a transfer instruction using the 'on' method -const recipient = "0x1111111111111111111111111111111111111111"; -const amount = parseUnits("1.0", 6); // 1 USDC with 6 decimals -const gasLimit = 100000n; - -const transferInstruction = mcUSDC.on(optimism.id).transfer({ - args: [recipient, amount], - gasLimit, - value: 0n // Optional, defaults to 0n -}); - -// The instruction can be used in getQuote -const quote = await meeClient.getQuote({ - instructions: [transferInstruction], - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - } -}); -``` - -Alternatively, you can use the `build` method to create instructions: - -```typescript -// Create a transfer instruction using the 'build' method -const transferInstruction = await mcUSDC.build({ - type: "transfer", // The function name in the ABI - data: { - chainId: optimism.id, - args: [recipient, amount], - gasLimit: 100000n // Optional - } -}); - -console.log("Chain ID:", transferInstruction.chainId); -console.log("Calls:", transferInstruction.calls.length); -``` - -## Reading Contract State - -You can read contract state across multiple chains using the `read` method: - -```typescript -// Read balances across chains -const balances = await mcUSDC.read({ - onChains: [optimism, base], - functionName: "balanceOf", - args: [myAddress], - account: mcNexus -}); - -balances.forEach(({ chainId, result }) => { - console.log(`Balance on chain ${chainId}: ${result}`); -}); -``` - -## AAVE Integration Example - -Here's a more complex example using the AAVE protocol: - -```typescript -import { mcAaveV3Pool, mcUSDC } from "@biconomy/abstractjs"; -import { parseUnits } from "viem"; - -// Define amount to supply -const amountToSupply = parseUnits("0.1", 6); // 0.1 USDC - -// Create an AAVE supply instruction -const supplyInstruction = mcAaveV3Pool.build({ - type: "supply", - data: { - chainId: targetChain.id, - args: [ - mcUSDC.addressOn(targetChain.id), // Asset to supply - amountToSupply, // Amount to supply - mcNexus.signer.address, // On behalf of - 0 // Referral code - ] - } -}); - -// Create an approval instruction first -const approvalInstruction = mcUSDC.build({ - type: "approve", - data: { - chainId: targetChain.id, - args: [ - mcAaveV3Pool.addressOn(targetChain.id), // Spender - amountToSupply // Amount - ] - } -}); - -// Get quote for both instructions -const quote = await meeClient.getQuote({ - instructions: [approvalInstruction, supplyInstruction], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); -``` - -## Error Handling - -The Multichain Contract methods throw errors in these cases: - -```typescript -// Error when accessing a non-existent deployment -try { - const address = mcUSDC.addressOn(1); // Assuming no deployment on chain ID 1 -} catch (error) { - console.error(error.message); // "No deployment found for chain 1" -} - -// Error when calling a non-existent function -try { - // TypeScript would catch this at compile time, but this can happen at runtime - mcUSDC.on(optimism.id).nonExistentFunction({ - args: [], - gasLimit: 100000n - }); -} catch (error) { - console.error(error.message); // "Function nonExistentFunction not found in ABI" -} -``` - -## Type Definitions - -### MultichainContract -```typescript -type MultichainContract = { - abi: TAbi - deployments: Map - on: (chainId: number) => ChainSpecificContract - addressOn: (chainId: number) => Address - read: >(params: { - onChains: Chain[] - functionName: TFunctionName - args: ContractFunctionArgs - account: MultichainSmartAccount - }) => Promise - }>> - build: >(params: { - type: TFunctionName - data: { - chainId: number - args: ContractFunctionArgs - gasLimit?: bigint - } - }) => Promise -} -``` - diff --git a/docs/pages/sdk-reference/mee-client/helpers/index.md b/docs/pages/sdk-reference/mee-client/helpers/index.md deleted file mode 100644 index 7308c43..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/index.md +++ /dev/null @@ -1,79 +0,0 @@ -# MEE Client Helpers - -The AbstractJS SDK provides useful helper utilities for working with cross-chain applications. These helpers simplify common tasks when building with the MEE client. - -## Available Helpers - -| Helper | Description | -|--------|-------------| -| [getMultichainContract](./getMultichainContract.md) | Creates a contract instance that works across multiple chains | -| [getMeeScanLink](./more/getMeeScanLink.md) | Generates a link to view a supertransaction on MeeScan explorer | -| [getExplorerTxLink](./more/getExplorerTxLink.md) | Generates a link to view a transaction on a chain's block explorer | -| [getJiffyScanLink](./more/getJiffyScanLink.md) | Generates a link to view a user operation on JiffyScan | - -## Runtime Helpers - -Runtime helpers create dynamic values that are resolved at transaction execution time, enabling more flexible and powerful transactions: - -| Helper | Description | -|--------|-------------| -| [runtimeERC20BalanceOf](./runtimeERC20BalanceOf.md) | Creates a runtime value that resolves to the ERC20 token balance of an address at execution time | -| [runtimeEncodeAbiParameters](./runtimeEncodeAbiParameters.md) | Encodes complex data structures with runtime values for use in smart contract interactions | - -> **IMPORTANT**: When using any runtime helper (`runtimeERC20BalanceOf`, `runtimeEncodeAbiParameters`, etc.), you **must** use `mcNexus.buildComposable()` instead of `mcNexus.build()`. Runtime values will not work properly with the regular build method. - -## Pre-configured Protocol Contracts - -AbstractJS includes pre-configured contract instances for popular protocols and tokens: - -| Contract | Description | -|----------|-------------| -| [mcUSDC](./more/mcUSDC.md) | USDC token contract deployed across multiple chains | -| [mcAaveV3Pool](./more/mcAaveV3Pool.md) | Aave V3 pool contract for lending and borrowing | -| [mcUniswapSwapRouter](./more/mcUniswapSwapRouter.md) | Uniswap V3 SwapRouter for token swaps | - -## Basic Usage Example - -```typescript -import { - getMultichainContract, - getMeeScanLink, - runtimeERC20BalanceOf, - mcUSDC -} from "@biconomy/abstractjs"; - -// Get a contract address -const usdcAddress = mcUSDC.addressOn(10); // Get USDC address on Optimism - -// Create a transaction explorer link -const txHash = "0x123..."; -const explorerUrl = getMeeScanLink(txHash); - -// Create a runtime value that resolves to the current USDC balance -const dynamicAmount = runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId) -}); - -// IMPORTANT: When using runtime helpers, always use buildComposable instead of build -const transferInstruction = await mcNexus.buildComposable({ - type: "transfer", - data: { - recipient: recipientAddress, - tokenAddress: mcUSDC.addressOn(chainId), - amount: dynamicAmount, // Will use actual balance at execution time - chainId: chainId - } -}); - -// The instruction can now be used with getQuote -const quote = await meeClient.getQuote({ - instructions: [transferInstruction], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); -``` - -For more detailed documentation on each helper, click the links above. diff --git a/docs/pages/sdk-reference/mee-client/helpers/more/getExplorerTxLink.md b/docs/pages/sdk-reference/mee-client/helpers/more/getExplorerTxLink.md deleted file mode 100644 index a4d002b..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/more/getExplorerTxLink.md +++ /dev/null @@ -1,24 +0,0 @@ -# getExplorerTxLink - -The SDK provides several utility functions to help you generate links to various block explorers for tracking your transactions and user operations. - -## getExplorerTxLink - -Gets the block explorer transaction link for a given chain. Supports chain objects, chain IDs, or chain names. - -```typescript -import { getExplorerTxLink } from "@biconomy/abstractjs" -import { optimism } from "viem/chains" - -// Using chain object -const url1 = getExplorerTxLink( - "0x123...", - optimism -) - -// Using chain ID -const url2 = getExplorerTxLink( - "0x123...", - 10 // Optimism chain ID -) -``` diff --git a/docs/pages/sdk-reference/mee-client/helpers/more/getJiffyScanLink.md b/docs/pages/sdk-reference/mee-client/helpers/more/getJiffyScanLink.md deleted file mode 100644 index c73c60a..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/more/getJiffyScanLink.md +++ /dev/null @@ -1,14 +0,0 @@ -# getExplorerTxLink - -The SDK provides several utility functions to help you generate links to various block explorers for tracking your transactions and user operations. - -## getJiffyScanLink - -Gets the JiffyScan transaction link for viewing user operations. JiffyScan provides detailed information about user operation execution and bundling. - -```typescript -import { getJiffyScanLink } from "@biconomy/abstractjs" - -const url = getJiffyScanLink("0x123...") -console.log(url) // https://v2.jiffyscan.xyz/tx/0x123... -``` \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/helpers/more/getMeeScanLink.md b/docs/pages/sdk-reference/mee-client/helpers/more/getMeeScanLink.md deleted file mode 100644 index 5968d3f..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/more/getMeeScanLink.md +++ /dev/null @@ -1,14 +0,0 @@ -# getExplorerTxLink - -The SDK provides several utility functions to help you generate links to various block explorers for tracking your transactions and user operations. - -## getMeeScanLink - -Gets the MeeScan transaction link for viewing transactions and user operations on Biconomy's explorer. - -```typescript -import { getMeeScanLink } from "@biconomy/abstractjs" - -const url = getMeeScanLink("0x123...") -console.log(url) // https://meescan.biconomy.io/details/0x123... -``` diff --git a/docs/pages/sdk-reference/mee-client/helpers/more/mcAaveV3Pool.md b/docs/pages/sdk-reference/mee-client/helpers/more/mcAaveV3Pool.md deleted file mode 100644 index d5f19f9..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/more/mcAaveV3Pool.md +++ /dev/null @@ -1,103 +0,0 @@ -# mcAaveV3Pool - -A pre-configured multichain contract instance for interacting with Aave V3 Pool contracts across different networks. This allows you to perform lending and borrowing operations across multiple chains using a unified interface. - -```typescript -export const mcAaveV3Pool = getMultichainContract({ - abi: AavePoolAbi, - deployments: [ - ["0x794a61358D6845594F94dc1DB02A252b5b4814aD", optimism.id], - ["0xA238Dd80C259a72e81d7e4664a9801593F98d1c5", base.id], - ["0x794a61358D6845594F94dc1DB02A252b5b4814aD", polygon.id], - ["0x794a61358D6845594F94dc1DB02A252b5b4814aD", arbitrum.id] - ] -}) -``` -## Usage - -```typescript -import { mcAaveV3Pool } from "@biconomy/abstractjs" -import { optimism } from "viem/chains" - -// Supply assets to Aave -const supplyInstruction = await mcAaveV3Pool.build({ - type: "supply", - data: { - chainId: optimism.id, - args: [ - tokenAddress, // address of the token to supply - amount, // amount to supply - userAddress, // address receiving the aToken - 0 // referral code - ] - } -}) -``` - -## Parameters - -Common parameters for building instructions: - -| Parameter | Type | Description | -|-----------|------|-------------| -| type | `string` | The function name to call (e.g., "supply", "borrow", "repay") | -| data.chainId | `number` | The chain ID where the transaction should be executed | -| data.args | `any[]` | The arguments for the function call | - -## Response - -The contract provides access to all Aave V3 Pool functions, including: - -| Function | Description | -|----------|-------------| -| supply | Supply assets to the protocol | -| borrow | Borrow assets from the protocol | -| repay | Repay borrowed assets | -| withdraw | Withdraw supplied assets | -| getUserAccountData | Get user's lending/borrowing positions | - -## Example - -Here's a complete example showing how to supply and borrow assets: - -```typescript -import { mcAaveV3Pool } from "@biconomy/abstractjs" -import { optimism } from "viem/chains" - -// Supply USDC to Aave -const supplyOp = await mcAaveV3Pool.build({ - type: "supply", - data: { - chainId: optimism.id, - args: [ - usdcAddress, - parseUnits("100", 6), // 100 USDC - userAddress, - 0 - ] - } -}) - -// Borrow ETH against the supplied collateral -const borrowOp = await mcAaveV3Pool.build({ - type: "borrow", - data: { - chainId: optimism.id, - args: [ - wethAddress, - parseEther("0.1"), // 0.1 ETH - 2, // variable rate mode - 0, // referral code - userAddress - ] - } -}) -``` - -## Error Handling - -The contract will throw an error if: -- Attempting to interact with an unsupported chain -- Insufficient collateral for borrowing -- Invalid function parameters -- Unsupported interest rate mode \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/helpers/more/mcUSDC.md b/docs/pages/sdk-reference/mee-client/helpers/more/mcUSDC.md deleted file mode 100644 index daec24b..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/more/mcUSDC.md +++ /dev/null @@ -1,130 +0,0 @@ -# mcUSDC - -A pre-configured multichain contract instance for interacting with USDC (USD Coin) across different networks. This allows you to perform token operations like transfers, approvals, and balance checks across multiple chains using a unified interface. - -```typescript -export const mcUSDC = getMultichainContract({ - abi: erc20Abi, - deployments: [ - ["0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", 1], - ["0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85", 10], - ["0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359", 137], - ["0x1d17CBcF0D6D143135aE902365D2E5e2A16538D4", 324], - ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", 8453], - ["0xaf88d065e77c8cC2239327C5EDb3A432268e5831", 42161], - ["0xcebA9300f2b948710d2653dD7B07f33A8B32118C", 42220], - ["0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E", 43114] - ] -}) -``` - -## Usage - -```typescript -import { mcUSDC } from "@biconomy/abstractjs" -import { optimism, base } from "viem/chains" - -// Check USDC balance across multiple chains -const balances = await mcUSDC.read({ - onChains: [optimism, base], - functionName: "balanceOf", - args: [address] -}) - -// Build a transfer instruction -const transferOp = await mcUSDC.build({ - type: "transfer", - data: { - chainId: optimism.id, - args: [ - recipient, - parseUnits("100", 6) // 100 USDC (6 decimals) - ] - } -}) -``` - -## Parameters - -Common parameters for building instructions: - -| Parameter | Type | Description | -|-----------|------|-------------| -| type | `string` | The function name to call (e.g., "transfer", "approve") | -| data.chainId | `number` | The chain ID where the transaction should be executed | -| data.args | `any[]` | The arguments for the function call | - -## Response - -The contract provides standard ERC20 functions: - -| Function | Description | -|----------|-------------| -| transfer | Transfer tokens to another address | -| approve | Approve spender to use tokens | -| balanceOf | Get token balance of an address | -| allowance | Check approved amount for spender | -| totalSupply | Get total token supply | - -## Example - -Here's a complete example showing common USDC operations: - -```typescript -import { mcUSDC } from "@biconomy/abstractjs" -import { optimism } from "viem/chains" -import { parseUnits } from "viem" - -// Approve a spender -const approveOp = await mcUSDC.build({ - type: "approve", - data: { - chainId: optimism.id, - args: [ - spenderAddress, - parseUnits("1000", 6) // 1000 USDC - ] - } -}) - -// Transfer USDC -const transferOp = await mcUSDC.build({ - type: "transfer", - data: { - chainId: optimism.id, - args: [ - recipientAddress, - parseUnits("50", 6) // 50 USDC - ] - } -}) - -// Check balances across chains -const balances = await mcUSDC.read({ - onChains: [optimism, base], - functionName: "balanceOf", - args: [userAddress] -}) - -// Get allowance -const allowance = await mcUSDC.read({ - onChains: [optimism], - functionName: "allowance", - args: [userAddress, spenderAddress] -}) -``` - -## Error Handling - -The contract will throw an error if: -- Attempting to interact with an unsupported chain -- Insufficient balance for transfers -- Invalid function parameters -- Attempting to transfer to zero address - -## Important Notes - -- USDC uses 6 decimals (not 18 like most ERC20 tokens) -- Always use parseUnits(amount, 6) when specifying USDC amounts -- Token addresses may vary by chain -- Some chains may have bridged versions of USDC diff --git a/docs/pages/sdk-reference/mee-client/helpers/more/mcUniswapSwapRouter.md b/docs/pages/sdk-reference/mee-client/helpers/more/mcUniswapSwapRouter.md deleted file mode 100644 index f065f91..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/more/mcUniswapSwapRouter.md +++ /dev/null @@ -1,119 +0,0 @@ - # mcUniswapSwapRouter - -A pre-configured multichain contract instance for interacting with Uniswap's SwapRouter across different networks. This allows you to perform token swaps and related operations across multiple chains using a unified interface. - -```typescript -export const mcUniswapSwapRouter = getMultichainContract< - typeof UniswapSwapRouterAbi ->({ - abi: UniswapSwapRouterAbi, - deployments: [ - ["0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45", arbitrum.id], - ["0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45", optimism.id], - ["0x2626664c2603336E57B271c5C0b26F421741e481", base.id] - ] -}) -``` - -## Usage - -```typescript -import { mcUniswapSwapRouter } from "@biconomy/abstractjs" -import { optimism } from "viem/chains" - -// Build an exact input single swap -const swapOp = await mcUniswapSwapRouter.build({ - type: "exactInputSingle", - data: { - chainId: optimism.id, - args: [{ - tokenIn: tokenInAddress, - tokenOut: tokenOutAddress, - fee: 3000, - recipient: userAddress, - deadline: BigInt(Math.floor(Date.now() / 1000) + 900), - amountIn: parseUnits("100", 6), - amountOutMinimum: 1n, - sqrtPriceLimitX96: 0n - }], - // Some complex userOps will sometimes require more gas than the default. All surpluses are returned to the users smart account in native token - gasLimit: 1000000n - } -}) -``` - -## Parameters - -Common parameters for building swap instructions: - -| Parameter | Type | Description | -|-----------|------|-------------| -| type | `string` | The swap function to call (e.g., "exactInputSingle", "exactInput") | -| data.chainId | `number` | The chain ID where the swap should be executed | -| data.args | `SwapParams[]` | The swap parameters | -| data.gasLimit | `bigint` | Optional gas limit for the swap | - -### SwapParams - -| Parameter | Type | Description | -|-----------|------|-------------| -| tokenIn | `Address` | Address of input token | -| tokenOut | `Address` | Address of output token | -| fee | `number` | Pool fee tier (500, 3000, 10000) | -| recipient | `Address` | Address receiving the output tokens | -| deadline | `bigint` | Timestamp deadline for execution | -| amountIn | `bigint` | Amount of input tokens | -| amountOutMinimum | `bigint` | Minimum output tokens to receive | -| sqrtPriceLimitX96 | `bigint` | Price limit for the swap | - -## Example - -Here's a complete example showing how to perform a token swap with approval: - -```typescript -import { mcUniswapSwapRouter, mcUSDC } from "@biconomy/abstractjs" -import { optimism } from "viem/chains" -import { parseUnits } from "viem" - -// First approve the router -const approval = mcUSDC.build({ - type: "approve", - data: { - chainId: optimism.id, - args: [ - mcUniswapSwapRouter.addressOn(optimism.id), - parseUnits("100", 6) // 100 USDC - ] - } -}) - -// Build the swap -const swap = mcUniswapSwapRouter.build({ - type: "exactInputSingle", - data: { - chainId: optimism.id, - args: [{ - tokenIn: mcUSDC.addressOn(optimism.id), - tokenOut: wethAddress, - fee: 3000, - recipient: userAddress, - deadline: BigInt(Math.floor(Date.now() / 1000) + 900), - amountIn: parseUnits("100", 6), - amountOutMinimum: parseEther("0.05"), // 0.05 ETH minimum - sqrtPriceLimitX96: 0n - }], - // Some complex userOps will sometimes require more gas than the default. All surpluses are returned to the users smart account in native token - gasLimit: 1000000n - } -}) - -``` - -## Error Handling - -The contract will throw an error if: -- Attempting to swap on an unsupported chain -- Insufficient token approval -- Price impact too high -- Deadline expired -- Slippage tolerance exceeded \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/helpers/runtimeERC20BalanceOf.md b/docs/pages/sdk-reference/mee-client/helpers/runtimeERC20BalanceOf.md deleted file mode 100644 index a50d7c3..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/runtimeERC20BalanceOf.md +++ /dev/null @@ -1,116 +0,0 @@ -# runtimeERC20BalanceOf - -The `runtimeERC20BalanceOf` function creates a runtime value that resolves to the ERC20 token balance of a specific address at transaction execution time. This allows for dynamic amounts in transactions based on real-time balances. - -## Overview - -Instead of hardcoding token amounts in your transactions, `runtimeERC20BalanceOf` allows the smart contract to use the actual token balance at execution time. This is particularly useful for operations like: - -- Transferring an entire token balance -- Creating transactions that depend on balances which may change -- Setting approval amounts based on current holdings -- Validating that sufficient tokens are available before proceeding - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| targetAddress | `Address` | Yes | The address whose token balance will be checked | -| tokenAddress | `Address` | Yes | The ERC20 token contract address | -| constraints | `RuntimeConstraint[]` | No | Optional validation constraints to apply to the balance | - -## Runtime Constraints - -Constraints allow you to add validation rules to the balance: - -| Constraint | Description | Example | -|------------|-------------|---------| -| `greaterThanOrEqualTo(value)` | Ensures the balance is at least the specified amount | `greaterThanOrEqualTo(parseUnits("1", 6))` | -| `lessThanOrEqualTo(value)` | Ensures the balance doesn't exceed the specified amount | `lessThanOrEqualTo(parseUnits("100", 6))` | -| `equalTo(value)` | Ensures the balance equals the specified amount | `equalTo(parseUnits("50", 6))` | -| `notEqualTo(value)` | Ensures the balance doesn't equal the specified amount | `notEqualTo(0n)` | - -## Examples - -### Basic Usage - -```typescript -// Create a runtime value that resolves to the USDC balance of the account -const dynamicAmount = runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId) -}); - -// Use it in a transfer transaction -const transferInstruction = await mcNexus.buildComposable({ - type: "transfer", - data: { - recipient: recipientAddress, - tokenAddress: mcUSDC.addressOn(chainId), - amount: dynamicAmount, // Will use actual balance at execution time - chainId: chainId - } -}); -``` - -### With Constraints - -```typescript -// Create a runtime value with minimum balance requirement -const dynamicAmount = runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId), - constraints: [ - greaterThanOrEqualTo(parseUnits("0.01", 6)) // Ensure at least 0.01 USDC - ] -}); - -// The transaction will fail if the balance is less than 0.01 USDC -const approveInstruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: mcUSDC.addressOn(chainId), - abi: erc20Abi, - functionName: "approve", - args: [ - spenderAddress, - dynamicAmount - ], - chainId: chainId - } -}); -``` - -### Multiple Constraints - -```typescript -// Apply multiple constraints to the balance -const dynamicAmount = runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId), - constraints: [ - greaterThanOrEqualTo(parseUnits("1", 6)), // At least 1 USDC - lessThanOrEqualTo(parseUnits("1000", 6)) // No more than 1000 USDC - ] -}); -``` - -### Checking Another Account's Balance - -```typescript -// Get the token balance of any address (not just your own account) -const otherAccountBalance = runtimeERC20BalanceOf({ - targetAddress: "0xAnotherAccountAddress", - tokenAddress: mcUSDC.addressOn(chainId) -}); -``` - -## When to Use - -Use `runtimeERC20BalanceOf` when you: - -- Need to transfer or use an entire token balance -- Want to create self-adapting transactions that work with changing balances -- Need to ensure minimum balances before proceeding with a transaction -- Want to create dynamic approval amounts for DeFi interactions -- Need to reference token balances of external accounts in your transaction logic \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/helpers/runtimeEncodeAbiParameters.md b/docs/pages/sdk-reference/mee-client/helpers/runtimeEncodeAbiParameters.md deleted file mode 100644 index cb73997..0000000 --- a/docs/pages/sdk-reference/mee-client/helpers/runtimeEncodeAbiParameters.md +++ /dev/null @@ -1,130 +0,0 @@ -# runtimeEncodeAbiParameters - -The `runtimeEncodeAbiParameters` function encodes complex data structures with runtime values for use in smart contract interactions. This is particularly useful when you need to pass structured data that includes dynamic values determined at execution time. - -## Overview - -Smart contracts often require complex structured data as input parameters. The `runtimeEncodeAbiParameters` function allows you to encode this data while incorporating runtime values like token balances or references to previous transaction outputs. - -This is especially useful for: -- Creating complex parameter tuples or structs with runtime components -- Encoding calldata for contracts with complex parameter requirements -- Working with ABI-encoded byte parameters that contain dynamic values - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| types | `AbiParameter[]` | Yes | Array of parameter types according to ABI specification | -| values | `any[]` | Yes | Array of values to encode (can include runtime values) | - -## Examples - -### Basic Usage - -```typescript -// Encode complex parameters with one runtime value -const encodedData = runtimeEncodeAbiParameters( - [ - { name: "x", type: "uint256" }, - { name: "y", type: "uint256" }, - { name: "z", type: "bool" } - ], - [ - 420n, // Static value - runtimeERC20BalanceOf({ // Dynamic value resolved at execution time - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId) - }), - true // Static value - ] -); - -// Use the encoded data in a contract call -const instruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: contractAddress, - abi: CONTRACT_ABI, - functionName: "processData", - args: [encodedData], // Pass as a single bytes parameter - chainId: chainId - } -}); -``` - -### Complex Nested Structures - -```typescript -// Create a complex nested structure with runtime values -const encodedStruct = runtimeEncodeAbiParameters( - [ - { name: "owner", type: "address" }, - { name: "amounts", type: "uint256[]" }, - { name: "details", type: "tuple", components: [ - { name: "active", type: "bool" }, - { name: "limit", type: "uint256" } - ]} - ], - [ - mcNexus.addressOn(chainId), - [ - 100n, - runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId) - }) - ], - [ - true, - 500n - ] - ] -); -``` - -### Using in a Contract Method - -```typescript -// Example from the tests: calling a contract with complex encoded parameters -const instruction = await mcNexus.buildComposable({ - type: "default", - data: { - to: fooContractAddress, - abi: FOO_CONTRACT_ABI, - functionName: "foo", - args: [ - param1, - param2, - runtimeEncodeAbiParameters( - [ - { name: "x", type: "uint256" }, - { name: "y", type: "uint256" }, - { name: "z", type: "bool" } - ], - [ - 420n, - runtimeERC20BalanceOf({ - targetAddress: mcNexus.addressOn(chainId), - tokenAddress: mcUSDC.addressOn(chainId), - constraints: [] - }), - true - ] - ), - param4, - param5 - ], - chainId: chainId - } -}); -``` - -## When to Use - -Use `runtimeEncodeAbiParameters` when: - -- Working with contracts that require complex structured inputs -- You need to combine static values with dynamic runtime values in a single parameter -- Passing tuples, structs, or arrays that contain runtime values -- Creating encoded calldata with dynamic components for custom contract interactions \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/index.md b/docs/pages/sdk-reference/mee-client/index.md deleted file mode 100644 index f96bd59..0000000 --- a/docs/pages/sdk-reference/mee-client/index.md +++ /dev/null @@ -1,170 +0,0 @@ -# MEE Client - -The MEE (Modular Execution Environment) Client is your gateway to executing transactions across multiple blockchains with a single API. It simplifies cross-chain development by handling the complex orchestration of transactions behind the scenes. - -## What is MEE Client? - -MEE Client enables developers to: - -- Execute transactions across multiple blockchains with a single user signature -- Pay for gas fees on any chain using tokens from a different chain -- Orchestrate complex transaction sequences with interdependencies -- Combine explicit transactions with intent-based execution -- Support both standard EOAs and Smart Accounts through the Fusion Module - -## Installation - -```bash -npm install @biconomy/abstractjs viem @rhinestone/module-sdk -# or -yarn add @biconomy/abstractjs viem @rhinestone/module-sdk -``` - -## Quick Start - -Here's how to initialize the MEE Client: - -```typescript -import { privateKeyToAccount } from "viem/accounts"; -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia, mainnet } from "viem/chains"; -import { http } from "viem"; - -// 1. Create a signer account (for development) -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); - -// 2. Initialize the multichain smart account -const mcNexus = await toMultichainNexusAccount({ - chains: [baseSepolia, mainnet], - transports: [http(), http()], - signer: account -}); - -// 3. Create the MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// 4. Now you can execute cross-chain operations -const quote = await meeClient.getQuote({ - instructions: [{ - calls: [{ to: "0x123...", value: 0n, data: "0x..." }], - chainId: baseSepolia.id - }], - feeToken: { - address: "0x456...", // USDC contract - chainId: mainnet.id // Pay with tokens from Ethereum mainnet - } -}); - -// 5. Execute the quote -const { hash } = await meeClient.executeQuote({ quote }); -console.log(`Transaction hash: ${hash}`); -``` - -## MultichainSmartAccount Configuration - -When creating a multichain account using `toMultichainNexusAccount`, the following parameters are required: - -| Parameter | Type | Required | Default | Description | -|-----------|------|----------|---------|-------------| -| chains | `Chain[]` | Yes | - | Array of chains the account will interact with | -| transports | `Transport[]` | Yes | - | Array of transports for each chain (must match the order of chains) | -| signer | `Account` | Yes | - | The signer account that controls the smart account | - -The `MultichainSmartAccount` returned by `toMultichainNexusAccount` provides several useful methods: - -- `deploymentOn(chainId)`: Get the deployment information for a specific chain -- `getUnifiedERC20Balance(mcToken)`: Check token balances across all configured chains -- `buildBridgeInstructions({...})`: Create instructions for bridging tokens between chains -- `build({...})`: Build various types of instructions (default, intent, batch, etc.) - -Example usage: - -```typescript -// Get deployment on specific chain -const optimismDeployment = mcNexus.deploymentOn(10); - -// Check token balance across chains -const balance = await mcNexus.getUnifiedERC20Balance(mcUSDC); - -// Build bridge transaction -const bridgeInstructions = await mcNexus.buildBridgeInstructions({ - amount: BigInt("1000000"), // 1 USDC - mcToken: mcUSDC, - toChain: base -}); -``` - -## Developer Notice - -## Configuration Options - -When creating a MEE Client, you can configure the following parameters: - -| Parameter | Type | Required | Default | Description | -|-----------|------|----------|---------|-------------| -| account | `MultichainSmartAccount` | Yes | - | The multichain smart account used for cross-chain transactions. Must be created using `toMultichainNexusAccount` | -| pollingInterval | `number` | No | `1000` | Frequency in milliseconds for polling actions and events | -| url | `string` | No | `"https://network.biconomy.io/v1"` | The URL for the MEE node service | -| apiKey | `string` | No | - | API key for production use with higher rate limits. Can be obtained from the [Biconomy Dashboard](https://dashboard.biconomy.io) | - -## Example Use Cases - -### 1. Cross-Chain DeFi Operations - -Execute a sequence that withdraws funds from Aave on one chain and deposits to Compound on another chain: - -```typescript -// Example code showing a cross-chain DeFi operation -const crossChainDeFi = await meeClient.executeQuote({ - quote: await meeClient.getQuote({ - instructions: [ - // 1. Withdraw from Aave on Optimism - ...withdrawFromAaveInstructions, - // 2. Bridge funds to Base - ...bridgeToBaseInstructions, - // 3. Deposit to Compound on Base - ...depositToCompoundInstructions - ], - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - } - }) -}); -``` - -### 2. Using Fusion for EOA Users - -Enable regular EOA users to perform complex operations without upgrading to smart accounts: - -```typescript -// Example code showing Fusion functionality for EOAs -const fusionResult = await meeClient.executeFusionQuote({ - fusionQuote: await meeClient.getFusionQuote({ - trigger: { - chainId: optimism.id, - tokenAddress: mcUSDC.addressOn(optimism.id), - amount: parseUnits("1", 6) - }, - instructions: [approveInstruction, supplyInstruction], - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - } - }) -}); -``` - -## Available Documentation - -- [**Account Configuration**](/sdk-reference/mee-client/account/index.md) - Learn how to create and use MultichainNexusAccount -- [**Methods**](/sdk-reference/mee-client/methods/index.md) - Explore the available methods on the MEE Client -- [**Helpers**](/sdk-reference/mee-client/helpers/index.md) - Utility functions for working with the MEE Client - -## Next Steps - -After setting up the MEE Client, you can: -- Learn about [Supertransactions](/mee/supertransactions) for advanced cross-chain operations -- Explore [Cross-Chain Gas Abstraction](/multichain-gas-abstraction/overview) to optimize costs -- Check out [MEE Fusion](/mee/fusion) to enable EOA users to use smart account features diff --git a/docs/pages/sdk-reference/mee-client/methods/executeFusionQuote.md b/docs/pages/sdk-reference/mee-client/methods/executeFusionQuote.md deleted file mode 100644 index 44eb67f..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/executeFusionQuote.md +++ /dev/null @@ -1,164 +0,0 @@ -# executeFusionQuote - -The `executeFusionQuote` method enables EOA (Externally Owned Account) holders to execute cross-chain transactions with trigger conditions. This method combines `signFusionQuote` and `executeSignedQuote` into a single operation, making it easier for EOA users to perform conditional cross-chain transactions without first upgrading to a smart account. It automatically handles the signing process (either permit or on-chain) and executes the transaction in one step. - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| fusionQuote | `FusionQuote` | Yes | The fusion quote to execute, obtained from `getFusionQuote` | - -## Returns - -| Property | Type | Description | -|----------|------|-------------| -| hash | `Hex` | The transaction hash of the executed supertransaction | - -## Example - -Based on the test files, here's how to use `executeFusionQuote`: - -```typescript -import { createMeeClient } from "@biconomy/abstractjs"; -import { mcUSDC } from "@biconomy/abstractjs"; - -// Define the transaction trigger -const trigger = { - chainId: paymentChain.id, - tokenAddress: mcUSDC.addressOn(paymentChain.id), - amount: 1n // Amount of tokens that triggers the transaction -}; - -// Get a fusion quote -const fusionQuote = await meeClient.getFusionQuote({ - trigger, - instructions: [ - mcNexus.build({ - type: "transfer", - data: { - ...trigger, // Same chain, token and amount - recipient: recipientAddress - } - }) - ], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); - -// Execute the fusion quote -const { hash } = await meeClient.executeFusionQuote({ fusionQuote }); - -// Wait for the transaction with optional confirmations -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash, - confirmations: 3 -}); - -// Transaction links -console.log(receipt.explorerLinks); -``` - -## Example with AAVE Integration - -```typescript -import { parseUnits } from "viem"; -import { aave, mcUSDC, mcAUSDC } from "@biconomy/abstractjs"; - -const amountToSupply = parseUnits("0.1", 6); // 0.1 USDC - -// Check balance before the transaction -const balanceBefore = await getBalance( - mcNexus.deploymentOn(targetChain.id, true).publicClient, - mcNexus.signer.address, - mcAUSDC.addressOn(targetChain.id) -); - -// Define trigger -const trigger = { - chainId: paymentChain.id, - tokenAddress: mcUSDC.addressOn(paymentChain.id), - amount: amountToSupply -}; - -// Get fusion quote for AAVE supply operation -const fusionQuote = await meeClient.getFusionQuote({ - trigger, - instructions: [ - // Bridge USDC to target chain if needed - mcNexus.build({ - type: "intent", - data: { - amount: amountToSupply, - mcToken: mcUSDC, - toChain: targetChain - } - }), - // Approve AAVE to spend USDC - mcNexus.build({ - type: "approve", - data: { - chainId: targetChain.id, - tokenAddress: mcUSDC.addressOn(targetChain.id), - amount: amountToSupply, - spender: aave.pool.addressOn(targetChain.id) - } - }), - // Supply USDC to AAVE - mcAaveV3Pool.build({ - type: "supply", - data: { - chainId: targetChain.id, - args: [ - mcUSDC.addressOn(targetChain.id), - amountToSupply, - mcNexus.signer.address, - 0 - ] - } - }) - ], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); - -// Execute the fusion quote -const { hash } = await meeClient.executeFusionQuote({ fusionQuote }); - -// Wait for the transaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash -}); - -// Verify increased aUSDC balance -const balanceAfter = await getBalance( - mcNexus.deploymentOn(targetChain.id, true).publicClient, - mcNexus.signer.address, - mcAUSDC.addressOn(targetChain.id) -); -console.log(`aUSDC balance increased: ${balanceAfter > balanceBefore}`); -``` - -## Checking for Transaction Success - -After executing a fusion quote, you should wait for the receipt and check if it was successful: - -```typescript -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - -if (receipt.transactionStatus === "MINED_SUCCESS") { - console.log("Transaction completed successfully!"); - console.log("View transaction:"); - receipt.explorerLinks.forEach(link => console.log(link)); -} else { - console.error("Transaction failed:", receipt.transactionStatus); -} -``` - -## Related Methods - -- [`getFusionQuote`](/sdk-reference/mee-client/methods/getFusionQuote) - Get a fusion quote to execute -- [`waitForSupertransactionReceipt`](/sdk-reference/mee-client/methods/waitForSupertransactionReceipt) - Wait for a transaction to complete \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/executeQuote.md b/docs/pages/sdk-reference/mee-client/methods/executeQuote.md deleted file mode 100644 index 66e1dca..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/executeQuote.md +++ /dev/null @@ -1,83 +0,0 @@ -# executeQuote - -The `executeQuote` method executes a quote by signing it and then executing the signed quote. This is a convenience method that combines `signQuote` and `executeSignedQuote` into a single operation. - -## Parameters - -| Parameter | Type | Description | -|-----------|------|-------------| -| `quote` | `GetQuotePayload` | The quote payload to be executed, obtained from `getQuote` | - -## Returns - -Promise resolving to an `ExecuteSignedQuotePayload` containing: - -| Property | Type | Description | -|----------|------|-------------| -| `hash` | `Hex` | The transaction hash of the executed quote | - -## Example - -Based on the test files, here's a typical usage pattern: - -```typescript -// Get a quote for executing all instructions -// This will calculate the total cost in the specified payment token -const quote = await meeClient.getQuote({ - instructions: [ - mcNexus.build({ - type: "default", - data: { - calls: [{ to: zeroAddress, value: 0n }], - chainId: targetChain.id - } - }) - ], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); - -// Execute the quote and get back a transaction hash -// This sends the transaction to the network -const { hash } = await meeClient.executeQuote({ quote }); - -// Wait for the transaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - -// Check transaction status -if (receipt.transactionStatus === "MINED_SUCCESS") { - console.log("Transaction successful"); -} -``` - -## Error Handling - -Throws an error if: -- The account is not deployed on any required chain -- The quote signing fails -- The quote execution fails - -## Type Definitions - -### SignQuoteParams -```typescript -type SignQuoteParams = { - quote: GetQuotePayload - deadline?: number - nonce?: number -} -``` - -### ExecuteSignedQuotePayload -```typescript -type ExecuteSignedQuotePayload = { - hash: Hex -} -``` - -## Related Methods - -- [`getQuote`](/sdk-reference/mee-client/methods/getQuote) - Get a quote for executing instructions -- [`waitForSupertransactionReceipt`](/sdk-reference/mee-client/methods/waitForSupertransactionReceipt) - Wait for a transaction to complete diff --git a/docs/pages/sdk-reference/mee-client/methods/getFusionQuote.md b/docs/pages/sdk-reference/mee-client/methods/getFusionQuote.md deleted file mode 100644 index d8142b3..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/getFusionQuote.md +++ /dev/null @@ -1,218 +0,0 @@ -# getFusionQuote - -Gets a fusion quote that enables EOA (Externally Owned Account) holders to execute cross-chain transactions based on token triggers. This method is specifically designed to support EOA users who want to perform conditional cross-chain operations without needing to first upgrade to a smart account. The fusion quote includes both the trigger conditions and the instructions to be executed when those conditions are met. - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| trigger | `Trigger` | Yes | The condition that must be met for the transaction to execute | -| instructions | `InstructionLike[]` | Yes | Array of instructions to be executed | -| feeToken | `FeeTokenInfo` | Yes | Token to be used for paying transaction fees | - -### Trigger Object - -| Property | Type | Required | Description | -|----------|------|----------|-------------| -| chainId | `number` | Yes | Chain ID where the trigger condition will be monitored | -| tokenAddress | `Address` | Yes | Address of the token to monitor | -| amount | `bigint` | Yes | Amount of tokens required to trigger the transaction | -| useMaxAvailableAmount | `boolean` | No | Whether to use the maximum available token balance, automatically accounting for gas fees. When true, the specified amount will be ignored and the maximum available balance after deducting gas fees will be used. Should be used in combination with runtimeERC20BalanceOf in the instruction which uses the permitted token. Default is false. | - -### FeeTokenInfo Object - -| Property | Type | Required | Description | -|----------|------|----------|-------------| -| address | `Address` | Yes | Address of the fee token | -| chainId | `number` | Yes | Chain ID where the fee token is deployed | - -## Returns - -The method returns a fusion quote that can be passed to `executeFusionQuote` to execute the transaction when the trigger condition is met. - -## Basic Example - -```typescript -// Define the trigger condition -const trigger = { - chainId: paymentChain.id, - tokenAddress: mcUSDC.addressOn(paymentChain.id), - amount: 1n // The amount that will trigger the transaction -}; - -// Get a fusion quote -const fusionQuote = await meeClient.getFusionQuote({ - trigger, - instructions: [ - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: zeroAddress, - gasLimit: 50000n, - value: 0n - } - ], - chainId: paymentChain.id - } - }) - ], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); - -// Execute the fusion quote -const { hash } = await meeClient.executeFusionQuote({ fusionQuote }); -``` - -## AAVE Integration Example - -```typescript -import { parseUnits } from "viem"; - -// Define the amount to supply to AAVE -const amountToSupply = parseUnits("0.1", 6); // 0.1 USDC - -// Check aUSDC balance before the transaction -const balanceBefore = await getBalance( - mcNexus.deploymentOn(targetChain.id, true).publicClient, - mcNexus.signer.address, - mcAUSDC.addressOn(targetChain.id) -); - -// Define the trigger for the transaction -const trigger = { - chainId: paymentChain.id, - tokenAddress: mcUSDC.addressOn(paymentChain.id), - amount: amountToSupply -}; - -// Get a fusion quote for AAVE operations -const fusionQuote = await meeClient.getFusionQuote({ - instructions: [ - // Bridge USDC if needed - mcNexus.build({ - type: "intent", - data: { - amount: amountToSupply, - mcToken: mcUSDC, - toChain: targetChain - } - }), - // Approve AAVE to spend USDC - mcNexus.build({ - type: "approve", - data: { - chainId: targetChain.id, - tokenAddress: mcUSDC.addressOn(targetChain.id), - amount: amountToSupply, - spender: aave.pool.addressOn(targetChain.id) - } - }), - // Supply USDC to AAVE - mcAaveV3Pool.build({ - type: "supply", - data: { - chainId: targetChain.id, - args: [ - mcUSDC.addressOn(targetChain.id), - amountToSupply, - mcNexus.signer.address, - 0 - ] - } - }) - ], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - }, - trigger -}); - -// Execute the fusion quote -const { hash } = await meeClient.executeFusionQuote({ fusionQuote }); - -// Wait for the transaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash -}); - -// Verify that aUSDC balance increased -const balanceAfter = await getBalance( - mcNexus.deploymentOn(targetChain.id, true).publicClient, - mcNexus.signer.address, - mcAUSDC.addressOn(targetChain.id) -); -console.log(`aUSDC balance increased: ${balanceAfter > balanceBefore}`); -``` - -## Complete Transaction Flow - -Here's a complete transaction flow using `getFusionQuote` and related methods: - -```typescript -import { parseUnits } from "viem"; -import { mcUSDC } from "@biconomy/abstractjs"; - -// 1. Define the trigger condition -const trigger = { - chainId: paymentChain.id, - tokenAddress: mcUSDC.addressOn(paymentChain.id), - amount: parseUnits("0.1", 6) // 0.1 USDC -}; - -// 2. Get a fusion quote -const fusionQuote = await meeClient.getFusionQuote({ - trigger, - instructions: [ - mcNexus.build({ - type: "transfer", - data: { - ...trigger, - recipient: recipientAddress - } - }) - ], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); - -// 3. Execute the fusion quote -const { hash } = await meeClient.executeFusionQuote({ fusionQuote }); - -// 4. Wait for the transaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash, - confirmations: 3 // Optional: wait for multiple confirmations -}); - -// 5. Check transaction status -if (receipt.transactionStatus === "MINED_SUCCESS") { - console.log("Transaction completed successfully!"); - console.log("Explorer links:", receipt.explorerLinks); -} else { - console.error("Transaction failed:", receipt.transactionStatus); -} -``` - -## Implementation Details - -Under the hood, `getFusionQuote` automatically determines whether to use permit-based or standard transactions by checking the payment token's permit support: - -```typescript -const { permitEnabled } = await getPaymentToken(client, parameters.trigger); -return permitEnabled - ? getPermitQuote(client, parameters) - : getOnChainQuote(client, parameters); -``` - -## Related Methods - -- [`executeFusionQuote`](/sdk-reference/mee-client/methods/executeFusionQuote) - Execute a fusion quote -- [`waitForSupertransactionReceipt`](/sdk-reference/mee-client/methods/waitForSupertransactionReceipt) - Wait for a transaction to complete diff --git a/docs/pages/sdk-reference/mee-client/methods/getQuote.md b/docs/pages/sdk-reference/mee-client/methods/getQuote.md deleted file mode 100644 index b04b909..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/getQuote.md +++ /dev/null @@ -1,197 +0,0 @@ -# getQuote - -The `getQuote` method requests a quote from the MEE service for executing a set of instructions. It returns a committed supertransaction quote that can span multiple chains. - -## Parameters - -| Parameter | Type | Description | -|-----------|------|-------------| -| `instructions` | `InstructionLike[]` | Array of instructions to be executed. Can be Instruction objects or promises that resolve to Instruction objects | -| `feeToken` | `FeeTokenInfo` | Information about the token used for paying transaction fees | -| `account` | `MultichainSmartAccount` | (Optional) Smart account to execute the transaction. If not provided, uses the client's default account | -| `delegate` | `boolean` | (Optional) When set to `true`, the MEE node will execute the transaction on behalf of your account. This allows you to submit transactions without needing to sign them yourself. Default is `false` | -| `eoa` | `Address` | (Optional) EOA address to be used for the transaction. Only required when using permit-enabled tokens | -| `lowerBoundTimestamp` | `number` | (Optional) Lower bound execution timestamp for all user operations. Defaults to current time | -| `upperBoundTimestamp` | `number` | (Optional) Upper bound execution timestamp for all user operations. Defaults to current time + 180 seconds | - -## Returns - -Promise resolving to a `GetQuotePayload` containing: - -| Property | Type | Description | -|----------|------|-------------| -| `hash` | `Hex` | Supertransaction hash for reference | -| `node` | `Address` | Address of the MEE node that will process the transaction | -| `commitment` | `Hex` | Cryptographic commitment hash | -| `paymentInfo` | `FilledPaymentInfo` | Complete payment information including token amounts, sender address, and chain details | -| `userOps` | `MeeFilledUserOpDetails[]` | Array of user operations with their details including gas parameters and execution windows | - -## Basic Example - -```typescript -// Get a quote for executing a simple instruction -const quote = await meeClient.getQuote({ - instructions: [ - { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - value: 0n, - gasLimit: 50000n - } - ], - chainId: targetChain.id - } - ], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); - -// Sign the quote -const signedQuote = await meeClient.signQuote({ quote }); - -// Execute the quote -const { hash } = await meeClient.executeQuote({ quote }); - -// Wait for transaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -console.log("Transaction status:", receipt.transactionStatus); -console.log("Explorer links:", receipt.explorerLinks); -``` - -## Using with Account Builder - -You can use the `build` method of your MultichainSmartAccount to create instructions: - -```typescript -// These can be any 'Instruction', or any helper method that resolves to an 'Instruction' -const transferInstruction = await mcNexus.build({ - type: "transfer", - data: { - chainId: targetChain.id, - tokenAddress: mcUSDC.addressOn(targetChain.id), - amount: parseUnits("0.1", 6), - recipient: recipientAddress - } -}); - -const quote = await meeClient.getQuote({ - instructions: [transferInstruction], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); - -console.log("Quote received with payment amount:", quote.paymentInfo.tokenAmount); -``` - -## Delegated Transaction Example - -```typescript -// Get a quote for executing a transaction using delegation -const quote = await meeClient.getQuote({ - delegate: true, - instructions: [ - { - calls: [ - { - to: recipientAddress, - value: 1n - } - ], - chainId: sepolia.id - } - ], - feeToken: { - address: "0x0000000000000000000000000000000000000000", // Native token - chainId: sepolia.id - } -}); - -// Sign and execute the quote -const signedQuote = await meeClient.signQuote({ quote }); -const { hash } = await meeClient.executeQuote({ quote }); - -// Wait for transaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -console.log("Transaction status:", receipt.transactionStatus); -``` - -## Delegation - -The `delegate` feature leverages EIP-7702 to deploy companion accounts more efficiently than traditional CREATE2 deployments. This provides significant benefits: - -1. **Gas efficiency**: Companion accounts deployed via EIP-7702 are substantially cheaper than standard deployments -2. **Future compatibility**: The implementation anticipates the EIP-7702 protocol enhancement -3. **Enhanced capabilities**: Works with both existing smart accounts and EOAs - -Key use cases include: -- Automated/recurring transactions -- Gasless experiences -- Simplified cross-chain operations -- Funds are returned to the EOA instead of nexus account - -Your account must support delegation through its validation logic. The Biconomy MultichainNexusAccount includes built-in delegation support. - -## Error Handling - -The method throws an error if: -- The account is not deployed on required chains -- The fee token is not supported on the specified chain -- The chain(s) specified in the instructions are not supported by the MEE node - -## Type Definitions - -### Instruction -```typescript -type AbstractCall = { - to: Address - gasLimit?: bigint // Defaults to 500_000n. Overestimated gas will be refunded. -} & OneOf< - | { value: bigint; data?: Hex } - | { value?: bigint; data: Hex } - | { value: bigint; data: Hex } -> - -type Instruction = { - calls: AbstractCall[] | ComposableCall[] - chainId: number - isComposable?: boolean -} -``` - -### FeeTokenInfo -```typescript -type FeeTokenInfo = { - address: Address // Address of the fee token - chainId: number // Chain ID where the fee token is deployed -} -``` - -### GetQuoteParams -```typescript -type GetQuoteParams = { - instructions: InstructionLike[] - feeToken: FeeTokenInfo - account?: MultichainSmartAccount - delegate?: boolean - eoa?: Address - lowerBoundTimestamp?: number - upperBoundTimestamp?: number - path?: string -} -``` - -### GetQuotePayload -```typescript -type GetQuotePayload = { - hash: Hex - node: Address - commitment: Hex - paymentInfo: FilledPaymentInfo - userOps: MeeFilledUserOpDetails[] -} -``` \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/index.md b/docs/pages/sdk-reference/mee-client/methods/index.md deleted file mode 100644 index 136f282..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/index.md +++ /dev/null @@ -1,234 +0,0 @@ -# MeeClient Methods - -The MEE Client provides a set of powerful methods for executing transactions across multiple blockchains. This page serves as your guide to understanding and using these methods effectively. - -## Overview - -The MEE Client extends a base HTTP client with specialized actions for cross-chain transactions. These methods enable you to: - -1. **Get execution quotes** - Find out how much a transaction will cost -2. **Execute cross-chain instructions** - Run transactions on multiple chains -3. **Work with Fusion transactions** - Enable EOA users to use advanced features -4. **Track transaction status** - Monitor the progress of your transactions -5. **Query token information** - Get details about supported payment tokens - -## Core Methods - -### getQuote - -Gets a quote for executing a set of instructions across multiple chains. - -```typescript -const quote = await meeClient.getQuote({ - instructions: [ - // Instructions to execute on chain A - { - calls: [{ to: "0xContract", value: 0n, data: "0xCalldata" }], - chainId: chainA.id - }, - // Instructions to execute on chain B - { - calls: [{ to: "0xContract", value: 0n, data: "0xCalldata" }], - chainId: chainB.id - } - ], - feeToken: { - // Pay for execution with tokens on chain A - address: "0xTokenAddress", - chainId: chainA.id - } -}); - -console.log(`Execution price: ${quote.paymentInfo.tokenAmount}`); -``` - -[Learn more about getQuote](./getQuote.md) - -### executeQuote - -Executes a quote obtained from `getQuote` to run transactions across multiple chains. - -```typescript -const { hash } = await meeClient.executeQuote({ - quote -}); - -console.log(`Transaction hash: ${hash}`); -``` - -[Learn more about executeQuote](./executeQuote.md) - -### getFusionQuote - -Gets a quote for executing a Fusion transaction, which allows regular EOA wallets to perform complex operations without upgrading to smart accounts. - -```typescript -const fusionQuote = await meeClient.getFusionQuote({ - // The on-chain trigger transaction - trigger: { - chainId: optimism.id, - tokenAddress: "0xUSDCAddress", - amount: parseUnits("1", 6) - }, - // Instructions to execute after trigger - instructions: [ - approveInstruction, - supplyInstruction - ], - // Pay with these tokens - feeToken: { - address: "0xUSDCAddress", - chainId: optimism.id - } -}); -``` - -[Learn more about getFusionQuote](./getFusionQuote.md) - -### executeFusionQuote - -Executes a Fusion quote obtained from `getFusionQuote`. - -```typescript -const { hash } = await meeClient.executeFusionQuote({ - fusionQuote -}); - -console.log(`Fusion transaction hash: ${hash}`); -``` - -[Learn more about executeFusionQuote](./executeFusionQuote.md) - -### getPaymentToken - -Retrieves detailed information about a specific payment token on a given blockchain, including whether it supports ERC20Permit. - -```typescript -const tokenInfo = await meeClient.getPaymentToken({ - chainId: 1, // Ethereum Mainnet - tokenAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC -}); - -console.log(`Token: ${tokenInfo.symbol}`); -console.log(`Decimals: ${tokenInfo.decimals}`); -console.log(`Permit Enabled: ${tokenInfo.permitEnabled}`); -``` - -[Learn more about getPaymentToken](./more/getPaymentToken.md) - -### getSupertransactionReceipt - -Retrieves the receipt for a supertransaction with details about its execution across multiple chains. - -```typescript -const receipt = await meeClient.getSupertransactionReceipt({ - hash -}); - -console.log("Transaction status:", receipt.transactionStatus); -console.log("Explorer links:", receipt.explorerLinks); -``` - -[Learn more about getSupertransactionReceipt](./more/getSupertransactionReceipt.md) - -### waitForSupertransactionReceipt - -Waits for a supertransaction to complete and returns the receipt when all operations have reached a final state. - -```typescript -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash -}); - -if (receipt.transactionStatus === "MINED_SUCCESS") { - console.log("Transaction completed successfully!"); - // Process transaction results -} else { - console.error("Transaction failed:", receipt.transactionStatus); -} -``` - -[Learn more about waitForSupertransactionReceipt](./waitForSupertransactionReceipt.md) - -## Configuration - -When creating a MEE Client, you can configure these parameters: - -| Parameter | Type | Description | -|-----------|------|-------------| -| `url` | `Url` | (Optional) URL for the MEE node service. Defaults to "https://network.biconomy.io/v1" | -| `pollingInterval` | `number` | (Optional) Polling interval in milliseconds. Defaults to 1000 | -| `account` | `MultichainSmartAccount` | The multichain smart account to use for transactions | -| `apiKey` | `string` | (Optional) API key for production use with higher rate limits | - -## Complete Example - -Here's a complete example demonstrating how to use multiple methods together: - -```typescript -import { createMeeClient, mcUSDC } from '@biconomy/abstractjs'; -import { parseUnits } from 'viem'; - -// Create the MEE client -const meeClient = await createMeeClient({ - account: multiChainAccount, - apiKey: "mee_your_api_key_here" // Optional for production use -}); - -// 1. Get a quote for cross-chain operations -const quote = await meeClient.getQuote({ - instructions: [ - // Transfer USDC on Optimism - { - calls: [{ - to: "0xUSDCAddress", - data: encodeTransferFunction("0xRecipient", parseUnits("10", 6)) - }], - chainId: optimism.id - }, - // Deploy a contract on Base - { - calls: [{ - data: contractDeploymentBytecode - }], - chainId: base.id - } - ], - feeToken: { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id - } -}); - -// 2. Execute the quote -const { hash } = await meeClient.executeQuote({ quote }); -console.log(`Transaction submitted with hash: ${hash}`); - -// 3. Wait for transaction receipt -const receipt = await meeClient.getSupertransactionReceipt({ hash }); -console.log("Transaction completed with status:", receipt.transactionStatus); - -// Check individual user operations -receipt.userOps.forEach((userOp, i) => { - console.log(`Operation ${i} on chain ${userOp.chainId}: ${userOp.executionStatus}`); -}); - -// Alternative: Use waitForSupertransactionReceipt to automatically wait for completion -// const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -// console.log("All operations completed with status:", receipt.transactionStatus); -``` - -## Type Definitions - -### MeeClient -```typescript -type MeeClient = BaseMeeClient & { - getQuote: (params: GetQuoteParams) => Promise - executeQuote: (params: SignQuoteParams) => Promise - getFusionQuote: (params: GetFusionQuoteParams) => Promise - executeFusionQuote: (params: ExecuteFusionQuoteParams) => Promise - getPaymentToken: (params: GetPaymentTokenParams) => Promise - getSupertransactionReceipt: (params: GetSupertransactionReceiptParams) => Promise - waitForSupertransactionReceipt: (params: { hash: Hex }) => Promise -} -``` \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/more/execute.md b/docs/pages/sdk-reference/mee-client/methods/more/execute.md deleted file mode 100644 index c8a7ffe..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/execute.md +++ /dev/null @@ -1,246 +0,0 @@ -# execute - -The `execute` method is a convenience function that combines three steps into a single operation: - -1. Fetches a quote using `getQuote` -2. Signs the quote using `signQuote` -3. Executes the signed quote using `executeSignedQuote` - -This streamlined approach simplifies the process of executing transactions through the MEE. - -> **Important Limitation**: When using the `execute` method, there is no intermediate step to display gas values to users for confirmation. If your application requires showing gas costs to users before proceeding with the transaction, you should use the individual methods (`getQuote`, `signQuote`, and `executeSignedQuote`) instead. - -## Usage - -```typescript -const { hash } = await meeClient.execute({ - instructions: instructions, - feeToken: { - address: mcUSDC.addressOn(chainId), - chainId - } -}); -``` - -## Parameters - -### `instructions` - -An array of instruction objects that describe the transactions to be executed. - -```typescript -type Instruction = { - calls: { - to: Address; // Recipient address - gasLimit?: bigint; // Optional gas limit - value: bigint; // Amount of native tokens to send (in wei) - data?: Hex; // Call data for the transaction - }[]; - chainId: number; // Target chain ID -}; -``` - -### `feeToken` - -Information about the token used to pay for transaction fees. - -```typescript -type FeeTokenInfo = { - address: Address; // Token contract address - chainId: number; // Chain ID where the fee token resides -}; -``` - -## Return Value - -Returns a Promise that resolves to an execution payload containing transaction details. - -```typescript -interface ExecuteSignedQuotePayload { - hash: Hex; // Transaction hash - // Additional transaction details may be included -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, zeroAddress } from "viem"; -import { optimism, base } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Define fee token on payment chain (optimism in this case) -const feeToken = { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id -}; - -// Execute a simple transaction on the target chain -const { hash } = await meeClient.execute({ - instructions: [ - { - calls: [ - { - to: zeroAddress, - value: 0n, - gasLimit: 50000n - } - ], - chainId: base.id - } - ], - feeToken -}); - -// Wait for transaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -console.log("Transaction completed:", receipt); -``` - -### Complex Example with Multiple Instructions - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { parseUnits } from "viem"; -import { optimism, base } from "viem/chains"; - -// Setup account and client -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - signer: eoaAccount, - transports -}); - -const meeClient = await createMeeClient({ account: mcNexus }); - -// Define payment token -const feeToken = { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id -}; - -// Prepare multiple instructions using build -const transferAmount = parseUnits("10", 6); // 10 USDC with 6 decimals -const recipientAddress = "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"; - -// First instruction: Intent to move tokens to target chain -const bridgeInstruction = await mcNexus.build({ - type: "intent", - data: { - amount: transferAmount, - mcToken: mcUSDC, - toChain: base - } -}); - -// Second instruction: Transfer tokens to recipient on target chain -const transferInstruction = await mcNexus.build({ - type: "transfer", - data: { - chainId: base.id, - tokenAddress: mcUSDC.addressOn(base.id), - amount: transferAmount, - recipient: recipientAddress - } -}); - -// Combine instructions and execute -const { hash } = await meeClient.execute({ - instructions: [bridgeInstruction, transferInstruction], - feeToken -}); - -// Wait for transaction completion -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -console.log("Cross-chain transfer completed:", receipt); -``` - -## Error Handling - -The `execute` method can throw errors at any of the three stages: - -1. During quote generation (`getQuote`) -2. During quote signing (`signQuote`) -3. During execution (`executeSignedQuote`) - -Here's how to handle potential errors: - -```typescript -try { - const { hash } = await meeClient.execute({ - instructions, - feeToken - }); - - console.log("Transaction submitted:", hash); - - const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - console.log("Transaction completed:", receipt); -} catch (error) { - if (error.message.includes("insufficient funds")) { - console.error("Not enough tokens to pay for transaction fees"); - } else if (error.message.includes("signature")) { - console.error("Failed to sign the transaction"); - } else if (error.message.includes("execution reverted")) { - console.error("Transaction execution failed"); - } else { - console.error("Error executing transaction:", error); - } -} -``` - -## Comparison with Manual Approach - -The `execute` method combines three separate API calls into one for convenience. If you need more control over the process, you can use the individual methods instead: - -```typescript -// Manual approach with separate steps -const quote = await meeClient.getQuote({ - instructions, - feeToken -}); - -// At this point, you can display gas costs to the user -console.log("Gas fee in tokens:", quote.paymentInfo.amount); -console.log("Token symbol:", quote.paymentInfo.tokenSymbol); - -// Proceed with signing and execution only after user confirmation -const signedQuote = await meeClient.signQuote({ quote }); -const { hash } = await meeClient.executeSignedQuote({ signedQuote }); -``` - -This is equivalent to: - -```typescript -// Streamlined approach with execute -const { hash } = await meeClient.execute({ - instructions, - feeToken -}); -``` - -### When to Use Each Approach - -- Use `execute` when: - - You don't need to display gas costs to users before proceeding - - You're building automated processes without user interaction - - Simplicity is more important than granular control - -- Use the manual approach (`getQuote` → `signQuote` → `executeSignedQuote`) when: - - You need to show users the gas costs before they confirm - - You want to implement custom logic between steps - - Your app requires more complex error handling at each stage - -The `execute` method is recommended for most use cases where you don't need special handling between the quote, signing, and execution steps. diff --git a/docs/pages/sdk-reference/mee-client/methods/more/executeSignedQuote.md b/docs/pages/sdk-reference/mee-client/methods/more/executeSignedQuote.md deleted file mode 100644 index 2bfbf0d..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/executeSignedQuote.md +++ /dev/null @@ -1,220 +0,0 @@ -# executeSignedQuote - -The `executeSignedQuote` method represents the final step in the quote flow, where a previously signed quote is submitted to the blockchain through the MEE service. This method is part of the three-step process for executing transactions: - -1. Get a quote using `getQuote` -2. Sign the quote using `signQuote` -3. Execute the signed quote using `executeSignedQuote` - -This method is essential when you need more control over the transaction flow, particularly when you want to display gas fees to users for confirmation before executing the transaction. - -## Usage - -```typescript -const { hash } = await meeClient.executeSignedQuote({ - signedQuote -}); -``` - -## Parameters - -### `signedQuote` - -The signed quote payload obtained from `signQuote`. - -```typescript -type ExecuteSignedQuoteParams = { - signedQuote: SignQuotePayload; -} -``` - -## Return Value - -Returns a Promise that resolves to an object containing the transaction hash. - -```typescript -type ExecuteSignedQuotePayload = { - hash: Hex; // The transaction hash of the executed supertransaction -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, zeroAddress } from "viem"; -import { optimism, base } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Define fee token on payment chain -const feeToken = { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id -}; - -// Step 1: Get a quote -const quote = await meeClient.getQuote({ - instructions: [ - { - calls: [ - { - to: zeroAddress, - value: 0n, - gasLimit: 50000n - } - ], - chainId: base.id - } - ], - feeToken -}); - -// Display gas cost to user for confirmation -console.log("Gas fee in tokens:", quote.paymentInfo.amount); -console.log("Token symbol:", quote.paymentInfo.tokenSymbol); - -// Step 2: Sign the quote after user confirms -const signedQuote = await meeClient.signQuote({ quote }); - -// Step 3: Execute the signed quote -const { hash } = await meeClient.executeSignedQuote({ - signedQuote -}); - -// Wait for transaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -console.log("Transaction completed:", receipt); -``` - -### Full Flow with User Confirmation - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { parseUnits } from "viem"; -import { optimism, base } from "viem/chains"; - -// Setup account and client -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - signer: eoaAccount, - transports: [http(), http()] -}); - -const meeClient = await createMeeClient({ account: mcNexus }); - -// Define instructions for a token transfer -const transferAmount = parseUnits("10", 6); // 10 USDC with 6 decimals -const recipientAddress = "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"; - -// Define payment token -const feeToken = { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id -}; - -// Step 1: Get quote for a cross-chain token transfer -const quote = await meeClient.getQuote({ - instructions: [ - mcNexus.build({ - type: "intent", - data: { - amount: transferAmount, - mcToken: mcUSDC, - toChain: base - } - }), - mcNexus.build({ - type: "transfer", - data: { - chainId: base.id, - tokenAddress: mcUSDC.addressOn(base.id), - amount: transferAmount, - recipient: recipientAddress - } - }) - ], - feeToken -}); - -// Calculate USD equivalent for better UX (example) -const tokenDecimals = 6; // USDC has 6 decimals -const amountInToken = Number(quote.paymentInfo.amount) / 10**tokenDecimals; -console.log(`This transaction will cost approximately ${amountInToken} ${quote.paymentInfo.tokenSymbol}`); - -// Simulate user confirmation (in a real app, this would be a UI prompt) -const userConfirmed = await userConfirmationPrompt(amountInToken, quote.paymentInfo.tokenSymbol); - -if (userConfirmed) { - // Step 2: Sign the quote - const signedQuote = await meeClient.signQuote({ quote }); - - // Step 3: Execute the signed quote - const { hash } = await meeClient.executeSignedQuote({ - signedQuote - }); - - console.log("Transaction submitted with hash:", hash); - - // Wait for transaction completion - const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - console.log("Cross-chain transfer completed:", receipt); -} else { - console.log("Transaction cancelled by user"); -} - -// Helper function for user confirmation (in a real app, this would be a UI component) -async function userConfirmationPrompt(amount, symbol) { - // In a real application, this would be a UI prompt - // Here we're just simulating a confirmation - return true; // User confirmed -} -``` - -## Error Handling - -The `executeSignedQuote` method can throw errors in several situations: - -```typescript -try { - const { hash } = await meeClient.executeSignedQuote({ - signedQuote - }); - - console.log("Transaction submitted:", hash); -} catch (error) { - if (error.message.includes("insufficient funds")) { - console.error("Not enough tokens to pay for transaction fees"); - } else if (error.message.includes("signature")) { - console.error("Invalid signature in the signed quote"); - } else if (error.message.includes("execution reverted")) { - console.error("Transaction execution failed"); - } else { - console.error("Error executing signed quote:", error); - } -} -``` - -## Related Methods - -- [`getQuote`](/sdk-reference/mee-client/methods/getQuote) - Get a quote for executing instructions -- [`signQuote`](/sdk-reference/mee-client/methods/more/signQuote) - Sign a quote before execution -- [`execute`](/sdk-reference/mee-client/methods/more/execute) - Convenience method that combines all three steps -- [`waitForSupertransactionReceipt`](/sdk-reference/mee-client/methods/waitForSupertransactionReceipt) - Wait for a transaction receipt - -## When to Use - -Use `executeSignedQuote` as part of the three-step process (getQuote → signQuote → executeSignedQuote) when: -- You need to display gas costs to users before execution -- You want more control over error handling at each stage -- You need to implement custom logic between steps diff --git a/docs/pages/sdk-reference/mee-client/methods/more/getGasToken.md b/docs/pages/sdk-reference/mee-client/methods/more/getGasToken.md deleted file mode 100644 index a2fa675..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/getGasToken.md +++ /dev/null @@ -1,191 +0,0 @@ -# getGasToken - -The `getGasToken` method retrieves information about supported gas tokens for a specific blockchain. This method is useful for validating if a particular token address is supported for gas payments on the specified chain and to obtain detailed information about all available payment tokens. - -## Usage - -```typescript -const gasTokenInfo = await meeClient.getGasToken({ - chainId: 1, // Ethereum Mainnet - address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC -}); -``` - -## Parameters - -### `parameters` - -An object containing the query parameters for the gas token. - -```typescript -type GetGasTokenParams = { - /** - * The blockchain chain ID to query - * @example 1 // Ethereum Mainnet - * @example 137 // Polygon - */ - chainId: number; - - /** - * The address of the payment token to validate - * @example "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC on Ethereum - */ - address: Address; -} -``` - -## Return Value - -Returns a Promise that resolves to a `GetGasTokenPayload` object containing information about the available gas tokens on the specified chain. - -```typescript -type GetGasTokenPayload = { - /** - * Chain identifier as a string - * @example "1" // Ethereum Mainnet - */ - chainId: string; - - /** - * List of payment tokens that can be used for gas fees on this chain - */ - paymentTokens: PaymentToken[]; -} - -type PaymentToken = { - name: string; // Token name (e.g., "USD Coin") - address: Address; // Token contract address - symbol: string; // Token symbol (e.g., "USDC") - decimals: number; // Token decimal places - permitEnabled: boolean; // Whether the token supports EIP-2612 permits -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { optimism, base } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Get gas token information for Ethereum Mainnet -try { - const result = await meeClient.getGasToken({ - chainId: 1, - address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC on Ethereum - }); - - console.log(`Available payment tokens on chain ${result.chainId}:`); - result.paymentTokens.forEach(token => { - console.log(`- ${token.symbol} (${token.name}): ${token.address}`); - console.log(` Decimals: ${token.decimals}, Permit enabled: ${token.permitEnabled}`); - }); -} catch (error) { - console.error("Error fetching gas token information:", error); -} -``` - -### Checking Multiple Chains - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism, polygon, arbitrum } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism, polygon, arbitrum], - signer: eoaAccount, - transports: [http(), http(), http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Check supported tokens across multiple chains -async function checkSupportedTokens() { - const chainIds = [mainnet.id, optimism.id, polygon.id, arbitrum.id]; - - for (const chainId of chainIds) { - try { - // Use USDC address for each chain - const tokenAddress = mcUSDC.addressOn(chainId); - - const gasTokenInfo = await meeClient.getGasToken({ - chainId, - address: tokenAddress - }); - - console.log(`Chain ${chainId} supports ${gasTokenInfo.paymentTokens.length} payment tokens`); - - // Check if native token is supported - const nativeToken = gasTokenInfo.paymentTokens.find(token => - token.symbol === "ETH" || token.symbol === "MATIC"); - - if (nativeToken) { - console.log(`Native token ${nativeToken.symbol} is supported on chain ${chainId}`); - } - - // Check if USDC is supported - const usdcToken = gasTokenInfo.paymentTokens.find(token => - token.symbol === "USDC"); - - if (usdcToken) { - console.log(`USDC is supported on chain ${chainId} at address ${usdcToken.address}`); - } - } catch (error) { - console.error(`Error checking chain ${chainId}:`, error.message); - } - } -} - -await checkSupportedTokens(); -``` - -## Error Handling - -The `getGasToken` method will throw an error if the specified chain ID is not supported: - -```typescript -try { - const gasTokenInfo = await meeClient.getGasToken({ - chainId: 1, - address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" - }); - - // Process gas token information - console.log(`Found ${gasTokenInfo.paymentTokens.length} payment tokens on chain ${gasTokenInfo.chainId}`); -} catch (error) { - if (error.message.includes("Gas token not found for chain")) { - console.error("The specified chain ID is not supported by the MEE service"); - } else { - console.error("Error retrieving gas token information:", error); - } -} -``` - -## Related Methods - -- [`getQuote`](/sdk-reference/mee-client/methods/getQuote) - Get a quote for executing instructions with gas fees -- [`getFusionQuote`](/sdk-reference/mee-client/methods/getFusionQuote) - Get a fusion quote for triggered transactions -- [`mcUSDC`](/sdk-reference/mee-client/helpers/more/mcUSDC) - Helper for working with USDC across chains - -## When to Use - -Use `getGasToken` when: -- You need to verify if a specific token is supported for gas payments on a chain -- You want to display a list of supported payment tokens to users -- You need to get token metadata like decimals and symbols for UI display -- You're building a fee estimation feature and need to know which tokens are available \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/more/getInfo.md b/docs/pages/sdk-reference/mee-client/methods/more/getInfo.md deleted file mode 100644 index c0dd2ab..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/getInfo.md +++ /dev/null @@ -1,301 +0,0 @@ -# getInfo - -The `getInfo` method retrieves information about the Modular Execution Environment (MEE) service configuration, including supported blockchain chains, gas tokens, and wallet providers. This method is essential for understanding what capabilities are available for your application when interacting with the MEE service. - -## Usage - -```typescript -const info = await meeClient.getInfo(); -``` - -## Parameters - -This method does not require any parameters. - -## Return Value - -Returns a Promise that resolves to a `GetInfoPayload` object containing comprehensive information about the MEE service configuration. - -```typescript -type GetInfoPayload = { - /** - * Version of the MEE API - * @example "1.0.0" - */ - version: string; - - /** - * Node information string - * @example "mee-node-1" - */ - node: string; - - /** - * List of supported blockchain chains - */ - supported_chains: SupportedChain[]; - - /** - * List of supported gas tokens per chain - */ - supported_gas_tokens: GetGasTokenPayload[]; - - /** - * List of supported wallet providers and their capabilities - */ - supported_wallet_providers: SupportedWalletProvider[]; -} - -/** - * Represents a supported blockchain chain - */ -interface SupportedChain { - /** - * Chain identifier - * @example "1" // Ethereum Mainnet - * @example "137" // Polygon - */ - chainId: string; - - /** - * Human-readable chain name - * @example "Ethereum Mainnet" - * @example "Polygon" - */ - name: string; -} - -/** - * Represents a supported wallet provider configuration - */ -interface SupportedWalletProvider { - /** - * Wallet provider identifier - * @example "SAFE_V141" - * @example "BICO_V2" - */ - walletProvider: string; - - /** - * List of chain IDs supported by this wallet provider - * @example ["1", "137"] // Provider supports Ethereum and Polygon - */ - supportedChains: string[]; - - /** - * Whether EOA (Externally Owned Account) is enabled for this provider - */ - eoaEnabled?: boolean; - - /** - * Whether EOA fusion is supported by this provider - */ - eoaFusion?: boolean; -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { optimism, polygon } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, polygon], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -try { - const info = await meeClient.getInfo(); - - console.log(`MEE API Version: ${info.version}`); - console.log(`Node: ${info.node}`); - - // Log supported chains - console.log("Supported chains:"); - info.supported_chains.forEach(chain => { - console.log(`- ${chain.name} (Chain ID: ${chain.chainId})`); - }); - - // Check if specific chains are supported - const supportedChainIds = info.supported_chains.map(chain => Number(chain.chainId)); - console.log(`Optimism (${optimism.id}) supported: ${supportedChainIds.includes(optimism.id)}`); - console.log(`Polygon (${polygon.id}) supported: ${supportedChainIds.includes(polygon.id)}`); - - // Log wallet providers - console.log("Supported wallet providers:"); - info.supported_wallet_providers.forEach(provider => { - console.log(`- ${provider.walletProvider}`); - console.log(` Supported chains: ${provider.supportedChains.join(", ")}`); - console.log(` EOA enabled: ${provider.eoaEnabled || false}`); - console.log(` EOA fusion: ${provider.eoaFusion || false}`); - }); - - // Check if USDC is available as a payment token - const usdcAvailable = info.supported_gas_tokens.some(gasToken => - gasToken.paymentTokens.some(token => token.symbol === "USDC") - ); - console.log(`USDC available as payment token: ${usdcAvailable}`); - -} catch (error) { - console.error("Error fetching MEE service information:", error); -} -``` - -### Finding Available Payment Tokens - -```typescript -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Get available payment tokens across supported chains -async function getAvailablePaymentTokens() { - const info = await meeClient.getInfo(); - - // Create a mapping of chain ID to available payment tokens - const paymentTokensByChain = {}; - - info.supported_gas_tokens.forEach(gasToken => { - const chainId = gasToken.chainId; - const chainName = info.supported_chains.find(chain => chain.chainId === chainId)?.name || chainId; - - paymentTokensByChain[chainId] = { - chainName, - tokens: gasToken.paymentTokens.map(token => ({ - symbol: token.symbol, - name: token.name, - address: token.address, - decimals: token.decimals, - permitEnabled: token.permitEnabled - })) - }; - }); - - // Display tokens for each chain - Object.entries(paymentTokensByChain).forEach(([chainId, data]) => { - console.log(`\n${data.chainName} (Chain ID: ${chainId})`); - console.log("Available payment tokens:"); - - data.tokens.forEach(token => { - console.log(`- ${token.symbol} (${token.name})`); - console.log(` Address: ${token.address}`); - console.log(` Decimals: ${token.decimals}`); - console.log(` Permit enabled: ${token.permitEnabled}`); - }); - }); - - return paymentTokensByChain; -} - -await getAvailablePaymentTokens(); -``` - -### Checking Wallet Provider Compatibility - -```typescript -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, arbitrum } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, arbitrum], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Check compatibility of wallet providers with specific chains -async function checkWalletProviderCompatibility(targetChains = [mainnet.id, arbitrum.id]) { - const info = await meeClient.getInfo(); - - // Convert chain IDs to strings for comparison - const targetChainIds = targetChains.map(id => id.toString()); - - console.log("Wallet provider compatibility:"); - - info.supported_wallet_providers.forEach(provider => { - const supportedTargetChains = targetChainIds.filter(chainId => - provider.supportedChains.includes(chainId) - ); - - const isFullyCompatible = supportedTargetChains.length === targetChainIds.length; - - console.log(`\n${provider.walletProvider}:`); - console.log(`- Fully compatible with all target chains: ${isFullyCompatible}`); - - if (!isFullyCompatible) { - const missingChains = targetChainIds - .filter(chainId => !provider.supportedChains.includes(chainId)) - .map(chainId => { - const chain = info.supported_chains.find(c => c.chainId === chainId); - return chain ? chain.name : `Chain ID ${chainId}`; - }); - - console.log(`- Unsupported chains: ${missingChains.join(", ")}`); - } - - console.log(`- EOA enabled: ${provider.eoaEnabled || false}`); - console.log(`- EOA fusion supported: ${provider.eoaFusion || false}`); - }); -} - -await checkWalletProviderCompatibility(); -``` - -## Error Handling - -The `getInfo` method may throw errors if there are connectivity issues or if the MEE service is unavailable: - -```typescript -try { - const info = await meeClient.getInfo(); - // Process the information -} catch (error) { - console.error("Failed to fetch MEE service information:", error); - - // Implement appropriate fallback behavior - if (error.message.includes("Network error")) { - console.log("Please check your internet connection and try again."); - } else if (error.status === 401) { - console.log("Authentication error. Please check your API credentials."); - } else { - console.log("An unexpected error occurred. Please try again later."); - } -} -``` - -## Related Methods - -- [`getGasToken`](/sdk-reference/mee-client/methods/more/getGasToken) - Get detailed information about gas tokens for a specific chain -- [`getQuote`](/sdk-reference/mee-client/methods/getQuote) - Get a quote for executing instructions with gas fees -- [`executeQuote`](/sdk-reference/mee-client/methods/executeQuote) - Execute a quote obtained from the MEE service - -## When to Use - -Use `getInfo` when: -- Initializing your application to determine which chains and tokens are supported -- Validating that your intended account type and chains are compatible with the MEE service -- Building UI components that need to display available options to users -- Before attempting transactions, to ensure the required functionality is available \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/more/getOnChainQuote.md b/docs/pages/sdk-reference/mee-client/methods/more/getOnChainQuote.md deleted file mode 100644 index 4fb0307..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/getOnChainQuote.md +++ /dev/null @@ -1,350 +0,0 @@ -# getOnChainQuote - -The `getOnChainQuote` method retrieves a quote for an on-chain transaction from the Modular Execution Environment (MEE) service. This method is specifically used when the payment token doesn't support ERC20Permit or when a standard on-chain transaction is preferred. - -## Usage - -```typescript -const onChainQuote = await meeClient.getOnChainQuote({ - instructions: [ - // Instructions to execute - ], - feeToken: { - address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC - chainId: 1 // Ethereum - }, - trigger: { - chainId: 1, // Ethereum - tokenAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC - amount: 1000000n // 1 USDC (6 decimals) - } -}); -``` - -## Parameters - -### `parameters` - -An object containing the parameters for requesting an on-chain quote. - -```typescript -type GetOnChainQuoteParams = { - /** - * Array of transaction instructions to execute - */ - instructions: Instruction[]; - - /** - * Fee token information including address and chain ID - */ - feeToken: FeeTokenInfo; - - /** - * Trigger information for the transaction - */ - trigger: Trigger; - - /** - * Optional account to use (defaults to client.account) - */ - account?: MultichainSmartAccount; -} - -/** - * Fee token information - */ -type FeeTokenInfo = { - /** - * The address of the token to pay fees with - */ - address: Address; - - /** - * The chain ID where the fee token exists - */ - chainId: number; -} - -/** - * Trigger information - */ -type Trigger = { - /** - * Chain ID where the token exists - */ - chainId: number; - - /** - * Address of the token to use for payment - */ - tokenAddress: Address; - - /** - * Amount of tokens to use - */ - amount: bigint | string; -} -``` - -## Return Value - -Returns a Promise that resolves to a `GetOnChainQuotePayload` object containing both the standard quote payload and trigger information. - -```typescript -type GetOnChainQuotePayload = { - /** - * Standard quote payload with transaction details - */ - quote: GetQuotePayload; - - /** - * Trigger information with updated amount including fees - */ - trigger: Trigger; -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Token information -const tokenAddress = mcUSDC.addressOn(mainnet.id); - -// Create trigger information -const trigger = { - chainId: mainnet.id, - tokenAddress: tokenAddress, - amount: 1000000n // 1 USDC (6 decimals) -}; - -// Fee token information -const feeToken = { - address: tokenAddress, - chainId: mainnet.id -}; - -try { - // Get on-chain quote for a simple transaction - const onChainQuote = await meeClient.getOnChainQuote({ - instructions: [ - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } - }) - ], - feeToken, - trigger - }); - - console.log("On-chain quote received:"); - console.log(`Quote ID: ${onChainQuote.quote.id}`); - console.log(`Payment Token: ${onChainQuote.quote.paymentInfo.token}`); - console.log(`Payment Chain: ${onChainQuote.quote.paymentInfo.chainId}`); - console.log(`Total Amount (including fees): ${onChainQuote.trigger.amount}`); - - // The quote can now be signed and executed - -} catch (error) { - console.error("Error getting on-chain quote:", error); -} -``` - -### Transfer Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, parseUnits } from "viem"; -import { mainnet, base } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, base], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Create recipient account -const recipientAddress = "0x1234567890123456789012345678901234567890"; - -// Set up the trigger for the on-chain payment -const trigger = { - chainId: mainnet.id, - tokenAddress: mcUSDC.addressOn(mainnet.id), - amount: parseUnits("5", 6) // 5 USDC -}; - -// Fee token information (same as the trigger token in this example) -const feeToken = { - address: mcUSDC.addressOn(mainnet.id), - chainId: mainnet.id -}; - -// Get on-chain quote for transferring USDC on Base -const onChainQuote = await meeClient.getOnChainQuote({ - trigger, - instructions: [ - mcNexus.build({ - type: "transfer", - data: { - chainId: base.id, - tokenAddress: mcUSDC.addressOn(base.id), - amount: parseUnits("5", 6), // 5 USDC - recipient: recipientAddress - } - }) - ], - feeToken -}); - -console.log(`Quote obtained with ID: ${onChainQuote.quote.id}`); -console.log(`Total payment amount (including fees): ${onChainQuote.trigger.amount}`); - -// The quote can now be signed and executed using signOnChainQuote and executeSignedQuote -``` - -### Multiple Instructions Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Token address -const tokenAddress = mcUSDC.addressOn(mainnet.id); - -// Create trigger -const trigger = { - chainId: mainnet.id, - tokenAddress: tokenAddress, - amount: 1000000n // 1 USDC -}; - -// Fee token -const feeToken = { - address: tokenAddress, - chainId: mainnet.id -}; - -// Create multiple instructions -const instructions = [ - // First instruction on Optimism - { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - }, - // Second instruction on Optimism - { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } -]; - -// Get on-chain quote for multiple instructions -try { - const fusionQuote = await meeClient.getOnChainQuote({ - instructions, - feeToken, - trigger - }); - - console.log("On-chain quote received for multiple instructions"); - console.log(`Number of user operations: ${fusionQuote.quote.userOps.length}`); - console.log(`Quote ID: ${fusionQuote.quote.id}`); - - // The fusionQuote can now be signed and executed - -} catch (error) { - console.error("Error getting on-chain quote:", error); -} -``` - -## Error Handling - -The `getOnChainQuote` method may throw errors if there are issues with the specified parameters or if the MEE service is unavailable: - -```typescript -try { - const onChainQuote = await meeClient.getOnChainQuote({ - instructions: [/* your instructions */], - feeToken, - trigger - }); - - // Process the on-chain quote - -} catch (error) { - console.error("Failed to get on-chain quote:", error); - - if (error.message.includes("not supported")) { - console.log("The specified token or chain is not supported."); - } else if (error.message.includes("insufficient balance")) { - console.log("Insufficient balance to cover the transaction."); - } else { - console.log("An unexpected error occurred. Please try again later."); - } -} -``` - -## Related Methods - -- [`signOnChainQuote`](/sdk-reference/mee-client/methods/more/signOnChainQuote) - Sign an on-chain quote for execution -- [`executeSignedQuote`](/sdk-reference/mee-client/methods/more/executeSignedQuote) - Execute a signed on-chain quote -- [`getQuote`](/sdk-reference/mee-client/methods/getQuote) - Get a standard quote for executing instructions - -## When to Use - -Use `getOnChainQuote` when: -- The payment token doesn't support ERC20Permit -- You prefer a standard on-chain transaction flow -- You need to trigger transactions based on token transfers -- You want to execute multi-chain operations using on-chain triggers \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/more/getPaymentToken.md b/docs/pages/sdk-reference/mee-client/methods/more/getPaymentToken.md deleted file mode 100644 index 844f601..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/getPaymentToken.md +++ /dev/null @@ -1,307 +0,0 @@ -# getPaymentToken - -The `getPaymentToken` method retrieves detailed information about a specific payment token on a given blockchain. This method is useful for validating if a token is supported for gas payments and for obtaining token configuration details such as decimals, symbol, and permit capabilities. - -## Usage - -```typescript -const tokenInfo = await meeClient.getPaymentToken({ - chainId: 1, // Ethereum Mainnet - tokenAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC -}); -``` - -## Parameters - -### `parameters` - -An object containing the query parameters for the payment token. - -```typescript -type GetPaymentTokenParams = { - /** - * The blockchain chain ID to query - * @example 1 // Ethereum Mainnet - * @example 137 // Polygon - */ - chainId: number; - - /** - * The address of the token to retrieve information for - * @example "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC - */ - tokenAddress: Address; -} -``` - -## Return Value - -Returns a Promise that resolves to a `PaymentToken` object containing detailed information about the token. - -```typescript -interface PaymentToken { - /** - * Human-readable name of the token - * @example "USD Coin" - */ - name: string; - - /** - * Contract address of the token on the blockchain - * @example "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC on Ethereum - */ - address: Address; - - /** - * Token symbol - * @example "USDC" - */ - symbol: string; - - /** - * Number of decimal places the token uses - * @example 6 // USDC uses 6 decimals - * @example 18 // Most ERC20 tokens use 18 decimals - */ - decimals: number; - - /** - * Indicates whether the token supports ERC20Permit functionality - * When true, gasless approvals are possible - */ - permitEnabled: boolean; -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Get information about USDC on Ethereum Mainnet -try { - const usdcInfo = await meeClient.getPaymentToken({ - chainId: 1, - tokenAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC on Ethereum - }); - - console.log("Token Information:"); - console.log(`Name: ${usdcInfo.name}`); - console.log(`Symbol: ${usdcInfo.symbol}`); - console.log(`Decimals: ${usdcInfo.decimals}`); - console.log(`Permit Enabled: ${usdcInfo.permitEnabled}`); - console.log(`Address: ${usdcInfo.address}`); - -} catch (error) { - console.error("Error fetching token information:", error); -} -``` - -### Checking Token Compatibility for Permit Transactions - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism, polygon } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism, polygon], - signer: eoaAccount, - transports: [http(), http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Function to check if a token supports permits on a specific chain -async function checkTokenPermitSupport(chainId, tokenAddress) { - try { - const tokenInfo = await meeClient.getPaymentToken({ - chainId, - tokenAddress - }); - - if (tokenInfo.permitEnabled) { - console.log(`${tokenInfo.symbol} on chain ${chainId} supports permits. Use signPermitQuote.`); - return true; - } else { - console.log(`${tokenInfo.symbol} on chain ${chainId} does NOT support permits. Use signOnChainQuote.`); - return false; - } - } catch (error) { - console.error(`Error checking token ${tokenAddress} on chain ${chainId}:`, error.message); - return false; - } -} - -// Check USDC on different chains -async function checkUsdcAcrossChains() { - const chains = [mainnet.id, optimism.id, polygon.id]; - - for (const chainId of chains) { - const tokenAddress = mcUSDC.addressOn(chainId); - await checkTokenPermitSupport(chainId, tokenAddress); - } -} - -// Run the check -await checkUsdcAcrossChains(); -``` - -### Getting Token Information for a Quote - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, parseUnits } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -async function prepareQuoteWithTokenInfo(chainId, tokenAddress, amount) { - try { - // Get token information - const tokenInfo = await meeClient.getPaymentToken({ - chainId, - tokenAddress - }); - - console.log(`Using ${tokenInfo.symbol} as payment token`); - - // Parse the amount using correct decimals - const parsedAmount = parseUnits(amount.toString(), tokenInfo.decimals); - - // Set up fee token - const feeToken = { - address: tokenAddress, - chainId - }; - - // Set up trigger - const trigger = { - chainId, - tokenAddress, - amount: parsedAmount - }; - - // Determine which quote method to use based on permit support - if (tokenInfo.permitEnabled) { - console.log(`Getting permit quote with ${tokenInfo.symbol}`); - return await meeClient.getPermitQuote({ - trigger, - instructions: [ - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } - }) - ], - feeToken - }); - } else { - console.log(`Getting on-chain quote with ${tokenInfo.symbol}`); - return await meeClient.getOnChainQuote({ - trigger, - instructions: [ - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } - }) - ], - feeToken - }); - } - } catch (error) { - console.error("Error preparing quote:", error); - throw error; - } -} - -// Use the function with USDC on Ethereum -const quote = await prepareQuoteWithTokenInfo( - mainnet.id, - mcUSDC.addressOn(mainnet.id), - 1 // 1 USDC -); - -console.log("Quote received:", quote.quote.id); -``` - -## Error Handling - -The `getPaymentToken` method will throw an error if the specified token or chain is not supported: - -```typescript -try { - const tokenInfo = await meeClient.getPaymentToken({ - chainId: 1, - tokenAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" - }); - - // Process token information - console.log(`Token ${tokenInfo.symbol} has ${tokenInfo.decimals} decimals`); - -} catch (error) { - if (error.message.includes("Gas token not found for chain")) { - console.error("The specified chain ID is not supported by the MEE service"); - } else if (error.message.includes("Payment token not found")) { - console.error("The specified token is not supported on this chain"); - } else { - console.error("Error retrieving payment token information:", error); - } -} -``` - -## Related Methods - -- [`getGasToken`](/sdk-reference/mee-client/methods/more/getGasToken) - Get information about all supported gas tokens on a chain -- [`getInfo`](/sdk-reference/mee-client/methods/more/getInfo) - Get comprehensive information about supported chains and tokens -- [`getPermitQuote`](/sdk-reference/mee-client/methods/more/getPermitQuote) - Get a quote for permit-enabled tokens -- [`getOnChainQuote`](/sdk-reference/mee-client/methods/more/getOnChainQuote) - Get a quote for tokens without permit support - -## When to Use - -Use `getPaymentToken` when: -- You need detailed information about a specific token's configuration -- You want to check if a token supports ERC20Permit before choosing which quote method to use -- You need token decimals to properly format amounts for transactions -- You're validating that a specific token is supported for gas payments on a chain \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/more/getPermitQuote.md b/docs/pages/sdk-reference/mee-client/methods/more/getPermitQuote.md deleted file mode 100644 index 03a7fdc..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/getPermitQuote.md +++ /dev/null @@ -1,375 +0,0 @@ -# getPermitQuote - -The `getPermitQuote` method retrieves a quote for a permit-enabled transaction from the Modular Execution Environment (MEE) service. This method is specifically used when the payment token supports ERC20Permit (EIP-2612), allowing for gasless approvals and more efficient transactions. - -## Usage - -```typescript -const permitQuote = await meeClient.getPermitQuote({ - instructions: [ - // Instructions to execute - ], - feeToken: { - address: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC - chainId: 1 // Ethereum - }, - trigger: { - chainId: 1, // Ethereum - tokenAddress: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", // USDC - amount: 1000000n // 1 USDC (6 decimals) - } -}); -``` - -## Parameters - -### `parameters` - -An object containing the parameters for requesting a permit-enabled quote. - -```typescript -type GetPermitQuoteParams = { - /** - * Array of transaction instructions to execute - */ - instructions: Instruction[]; - - /** - * Fee token information including address and chain ID - */ - feeToken: FeeTokenInfo; - - /** - * Trigger information for the permit transaction - * Must contain a permit-enabled token address - */ - trigger: Trigger; - - /** - * Optional account to use (defaults to client.account) - */ - account?: MultichainSmartAccount; -} - -/** - * Fee token information - */ -type FeeTokenInfo = { - /** - * The address of the token to pay fees with - */ - address: Address; - - /** - * The chain ID where the fee token exists - */ - chainId: number; -} - -/** - * Trigger information - */ -type Trigger = { - /** - * Chain ID where the token exists - */ - chainId: number; - - /** - * Address of the token to use for payment - * Must support ERC20Permit (EIP-2612) - */ - tokenAddress: Address; - - /** - * Amount of tokens to use - */ - amount: bigint | string; -} -``` - -## Return Value - -Returns a Promise that resolves to a `GetPermitQuotePayload` object containing both the standard quote payload and permit-specific trigger information. - -```typescript -type GetPermitQuotePayload = { - /** - * Standard quote payload with transaction details - */ - quote: GetQuotePayload; - - /** - * Trigger information with updated amount including fees - * The amount includes both the original amount and gas fees - */ - trigger: Trigger; -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Token information -const tokenAddress = mcUSDC.addressOn(mainnet.id); - -// Create trigger information -const trigger = { - chainId: mainnet.id, - tokenAddress: tokenAddress, - amount: 1000000n // 1 USDC (6 decimals) -}; - -// Fee token information -const feeToken = { - address: tokenAddress, - chainId: mainnet.id -}; - -try { - // Get permit quote for a simple transaction - const permitQuote = await meeClient.getPermitQuote({ - instructions: [ - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } - }) - ], - feeToken, - trigger - }); - - console.log("Permit quote received:"); - console.log(`Quote ID: ${permitQuote.quote.id}`); - console.log(`Payment Token: ${permitQuote.quote.paymentInfo.token}`); - console.log(`Payment Chain: ${permitQuote.quote.paymentInfo.chainId}`); - console.log(`Total Amount (including fees): ${permitQuote.trigger.amount}`); - - // The permit quote can now be signed and executed - -} catch (error) { - console.error("Error getting permit quote:", error); -} -``` - -### Intent and Transaction Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, zeroAddress } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Token address -const tokenAddress = mcUSDC.addressOn(mainnet.id); - -// Create trigger -const trigger = { - chainId: mainnet.id, - tokenAddress: tokenAddress, - amount: 1n // Minimal amount for testing -}; - -// Fee token -const feeToken = { - address: tokenAddress, - chainId: mainnet.id -}; - -// Get permit quote for an intent and a transaction -try { - const permitQuote = await meeClient.getPermitQuote({ - trigger, - instructions: [ - // Intent to bridge USDC to the target chain - mcNexus.build({ - type: "intent", - data: { - amount: 1n, - mcToken: mcUSDC, - toChain: optimism - } - }), - // A simple transaction on the target chain - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: zeroAddress, - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } - }) - ], - feeToken - }); - - console.log("Permit quote received for intent and transaction"); - console.log(`Number of user operations: ${permitQuote.quote.userOps.length}`); - console.log(`Quote ID: ${permitQuote.quote.id}`); - console.log(`Total amount (including fees): ${permitQuote.trigger.amount}`); - -} catch (error) { - console.error("Error getting permit quote:", error); -} -``` - -### Multiple Instructions Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Token address -const tokenAddress = mcUSDC.addressOn(mainnet.id); - -// Create trigger -const trigger = { - chainId: mainnet.id, - tokenAddress: tokenAddress, - amount: 1n // Minimal amount for test -}; - -// Fee token -const feeToken = { - address: tokenAddress, - chainId: mainnet.id -}; - -// Create multiple instructions -const instructions = [ - // First instruction on Optimism - { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - }, - // Second instruction on Optimism - { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } -]; - -// Get permit quote for multiple instructions -try { - const quote = await meeClient.getPermitQuote({ - instructions, - feeToken, - trigger - }); - - console.log("Permit quote received for multiple instructions"); - console.log(`Number of user operations: ${quote.quote.userOps.length}`); - console.log(`Quote ID: ${quote.quote.id}`); - - // The quote can now be signed and executed - -} catch (error) { - console.error("Error getting permit quote:", error); -} -``` - -## Error Handling - -The `getPermitQuote` method may throw errors if there are issues with the specified parameters or if the token doesn't support permits: - -```typescript -try { - const permitQuote = await meeClient.getPermitQuote({ - instructions: [/* your instructions */], - feeToken, - trigger - }); - - // Process the permit quote - -} catch (error) { - console.error("Failed to get permit quote:", error); - - if (error.message.includes("does not support ERC20Permit")) { - console.log("The specified token does not support ERC20Permit (EIP-2612). Use getOnChainQuote instead."); - } else if (error.message.includes("insufficient balance")) { - console.log("Insufficient balance to cover the transaction."); - } else if (error.message.includes("not supported")) { - console.log("The specified token or chain is not supported."); - } else { - console.log("An unexpected error occurred. Please try again later."); - } -} -``` - -## Related Methods - -- [`signPermitQuote`](/sdk-reference/mee-client/methods/more/signPermitQuote) - Sign a permit quote for execution -- [`executeSignedQuote`](/sdk-reference/mee-client/methods/more/executeSignedQuote) - Execute a signed permit quote -- [`getOnChainQuote`](/sdk-reference/mee-client/methods/more/getOnChainQuote) - Get a quote for tokens that don't support ERC20Permit -- [`getQuote`](/sdk-reference/mee-client/methods/getQuote) - Get a standard quote for executing instructions - -## When to Use - -Use `getPermitQuote` when: -- The payment token supports ERC20Permit (EIP-2612) -- You want to benefit from gasless approvals -- You need more efficient transactions without pre-approvals -- You want to execute cross-chain operations using a permit-enabled token \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/more/getSupertransactionReceipt.md b/docs/pages/sdk-reference/mee-client/methods/more/getSupertransactionReceipt.md deleted file mode 100644 index 214e159..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/getSupertransactionReceipt.md +++ /dev/null @@ -1,210 +0,0 @@ -# getSupertransactionReceipt - -The `getSupertransactionReceipt` method retrieves the receipt for a supertransaction from the MEE node. It can optionally wait for the transaction to be mined and return the receipts from all constituent transactions. - -## When to Use This Method - -The `getSupertransactionReceipt` method provides immediate, granular control over transaction monitoring: - -- **Returns immediately** with the current transaction state -- Allows you to implement **custom polling logic** based on your application needs -- Gives you **fine-grained control** over how and when to check transaction status -- Lets you **build reactive UIs** that update in real-time as transaction status changes -- Enables **non-blocking workflows** where you can continue execution while monitoring transactions - -Use this method when you need precise control over transaction status monitoring or want to implement custom waiting strategies. For a simpler "wait until complete" approach, consider using `waitForSupertransactionReceipt`, which repeatedly polls this method until all operations settle. - -## Parameters - -| Parameter | Type | Required | Description | -|-----------|------|----------|-------------| -| `hash` | `Hex` | Yes | The supertransaction hash to get the receipt for | -| `waitForReceipts` | `boolean` | No | Whether to wait for transaction receipts to be mined. Defaults to `true` | -| `confirmations` | `number` | No | Number of confirmations to wait for. Defaults to `2` | -| `account` | `MultichainSmartAccount` | No | Smart account to execute the transaction. If not provided, uses the client's default account | - -## Returns - -Promise resolving to a receipt containing: - -| Property | Type | Description | -|----------|------|-------------| -| `hash` | `Hex` | Transaction hash | -| `node` | `Address` | Address of the MEE node | -| `commitment` | `Hex` | Commitment hash | -| `paymentInfo` | `FilledPaymentInfo` | Complete payment information with token amounts | -| `userOps` | `(MeeFilledUserOpDetails & UserOpStatus)[]` | Array of user operations with their status and details | -| `explorerLinks` | `Url[]` | Array of links to explorers where the transaction can be viewed | -| `transactionStatus` | `string` | Status of the supertransaction: `SUCCESS`, `MINING`, `MINED_SUCCESS`, `MINED_FAIL`, `FAILED`, or `PENDING` | -| `receipts` | `TransactionReceipt[] \| null` | Array of transaction receipts if `waitForReceipts` is `true`, otherwise `null` | - -## Basic Example - -This example shows how to get a transaction receipt and check its status: - -```typescript -// Execute a quote -const quote = await meeClient.getQuote({ - instructions: [ - { - calls: [ - { - to: zeroAddress, - value: 0n, - gasLimit: 50000n - } - ], - chainId: targetChain.id - } - ], - feeToken: { - address: mcUSDC.addressOn(paymentChain.id), - chainId: paymentChain.id - } -}); - -// Execute the quote -const { hash } = await meeClient.executeQuote({ quote }); - -// Get the receipt -const receipt = await meeClient.getSupertransactionReceipt({ - hash -}); - -// Check transaction status -console.log(`Transaction status: ${receipt.transactionStatus}`); - -// Explorer links for viewing the transaction -console.log(`Explorer links:`, receipt.explorerLinks); -``` - -## Checking Transaction Completion - -You can check if a transaction is complete or still pending: - -```typescript -const receipt = await meeClient.getSupertransactionReceipt({ hash }); - -// Check if any operations are still pending -const pendingOps = receipt.userOps.filter(op => - op.executionStatus === "PENDING" || op.executionStatus === "MINING" -); - -if (pendingOps.length > 0) { - console.log(`${pendingOps.length} operations still pending...`); - // Implement custom retry/polling logic here -} else { - console.log("All operations complete!"); - - if (receipt.transactionStatus === "MINED_SUCCESS") { - console.log("Transaction successful!"); - } else { - console.log("Transaction failed:", receipt.transactionStatus); - } -} -``` - -## Waiting for Confirmations - -For transactions where you need to wait for a specific number of confirmations, use the `confirmations` parameter: - -```typescript -// Execute a transaction -const { hash } = await meeClient.executeSignedQuote({ signedQuote }); - -// Wait for the transaction with 3 confirmations -const receiptWithConfirmations = await meeClient.getSupertransactionReceipt({ - hash, - waitForReceipts: true, - confirmations: 3 -}); - -// Now you can safely consider the transaction finalized -console.log("Transaction finalized with 3 confirmations"); -console.log("Explorer links:", receiptWithConfirmations.explorerLinks); - -// If receipts were requested, you can check them -if (receiptWithConfirmations.receipts) { - receiptWithConfirmations.receipts.forEach((chainReceipt, index) => { - const userOp = receiptWithConfirmations.userOps[index]; - console.log(`Transaction on chain ${userOp.chainId}:`); - console.log(` Block number: ${chainReceipt.blockNumber}`); - console.log(` Gas used: ${chainReceipt.gasUsed}`); - }); -} -``` - -## Status Types - -The supertransaction and its constituent user operations can have the following statuses: - -| Status | Description | -|--------|-------------| -| `MINING` | The transaction is being mined | -| `MINED_SUCCESS` | The transaction has been mined successfully but may not have all confirmations yet | -| `MINED_FAIL` | The transaction was mined but failed during execution | -| `FAILED` | The transaction failed before or during mining | -| `PENDING` | The transaction is pending and has not been mined yet | - -## Explorer Links - -The receipt includes links to different blockchain explorers: - -1. **MEE Scan** - View the entire supertransaction -2. **Chain Explorers** - View individual transactions on each chain's block explorer -3. **JiffyScan** - View user operations on JiffyScan - -## Error Handling - -The method throws errors in the following cases: - -- If the transaction has failed (`FAILED` or `MINED_FAIL` status) -- If the transaction status is unknown -- If there are network connectivity issues when retrieving the receipt - -Error handling example: - -```typescript -try { - const receipt = await meeClient.getSupertransactionReceipt({ hash }); - console.log("Transaction status:", receipt.transactionStatus); -} catch (error) { - console.error("Transaction failed:", error.message); - // Implement fallback logic or user notification -} -``` - -## Type Definitions - -### GetSupertransactionReceiptParams -```typescript -type GetSupertransactionReceiptParams = { - hash: Hex - waitForReceipts?: boolean - confirmations?: number - account?: MultichainSmartAccount -} -``` - -### UserOpStatus -```typescript -type UserOpStatus = { - executionStatus: "SUCCESS" | "MINING" | "MINED_SUCCESS" | "MINED_FAIL" | "FAILED" | "PENDING" - executionData: Hex - executionError: string -} -``` - -### GetSupertransactionReceiptPayload -```typescript -type GetSupertransactionReceiptPayload = { - hash: Hex - node: Address - commitment: Hex - paymentInfo: FilledPaymentInfo - userOps: (MeeFilledUserOpDetails & UserOpStatus)[] - explorerLinks: Url[] - transactionStatus: UserOpStatus["executionStatus"] - receipts: TransactionReceipt[] | null -} -``` diff --git a/docs/pages/sdk-reference/mee-client/methods/more/signOnChainQuote.md b/docs/pages/sdk-reference/mee-client/methods/more/signOnChainQuote.md deleted file mode 100644 index 2af0a9a..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/signOnChainQuote.md +++ /dev/null @@ -1,322 +0,0 @@ -# signOnChainQuote - -The `signOnChainQuote` method signs a fusion quote with an on-chain transaction. This method is used as part of the flow for executing transactions with tokens that don't support ERC20Permit, where an on-chain approval transaction is needed before executing the quote. - -## Usage - -```typescript -const signedQuote = await meeClient.signOnChainQuote({ - fusionQuote: onChainQuote, - confirmations: 2 -}); -``` - -## Parameters - -### `parameters` - -An object containing the parameters for signing an on-chain quote. - -```typescript -type SignOnChainQuoteParams = { - /** - * The fusion quote to sign, obtained from getOnChainQuote - */ - fusionQuote: GetOnChainQuotePayload; - - /** - * Optional account to use for signing (defaults to client.account) - */ - account?: MultichainSmartAccount; - - /** - * The number of confirmations to wait for (defaults to 2) - */ - confirmations?: number; -} - -/** - * The payload from getOnChainQuote containing quote and trigger information - */ -type GetOnChainQuotePayload = { - quote: GetQuotePayload; - trigger: Trigger; -} -``` - -## Return Value - -Returns a Promise that resolves to a `SignOnChainQuotePayload` object containing the quote details with the added signature. - -```typescript -type SignOnChainQuotePayload = GetQuotePayload & { - /** - * The signature of the quote, produced by sending an on-chain transaction - */ - signature: Hex; -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Token information on Optimism -const tokenAddress = mcUSDC.addressOn(optimism.id); - -// Create trigger information -const trigger = { - chainId: optimism.id, - tokenAddress: tokenAddress, - amount: 1000000n // 1 USDC (6 decimals) -}; - -// Fee token information -const feeToken = { - address: tokenAddress, - chainId: optimism.id -}; - -try { - // 1. Get an on-chain quote - const onChainQuote = await meeClient.getOnChainQuote({ - instructions: [ - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: "0x0000000000000000000000000000000000000000", - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } - }) - ], - feeToken, - trigger - }); - - console.log("On-chain quote received:"); - console.log(`Quote ID: ${onChainQuote.quote.id}`); - - // 2. Sign the on-chain quote (this will send an on-chain transaction) - const signedQuote = await meeClient.signOnChainQuote({ - fusionQuote: onChainQuote, - confirmations: 2 - }); - - console.log("Quote signed with signature:", signedQuote.signature); - - // The signedQuote can now be executed with executeSignedQuote - -} catch (error) { - console.error("Error during on-chain quote signing:", error); -} -``` - -### Full Execution Flow Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, parseUnits } from "viem"; -import { generatePrivateKey, privateKeyToAccount } from "viem/accounts"; -import { optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism], - signer: eoaAccount, - transports: [http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Create a recipient account for the transfer -const recipientAccount = privateKeyToAccount(generatePrivateKey()); - -// Token address on Optimism -const tokenAddress = mcUSDC.addressOn(optimism.id); - -// Create trigger for a token transfer -const trigger = { - chainId: optimism.id, - tokenAddress: tokenAddress, - amount: 1n // Minimal amount for testing -}; - -// Fee token (same as trigger token in this example) -const feeToken = { - address: tokenAddress, - chainId: optimism.id -}; - -// Get deployment information -const sender = mcNexus.signer.address; -const { address: recipient } = mcNexus.deploymentOn(optimism.id, true); - -// Get an on-chain quote for a token transfer -const onChainQuote = await meeClient.getOnChainQuote({ - trigger, - instructions: [ - // Transfer from EOA to smart account - mcNexus.build({ - type: "transferFrom", - data: { ...trigger, sender, recipient } - }), - // Transfer from smart account to recipient - mcNexus.build({ - type: "transfer", - data: { - ...trigger, - recipient: recipientAccount.address - } - }) - ], - feeToken -}); - -// Sign the on-chain quote (this sends an on-chain transaction) -const signedQuote = await meeClient.signOnChainQuote({ - fusionQuote: onChainQuote -}); - -// Execute the signed quote -const executionResponse = await meeClient.executeSignedQuote({ - signedQuote -}); - -console.log(`Quote execution submitted with hash: ${executionResponse.hash}`); - -// Wait for the supertransaction receipt -const receipt = await meeClient.waitForSupertransactionReceipt({ - hash: executionResponse.hash -}); - -console.log("Transaction confirmed!"); -console.log(`Explorer links: ${receipt.explorerLinks.join(', ')}`); - -// Verify the recipient received the tokens -const recipientBalance = await getBalance( - mcNexus.deploymentOn(optimism.id, true).publicClient, - recipientAccount.address, - tokenAddress -); - -console.log(`Recipient balance: ${recipientBalance}`); -``` - -### Using Custom Confirmations - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http } from "viem"; -import { optimism, base } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Define trigger and fee token -const trigger = { - chainId: optimism.id, - tokenAddress: mcUSDC.addressOn(optimism.id), - amount: 1n -}; - -const feeToken = { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id -}; - -// Get on-chain quote -const onChainQuote = await meeClient.getOnChainQuote({ - trigger, - instructions: [ - mcNexus.build({ - type: "transfer", - data: { - chainId: base.id, - tokenAddress: mcUSDC.addressOn(base.id), - amount: 1n, - recipient: "0x1234567890123456789012345678901234567890" - } - }) - ], - feeToken -}); - -// Sign the quote with a higher confirmation requirement -// This is useful for high-value transactions or on networks with frequent reorgs -const signedQuote = await meeClient.signOnChainQuote({ - fusionQuote: onChainQuote, - confirmations: 5 // Wait for 5 confirmations instead of the default 2 -}); - -console.log(`Quote signed with 5 confirmations. Signature: ${signedQuote.signature}`); -``` - -## Error Handling - -The `signOnChainQuote` method may throw errors during the on-chain transaction process: - -```typescript -try { - const signedQuote = await meeClient.signOnChainQuote({ - fusionQuote: onChainQuote - }); - - // Process the signed quote - -} catch (error) { - console.error("Failed to sign on-chain quote:", error); - - if (error.message.includes("insufficient funds")) { - console.log("Your account doesn't have enough funds to send the approval transaction."); - } else if (error.message.includes("user rejected")) { - console.log("The transaction was rejected by the user."); - } else if (error.message.includes("transaction failed")) { - console.log("The approval transaction failed. This might be due to network congestion or other issues."); - } else { - console.log("An unexpected error occurred. Please try again later."); - } -} -``` - -## Related Methods - -- [`getOnChainQuote`](/sdk-reference/mee-client/methods/more/getOnChainQuote) - Get an on-chain quote to be signed -- [`executeSignedQuote`](/sdk-reference/mee-client/methods/more/executeSignedQuote) - Execute a signed quote -- [`waitForSupertransactionReceipt`](/sdk-reference/mee-client/methods/more/getSupertransactionReceipt) - Wait for a supertransaction receipt - -## When to Use - -Use `signOnChainQuote` when: -- You need to sign a quote for tokens that don't support ERC20Permit -- You've obtained an on-chain quote with `getOnChainQuote` and need to proceed with execution -- You want to execute a transaction that requires an on-chain approval step -- You're building a flow that requires user confirmation via an on-chain transaction \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/more/signPermitQuote.md b/docs/pages/sdk-reference/mee-client/methods/more/signPermitQuote.md deleted file mode 100644 index 825afb5..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/signPermitQuote.md +++ /dev/null @@ -1,369 +0,0 @@ -# signPermitQuote - -The `signPermitQuote` method signs a permit quote using EIP-2612 permit signatures. This enables gasless approvals for ERC20 tokens that implement the permit extension, allowing for more efficient transactions without requiring separate approval transactions. - -## Usage - -```typescript -const signedQuote = await meeClient.signPermitQuote({ - fusionQuote: permitQuote -}); -``` - -## Parameters - -### `parameters` - -An object containing the parameters for signing a permit quote. - -```typescript -type SignPermitQuoteParams = { - /** - * The fusion quote to sign, obtained from getPermitQuote - */ - fusionQuote: GetPermitQuotePayload; - - /** - * Optional account to use for signing (defaults to client.account) - */ - account?: MultichainSmartAccount; -} - -/** - * The payload from getPermitQuote containing quote and trigger information - */ -type GetPermitQuotePayload = { - quote: GetQuotePayload; - trigger: Trigger; -} - -/** - * Trigger information - */ -type Trigger = { - /** - * Chain ID where the token exists - * @example 1 // Ethereum Mainnet - */ - chainId: number; - - /** - * Address of the token to use for payment - * Must support ERC20Permit (EIP-2612) - * @example "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // USDC - */ - tokenAddress: Address; - - /** - * Amount of tokens to use, in the token's smallest unit - * @example 1000000n // 1 USDC (6 decimals) - */ - amount: bigint; -} -``` - -## Return Value - -Returns a Promise that resolves to a `SignPermitQuotePayload` object containing the quote details with the added permit signature. - -```typescript -type SignPermitQuotePayload = GetQuotePayload & { - /** - * The signature of the quote, prefixed with '0x02' and concatenated with - * the encoded permit parameters and signature components - */ - signature: Hex; -} -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, zeroAddress } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Token information (using a token that supports EIP-2612 permits) -const tokenAddress = mcUSDC.addressOn(mainnet.id); - -// Create trigger information -const trigger = { - chainId: mainnet.id, - tokenAddress: tokenAddress, - amount: 1000000n // 1 USDC (6 decimals) -}; - -// Fee token information -const feeToken = { - address: tokenAddress, - chainId: mainnet.id -}; - -try { - // 1. Get a permit quote - const permitQuote = await meeClient.getPermitQuote({ - instructions: [ - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: zeroAddress, - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } - }) - ], - feeToken, - trigger - }); - - console.log("Permit quote received:"); - console.log(`Quote ID: ${permitQuote.quote.id}`); - - // 2. Sign the permit quote - const signedQuote = await meeClient.signPermitQuote({ - fusionQuote: permitQuote - }); - - console.log("Quote signed with signature:", signedQuote.signature); - - // The signedQuote can now be executed with executeSignedQuote - -} catch (error) { - console.error("Error during permit quote signing:", error); -} -``` - -### Complete Flow Example with Execution - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, generatePrivateKey, privateKeyToAccount } from "viem"; -import { mainnet } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet], - signer: eoaAccount, - transports: [http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Create a recipient account -const recipientAccount = privateKeyToAccount(generatePrivateKey()); - -// Token address that supports EIP-2612 permit -const tokenAddress = mcUSDC.addressOn(mainnet.id); - -// Create trigger for a minimal transfer (for testing) -const trigger = { - chainId: mainnet.id, - tokenAddress: tokenAddress, - amount: 1n -}; - -// Fee token (same as trigger token in this example) -const feeToken = { - address: tokenAddress, - chainId: mainnet.id -}; - -// Get smart account information -const recipient = mcNexus.addressOn(mainnet.id, true); -const sender = mcNexus.signer.address; - -try { - // 1. Get the fusion quote - const permitQuote = await meeClient.getPermitQuote({ - trigger, - instructions: [ - // Transfer from EOA to smart account - mcNexus.build({ - type: "transferFrom", - data: { ...trigger, recipient, sender } - }), - // Transfer from smart account to recipient - mcNexus.build({ - type: "transfer", - data: { - ...trigger, - recipient: recipientAccount.address - } - }) - ], - feeToken - }); - - // Calculate total amount including fees - const fusionQuote = { - quote: permitQuote.quote, - trigger: { - ...trigger, - amount: BigInt(trigger.amount) + BigInt(permitQuote.quote.paymentInfo.tokenWeiAmount) - } - }; - - // 2. Sign the permit quote - const signedQuote = await meeClient.signPermitQuote({ fusionQuote }); - - // 3. Execute the signed quote - const { hash } = await meeClient.executeSignedQuote({ signedQuote }); - - console.log(`Quote execution submitted with hash: ${hash}`); - - // 4. Wait for the transaction to be confirmed - const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - - console.log("Transaction confirmed!"); - console.log(`Explorer links: ${receipt.explorerLinks.join(', ')}`); - - // 5. Verify the recipient received the tokens - const recipientBalance = await getBalance( - mcNexus.deploymentOn(mainnet.id, true).publicClient, - recipientAccount.address, - tokenAddress - ); - - console.log(`Recipient balance: ${recipientBalance}`); - -} catch (error) { - console.error("Error during permit flow:", error); -} -``` - -### Using Intent and Transaction Instructions - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, zeroAddress } from "viem"; -import { mainnet, optimism } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [mainnet, optimism], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Token address -const tokenAddress = mcUSDC.addressOn(mainnet.id); - -// Create trigger -const trigger = { - chainId: mainnet.id, - tokenAddress: tokenAddress, - amount: 1n // Minimal amount for test -}; - -// Fee token -const feeToken = { - address: tokenAddress, - chainId: mainnet.id -}; - -// Get permit quote for an intent and a transaction -try { - const fusionQuote = await meeClient.getPermitQuote({ - trigger, - instructions: [ - // Intent to bridge USDC to the target chain - mcNexus.build({ - type: "intent", - data: { - amount: 1n, - mcToken: mcUSDC, - toChain: optimism - } - }), - // A simple transaction on the target chain - mcNexus.build({ - type: "default", - data: { - calls: [ - { - to: zeroAddress, - gasLimit: 50000n, - value: 0n - } - ], - chainId: optimism.id - } - }) - ], - feeToken - }); - - // Sign the fusion quote with the permit - const signedQuote = await meeClient.signPermitQuote({ fusionQuote }); - - console.log("Permit quote signed for intent and transaction"); - console.log(`Number of user operations: ${signedQuote.userOps.length}`); - console.log(`Quote ID: ${signedQuote.id}`); - console.log(`Signature: ${signedQuote.signature.slice(0, 66)}...`); - -} catch (error) { - console.error("Error signing permit quote:", error); -} -``` - -## Error Handling - -The `signPermitQuote` method may throw errors during the signing process: - -```typescript -try { - const signedQuote = await meeClient.signPermitQuote({ - fusionQuote: permitQuote - }); - - // Process the signed quote - -} catch (error) { - console.error("Failed to sign permit quote:", error); - - if (error.message.includes("does not support ERC20Permit")) { - console.log("The specified token does not support ERC20Permit (EIP-2612). Use signOnChainQuote instead."); - } else if (error.message.includes("user rejected")) { - console.log("The signature request was rejected by the user."); - } else if (error.message.includes("domain separator")) { - console.log("Error with token contract domain separator. Verify the token implements permit correctly."); - } else { - console.log("An unexpected error occurred. Please try again later."); - } -} -``` - -## Related Methods - -- [`getPermitQuote`](/sdk-reference/mee-client/methods/more/getPermitQuote) - Get a permit quote to be signed -- [`executeSignedQuote`](/sdk-reference/mee-client/methods/more/executeSignedQuote) - Execute a signed quote -- [`signOnChainQuote`](/sdk-reference/mee-client/methods/more/signOnChainQuote) - Sign a quote for tokens that don't support ERC20Permit - -## When to Use - -Use `signPermitQuote` when: -- You're working with tokens that support ERC20Permit (EIP-2612) -- You've obtained a permit quote with `getPermitQuote` and need to sign it -- You want to execute transactions without requiring separate approval transactions -- You want to create a more efficient and user-friendly transaction flow with fewer on-chain steps \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/more/signQuote.md b/docs/pages/sdk-reference/mee-client/methods/more/signQuote.md deleted file mode 100644 index efd6bc2..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/more/signQuote.md +++ /dev/null @@ -1,153 +0,0 @@ -# signQuote - -The `signQuote` method is the second step in the three-step process for executing transactions through the MEE. It takes a quote obtained from `getQuote` and generates a digital signature that authorizes the execution of the transactions specified in the quote. - -This step is crucial for user flow control, as it allows developers to insert confirmation steps between getting a quote and executing it, enabling users to approve transaction costs before proceeding. - -## Usage - -```typescript -const signedQuote = await meeClient.signQuote({ - quote -}); -``` - -## Parameters - -### `quote` - -The quote object returned from `getQuote`. - -```typescript -type SignQuoteParameters = { - quote: GetQuotePayload; - account?: SmartAccountSigner; // Optional account to use for signing -}; -``` - -## Return Value - -Returns a Promise that resolves to a signed quote payload. - -```typescript -type SignQuotePayload = GetQuotePayload & { - signature: Hex; -}; -``` - -## Examples - -### Basic Example - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { http, zeroAddress } from "viem"; -import { optimism, base } from "viem/chains"; - -// Setup multichain account -const mcNexus = await toMultichainNexusAccount({ - chains: [optimism, base], - signer: eoaAccount, - transports: [http(), http()] -}); - -// Create MEE client -const meeClient = await createMeeClient({ account: mcNexus }); - -// Define fee token on payment chain -const feeToken = { - address: mcUSDC.addressOn(optimism.id), - chainId: optimism.id -}; - -// Step 1: Get a quote -const quote = await meeClient.getQuote({ - instructions: [ - { - calls: [ - { - to: zeroAddress, - value: 0n, - gasLimit: 50000n - } - ], - chainId: base.id - } - ], - feeToken -}); - -// Display gas cost to user for confirmation -console.log("Gas fee in tokens:", quote.paymentInfo.amount); -console.log("Token symbol:", quote.paymentInfo.tokenSymbol); - -// After user confirmation, sign the quote -const signedQuote = await meeClient.signQuote({ quote }); - -// Now the signed quote can be executed -const { hash } = await meeClient.executeSignedQuote({ - signedQuote -}); -``` - -### With Custom Account Signer - -In some cases, you might want to use a specific account signer different from the one configured in the MEE client: - -```typescript -import { createMeeClient, toMultichainNexusAccount, mcUSDC } from "@biconomy/abstractjs"; -import { privateKeyToAccount } from "viem/accounts"; -import { optimism, base } from "viem/chains"; - -// Create a specific signer -const customSigner = privateKeyToAccount("0x..." /* private key */); - -// ... setup client and get quote as in previous example - -// Sign the quote with the custom signer -const signedQuote = await meeClient.signQuote({ - quote, - account: customSigner -}); - -// Execute the signed quote -const { hash } = await meeClient.executeSignedQuote({ - signedQuote -}); -``` - -## Error Handling - -The `signQuote` method can throw errors in several situations: - -```typescript -try { - const signedQuote = await meeClient.signQuote({ - quote - }); - - console.log("Quote successfully signed"); -} catch (error) { - if (error.message.includes("signature")) { - console.error("Failed to sign the quote. Check signer permissions."); - } else if (error.message.includes("format")) { - console.error("Invalid quote format"); - } else { - console.error("Error signing quote:", error); - } -} -``` - -## Related Methods - -- [`getQuote`](/sdk-reference/mee-client/methods/getQuote) - Get a quote for executing instructions -- [`executeSignedQuote`](/sdk-reference/mee-client/methods/more/executeSignedQuote) - Execute a signed quote -- [`execute`](/sdk-reference/mee-client/methods/more/execute) - Convenience method that combines all three steps - -## When to Use - -Use `signQuote` as part of the three-step process (getQuote → signQuote → executeSignedQuote) when: -- You need to display gas costs to users before they authorize the transaction -- You want to implement a confirmation step in your application's UX flow -- You need to ensure users have explicitly approved the transaction costs -- You're building a UI with "Approve" and "Reject" buttons for transaction confirmation \ No newline at end of file diff --git a/docs/pages/sdk-reference/mee-client/methods/waitForSupertransactionReceipt.md b/docs/pages/sdk-reference/mee-client/methods/waitForSupertransactionReceipt.md deleted file mode 100644 index 6c228fb..0000000 --- a/docs/pages/sdk-reference/mee-client/methods/waitForSupertransactionReceipt.md +++ /dev/null @@ -1,147 +0,0 @@ -# waitForSupertransactionReceipt - -Waits for a super transaction receipt to be available and returns the transaction details along with explorer links. - -## When to Use This Method - -The `waitForSupertransactionReceipt` method is designed for scenarios where you need to wait for transaction completion before proceeding: - -- **Blocks execution** until all user operations have reached a final state -- **Simplifies transaction monitoring** with a convenient "fire and wait" pattern -- **Automatically polls** `getSupertransactionReceipt` at regular intervals (default: 1000ms) -- Continues polling until **all operations have settled** (no longer in "PENDING" state) -- Perfect for **sequential workflows** that depend on transaction completion - -Use this method when you want a simplified approach to waiting for transaction completion without implementing custom polling logic. For more granular control over transaction status checking, consider using `getSupertransactionReceipt` directly. - -## Usage - -```typescript -const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); -``` - -## Parameters - -| Parameter | Type | Required | Description | -| --------- | ---- | ----------- | ----------- | -| `hash` | `Hex` | Yes | The hash of the super transaction to wait for | -| `confirmations?` | `number` | No | Optional number of confirmations to wait for (optional, example seen in tests: 3) | -| `waitForReceipts?` | `boolean` | No | Set internally to true - will ensure receipts are included in the response | - -## Returns - -Returns a promise that resolves to a `WaitForSupertransactionReceiptPayload` object containing: - -| Property | Type | Description | -| -------- | ---- | ----------- | -| `hash` | `Hex` | The hash of the super transaction | -| `node` | `Address` | Address of the MEE node that processed the transaction | -| `commitment` | `Hex` | Commitment hash for the transaction | -| `paymentInfo` | `FilledPaymentInfo` | Payment information object (see below) | -| `userOps` | `MeeFilledUserOpDetails[]` | Array of user operations (see below) | -| `explorerLinks` | `Url[]` | Array of links to view the transaction on block explorers | -| `transactionStatus` | `"MINED_SUCCESS" \| "MINED_FAIL" \| "PENDING" \| "FAILED"` | Overall status of the transaction | -| `receipts` | `Array` | Array of blockchain transaction receipts | - -### FilledPaymentInfo Object - -| Property | Type | Description | -| -------- | ---- | ----------- | -| `token` | `Address` | Address of the token used for payment | -| `amount` | `bigint` | Amount of tokens to be paid | -| `decimals` | `number` | Number of decimals for the token | -| `symbol` | `string` | Token symbol | -| `exchangeRate` | `string` | Exchange rate used for the transaction | - -### MeeFilledUserOpDetails Object - -| Property | Type | Description | -| -------- | ---- | ----------- | -| `chainId` | `number` | Chain ID where the operation is executed | -| `sender` | `Address` | Address of the sender account | -| `nonce` | `bigint` | Account nonce | -| `initCode` | `Hex` | Account initialization code (if needed) | -| `callData` | `Hex` | The call data for the operation | -| `callGasLimit` | `bigint` | Gas limit for the main execution | -| `verificationGasLimit` | `bigint` | Gas limit for signature verification | -| `preVerificationGas` | `bigint` | Gas required for pre-verification | -| `maxFeePerGas` | `bigint` | Maximum fee per gas unit | -| `maxPriorityFeePerGas` | `bigint` | Maximum priority fee per gas unit | -| `paymasterAndData` | `Hex` | Paymaster contract address and data | -| `signature` | `Hex` | Operation signature | -| `factory` | `Address` | Account factory address | -| `executionStatus` | `"SUCCESS" \| "PENDING" \| "FAILED"` | Status of the operation execution | -| `executionData` | `Hex` | Data returned from the execution | -| `executionError` | `string \| null` | Error message if execution failed | - -## Behavior - -- Polls the MEE explorer API by calling `getSupertransactionReceipt` until all user operations are no longer in a "PENDING" state -- Uses the client's `pollingInterval` (defaults to 1000ms) between checks -- Throws an error if any user operation fails (status "FAILED" or "MINED_FAIL") -- Automatically generates relevant block explorer links for the transaction - -## Examples - -### Basic Usage - -```typescript -import { createMeeClient } from '@biconomy/abstractjs'; - -// Create MEE client -const meeClient = await createMeeClient({ - account: multiChainAccount, -}); - -// Execute a quote -const { hash } = await meeClient.executeQuote({ quote }); - -// Wait for all operations to complete before proceeding -// This will block execution until the transaction is done -try { - const receipt = await meeClient.waitForSupertransactionReceipt({ hash }); - - if (receipt.transactionStatus === "MINED_SUCCESS") { - console.log("Transaction completed successfully!"); - console.log("View transaction:"); - receipt.explorerLinks.forEach(link => console.log(link)); - - // Continue with your workflow now that transaction is complete - processTransactionResults(receipt); - } else { - console.error("Transaction failed:", receipt.transactionStatus); - } -} catch (error) { - console.error("Error waiting for transaction:", error); -} -``` - -### With Confirmations Parameter - -Based on the test files, you can specify the number of confirmations to wait for: - -```typescript -// Execute a signed quote -const executeSignedQuoteResponse = await meeClient.executeSignedQuote({ - signedQuote -}); - -// Wait for the transaction with 3 confirmations -const superTransactionReceipt = await meeClient.waitForSupertransactionReceipt({ - hash: executeSignedQuoteResponse.hash, - confirmations: 3 -}); - -// Check explorerLinks -expect(superTransactionReceipt.explorerLinks.length).toBeGreaterThan(0); -``` - -## Comparison with getSupertransactionReceipt - -While `getSupertransactionReceipt` provides a snapshot of the current transaction state and returns immediately, `waitForSupertransactionReceipt` simplifies the process by: - -1. Repeatedly polling `getSupertransactionReceipt` at regular intervals -2. Automatically handling the waiting logic for you -3. Only resolving once all operations have reached a final state (no longer "PENDING") -4. Throwing errors automatically if the transaction fails -5. Providing a more convenient API for sequential workflows \ No newline at end of file diff --git a/docs/pages/smart-account/7579methods.mdx b/docs/pages/smart-account/7579methods.mdx deleted file mode 100644 index 072e1da..0000000 --- a/docs/pages/smart-account/7579methods.mdx +++ /dev/null @@ -1,194 +0,0 @@ -# Base ERC-7579 Methods - -## `installModule` -Installs the module on the smart account. - -**Usage Example** - -```typescript -const userOpReceipt: UserOpReceipt = await smartAccount.installModule({ - moduleAddress: K1_VALIDATOR, - type: 'validator', - data: encodePacked(["address"], [await smartAccount.getAddress()]) -}) -``` - -**Parameters** - -- moduleAddress (`Address`, required) -- type ([ModuleType](https://github.com/bcnmy/biconomy-client-sdk/blob/b66b611aa35af13da879995078892827aabf30e4/src/modules/utils/Types.ts#L232), required) -- data (`0x${string}` | undefined, optional) - -**Returns** - -- `Promise`: A promise of [UserOpReceipt](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/bundler/utils/Types.ts#L23) - -## `uninstallModule` -Uninstalls the module of the smart account. - -**Usage Example** - -```typescript -await smartAccount.uninstallModule(moduleAddress, ModuleType.Validation); -``` - -**Parameters** - -- moduleAddress (`Address`, required) -- type ([ModuleType](https://github.com/bcnmy/biconomy-client-sdk/blob/b66b611aa35af13da879995078892827aabf30e4/src/modules/utils/Types.ts#L232), required) -- moduleSelector (`0x${string}` | undefined, optional) This will only be needed when uninstalling `Fallback` modules -- data (`0x${string}` | undefined, optional) - -**Returns** - -- `Promise`: A promise of [UserOpReceipt](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/bundler/utils/Types.ts#L23) - -## `isModuleInstalled` -Checks if a module is installed on the smart account. - -**Usage Example** - -```typescript -const isInstalled: boolean = await smartAccount.isModuleInstalled({ - type, - moduleAddress -}); -``` - -**Parameters** - -- type ([ModuleType](https://github.com/bcnmy/biconomy-client-sdk/blob/b66b611aa35af13da879995078892827aabf30e4/src/modules/utils/Types.ts#L232), required) -- moduleAddress (`Address`, required) -- data (`0x${string}` | undefined, optional) - -**Returns** - -- `Promise`: A promise of a boolean - -## `getPreviousModule` -Gets the pointer to the previously installed module based on given `moduleAddress` and `type` - -**Usage Example** - -```typescript -const previousModule = await smartAccount.getPreviousModule({ - moduleAddress, - type -}); -``` - -**Parameters** - -- moduleAddress (`Address`, required) -- type ([ModuleType](https://github.com/bcnmy/biconomy-client-sdk/blob/b66b611aa35af13da879995078892827aabf30e4/src/modules/utils/Types.ts#L232), required) - -**Returns** - -- `Promise<{moduleAddress: Address; type: ModuleType}>`: A promise of an object - -## `getInstalledValidators` -Gets the installed validators - -**Usage Example** - -```typescript -const validators = await smartAccount.getInstalledValidators(); -``` - -**Returns** - -- `Promise`: A promise of validator addresses - -## `getInstalledExecutors` -Gets the installed executors - -**Usage Example** - -```typescript -const executors = await smartAccount.getInstalledExecutors(); -``` - -**Returns** - -- `Promise`: A promise of executor addresses - -## `getInstalledModules` -Gets all the installed modules - -**Usage Example** - -```typescript -const modules = await smartAccount.getInstalledModules(); -``` - -**Returns** - -- `Promise`: A promise of module addresses - -## `getActiveHook` -Gets the active hook module - -**Usage Example** - -```typescript -const hook = await smartAccount.getActiveHook(); -``` - -**Returns** - -- `Promise
`: A promise of a hook address - -## `getFallbackBySelector` -Gets the fallback module by the selector - -**Usage Example** - -```typescript -const fallback = await smartAccount.getFallbackBySelector(); -``` - -**Parameters** - -- selector (`Hex`, optional) The fallback module selector, if not passed, the [GENERIC_FALLBACK_SELECTOR](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/account/utils/Constants.ts#L122) will be used - -**Returns** - -- `Promise
`: A promise of a fallback module address - -## `supportsModule` -Check if the smart account supports a module - -**Usage Example** - -```typescript -const isSupported = await smartAccount.supportsModule(ModuleType.Hook); -``` - -**Parameters** - -- type ([ModuleType](https://github.com/bcnmy/biconomy-client-sdk/blob/b66b611aa35af13da879995078892827aabf30e4/src/modules/utils/Types.ts#L232), required) - -**Returns** - -- `Promise`: A promise of a boolean - -## `sendTransactionWithExecutor` -Sends a transaction using an active executor module. - -**Usage Example** - -```typescript -const userOpReceipt: UserOpReceipt = await smartAccount.sendTransactionWithExecutor( - [transaction], - ownedAccountAddress -) -``` - -**Parameters** - -- manyOrOneTransactions ([Transaction](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/account/utils/Types.ts#L346) | `Transaction[]`, required) -- ownedAccountAddress (`Address`, required) - -**Returns** - -- `Promise`: A promise of [UserOpReceipt](https://github.com/bcnmy/biconomy-client-sdk/blob/b3fe78f74ec366f50bbbb5ad8cf043e689df6bff/src/bundler/utils/Types.ts#L23) \ No newline at end of file diff --git a/docs/pages/smart-account/index.mdx b/docs/pages/smart-account/index.mdx deleted file mode 100644 index 07eda6a..0000000 --- a/docs/pages/smart-account/index.mdx +++ /dev/null @@ -1,69 +0,0 @@ -# NexusSmartAccount - -The `NexusSmartAccount` class is a comprehensive implementation of a smart contract account that is compliant with ERC-7579 and ERC-4337 standards. It is part of the Biconomy suite of contracts for Modular Smart Accounts. - -## Overview - -`NexusSmartAccount` extends `BaseSmartContractAccount` and provides a wide range of functionality for managing and interacting with smart contract accounts. It includes features such as: - -- Account creation and deployment -- Transaction execution -- User operation building and sending -- Module management (installation, uninstallation, and querying) -- Balance checking -- Gas estimation -- Signature validation - -## Key Components - -### Modules - -The account supports various types of modules: - -- Validation modules -- Execution modules -- Fallback modules -- Hook modules - -These modules can be installed, uninstalled, and queried, allowing for a flexible and extensible account structure. - -### Bundler and Paymaster - -The class integrates with a bundler for submitting user operations and a paymaster for gas abstraction, enhancing the user experience by potentially allowing gasless transactions. - -### User Operations - -The class provides methods for building, signing, and sending user operations, which are the core concept of ERC-4337 for account abstraction. - -## Main Methods - -Some of the key methods include: - -- `create`: Static method to create a new NexusSmartAccount instance -- `getAddress`: Retrieves the account's address -- `sendTransaction`: Sends a transaction (or batch of transactions) -- `buildUserOp`: Builds a user operation -- `sendUserOp`: Sends a user operation -- `installModule`: Installs a module on the account -- `uninstallModule`: Uninstalls a module from the account -- `getBalances`: Retrieves token balances for the account -- `signMessage`: Signs a message using the account - -## Usage - -The `NexusSmartAccount` is designed to be used as part of a larger system for managing smart contract accounts. It provides a high level of flexibility and functionality, allowing developers to create sophisticated account-based applications. - -To use this class, you would typically: - -1. Create an instance using the static `create` method -2. Use the instance to perform actions like sending transactions, managing modules, or interacting with the blockchain - -## Advanced Features - -The class also includes advanced features such as: - -- Counterfactual address calculation -- ERC-6492 compliant signature generation -- Gas estimation for user operations -- Token fee estimation and management -- Support for various execution modes \ No newline at end of file diff --git a/docs/pages/smartAccountsV2/FAQ.md b/docs/pages/smartAccountsV2/FAQ.md index 833c1d2..83e8631 100644 --- a/docs/pages/smartAccountsV2/FAQ.md +++ b/docs/pages/smartAccountsV2/FAQ.md @@ -76,7 +76,7 @@ Here is a tutorial on how to send parallel user ops with the Biconomy SDK: https **Is the bundler URL the same for all chains?** -Yes, for testnets same [bundler URL](/dashboard#bundler-url) can be used, just change the chainId. For mainnet you can reach out to [us](https://t.me/pitonivan). +Yes, for testnets same bundler URL can be used, just change the chainId. For mainnet you can reach out to [us](https://t.me/pitonivan). **How can I sign the userOp manually?** @@ -100,4 +100,4 @@ You can programmatically deposit funds using the paymasterContract `depositFor` **Are there APIs to create my own dashboard?** -Yes, you can utilize the [dashboard APIs](/dashboard/apis) to create a paymaster, change policies, and even get the transaction's data. \ No newline at end of file +Yes, you can utilize the dashboard APIs to create a paymaster, change policies, and even get the transaction's data. \ No newline at end of file diff --git a/docs/pages/smartAccountsV2/account/integration.mdx b/docs/pages/smartAccountsV2/account/integration.mdx index 7b9b34f..7593bd6 100644 --- a/docs/pages/smartAccountsV2/account/integration.mdx +++ b/docs/pages/smartAccountsV2/account/integration.mdx @@ -7,7 +7,6 @@ custom_edit_url: https://github.com/bcnmy/docs/blob/master/docs/account/integrat Smart Accounts are created deterministically using the [CREATE2](https://docs.openzeppelin.com/cli/2.7/deploying-with-create2) opcode, meaning the smart account address can be identified even before it is deployed. It will also maintain the same address across different chains. -To integrate a `Biconomy Smart Account`, you'll need the [bundler url](/dashboard#bundler-url). If you also want to use the paymaster, you'll need [Paymaster api key](/smartAccountsV2/paymaster). ## Installation diff --git a/docs/pages/smartAccountsV2/account/signers/dynamic.md b/docs/pages/smartAccountsV2/account/signers/dynamic.md index 589020a..99db3ea 100644 --- a/docs/pages/smartAccountsV2/account/signers/dynamic.md +++ b/docs/pages/smartAccountsV2/account/signers/dynamic.md @@ -67,7 +67,7 @@ const embeddedWallet = userWallets.find( ## 3. Configure your Biconomy bundler and paymaster -Go to the [Biconomy Dashboard](https://dashboard.biconomy.io/) and configure a Paymaster and a Bundler for your app. Make sure these correspond to the desired network for your user's smart accounts. You can learn more about the dashboard [here](/dashboard) +Go to the Biconomy Dashboard and configure a Paymaster and a Bundler for your app. Make sure these correspond to the desired network for your user's smart accounts. ## 4. Create the smart account diff --git a/docs/pages/smartAccountsV2/account/signers/privy.md b/docs/pages/smartAccountsV2/account/signers/privy.md index 6ca3ee0..99e85e3 100644 --- a/docs/pages/smartAccountsV2/account/signers/privy.md +++ b/docs/pages/smartAccountsV2/account/signers/privy.md @@ -58,7 +58,7 @@ Your PrivyProvider should then look like: ## 3. Configure your Biconomy bundler and paymaster -Go to the [Biconomy Dashboard](https://dashboard.biconomy.io/) and configure a Paymaster and a Bundler for your app. Make sure these correspond to the desired network for your user's smart accounts. You can learn more about the dashboard [here](/dashboard) +Go to the [Biconomy Dashboard](https://dashboard.biconomy.io/) and configure a Paymaster and a Bundler for your app. Make sure these correspond to the desired network for your user's smart accounts. ## 4. Initialize your users' smart accounts diff --git a/docs/pages/smartAccountsV2/bundler/index.mdx b/docs/pages/smartAccountsV2/bundler/index.mdx index 036ff24..a8c540b 100644 --- a/docs/pages/smartAccountsV2/bundler/index.mdx +++ b/docs/pages/smartAccountsV2/bundler/index.mdx @@ -4,7 +4,7 @@ The Bundler is a service that tracks userOps that exist in an alternative mem po This is the final piece of the flow where after constructing your `userOp` and then potentially signing it with data from a paymaster, you send the `userOp` on-chain to be handled and executed as a transaction on the EVM. You can start using our Bundlers right now in your dApps; each of our [tutorials](/smartAccountsV2/tutorials) will walk you through how to use them in different scenarios. -You can get the Bundler URL from [here](/dashboard#bundler-url). In short, the Bundler is responsible for the following: +In short, the Bundler is responsible for the following: - Aggregating userOps in an alternative `mempool` to normal Ethereum Transactions - Submitting to the Network: Bundlers EOA will send the `userOp` to the Entry Point Contract as a transaction diff --git a/docs/pages/smartAccountsV2/bundler/integration.mdx b/docs/pages/smartAccountsV2/bundler/integration.mdx index 5112529..439496d 100644 --- a/docs/pages/smartAccountsV2/bundler/integration.mdx +++ b/docs/pages/smartAccountsV2/bundler/integration.mdx @@ -17,11 +17,6 @@ npm install @biconomy/account ## Integration -:::info - -[Click here](/dashboard) to learn more about our dashboard and how to get your own bundler url. -::: - To create a bundler instance pass the bundler url, with other optional params. ```typescript diff --git a/docs/pages/smartAccountsV2/overview.md b/docs/pages/smartAccountsV2/overview.md index 1a9418d..6f99919 100644 --- a/docs/pages/smartAccountsV2/overview.md +++ b/docs/pages/smartAccountsV2/overview.md @@ -68,13 +68,13 @@ For the mainnet bundler URL, reach out to us via email at ```bd@biconomy.io``` o If you are looking to integrate account abstraction using APIs, checkout the [bundler APIs](/smartAccountsV2/bundler/api/) and [tutorials](/smartAccountsV2/tutorials/apiIntegration/). -## [Paymaster](/smartAccountsV2/paymaster) +## Paymaster -Biconomy's paymaster service enables Dapps to sponsor transactions and, also allows users to use ERC-20 tokens as payment for gas. Log in to the [Biconomy dashboard](/dashboard) to get the paymaster URL and switch modes between our sponsorship and token Paymaster. Make use of different [Spending limits](/dashboard/spendingLimits) to customize the paymaster usage. +Biconomy's paymaster service enables Dapps to sponsor transactions and, also allows users to use ERC-20 tokens as payment for gas. Log in to the Biconomy dashboard to get the paymaster URL and switch modes between our sponsorship and token Paymaster. Make use of different spending limits to customize the paymaster usage. ### Sponsorship Paymaster -Enabling the Sponsored mode facilitates gasless transactions, eliminating the necessity for users to have native tokens to cover gas fees. Learn how to set up your paymaster [here](/dashboard/paymaster). +Enabling the Sponsored mode facilitates gasless transactions, eliminating the necessity for users to have native tokens to cover gas fees. ### Token Paymaster diff --git a/docs/pages/smartAccountsV2/paymaster/index.mdx b/docs/pages/smartAccountsV2/paymaster/index.mdx index c5a0577..bb910e4 100644 --- a/docs/pages/smartAccountsV2/paymaster/index.mdx +++ b/docs/pages/smartAccountsV2/paymaster/index.mdx @@ -6,7 +6,7 @@ With Biconomy's Paymaster service, you can manage gas fees for your users effort **Revenue sharing**: on a case-by-case basis depending on volumes, we do offer a split of the Paymaster fee revenue with selected Apps. to learn more. -To use it, you must [set up the paymaster](/dashboard/paymaster) on the dashboard and obtain the paymasterURL. Biconomy paymaster supports two modes: +Biconomy paymaster supports two modes: ## Sponsorship Paymaster diff --git a/docs/pages/smartAccountsV2/paymaster/integration.mdx b/docs/pages/smartAccountsV2/paymaster/integration.mdx index 0387079..7215ad6 100644 --- a/docs/pages/smartAccountsV2/paymaster/integration.mdx +++ b/docs/pages/smartAccountsV2/paymaster/integration.mdx @@ -17,11 +17,7 @@ npm install @biconomy/account ## Integration Set up a paymaster for the smart account by providing only the paymaster API key. The default mode used is `Sponsored` mode in this case. -:::info -[Click here](/dashboard/paymaster) to learn more about our dashboard and how to get your Paymaster api key. - -::: ```typescript import { createSmartAccountClient } from "@biconomy/account"; diff --git a/docs/pages/smartAccountsV2/tutorials/apiIntegration/paymasterERC20.md b/docs/pages/smartAccountsV2/tutorials/apiIntegration/paymasterERC20.md index c6ab671..8aebd1e 100644 --- a/docs/pages/smartAccountsV2/tutorials/apiIntegration/paymasterERC20.md +++ b/docs/pages/smartAccountsV2/tutorials/apiIntegration/paymasterERC20.md @@ -8,7 +8,7 @@ This tutorial represents the API integration flow where ERC20 tokens in smart wa ## Pre-requisites: -- Biconomy bundler url (refer to the [docs](/dashboard#bundler-keys) to get the same) +- Biconomy bundler url - Partial user operation, where - sender is the smart account Address - nonce can be calculated using the smart account contract methods diff --git a/docs/pages/smartAccountsV2/tutorials/apiIntegration/paymasterSponsored.md b/docs/pages/smartAccountsV2/tutorials/apiIntegration/paymasterSponsored.md index 622f78e..277461b 100644 --- a/docs/pages/smartAccountsV2/tutorials/apiIntegration/paymasterSponsored.md +++ b/docs/pages/smartAccountsV2/tutorials/apiIntegration/paymasterSponsored.md @@ -8,7 +8,7 @@ This tutorial represents the API integration flow where paymaster is used to spo ## Pre-requisites: -- Biconomy bundler url (refer to the [docs](/dashboard#bundler-keys) to get the same) +- Biconomy bundler url - Partial user operation, where - sender is the smart account Address - nonce can be calculated using the smart account contract methods diff --git a/docs/pages/smartAccountsV2/tutorials/apiIntegration/userSponsored.md b/docs/pages/smartAccountsV2/tutorials/apiIntegration/userSponsored.md index 819d05c..e7b655d 100644 --- a/docs/pages/smartAccountsV2/tutorials/apiIntegration/userSponsored.md +++ b/docs/pages/smartAccountsV2/tutorials/apiIntegration/userSponsored.md @@ -8,7 +8,7 @@ This tutorial represents the API integration flow where smart contract wallet ha ## Pre-requisites: -- Biconomy bundler url (refer to the [docs](/dashboard#bundler-keys) to get the same) +- Biconomy bundler url - Partial user operation, where - sender is the smart account Address - nonce can be calculated using the smart account contract methods. diff --git a/docs/pages/smarteoa/index.mdx b/docs/pages/smarteoa/index.mdx index 00a622e..7756361 100644 --- a/docs/pages/smarteoa/index.mdx +++ b/docs/pages/smarteoa/index.mdx @@ -69,5 +69,4 @@ explicitly depositing to the Companion Account. Certain types of wallets allow users to delegate directly to a Biconomy Nexus account. When working with those wallets, developers don't need to use Companion Accounts. For now, this mostly applies to embedded wallets such as Privy, Dynamic, etc... -Check out [this guide](/eip7702/wallet-guide) to learn how to use direct delegation. diff --git a/docs/pages/tutorials/batch.mdx b/docs/pages/tutorials/batch.mdx deleted file mode 100644 index f13d342..0000000 --- a/docs/pages/tutorials/batch.mdx +++ /dev/null @@ -1,97 +0,0 @@ -## Sending Batch Transactions with SDK ⚡️ - -Account abstraction enables the bundling of multiple transactions into a single transaction. This can be useful in various scenarios, such as executing multiple trades at once on a decentralized exchange or making batch payments. For instance, you can deploy an NFT contract, mint an NFT, and transfer it, all with a single user action and transaction. - -We have created a quick start [template](https://github.com/bcnmy/examples/tree/main) repository that you can use to get started. It comes set up with TypeScript, `viem`, and `@biconomy/abstractjs`. - - - - - -::::steps - -### Set up an owner account -First, we need to set up an Owner for the Smart Account which will be used to sign User Operations (transactions) for the Smart Account. - -```typescript -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); -``` - -### Set up Nexus client - -A Smart Account needs access to the Network to query for information about its state (e.g., nonce, address, etc.). Let's configure a client for the Smart Account. A `bundlerUrl` is required to submit User Operations to the Network, which will initialize the Smart Account. - -```typescript -import { createBicoBundlerClient, createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; // [!code focus:12] -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster: createBicoPaymasterClient({paymasterUrl}) -}); -``` - -### Send batch transactions - -Next, define the transactions you want to send in a batch. Each transaction should specify the necessary parameters. Use the `sendTransaction` method to send the batch of transactions. - -```typescript -import { createBicoBundlerClient, createBicoPaymasterClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster: createBicoPaymasterClient({paymasterUrl}) -}); - -const hash = await nexusClient.sendUserOperation({ // [!code focus:11] - calls: [ - { - to: '0xf5715961C550FC497832063a98eA34673ad7C816', - value: parseEther('0'), - }, - { - to: '0x0000000000000000000000000000000000000000', - data: "0x", - }, - ], -}); -const receipt = await nexusClient.waitForUserOperationReceipt({ hash }); // [!code focus] -``` -:::: - - -You have successfully sent batch transactions using the SDK. For more advanced features and options, refer to the official documentation. - -[See sendTransaction Docs](/sdk-reference/bundler-client) - - diff --git a/docs/pages/tutorials/gasless.mdx b/docs/pages/tutorials/gasless.mdx deleted file mode 100644 index 6ebe9b2..0000000 --- a/docs/pages/tutorials/gasless.mdx +++ /dev/null @@ -1,84 +0,0 @@ -## Sending Gasless Transactions with SDK ⚡️ - -Gasless transactions enable users to interact with the blockchain without paying for gas fees. This is achieved through the use of a paymaster, which sponsors the transaction fees on behalf of the user. In this tutorial, we will guide you through the process of sending gasless transactions using the SDK. - - - - - - -::::steps - -### Set up an owner account -First, we need to set up an Owner for the Smart Account which will be used to sign User Operations (transactions) for the Smart Account. - -```typescript -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); -``` - -### Set up Nexus client with paymaster -Login to the [Dashboard](https://dashboard.biconomy.io/) and setup a v2 paymaster. Let's configure a client for the Smart Account with a `paymasterUrl` to enable gasless transactions. A `bundlerUrl` is required to submit transactions to the Network, which will initialize the Smart Account. - -```typescript -import { createBicoBundlerClient, createBicoPaymasterClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; // [!code focus:8] - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster: createBicoPaymasterClient({paymasterUrl}) -}); -``` - -### Send gasless transaction -Next, define the transaction you want to send. Use the `sendTransaction` method to send the transaction. Since we have a paymaster configured, this transaction will be gasless. - -```typescript - -import { createBicoBundlerClient, createBicoPaymasterClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster: createBicoPaymasterClient({paymasterUrl}) -}); // [!code focus:7] - -const hash = await nexusClient.sendUserOperation({ calls: - [{to : '0xf5715961C550FC497832063a98eA34673ad7C816', value: parseEther('0')}] }, -); -console.log("Transaction hash: ", hash) -const receipt = await nexusClient.waitForUserOperationReceipt({ hash }); - -``` - -By following these steps, you have successfully sent a gasless transaction using the SDK. For more advanced features and options, refer to the official documentation. - -[See sendTransaction Docs](/sdk-reference/bundler-client) diff --git a/docs/pages/tutorials/getQuotes.md b/docs/pages/tutorials/getQuotes.md deleted file mode 100644 index 8f74395..0000000 --- a/docs/pages/tutorials/getQuotes.md +++ /dev/null @@ -1,177 +0,0 @@ -## Getting Fee Quotes from the Token Paymaster with SDK ⚡️ - -Users need to know the fee amount before they can send a transaction. In this tutorial, we will guide you through the process of getting a fee quote from the Token Paymaster for USDC. -We will also show how to enforce a custom approval amount equal to the fee amount for a transaction, instead of asking the user for a max approval amount. - -::::steps - -### Set up an owner account -First, we need to set up an Owner for the Smart Account which will be used to sign User Operations (transactions) for the Smart Account. - -```typescript -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); -``` - -### Set up Nexus client with paymaster -Login to the [Dashboard](https://dashboard.biconomy.io/) and setup a v2 paymaster. Let's configure a client for the Smart Account with a `paymasterUrl` to enable it. A `bundlerUrl` is required to submit transactions to the Network, which will initialize the Smart Account. - -```typescript -import { createBicoBundlerClient, createBicoPaymasterClient, toBiconomyTokenPaymasterContext, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; // [!code focus:16] -const baseSepoliaUSDC = "0x036cbd53842c5426634e7929541ec2318f3dcf7e"; - -const paymasterContext = toBiconomyTokenPaymasterContext({ - feeTokenAddress: baseSepoliaUSDC -}) - -const paymaster = createBicoPaymasterClient({ - transport: http(paymasterUrl) -}) - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster, - paymasterContext -}); -``` - -### Calculating the USDC fee amount and enforcing a custom approval amount -Next, we will prepare the user operation that we want to send using `prepareUserOperation` and get a fee quote for USDC from the Token Paymaster using `getTokenPaymasterQuotes`. -We will use the `maxGasFee` and `decimal` from the quote to calculate the fee amount in USDC and parse it using `parseUnits`. - -```typescript - -import { createBicoBundlerClient, createBicoPaymasterClient, toBiconomyTokenPaymasterContext, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther, parseUnits } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; -const baseSepoliaUSDC = "0x036cbd53842c5426634e7929541ec2318f3dcf7e"; -const recipientAddress = "0x0000000000000000000000000000000000000000"; - -const paymaster = createBicoPaymasterClient({ - transport: http(paymasterUrl) -}) - -const paymasterContext = toBiconomyTokenPaymasterContext({ - feeTokenAddress: baseSepoliaUSDC -}) - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster, - paymasterContext -}); // [!code focus:7] - -const userOp = await nexusClient.prepareUserOperation({ - calls: [ - { - to: recipientAddress, - value: 1n, - chain: baseSepolia - } - ] -}) -const quote = await paymaster.getTokenPaymasterQuotes({ userOp, tokenList:[baseSepoliaUSDC] }) -const usdcFeeAmount = parseUnits( - quote.feeQuotes[0].maxGasFee.toString(), - quote.feeQuotes[0].decimal -) -``` - -### Sending a transaction and paying the gas with USDC -```typescript -import { createBicoBundlerClient, createBicoPaymasterClient, toBiconomyTokenPaymasterContext, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther, parseUnits } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; -const baseSepoliaUSDC = "0x036cbd53842c5426634e7929541ec2318f3dcf7e"; -const recipientAddress = "0x0000000000000000000000000000000000000000"; - -const paymaster = createBicoPaymasterClient({ - transport: http(paymasterUrl) -}) - -const paymasterContext = toBiconomyTokenPaymasterContext({ - feeTokenAddress: baseSepoliaUSDC -}) - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster, - paymasterContext -}); // [!code focus:7] - -const userOp = await nexusClient.prepareUserOperation({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x", - } - ] -}) -const quote = await paymaster.getTokenPaymasterQuotes({ userOp, tokenList:[baseSepoliaUSDC] }) -const usdcFeeAmount = parseUnits( - quote.feeQuotes[0].maxGasFee.toString(), - quote.feeQuotes[0].decimal -) - -const userOpHash = await nexusClient.sendTokenPaymasterUserOp({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x" - } - ], - feeTokenAddress: baseSepoliaUSDC, - customApprovalAmount: usdcFeeAmount -}) -const receipt = await nexusClient.waitForUserOperationReceipt({ - hash: userOpHash -}) -``` - -For a complete list of supported ERC20 tokens that can be used for gas payment, check out our [supported tokens documentation](/contractsAndAudits#token-paymaster-supported-tokens). - -By following these steps, you have successfully calculated the USDC fee amount and enforced a custom approval amount for a transaction using the SDK. For more advanced features and options, refer to the official documentation. - -[See sendTransaction Docs](/sdk-reference/bundler-client/methods/sendUserOperation) diff --git a/docs/pages/tutorials/index.md b/docs/pages/tutorials/index.md deleted file mode 100644 index e69de29..0000000 diff --git a/docs/pages/tutorials/passKey.md b/docs/pages/tutorials/passKey.md deleted file mode 100644 index a0db2d9..0000000 --- a/docs/pages/tutorials/passKey.md +++ /dev/null @@ -1,219 +0,0 @@ -# Biconomy Passkey SDK Integration Guide - -## Why use Passkeys? - -Developers can leverage Passkeys to enable their users to sign transactions and log in with FaceID or Fingerprints. This -reduces a major point of friction when interacting with blockchain as it enables users to store their private key within -the Hardware Secure enclave provided by computer and smartphone manufacturers such as Apple. - -::::tip[🪄 Passkey Benefits] - -- No apps can access the private key within the Secure Enclave, they can only request signatures -- Users can store their Passkeys on a secure cloud such as iCloud -- Users don't have to remember seed phrases -- Onboarding users is instant -- Signing transactions is much safer than using pure passwords, like in browser extension wallets - :::: - -This guide demonstrates how to integrate the Biconomy SDK with passkey authentication in a client-side application. - -:::danger[🚨 Important] -Passkey functionality only works in client-side applications (browsers) as it requires access to the WebAuthn API. It cannot be implemented in backend services. -:::: - -::::steps - -#### Setup Environment Variables - -Create a `.env` file with your Biconomy configuration: - -``` -NEXT_PUBLIC_BUNDLER_URL=your_bundler_url -NEXT_PUBLIC_PAYMASTER_URL=your_paymaster_url -``` - -#### Create Nexus Client - -```typescript " -import { createBicoBundlerClient, createBicoPaymasterClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "wagmi/chains"; -import { http, useAccount, useWalletClient } from "wagmi"; - -const account = useAccount(); -const { data: walletClient } = useWalletClient({ account: account.address }); - -async function initNexusClient() { - if (walletClient) { - const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: walletClient, - chain: baseSepolia, // or your preferred chain - transport: http(), - }), - paymaster: createBicoPaymasterClient({ - paymasterUrl: process.env.NEXT_PUBLIC_PAYMASTER_URL || "", - }), - transport: http(process.env.NEXT_PUBLIC_BUNDLER_URL), - }); - - return nexusClient; - } - throw new Error("Wallet client not found"); -} -``` - -#### Register a New Passkey - -```typescript -import { - toWebAuthnKey, - toPasskeyValidator, - WebAuthnMode, -} from "@biconomy/passkey"; -import { NexusClient } from "@biconomy/abstractjs"; - -async function registerPasskey(nexusClient: NexusClient, passkeyName: string) { - // Create WebAuthn key - // Ideally "passkeyName" would be set by the user in the UI - const webAuthnKey = await toWebAuthnKey({ - passkeyName: passkeyName, - mode: WebAuthnMode.Register, - }); - - // Create passkey validator - const passkeyValidator = await toPasskeyValidator({ - account: nexusClient.account, - webAuthnKey, - }); - - // Store webAuthnKey for future use - const formattedWebAuthnKey = { - pubX: webAuthnKey.pubX.toString(), - pubY: webAuthnKey.pubY.toString(), - authenticatorId: webAuthnKey.authenticatorId, - authenticatorIdHash: webAuthnKey.authenticatorIdHash, - }; - localStorage.setItem("webAuthnKey", JSON.stringify(formattedWebAuthnKey)); - - return passkeyValidator; -} -``` - -#### Login with Existing Passkey - -```typescript -import { NexusClient } from "@biconomy/abstractjs"; -import { - toWebAuthnKey, - WebAuthnMode, - toPasskeyValidator, -} from "@biconomy/passkey"; - -async function loginPasskey(nexusClient: NexusClient) { - const webAuthnKey = await toWebAuthnKey({ - mode: WebAuthnMode.Login, - }); - - const passkeyValidator = await toPasskeyValidator({ - account: nexusClient.account, - webAuthnKey, - }); - - return passkeyValidator; -} -``` - -#### Install Passkey Validator Module - -```typescript -import type { NexusClient, Module } from "@biconomy/abstractjs"; - -async function installPasskeyValidator( - nexusClient: NexusClient, - passkeyValidator: Module -) { - const passkeyValidatorAddress = "0xD990393C670dCcE8b4d8F858FB98c9912dBFAa06"; - const userOpHash = await nexusClient?.installModule({ - module: { - address: passkeyValidatorAddress, - type: "validator", - initData: passkeyValidator?.initData, - }, - }); - - // Wait for transaction to be confirmed - await nexusClient?.waitForUserOperationReceipt({ hash: userOpHash }); -} -``` - -#### Using Passkey for Transactions - -```typescript -import { - createBicoBundlerClient, - createBicoPaymasterClient, - type Module, - type NexusClient, - moduleActivator, -} from "@biconomy/abstractjs"; -import { baseSepolia } from "wagmi/chains"; -import { http, useAccount, useWalletClient } from "wagmi"; -import type { Address } from "viem"; - -const account = useAccount(); -const { data: walletClient } = useWalletClient({ account: account.address }); - -async function sendTransactionWithPasskey( - nexusClient: NexusClient, - passkeyValidator: Module, - recipientAddress: Address -) { - // Extend NexusClient with passkey validator - nexusClient.extend(moduleActivator(passkeyValidator)); - // Send transaction - const hash = await nexusClient.sendUserOperation({ - calls: [ - { - to: recipientAddress, - value: BigInt(0), // or your desired value - }, - ], - }); - - // Wait for confirmation - const receipt = await nexusClient.waitForUserOperationReceipt({ hash }); - return receipt; -} -``` - -#### Uninstall Passkey Validator (Optional) - -```typescript -import { - type NexusClient, - type Module, - createBicoBundlerClient, - moduleActivator, -} from "@biconomy/abstractjs"; - -async function uninstallPasskeyValidator( - nexusClient: NexusClient, - passkeyValidator: Module -) { - nexusClient.extend(moduleActivator(passkeyValidator)); - const userOpHash = await nexusClient?.uninstallModule({ - module: { - address: passkeyValidator.address, - type: "validator", - deInitData: "0x", - }, - }); - - await nexusClient?.waitForUserOperationReceipt({ hash: userOpHash }); - - // Clear stored passkey data - localStorage.removeItem("webAuthnKey"); -} -``` - -:::: diff --git a/docs/pages/tutorials/quickstart.mdx b/docs/pages/tutorials/quickstart.mdx deleted file mode 100644 index 8a1d36b..0000000 --- a/docs/pages/tutorials/quickstart.mdx +++ /dev/null @@ -1,28 +0,0 @@ - - -## Installation - -:::code-group - -```bash [npm] -npm i @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.3 -``` - -```bash [pnpm] -pnpm i @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.3 -``` - -```bash [bun] -bun add @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.3 -``` - -::: - -We have created quickstart templates for different environments that you can use to get started: - -- [Bun Quickstart](https://github.com/bcnmy/examples/tree/main/bun-quickstart) - A minimal template using Bun runtime -- [Next.js Quickstart](https://github.com/bcnmy/examples/tree/main/nextjs-quickstart) - A template using Next.js framework -- [Vite Quickstart](https://github.com/bcnmy/examples/tree/main/vite-quickstart) - A template using Vite + React - -Each template comes pre-configured with TypeScript, `viem`, and `@biconomy/abstractjs` and `@rhinestone/module-sdk` at version `0.2.3`. - diff --git a/docs/pages/tutorials/signers/capsule.mdx b/docs/pages/tutorials/signers/capsule.mdx deleted file mode 100644 index 4bb39a2..0000000 --- a/docs/pages/tutorials/signers/capsule.mdx +++ /dev/null @@ -1,66 +0,0 @@ -# How to use a Capsule signer with Biconomy - -[Capsule](https://www.usecapsule.com/) is a signing solution that you can use to create secure, embedded MPC wallets with just an email or a social login. Capsule wallets are portable across applications, recoverable, and programmable, so your users do not need to create different signers or contract accounts for every application they use. - -Read below to learn how to configure your app to create smart accounts for all your users using Capsule and Biconomy. This guide assumes you are using React or a React based web framework such as Next JS. For Capsule guides in other frameworks, check out the Capsule developer docs or get in touch via hello@usecapsule.com. - -::::steps - -### Install the dependencies - -```bash -npm i @usecapsule/web-sdk @usecapsule/viem-v2-integration @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -### Create the Capsule owner - -You will need to do some initial setup and get API keys from capsule, for additional help check out the [Capsule Starter Guide](https://docs.usecapsule.com/getting-started/initial-setup/web-modal-and-sdk-setup). - -```ts -import { http } from "viem"; -import { baseSepolia, optimism, base, polygon } from "viem/chains"; -import Capsule, { Environment } from "@usecapsule/web-sdk"; -import { createCapsuleViemClient } from "@usecapsule/viem-v2-integration"; -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; - -// Param options here will be specific to your project. See the Capsule docs for more info. -const capsule = new Capsule(Environment.BETA, ""); - -// Follow the Capsule docs for more instructions on creating the Viem client https://docs.usecapsule.com/integration-guide/signing-transactions -const smartAccountOwner = createCapsuleViemClient(capsule, { - chain: baseSepolia, - transport: http("https://sepolia.base.org"), -}) -``` - -### Create the MeeClient - -Create the multichain MEE client using the Capsule signer client. - -```ts -import { http } from "viem"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import Capsule, { Environment } from "@usecapsule/web-sdk"; -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { createCapsuleViemClient } from "@usecapsule/viem-v2-integration" - -const capsule = new Capsule(Environment.BETA, "YOUR_API_KEY"); - -// Follow the Capsule docs for more instructions on creating the Viem client https://docs.usecapsule.com/integration-guide/signing-transactions -const smartAccountOwner = createCapsuleViemClient(capsule, { - chain: baseSepolia, - transport: http("https://sepolia.base.org"), -}) - -// Create a multichain smart account -const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: smartAccountOwner - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use -}) -``` - -:::: \ No newline at end of file diff --git a/docs/pages/tutorials/signers/dfns.mdx b/docs/pages/tutorials/signers/dfns.mdx deleted file mode 100644 index e1241e4..0000000 --- a/docs/pages/tutorials/signers/dfns.mdx +++ /dev/null @@ -1,83 +0,0 @@ -## How to use DFNS signer with Biconomy smart accounts - -[Dfns](https://www.dfns.co/) is an MPC/TSS Wallet-as-a-Service API/SDK provider. Dfns aims to optimize the balance of security and UX by deploying key shares into a decentralized network on the backend while enabling wallet access via biometric open standards on the frontend like Webauthn. Reach out here to set up a sandbox environment to get started. - -Before using the code in this guide you will need to onboard onto DFNS, check out their onboarding guide [here](https://docs.dfns.co/dfns-docs/getting-started/gettingstarted). - -The first thing we need to do is generate a DFNS wallet. Let's take a look at the imports and then the code for generating the wallet. - -::::steps - -### Install the dependencies - -```bash -npm i @dfns/sdk @dfns/sdk-keysigner @dfns/lib-viem @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -### Setup DFNS - -Remember to get your API keys from the DFNS dashboard and follow their [getting started](https://docs.dfns.co/dfns-docs/getting-started/gettingstarted) guides for this part of the process. -```ts -import { DfnsWallet } from "@dfns/lib-viem" -import { DfnsApiClient } from "@dfns/sdk" -import { AsymmetricKeySigner } from "@dfns/sdk-keysigner" -import { AccountSource, createWalletClient, http } from "viem" -import { toAccount } from "viem/accounts" - -const initDfnsWallet = (walletId: string) => { - const signer = new AsymmetricKeySigner({ - privateKey: DFNS_PRIVATE_KEY, - credId: DFNS_CRED_ID, - appOrigin: DFNS_APP_ORIGIN, - }) - - const dfnsClient = new DfnsApiClient({ - appId: DFNS_APP_ID, - authToken: DFNS_AUTH_TOKEN, - baseUrl: DFNS_API_URL, - signer, - }) - - return DfnsWallet.init({ - walletId, - dfnsClient, - maxRetries: 10, - }) -} - -const sepoliaWallet = await initDfnsWallet(SEPOLIA_WALLET_ID) -const account = toAccount(sepoliaWallet as AccountSource) -const smartAccountOwner = createWalletClient({ - account, - transport: http("https://rpc.ankr.com/eth_sepolia"), -}) -``` - -### Create the MeeClient - -Create the multichain MEE client using the DFNS signer client. - -```ts -import { DfnsWallet } from "@dfns/lib-viem" -import { DfnsApiClient } from "@dfns/sdk" -import { AsymmetricKeySigner } from "@dfns/sdk-keysigner" -import { AccountSource, createWalletClient, http } from "viem" -import { toAccount } from "viem/accounts" -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains" -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; - -// Create a multichain MEE client -const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: smartAccountOwner - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use -}); - -// Now you can execute cross-chain transactions -console.log("MEE Client ready for cross-chain operations with address:", meeClient.account.address); -``` - -:::: \ No newline at end of file diff --git a/docs/pages/tutorials/signers/dynamic.mdx b/docs/pages/tutorials/signers/dynamic.mdx deleted file mode 100644 index e7f3253..0000000 --- a/docs/pages/tutorials/signers/dynamic.mdx +++ /dev/null @@ -1,74 +0,0 @@ -# How to use a Dynamic signer with Biconomy - -Dynamic.xyz is a web3 login solution for everyone, offering straightforward onboarding and embedded wallet options for newcomers and elegant and smart login flows for crypto-native users. We aim to abstract away the complexities of user management, offering powerful developer tools around authentication, authorization and onboarding. - -::::steps - -### Install the dependencies - -```bash -npm i @dynamic-labs/sdk-react-core @dynamic-labs/wagmi-connector @dynamic-labs/ethereum @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 wagmi -``` - -### Create the Dynamic provider - -Following Dynamic's [quickstart guide](https://docs.dynamic.xyz/quickstart), set up the Dynamic provider in your app. Also integrate the DynamicWagmiConnector, which will allow you to use Dynamic as a signer. - -```ts -import { DynamicContextProvider, DynamicWidget } from "@dynamic-labs/sdk-react-core"; -import { DynamicWagmiConnector } from "@dynamic-labs/wagmi-connector"; -import { EthereumWalletConnectors } from "@dynamic-labs/ethereum"; - -export const App = () => { - return ( - - - - - - ); -}; -``` - -### Create the MeeClient - -Create the multichain MEE client using the Dynamic signer. -Note: Inside any component which is wrapped by DynamicContextProvider, you can access any of [the provided hooks](https://docs.dynamic.xyz/react-sdk/hooks/hooks-introduction). While you can access the full context via usedynamiccontext, we are most interested in the users currently connected wallets which we can easily access via useuserwallets. - -```ts -import { http } from "viem"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { useUserWallets } from "@dynamic-labs/sdk-react-core"; -import { useWalletClient } from "wagmi"; - -const { - data: walletClient -} = useWalletClient() - -const smartAccountOwner = createWalletClient({ - account: walletClient?.account, - transport: http("https://sepolia.base.org"), -}) - -// Create a multichain MEE client -const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: smartAccountOwner - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use -}); - -// Now you can execute cross-chain transactions -console.log("MEE Client ready for cross-chain operations with address:", meeClient.account.address); -``` - -:::: \ No newline at end of file diff --git a/docs/pages/tutorials/signers/magic.mdx b/docs/pages/tutorials/signers/magic.mdx deleted file mode 100644 index deee8ae..0000000 --- a/docs/pages/tutorials/signers/magic.mdx +++ /dev/null @@ -1,63 +0,0 @@ -## How to use Magic signer with Biconomy smart accounts - -[Magic](https://magic.link/) makes it easy to authenticate users and integrate them into your Web3 dApps quickly. -By integrating Magic with the Biconomy SDK, you can pair Magic's seamless social login experience with smart wallets powered by Nexus accounts. This enables features like gas sponsorship, transaction batching, and more, ensuring a frictionless experience for your users. - -## Integration - -::::steps - -### Install the dependencies - -```bash -npm i @magic-ext/oauth magic-sdk @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -### Create the `Magic object` -After following the Magic documentation, you will have access to a MagicBase object as shown below that you can pass as an owner to createeSmartAccountClient: - -```typescript -import { OAuthExtension } from "@magic-ext/oauth" -import { Magic as MagicBase } from "magic-sdk" - -const magic = new MagicBase(process.env.MAGIC_API_KEY as string, { - network: { - rpcUrl: "https://sepolia.base.org", - chainId: 84532, - }, - extensions: [new OAuthExtension()], -}) - -// Get the Provider from Magic and convert it to a smartAccountOwner -const smartAccountOwner = await magic.wallet.getProvider() - -``` - -### Create the MeeClient - -Next, use the Magic account to initialize the Biconomy MeeClient for multichain transactions: - -```typescript -import { OAuthExtension } from "@magic-ext/oauth" -import { Magic as MagicBase } from "magic-sdk" -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import { http } from "viem"; - -const main = async () => { - // Create a multichain MEE client - const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: smartAccountOwner - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use - }); - - // You can now use meeClient to execute cross-chain transactions - console.log("MEE Client ready for cross-chain operations"); -} - -main(); -``` \ No newline at end of file diff --git a/docs/pages/tutorials/signers/particle.mdx b/docs/pages/tutorials/signers/particle.mdx deleted file mode 100644 index 1cdb0eb..0000000 --- a/docs/pages/tutorials/signers/particle.mdx +++ /dev/null @@ -1,86 +0,0 @@ -## How to use Particle signer with Biconomy smart accounts - -One way to utilize Social Logins is via [Particle Network](https://particle.network/). This section will give you code snippets for creating Biconomy Smart Accounts with Particle Network. Particle Network allows you to introduce familiar Web2 experiences, with the following code snippets you can unlock: authentication with email to create a smart account as well as authentication with different social providers to create a Smart Account. - -## Setup -To use Particle Network with Biconomy, first create an application that integrates with Particle Network. - -Refer to the [Particle Network documentation](https://docs.particle.network/) site for instructions on setting up an application with the Particle Network. -For a quick start, Particle Network provides a guide, available [here](https://docs.particle.network/getting-started/get-started). - -## Integration - -::::steps - -### Install the dependencies - -```bash -npm i @particle-network/auth @particle-network/provider @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -### Create the `ParticleNetwork` -Particle auth will require api keys which you can get from the [Particle Dashboard](https://docs.particle.network/getting-started/dashboard). - -```typescript -import { ParticleNetwork } from "@particle-network/auth" -import { ParticleProvider } from "@particle-network/provider" - -// Param options here will be specific to your project. See the Particle docs for more info. -const particle = new ParticleNetwork({ - projectId, - clientKey, - appId, - chainName, - chainId, -}) -const smartAccountOwner = new ParticleProvider(particle.auth) - -``` - -### Create the MeeClient - -Next, use the Particle Network account to initialize the Biconomy MeeClient for multichain transactions: - -```typescript -import { ParticleNetwork } from "@particle-network/auth" -import { ParticleProvider } from "@particle-network/provider" -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import { http } from "viem"; - -const main = async () => { - // Create a multichain MEE client - const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: smartAccountOwner - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use - }); - - // You can now execute cross-chain transactions with MEE - // For example: - const quote = await meeClient.getQuote({ - instructions: [ - { - calls: [{ to: "0xContract", value: 0n, data: "0xCalldata" }], - chainId: optimism.id - }, - { - calls: [{ to: "0xContract", value: 0n, data: "0xCalldata" }], - chainId: base.id - } - ], - feeToken: { - address: "0xTokenAddress", // Replace with your fee token address - chainId: optimism.id - } - }); - - const { hash } = await meeClient.executeQuote({ quote }); - console.log(`Transaction hash: ${hash}`); -} - -main(); -``` \ No newline at end of file diff --git a/docs/pages/tutorials/signers/passport.mdx b/docs/pages/tutorials/signers/passport.mdx deleted file mode 100644 index 02f2c42..0000000 --- a/docs/pages/tutorials/signers/passport.mdx +++ /dev/null @@ -1,136 +0,0 @@ -# How to use a Passport signer with Biconomy - -[Passport](https://docs.0xpass.io/) is an MPC-based programmable, distributed, and non-custodial key management system, that allows users to generate wallets, scoped to their application, either via user Passkeys or any developer defined authentication method. Our signer allows you to sign messages and transactions with a Passport Network account. - -::::steps - -### Install the dependencies - -```bash -npm i @0xpass/passport @0xpass/webauthn-signer @0xpass/passport-viem @0xpass/key-signer @biconomy/abstractjs viem -``` - -### Create the Passport signer - -To use Passport, you'll first need to make sure you have configured a scope for your application. For this you can follow the guides below: - -- Refer to the [Passport documentation](https://docs.0xpass.io/) for instructions on setting up your application with Passport. -- For a primer on setting up your scope you can check [here](https://docs.0xpass.io/authentication/configuring-your-scope). - -Passport offers a Passkey signer, which follows the webauthn standard, which is a user owned authentication method that allows users to sign messages and transactions with their Passkey. - -:::code-group - -```ts [Passkey Signer] -import { Passport, TESTNET_RSA_PUBLIC_KEY } from "@0xpass/passport"; -import { WebauthnSigner } from "@0xpass/webauthn-signer"; -import { KeySigner } from "@0xpass/key-signer"; -import { createPassportClient } from "@0xpass/passport-viem"; -import { http } from "viem"; -import { baseSepolia } from "viem/chains"; - -// The rpId and rpName are the same as the ones you set up in your passport application scope. They follow the webauthn standard, of the following values -// rpId: the domain of where the passkey is generated -// rpName: human readable name for the domain -// You can read more on this here https://docs.0xpass.io/authentication/configuring-your-scope#scope-configuration -const webauthnSigner = new WebAuthnSigner({ - rpId: "rpId", - rpName: "rpName", -}); - -const passport = new Passport({ - scope_id: "scope_id", // <-- Replace this with your scope id you get after configuring your scope by following the Passport documentation - signer: webauthnSigner, - enclave_public_key: TESTNET_RSA_PUBLIC_KEY, -}); - -const fallbackProvider = http("https://sepolia.base.org"); - -await passport.setupEncryption(); -// Only need to call this once to register the user passkey to your passport application scope -await passport.register({ - username: "test", - userDisplayName: "test", -}); - -const [authenticatedHeader] = await passport.authenticate({ - username: "test", - userDisplayName: "test", -}); - -const signer = await createPassportClient( - authenticatedHeader, - fallbackProvider, - baseSepolia, - "https://tiramisu.0xpass.io" -); - -``` - -```ts [Developer Owned Auth Signer] -import { Passport, TESTNET_RSA_PUBLIC_KEY } from "@0xpass/passport"; -import { WebauthnSigner } from "@0xpass/webauthn-signer"; -import { KeySigner } from "@0xpass/key-signer"; -import { createPassportClient } from "@0xpass/passport-viem"; -import { http } from "viem"; -import { baseSepolia } from "viem/chains"; - - -const keySigner = new KeySigner(process.env.PRIVATE_KEY, true); - -const passport = new Passport({ - scope_id: "scope_id" // <-- Replace this with your scope id you get after configuring your scope by following the Passport documentation, - signer: keySigner, - enclave_public_key: TESTNET_RSA_PUBLIC_KEY, -}); - -const fallbackProvider = http("https://sepolia.base.org"); - -await passport.setupEncryption(); -// Only need to call this once to register the user identifier you authenticate with to your passport application scope -await passport.delegatedRegisterAccount({ username: "test" }); - -passport.setUserData({ username: "test" }); - -const signer = await createPassportClient( - await passport.getDelegatedAuthenticatedHeaders(), - fallbackProvider, - baseSepolia, - "https://tiramisu.0xpass.io" -); - -``` -::: - -### Create the MeeClient - -Create the multichain MEE client using the Passport signer. - -```ts -import { Passport, TESTNET_RSA_PUBLIC_KEY } from "@0xpass/passport"; -import { WebauthnSigner } from "@0xpass/webauthn-signer"; -import { KeySigner } from "@0xpass/key-signer"; -import { createPassportClient } from "@0xpass/passport-viem"; -import { http } from "viem"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; - -const connect = async () => { - try { - // Create a multichain smart account - const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: signer - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use - }); - - } catch (error) { - console.error(error); - } -}; -``` - -:::: \ No newline at end of file diff --git a/docs/pages/tutorials/signers/privy.mdx b/docs/pages/tutorials/signers/privy.mdx deleted file mode 100644 index 00215f6..0000000 --- a/docs/pages/tutorials/signers/privy.mdx +++ /dev/null @@ -1,193 +0,0 @@ -# How to use Privy signer with Biconomy - -[Privy](https://www.privy.io/) is a platform that provides user onboarding and embedded wallet infrastructure for applications built on blockchain technology. - -Read below to learn how to configure your app to create Nexus smart accounts for all your users using Privy signers. - -::::steps - -### Install the dependencies - -```bash -npm i @privy-io/react-auth @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 @tanstack/react-query -``` - -### Wrap your app with the PrivyProvider - -```ts -import { QueryClient, QueryClientProvider } from '@tanstack/react-query' -import { type ReactNode, useState } from 'react' -import { PrivyProvider } from '@privy-io/react-auth'; - -export function App { - const [queryClient] = useState(() => new QueryClient()) - - return ( - - - {props.children} - - - ) -} -``` - -### Login with your Privy embedded wallet - -```ts -import { http } from "viem"; -import { baseSepolia } from "viem/chains"; -import { createBicoBundlerClient, NexusClient } from "@biconomy/abstractjs"; -import { useWallets, usePrivy } from '@privy-io/react-auth'; // [!code focus] - -export default function Home() { - const { login } = usePrivy(); // [!code focus] - - return ( -
- // [!code focus] -
- ); -} -``` - -### Connect the Privy signer with Multichain MEE - -```ts -import { http } from "viem"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { useWallets, usePrivy } from '@privy-io/react-auth'; - -export default function Home() { - const { login } = usePrivy(); - const { wallets } = useWallets(); // [!code focus] - const [meeClient, setMeeClient] = useState(null); - - useEffect(() => { // [!code focus:15] - const embeddedWallet = wallets.find((wallet) => (wallet.walletClientType === 'privy')); - if (embeddedWallet) { - (async () => { - const provider = await embeddedWallet.getEthersProvider(); - const signer = provider.getSigner(); - - // Create a multichain MEE client - const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use - }); - - setMeeClient(meeClient); - })(); - } - }, [wallets]); - - return ( -
- {meeClient &&
MEE Client connected
} - -
- ); -} -``` - -### Execute a cross-chain transaction with MEE and Privy - -```ts -import { http } from "viem"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; -import { useWallets, usePrivy } from '@privy-io/react-auth'; - -export default function Home() { - const { login } = usePrivy(); - const { wallets } = useWallets(); - const [meeClient, setMeeClient] = useState(null); - - useEffect(() => { - const embeddedWallet = wallets.find((wallet) => (wallet.walletClientType === 'privy')); - if (embeddedWallet) { - (async () => { - const provider = await embeddedWallet.getEthersProvider(); - const signer = provider.getSigner(); - - // Create a multichain MEE client - const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use - }); - - setMeeClient(meeClient); - })(); - } - }, [wallets]); - - const executeMultichainTx = async () => { // [!code focus:24] - if (!meeClient) return; - - // Get a quote for cross-chain operations - const quote = await meeClient.getQuote({ - instructions: [ - // Send transaction on Optimism - { - calls: [{ - to: "0x0000000000000000000000000000000000000000", - value: BigInt(1), - data: "0x" - }], - chainId: optimism.id - }, - // Send transaction on Base - { - calls: [{ - to: "0x0000000000000000000000000000000000000000", - value: BigInt(1), - data: "0x" - }], - chainId: base.id - } - ], - feeToken: { - address: "0xTokenAddress", // Replace with your fee token address - chainId: optimism.id - } - }); - - // Execute the quote - const { hash } = await meeClient.executeQuote({ quote }); - console.log(`Transaction hash: ${hash}`); - }; - - return ( -
- {meeClient &&
MEE Client connected
} - - {meeClient && } // [!code focus] -
- ); -} -``` \ No newline at end of file diff --git a/docs/pages/tutorials/signers/turnkey.mdx b/docs/pages/tutorials/signers/turnkey.mdx deleted file mode 100644 index 16a4855..0000000 --- a/docs/pages/tutorials/signers/turnkey.mdx +++ /dev/null @@ -1,88 +0,0 @@ -## How to use turnkey signer with Biconomy smart accounts - -Turnkey is a key infrastructure provider with a great developer API and a powerful security policy engine. By integrating Turnkey with Biconomy, you can build custodial Account Abstraction (AA) wallets that leverage Turnkey's security while enabling advanced features like gas sponsorship, transaction batching, and more. - -## Setup -To integrate Turnkey with Biconomy, start by creating an application with Turnkey. - -For detailed guidance, refer to the [Turnkey documentation](https://docs.turnkey.com/). You can also explore their quick-start [examples](https://docs.turnkey.com/getting-started/examples) to get up and running quickly. - -## Integration -Integrating Biconomy with Turnkey is simple once your project is set up. Turnkey offers an Externally Owned Account (EOA) wallet that can serve as the signer for Biconomy smart accounts. - -::::steps - -### Create the `TurnkeyClient` and a `Turnkey viem account` -After following the Turnkey documentation, you will have access to a TurnkeyClient. An example is shown below that you can pass as an owner to createBicoBundlerClient: - -```typescript -import { createWalletClient, http } from "viem"; -import { baseSepolia } from "viem/chains"; -import { ApiKeyStamper } from "@turnkey/sdk-server"; -import { TurnkeyClient } from "@turnkey/http"; -import { createAccount } from "@turnkey/viem"; - -const main = async () => { - const bundlerUrl = `https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44` - const apiPublicKey = ''; - const apiPrivateKey = ''; - const stamper = new ApiKeyStamper({ apiPublicKey, apiPrivateKey }); - const signWith = ""; // create an address in the turnkey dashboard - - // Param options here will be specific to your project. See the Turnkey docs for more info. - const turnkeyClient = new TurnkeyClient({ baseUrl: "https://api.turnkey.com" }, stamper) - - const turnkeyAccount = await createAccount({ - client: turnkeyClient, - organizationId: '', - signWith: signWith, - }) -} - -main(); - -``` - -### Create the MeeClient - -Next, use the Turnkey viem account to initialize the Biconomy MeeClient for multichain transactions: - -```typescript -import { createWalletClient, http } from "viem"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import { ApiKeyStamper } from "@turnkey/sdk-server"; -import { TurnkeyClient } from "@turnkey/http"; -import { createAccount } from "@turnkey/viem"; -import { createMeeClient, toMultichainNexusAccount } from "@biconomy/abstractjs"; // [!code focus] - -const main = async () => { - const apiPublicKey = ''; - const apiPrivateKey = ''; - const stamper = new ApiKeyStamper({ apiPublicKey, apiPrivateKey }); - const signWith = ""; - - // Param options here will be specific to your project. See the Turnkey docs for more info. - const turnkeyClient = new TurnkeyClient({ baseUrl: "https://api.turnkey.com" }, stamper) - - const turnkeyAccount = await createAccount({ - client: turnkeyClient, - organizationId: '', - signWith: signWith, - }) - - // Create a multichain MEE client - const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: turnkeyAccount - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use - }); - - // Now you can execute cross-chain transactions - console.log("MEE Client ready for cross-chain operations"); -} - -main(); -``` \ No newline at end of file diff --git a/docs/pages/tutorials/signers/web3auth.mdx b/docs/pages/tutorials/signers/web3auth.mdx deleted file mode 100644 index d533fa3..0000000 --- a/docs/pages/tutorials/signers/web3auth.mdx +++ /dev/null @@ -1,120 +0,0 @@ -# How to use Web3Auth with Biconomy - -[Web3Auth](https://web3auth.io/) is a pluggable auth infrastructure that aggregates OAuth providers, different wallets, and existing key management solutions. It provides a seamless authentication experience while maintaining high security standards. - -::::steps - -### Install the dependencies - -:::code-group - -```bash [npm] -npm install @web3auth/modal @web3auth/base @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 @web3auth/ethereum-provider -``` - -```bash [pnpm] -pnpm add @web3auth/modal @web3auth/base @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 @web3auth/ethereum-provider -``` - -```bash [yarn] -yarn add @web3auth/modal @web3auth/base @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 @web3auth/ethereum-provider -``` - -```bash [bun] -bun add @web3auth/modal @web3auth/base @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 @web3auth/ethereum-provider -``` - -::: - -### Setup Web3Auth - -```ts -// @errors: 2322 -import { Web3Auth } from "@web3auth/modal"; -import { CHAIN_NAMESPACES } from "@web3auth/base"; -import { http, type WalletClient } from "viem"; -import { baseSepolia, optimism, base, polygon, arbitrum } from "viem/chains"; -import { EthereumPrivateKeyProvider } from "@web3auth/ethereum-provider"; -import { createMeeClient, type EthereumProvider, toMultichainNexusAccount } from "@biconomy/abstractjs"; - -// Chain configuration for Base Sepolia -const chainConfig = { - chainNamespace: CHAIN_NAMESPACES.EIP155, - chainId: "0x14a33", // Base Sepolia - rpcTarget: "https://sepolia.base.org", - displayName: "Base Sepolia", - blockExplorerUrl: "https://sepolia.basescan.org", - ticker: "ETH", - tickerName: "Ethereum", - logo: "https://cryptologos.cc/logos/ethereum-eth-logo.png" -}; - -// Initialize the private key provider -const privateKeyProvider = new EthereumPrivateKeyProvider({ - config: { chainConfig } -}); - -// Initialize Web3Auth -const web3auth = new Web3Auth({ - clientId: "YOUR_WEB3AUTH_CLIENT_ID", // Get from Web3Auth Dashboard - privateKeyProvider, - web3AuthNetwork: "sapphire_devnet", - chainConfig, - uiConfig: { - appName: "Your App Name", - mode: "dark", - loginMethodsOrder: ["google", "facebook"] - } -}); - -await web3auth.initModal(); - -// Connect and get the provider -const web3authProvider = (await web3auth.connect()) as EthereumProvider - -if (!web3authProvider) { - throw new Error("No provider found"); -} - -// Create a multichain MEE client -const meeClient = await createMeeClient({ - account: await toMultichainNexusAccount({ - chains: [optimism, base, polygon, arbitrum], - transports: [http(), http(), http(), http()], - signer: web3authProvider - }), - apiKey: "YOUR_MEE_API_KEY" // Optional for production use -}); - -// Get a quote for cross-chain operations -const quote = await meeClient.getQuote({ - instructions: [ - // Send transaction on Optimism - { - calls: [{ - to: "0x0000000000000000000000000000000000000000", - value: 1n, - data: "0x" - }], - chainId: optimism.id - }, - // Send transaction on Base - { - calls: [{ - to: "0x0000000000000000000000000000000000000000", - value: 1n, - data: "0x" - }], - chainId: base.id - } - ], - feeToken: { - address: "0xTokenAddress", // Replace with your fee token address - chainId: optimism.id - } -}); - -// Execute the cross-chain transaction -const { hash } = await meeClient.executeQuote({ quote }); -console.log(`Transaction hash: ${hash}`); -``` diff --git a/docs/pages/tutorials/simple.mdx b/docs/pages/tutorials/simple.mdx deleted file mode 100644 index 361e6e4..0000000 --- a/docs/pages/tutorials/simple.mdx +++ /dev/null @@ -1,118 +0,0 @@ -## Quickstart - -:::code-group - -```bash [npm] -npm i @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -```bash [pnpm] -pnpm i @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -```bash [bun] -bun add @biconomy/abstractjs viem @rhinestone/module-sdk@0.2.7 -``` - -::: - -We have created quickstart templates for different environments that you can use to get started: - -- [Bun Quickstart](https://github.com/bcnmy/examples/tree/main/bun-quickstart) - A minimal template using Bun runtime -- [Next.js Quickstart](https://github.com/bcnmy/examples/tree/main/nextjs-quickstart) - A template using Next.js framework -- [Vite Quickstart](https://github.com/bcnmy/examples/tree/main/vite-quickstart) - A template using Vite + React - -Each template comes pre-configured with TypeScript, `viem`, and `@biconomy/abstractjs`. - -## Sending your first transaction with the SDK ⚡️ - -::::steps - -### Set up an owner account -First, we need to set up an Owner for the Smart Account which will be used to sign User Operations (transactions) for the Smart Account. - -```typescript -import { privateKeyToAccount } from "viem/accounts"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -``` - -### Set up nexus client - -A Smart Account needs access to the Network to query for information about its state (e.g. nonce, address, etc). Let's configure a client for the Smart Account. -A `bundlerUrl` is required to submit User Operations to the Network, which will initialize the Smart Account. - -```typescript -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; // [!code focus] -import { baseSepolia } from "viem/chains"; // [!code focus] -import { http, parseEther } from "viem"; // [!code focus] - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; // [!code focus] - -const nexusClient = createBicoBundlerClient({ // [!code focus] - account: await toNexusAccount({ // [!code focus] - signer: account, // [!code focus] - chain: baseSepolia, // [!code focus] - transport: http(), // [!code focus] - }), - transport: http(bundlerUrl), // [!code focus] -}); -const smartAccountAddress = await nexusClient.account.address; // [!code focus] -``` - -[See createBicoBundlerClient Docs](/sdk-reference/bundler-client) - -### Send User Operation - -Next, we'll send a transaction to the Bundler. In the example below, 0 ETH will be transferred from the smart account to a random address. After sending the transaction, we'll use the `waitForTransactionReceipt` function to wait for the transaction to be mined and get its receipt. This function takes the transaction hash as a parameter and returns a promise that resolves to the transaction receipt once the transaction is confirmed on the blockchain. - -:::warning -Ensure your smart account has sufficient funds to execute the transaction below. If not, please transfer funds to the `smartAccountAddress` -::: - -```typescript -import { privateKeyToAccount } from "viem/accounts"; -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther } from "viem"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`) -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}); - -const smartAccountAddress = await nexusClient.account.address; -const hash = await nexusClient.sendUserOperation({ // [!code focus] - calls: [ // [!code focus] - { // [!code focus] - to: '0xf5715961C550FC497832063a98eA34673ad7C816', // [!code focus] - value: parseEther('0'), // [!code focus] - }, // [!code focus] - ], // [!code focus] -}); // [!code focus] -const receipt = await nexusClient.waitForUserOperationReceipt({ hash }); // [!code focus] -``` - -You can now view the transaction on the Base Sepolia explorer. By submitting this user operation, you've: - -- Deployed the counterfactual smart account contract. -- Executed a simple transaction using smart accounts. - - -[See sendTransaction Docs](/sdk-reference/bundler-client) - -### Optional: Sponsor transaction - -By using a Paymaster, we can add sponsorship of gas fees. Checkout [sponsoring transaction](/tutorials/gasless) for more information. diff --git a/docs/pages/tutorials/smart-sessions.md b/docs/pages/tutorials/smart-sessions.md deleted file mode 100644 index 8431713..0000000 --- a/docs/pages/tutorials/smart-sessions.md +++ /dev/null @@ -1,371 +0,0 @@ -# Sending Transactions with Smart sessions ⚡️ -This document provides a step-by-step guide on how to set up and use the Smart Sessions Module with the Nexus client. Below is a breakdown of how to create, install, and use the module's functionality. - -Smart sessions enable powerful UX improvements for web3 applications by allowing users to delegate specific permissions to session keys. This creates a more seamless user experience while maintaining security through granular controls. - -![Smart Session](https://i.imgur.com/gN0Xhm6.png) - - -## Smart Sessions Explained - -You can think of smart sessions as giving some signers/keys special granular access to your smart account. They can -execute transactions on that account, but they can't execute *any* transaction - only the transactions they were -explicitly approved to execute. - -These fall into a few broad categories: - -| Restriction Type | Description | -|-----------------|-------------| -| **How much they can execute** | Set the maximum amount of transactions a key can execute. | -| **When they can execute** | Set time restrictions which prevent the signers from executing in any times beyond the ones approved by you. | -| **How much funds they can use** | Set restrictions on how much tokens the signer can use in total or in a single call. | -| **Which contracts they can call** | Set restrictions saying which *exact* contracts the signer is allowed to call. | -| **What functions they can call** | Set a restriction on which *exact* functions on the contract the signer is allowed to call | - -All of these permissions can be combined with eachother to create powerful guardrails for signers - primarily bots or -AI agents. - -:::tip[Example of a complex session] -A bot signer is allowed to: -- Execute 20 transactions -- Execute between 8AM - 8PM on Weekdays -- Call only AAVE Contracts -- Call only `supply` and `withdraw` functions on the AAVE Contracts -- Can spend maximum of 5000 USDC -::: - -## Implementing Smart Sessions - -In this tutorial we will be implementing a Smart Session which allows another signer to execute -only the `incrementCounter` function on a `Counter` contract. This is an example of an `actionPolicy`. - -::::steps - -### Set up an owner account -First, we need to set up an Owner for the Smart Account which will be used to sign User Operations (transactions) for the Smart Account. - -```typescript -import { privateKeyToAccount } from "viem/accounts"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); -``` - -### Set up Nexus client - -A Smart Account needs access to the Network to query for information about its state (e.g., nonce, address, etc.). Let's configure a client for the Smart Account. A `bundlerUrl` is required to submit User Operations to the Network, which will initialize the Smart Account. - -```typescript -import { createBicoBundlerClient, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http } from "viem"; -import { privateKeyToAccount } from "viem/accounts"; - -const privateKey = "PRIVATE_KEY"; -const account = privateKeyToAccount(`0x${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), -}); -``` - -### Create a smart sessions module for the user's account - -```typescript -const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: account -}); -``` - -### Install the smart sessions module -To enable smart session creation, we first need to install the smart sessions module into the Nexus client. - -Once the module is installed, we extend the Nexus client with smartSessionCreateActions. This step adds the necessary functionality for managing and creating smart sessions, allowing the Nexus client to interact with the sessions module. - -```typescript -const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData -}) -const { success: installSuccess } = await nexusClient.waitForUserOperationReceipt({ hash }); -const nexusSessionClient = nexusClient.extend(smartSessionCreateActions(sessionsModule)); -``` - -### Create a Smart Session - -To create a smart session, first define the session's permissions by specifying the session's public key and the actions it can perform (e.g., calling a function like `incrementNumber` in a smart contract). - -The `grantPermission` function submits this information to the blockchain, assigning a unique `permissionId` to track and manage the session's permissions. - -```typescript - -const sessionOwner = privateKeyToAccount(generatePrivateKey()) -const sessionPublicKey = sessionOwner.address; - -const sessionRequestedInfo: CreateSessionDataParams[] = [ - { - sessionPublicKey, - actionPoliciesInfo: [{ - contractAddress: "0xabc", // Replace with your contract address - rules: [], - functionSelector: "0x273ea3e3" as Hex // Function selector for 'incrementNumber' - }] - } -]; - -const createSessionsResponse = await nexusSessionClient.grantPermission({ - sessionRequestedInfo -}); - -const { success } = await nexusClient.waitForUserOperationReceipt({ - hash: createSessionsResponse.userOpHash -}); -``` - -### Create active session data -The `sessionData` object serves as the configuration for using a smart session. It includes the session owner’s public key, the granter’s account address, and the specific permissions (via permissionId) for actions the session is allowed to perform. - -```typescript -const sessionData: SessionData = { - granter: nexusClient.account.address, - sessionPublicKey, - description: `Permission to increment number at ${"0xabc"} on behalf of ${nexusClient.account.address.slice(0, 6)} `, // Optional - moduleData: { - ...createSessionsResponse, - mode: SmartSessionMode.USE - } -}; - -const compressedSessionData = stringify(sessionData); -``` - -:::tip[Save the Session Data] -It’s crucial to save the compressedSessionData after the user grants permission. - -Most commonly, the data is stored either in the LocalStorage of the browser or to a Database. - -- **Local Storage**: Save SessionData as a string on the client side. If the user changes browsers or deletes history you won't be able to retrieve this session data. Preferably use this for shorter-lasting sessions. - -- **Database Storage**: Alternatively, you can save this data in your dapp’s database. Use this for longer lasting sessions where you might need to retrieve session data after the user has deleted history or switched browsers/devices. -::: - - -Use the `stringify()` (exported from `@biconomy/abstractjs`) function to prepare the session data for storage. It does the same as `JSON.stringify()` but it accommodates bigints. - -:::: - -## Use the Smart Session - -Assume that the user has left the dapp and is returning to resume their session. The SessionData from their previous session is necessary to continue seamlessly. - -::::steps - -### Retrieve the saved `compressedSessionData` - -```typescript -const sessionData = parse(compressedSessionData) as SessionData -``` -Decompress this data using the `parse()` function to restore it to its original structure, making it ready for use. The `parse()` function does the same as `JSON.parse()` but it accommodates bigints. - - -### Create a Nexus Client for Using the Session - -We need a new Nexus client that is associated with the session. This client will use the session owner's private key to sign transactions. - -- Account Address: The address of the account that granted the permission. -- Signer: The session owner's private key, which will sign actions during the session. - -```typescript - -const smartSessionNexusClient = createBicoBundlerClient({ - chain: baseSepolia, - account: await toNexusAccount({ - accountAddress: sessionData.granter, - signer: sessionOwner, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl) -}); -``` - -### Create a Smart Sessions Module for the Session Key - -We now create a smart sessions module using the session key (sessionOwner). This module validates that the session is permitted to perform actions based on the session data we provided. - - -```typescript -const usePermissionsModule = toSmartSessionsValidator({ - account: smartSessionNexusClient.account, - signer: sessionOwner, - moduleData: sessionData.moduleData -}); - -const useSmartSessionNexusClient = smartSessionNexusClient.extend( - smartSessionUseActions(usePermissionsModule) -); -``` - -### Send transactions with sessions -Now that we have everything set up, we can perform an action with the smart session. In this example, we're calling a function on a smart contract (incrementNumber) using the session key. This is done by specifying: - -- Target: The contract address. -- Call Data: The encoded data for the function we're calling, using the ABI to define the function. - -```typescript -const userOpHash = await useSmartSessionNexusClient.usePermission({ - calls: [ - { - to: "0xabc", // Replace with your target contract address - data: encodeFunctionData({ - abi: CounterAbi, - functionName: "incrementNumber" - }) - } - ] -}); - -console.log(`Transaction hash: ${userOpHash}`); - -``` -:::: - -## Full Code - -:::details[Click here] - -```typescript -import { - createBicoBundlerClient, toSmartSessionsValidator, smartSessionCreateActions, - smartSessionUseActions, CreateSessionDataParams, SessionData, -} from "@biconomy/abstractjs"; -import { generatePrivateKey, privateKeyToAccount } from "viem/accounts"; -import { baseSepolia } from "viem/chains"; -import { Hex, encodeFunctionData, http } from "viem"; -import { SmartSessionMode } from "@rhinestone/module-sdk/module" - -const CounterAbi = [ - { - inputs: [], - name: "incrementNumber", - outputs: [], - stateMutability: "nonpayable", - type: "function" - }, -] -const privateKey = ""; -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; - -export const createAccountAndSendTransaction = async () => { - const userAccount = privateKeyToAccount(`0x${privateKey}`) - const sessionOwner = privateKeyToAccount(generatePrivateKey()) - const sessionPublicKey = sessionOwner.address; - - // 2. Set up Nexus client - const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: userAccount, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - }); - - // 3. Create a smart sessions module for the user's account - const sessionsModule = toSmartSessionsValidator({ - account: nexusClient.account, - signer: userAccount - }); - - // 4. Install the smart sessions module - const hash = await nexusClient.installModule({ - module: sessionsModule.moduleInitData - }) - const { success: installSuccess } = await nexusClient.waitForUserOperationReceipt({ hash }) - - - const nexusSessionClient = nexusClient.extend( - smartSessionCreateActions(sessionsModule) - ) - - const sessionRequestedInfo: CreateSessionDataParams[] = [ - { - sessionPublicKey, // Public key of the session - actionPoliciesInfo: [ - { - contractAddress: "0xabc", - rules: [], - functionSelector: "0x273ea3e3" as Hex // Selector for 'incrementNumber' - } - ] - } - ] - - - // 5. Create the smart session - const createSessionsResponse = await nexusSessionClient.grantPermission({ - sessionRequestedInfo - }) - - const { success } = - await nexusClient.waitForUserOperationReceipt({ - hash: createSessionsResponse.userOpHash - }) - - // Use the Smart Session - - // 1. Create active session data - const sessionData: SessionData = { - granter: nexusClient.account.address, - sessionPublicKey, - moduleData: { - permissionIds: createSessionsResponse.permissionIds, - mode: SmartSessionMode.USE - } - } - - // 2. Create a Nexus Client for Using the Session - const smartSessionNexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: sessionOwner, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl) - }) - - // 3. Create a Smart Sessions Module for the Session Key - const usePermissionsModule = toSmartSessionsValidator({ - account: smartSessionNexusClient.account, - signer: sessionOwner, - moduleData: sessionData.moduleData - }) - - const useSmartSessionNexusClient = smartSessionNexusClient.extend( - smartSessionUseActions(usePermissionsModule) - ) - - // 4. Send transactions with sessions - const userOpHash = await useSmartSessionNexusClient.usePermission({ - calls: [ - { - to: "0xabc", - data: encodeFunctionData({ - abi: CounterAbi, - functionName: "incrementNumber" - }) - } - ] - }) -} - -createAccountAndSendTransaction() -``` -::: diff --git a/docs/pages/tutorials/tokenPaymaster.md b/docs/pages/tutorials/tokenPaymaster.md deleted file mode 100644 index d167ec3..0000000 --- a/docs/pages/tutorials/tokenPaymaster.md +++ /dev/null @@ -1,100 +0,0 @@ -## Paying Gas in ERC20 Tokens with SDK ⚡️ - -ERC20 tokens can be used to pay for gas fees. This is achieved through the use of a token paymaster. In this tutorial, we will guide you through the process of sending a user operation using an ERC20 token as the gas payment method. - -::::steps - -### Set up an owner account -First, we need to set up an Owner for the Smart Account which will be used to sign User Operations (transactions) for the Smart Account. - -```typescript -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); -``` - -### Set up Nexus client with paymaster -Login to the [Dashboard](https://dashboard.biconomy.io/) and setup a v2 paymaster. Let's configure a client for the Smart Account with a `paymasterUrl` to enable it. A `bundlerUrl` is required to submit transactions to the Network, which will initialize the Smart Account. - -```typescript -import { createBicoBundlerClient, createBicoPaymasterClient, toBiconomyTokenPaymasterContext, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; // [!code focus:16] -const baseSepoliaUSDC = "0x036cbd53842c5426634e7929541ec2318f3dcf7e"; - -const paymasterContext = toBiconomyTokenPaymasterContext({ - feeTokenAddress: baseSepoliaUSDC -}) - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster: createBicoPaymasterClient({paymasterUrl}), - paymasterContext -}); -``` - -### Sending a transaction and paying the gas with USDC -Next, define the transaction you want to send. Use the `sendTokenPaymasterUserOp` method to send the user operation using the Token Paymaster. - -```typescript - -import { createBicoBundlerClient, createBicoPaymasterClient, toBiconomyTokenPaymasterContext, toNexusAccount } from "@biconomy/abstractjs"; -import { baseSepolia } from "viem/chains"; -import { http, parseEther } from "viem"; -import { privateKeyToAccount, generatePrivateKey } from "viem/accounts"; - -const privateKey = generatePrivateKey(); -const account = privateKeyToAccount(`${privateKey}`); - -const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; -const paymasterUrl = "https://paymaster.biconomy.io/api/v2/84532/F7wyL1clz.75a64804-3e97-41fa-ba1e-33e98c2cc703"; -const baseSepoliaUSDC = "0x036cbd53842c5426634e7929541ec2318f3dcf7e"; -const recipientAddress = "0x0000000000000000000000000000000000000000"; - -const paymasterContext = toBiconomyTokenPaymasterContext({ - feeTokenAddress: baseSepoliaUSDC -}) - -const nexusClient = createBicoBundlerClient({ - account: await toNexusAccount({ - signer: account, - chain: baseSepolia, - transport: http(), - }), - transport: http(bundlerUrl), - paymaster: createBicoPaymasterClient({paymasterUrl}), - paymasterContext -}); // [!code focus:7] - -const userOpHash = await nexusClient.sendTokenPaymasterUserOp({ - calls: [ - { - to: recipientAddress, - value: 1n, - data: "0x" - } - ], - feeTokenAddress: baseSepoliaUSDC -}) - -const receipt = await nexusClient.waitForUserOperationReceipt({ hash: userOpHash }) -``` - -For a complete list of supported ERC20 tokens that can be used for gas payment, check out our [supported tokens documentation](/contractsAndAudits#token-paymaster-supported-tokens). - -By following these steps, you have successfully sent a transaction and paid the gas with USDC token using the SDK. For more advanced features and options, refer to the official documentation. - -[See sendTransaction Docs](/sdk-reference/bundler-client/methods/sendUserOperation) diff --git a/vocs.config.ts b/vocs.config.ts index a390bd1..e0fa691 100644 --- a/vocs.config.ts +++ b/vocs.config.ts @@ -418,635 +418,5 @@ export default defineConfig({ ] } ], - sidebar: [ - { - text: "Why Biconomy?", - link: "/about", - }, - { - text: "Supported Chains", - link: "/supportedNetworks", - }, - { - text: "Pricing", - link: "/pricing", - }, - { - text: 'Get API Key', - link: '/api-key' - }, - { - text: 'Modular Execution Environment (MEE)', - items: [ - { - text: 'What is MEE', - link: '/mee/what-is-mee' - }, - { - text: 'MEE vs. ERC-4337', - link: '/mee/mee-vs-4337' - } - ] - }, - { - text: 'QuickStart Guides', - items: [ - { - text: 'Multichain Orchestration', - link: '/multichain-orchestration/quickstart' - }, - { - text: 'Pay for Gas With ERC-20 Tokens', - link: '/multichain-gas-abstraction/for-sca' - }, - { - text: 'EIP-7702 for Embedded Wallets', - collapsed: true, - items: [ - { - text: 'Gas Abstracted Batch Execute w/ Privy', - link: '/smarteoa/demos/privy-7702-gasless' - }, - { - text: 'Gas Abstracted Batch Execute w/ Turnkey', - link: '/smarteoa/demos/turnkey-7702-gasless' - }, - { - text: 'In-Depth Tutorial w/ Privy', - link: '/smarteoa/demos/privy-7702-demo' - }, - ] - }, - // { - // text: 'EIP-7702 for External Wallets', - // collapsed: true, - // items: [ - // { - // text: 'Batch Execute from EOA with ERC-5792', - // link: '/smarteoa/demos/batch-execute-5792-fusion' - // }, - // { - // text: 'Batch Execute from EOA with Fusion' - // } - // ] - // } - - ] - }, - { - text: 'Multichain Orchestration APIs', - collapsed: true, - items: [ - { - text: 'Overview', - link: '/multichain-orchestration/overview' - }, - { - text: 'Zero-to-Hero Guide', - link: '/multichain-orchestration/comprehensive' - }, - { - text: 'Using Different Account Types', - items: [ - { - text: 'Native EOA', - link: '/multichain-orchestration/eoa' - }, - { - text: 'Smart Account', - link: '/multichain-orchestration/sca' - }, - { - text: 'EIP-7702 EOA', - link: '/multichain-orchestration/eip7702' - } - ] - }, - { - text: 'Learn Concepts', - items: [ - { - text: 'Runtime Parameter Injection', - link: '/multichain-orchestration/runtimeinjection' - }, - ] - }, - { - text: 'Instruction Builders', - collapsed: true, - items: [ - { - text: 'Overview', - link: '/multichain-orchestration/instruction-builders/overview' - }, - { - text: 'Default', - link: '/multichain-orchestration/instruction-builders/default' - }, - { - text: 'Multichain', - link: '/multichain-orchestration/instruction-builders/multichain' - }, - { - text: 'Composable', - link: '/multichain-orchestration/instruction-builders/composable' - }, - { - text: 'Raw CallData', - link: '/multichain-orchestration/instruction-builders/rawcalldata' - } - ] - } - ] - }, - { - text: 'Smart EOAs (EIP-7702 & Fusion)', - collapsed: true, - items: [ - { text: "Overview", link: '/smarteoa' }, - { text: 'Explained', items: [ - { text: "EIP-7702 Explained", link: '/eip7702/explained' }, - { text: 'Companion Accounts Explained', link: '/smarteoa/companion-explained'}, - ]}, - { text: 'Developer Guides', items: [ - { text: 'dApps using External Wallets', link: '/mee/fusion'}, - { text: 'dApps using Embedded Wallets', link: '/eip7702/wallet-guide'}, - { text: 'MetaMask Delegator Framework', link: '/smarteoa/delegator' } - ]} - ] - }, - { - text: "Signer Guides", - collapsed: true, - items: [ - { text: "Privy", link: "/tutorials/signers/privy" }, - { text: "Web3Auth", link: "/tutorials/signers/web3auth" }, - { text: "Magic", link: "/tutorials/signers/magic" }, - { text: "Particle", link: "/tutorials/signers/particle" }, - { text: "Passport", link: "/tutorials/signers/passport" }, - { text: "Turnkey", link: "/tutorials/signers/turnkey" }, - { text: "Dynamic", link: "/tutorials/signers/dynamic" }, - { text: "Capsule", link: "/tutorials/signers/capsule" }, - { text: "DFNS", link: "/tutorials/signers/dfns" }, - ], - }, - { - text: "Smart Accounts", - collapsed: true, - items: [ - { text: "Smart Accounts Overview", link: "/account-providers/overview" }, - { text: "Nexus Smart Account", link: "/overview", collapsed: true }, - { text: "EIP-7702: Smart EOAs Overview", link: '/eip7702/wallet-guide' }, - { text: 'Companion Accounts Overview', link: '/mee/fusion' } - ], - }, - { - text: 'Gas Abstraction APIs', - collapsed: true, - items: [ - { - text: 'Overview', - link: '/multichain-gas-abstraction/overview' - }, - { - text: 'Paying for Gas with ERC20 Tokens', - items: [ - { - text: 'For EOA Accounts', - link: '/multichain-gas-abstraction/for-eoa' - }, - { - text: 'For Smart Accounts', - link: '/multichain-gas-abstraction/for-sca' - } - ] - }, - { - text: 'Sponsoring Gas For Users', - link: '/multichain-gas-abstraction/sponsoring-gas' - } - ] - }, - { - text: 'Smart Sessions APIs', - collapsed: true, - items: [ - { - text: 'Overview', - link: '/multichain-smart-sessions/overview' - }, - { - text: 'Single Chain', - items: [ - { - text: 'Granting a Smart Session', - link: '/multichain-smart-sessions/grant' - }, - { - text: 'Redeeming a Smart Session', - link: '/multichain-smart-sessions/redeem' - } - ] - }, - ] - }, - { - text: 'Learn Concepts', - collapsed: true, - items: [ - { - text: 'EIP-7702 Guide for Apps 🔗', - link: 'https://blog.biconomy.io/a-comprehensive-eip-7702-guide-for-apps/' - }, - { - text: 'Companion Accounts & Fusion 🔗', - link: 'https://blog.biconomy.io/introduction-to-companion-accounts-fusion/' - }, - { - text: 'Supertransactions 🔗', - link: 'https://blog.biconomy.io/introduction-to-supertransactions-2/' - }, - { - text: 'Compsability Stack 🔗', - link: 'https://blog.biconomy.io/introduction-to-the-composability-stack/' - }, - { - text: 'Modular Execution Environment 🔗', - link: 'https://blog.biconomy.io/learn-modular-execution-environment-mee/' - } - ] - }, - { - text: "Resources", - collapsed: true, - items: [ - { text: "Contracts & Audits", link: "/contractsAndAudits" }, - { text: "Supported Networks", link: "/supportedNetworks" }, - ], - }, - - { - text: "Demos", - collapsed: true, - items: [ - { - text: "#001 SmartSessions", - link: "/demos/smartSessions", - }, - { - text: "#002 Fusion", - link: "/demos/fusion", - }, - ], - }, - { - text: "SDK Reference", - collapsed: true, - link: "/sdk-reference", - items: [ - { - text: "MEE Client", - link: "/sdk-reference/mee-client", - collapsed: false, - items: [ - { - text: "Multichain Account", - link: "/sdk-reference/mee-client/account", - collapsed: false, - items: [ - { - text: "build", - link: "/sdk-reference/mee-client/account/methods/build", - }, - { - text: "buildComposable", - link: "/sdk-reference/mee-client/account/methods/buildComposable", - }, - { - text: "more*", - collapsed: true, - items: [ - { - text: "deploymentOn", - link: "/sdk-reference/mee-client/account/methods/more/deploymentOn", - }, - { - text: "addressOn", - link: "/sdk-reference/mee-client/account/methods/more/addressOn", - }, - { - text: "isDelegated", - link: "/sdk-reference/mee-client/account/methods/more/isDelegated", - }, - { - text: "unDelegate", - link: "/sdk-reference/mee-client/account/methods/more/unDelegate", - }, - { - text: "waitForTransactionReceipts", - link: "/sdk-reference/mee-client/account/methods/more/waitForTransactionReceipts", - }, - ], - } - ], - }, - { - text: "Methods", - link: "/sdk-reference/mee-client/methods", - collapsed: false, - items: [ - { - text: "getQuote", - link: "/sdk-reference/mee-client/methods/getQuote", - }, - { - text: "executeQuote", - link: "/sdk-reference/mee-client/methods/executeQuote", - }, - { - text: "getFusionQuote", - link: "/sdk-reference/mee-client/methods/getFusionQuote", - }, - { - text: "executeFusionQuote", - link: "/sdk-reference/mee-client/methods/executeFusionQuote", - }, - { - text: "waitForSuperTransactionReceipt", - link: "/sdk-reference/mee-client/methods/waitForSuperTransactionReceipt", - }, - { - text: "more*", - collapsed: true, - items: [ - { - text: "getSuperTransactionReceipt", - link: "/sdk-reference/mee-client/methods/more/getSuperTransactionReceipt", - }, - { - text: "execute", - link: "/sdk-reference/mee-client/methods/more/execute", - }, - { - text: "executeSignedQuote", - link: "/sdk-reference/mee-client/methods/more/executeSignedQuote", - }, - { - text: "signQuote", - link: "/sdk-reference/mee-client/methods/more/signQuote", - }, - { - text: "getGasToken", - link: "/sdk-reference/mee-client/methods/more/getGasToken", - }, - { - text: "getInfo", - link: "/sdk-reference/mee-client/methods/more/getInfo", - }, - { - text: "getOnChainQuote", - link: "/sdk-reference/mee-client/methods/more/getOnChainQuote", - }, - { - text: "getPermitQuote", - link: "/sdk-reference/mee-client/methods/more/getPermitQuote", - }, - { - text: "signOnChainQuote", - link: "/sdk-reference/mee-client/methods/more/signOnChainQuote", - }, - { - text: "signPermitQuote", - link: "/sdk-reference/mee-client/methods/more/signPermitQuote", - }, - { - text: "getPaymentToken", - link: "/sdk-reference/mee-client/methods/more/getPaymentToken", - }, - ], - }, - ], - }, - { - text: "Helpers", - link: "/sdk-reference/mee-client/helpers", - collapsed: true, - items: [ - { - text: "runtimeERC20BalanceOf", - link: "/sdk-reference/mee-client/helpers/runtimeERC20BalanceOf", - }, - { - text: "runtimeEncodeAbiParameters", - link: "/sdk-reference/mee-client/helpers/runtimeEncodeAbiParameters", - }, - { - text: "getMultichainContract", - link: "/sdk-reference/mee-client/helpers/getMultichainContract", - }, - { - text: "more*", - collapsed: true, - items: [ - { - text: "mcUSDC", - link: "/sdk-reference/mee-client/helpers/more/mcUSDC", - }, - { - text: "getExplorerTxLink", - link: "/sdk-reference/mee-client/helpers/more/getExplorerTxLink", - }, - { - text: "getMeeScanLink", - link: "/sdk-reference/mee-client/helpers/more/getMeeScanLink", - }, - { - text: "getJiffyScanLink", - link: "/sdk-reference/mee-client/helpers/more/getJiffyScanLink", - }, - { - text: "mcAaveV3Pool ", - link: "/sdk-reference/mee-client/helpers/more/mcAaveV3Pool", - }, - { - text: "mcUniswapSwapRouter", - link: "/sdk-reference/mee-client/helpers/more/mcUniswapSwapRouter", - }, - ], - }, - ], - }, - ], - }, - { - text: "Bundler Client", - collapsed: true, - link: "/sdk-reference/bundler-client", - items: [ - { - text: "Account", - link: "/sdk-reference/bundler-client/account", - }, - { - text: "Methods", - link: "/sdk-reference/bundler-client/methods", - collapsed: false, - items: [ - { - text: "sendUserOperation", - link: "/sdk-reference/bundler-client/methods/sendUserOperation", - }, - { - text: "waitForUserOperationReceipt", - link: "/sdk-reference/bundler-client/methods/waitForUserOperationReceipt", - }, - { - text: "debugUserOperation", - link: "/sdk-reference/bundler-client/methods/debugUserOperation", - }, - { - text: "prepareTokenPaymasterUserOp", - link: "/sdk-reference/bundler-client/methods/prepareTokenPaymasterUserOp", - }, - { - text: "sendTokenPaymasterUserOp", - link: "/sdk-reference/bundler-client/methods/sendTokenPaymasterUserOp", - }, - { - text: "upgradeSmartAccount", - link: "/sdk-reference/bundler-client/methods/upgradeSmartAccount", - }, - { - text: "more*", - collapsed: true, - items: [ - { - text: "estimateUserOperationGas", - link: "/sdk-reference/bundler-client/methods/more/estimateUserOperationGas", - }, - { - text: "getUserOperation", - link: "/sdk-reference/bundler-client/methods/more/getUserOperation", - }, - { - text: "getUserOperationReceipt", - link: "/sdk-reference/bundler-client/methods/more/getUserOperationReceipt", - }, - { - text: "getSupportedEntryPoints", - link: "/sdk-reference/bundler-client/methods/more/getSupportedEntryPoints", - }, - { - text: "getChainId", - link: "/sdk-reference/bundler-client/methods/more/getChainId", - }, - { - text: "sendTransaction", - link: "/sdk-reference/bundler-client/methods/more/sendTransaction", - }, - { - text: "writeContract", - link: "/sdk-reference/bundler-client/methods/more/writeContract", - }, - { - text: "signMessage", - link: "/sdk-reference/bundler-client/methods/more/signMessage", - }, - { - text: "prepareUserOperationWithoutSignature", - link: "/sdk-reference/bundler-client/methods/more/prepareUserOperationWithoutSignature", - }, - { - text: "prepareUserOperation", - link: "/sdk-reference/bundler-client/methods/more/prepareUserOperation", - }, - { - text: "getGasFeeValues", - link: "/sdk-reference/bundler-client/methods/more/getGasFeeValues", - }, - { - text: "getUserOperationStatus", - link: "/sdk-reference/bundler-client/methods/more/getUserOperationStatus", - }, - { - text: "waitForConfirmedUserOperationReceipt", - link: "/sdk-reference/bundler-client/methods/more/waitForConfirmedUserOperationReceipt", - }, - { - text: "accountId", - link: "/sdk-reference/bundler-client/methods/more/accountId", - }, - { - text: "getActiveHook", - link: "/sdk-reference/bundler-client/methods/more/getActiveHook", - }, - { - text: "getFallbackBySelector", - link: "/sdk-reference/bundler-client/methods/more/getFallbackBySelector", - }, - { - text: "getInstalledExecutors", - link: "/sdk-reference/bundler-client/methods/more/getInstalledExecutors", - }, - { - text: "getInstalledValidators", - link: "/sdk-reference/bundler-client/methods/more/getInstalledValidators", - }, - { - text: "installModule", - link: "/sdk-reference/bundler-client/methods/more/installModule", - }, - { - text: "isModuleInstalled", - link: "/sdk-reference/bundler-client/methods/more/isModuleInstalled", - }, - { - text: "supportsExecutionMode", - link: "/sdk-reference/bundler-client/methods/more/supportsExecutionMode", - }, - { - text: "supportsModule", - link: "/sdk-reference/bundler-client/methods/more/supportsModule", - }, - { - text: "uninstallModule", - link: "/sdk-reference/bundler-client/methods/more/uninstallModule", - } - ] - } - ], - }, - ], - }, - - ], - }, - { - text: "Account Migrations", - link: "/migrations", - collapsed: false, - items: [ - { - text: "V2 to Nexus Migration", - link: "/migrations/v2ToNexus", - }, - { - text: "Nexus to Nexus Migration", - link: "/migrations/nexusToNexus", - }, - ], - }, - { - text: "Legacy Account Abstraction Docs", - collapsed: true, - items: [ - { - collapsed: true, - text: "V2 Accounts & EPv6 Infra", - items: smartAccountsV2Sidebar, - }, - { text: "V1 Docs", link: "https://legacy-docs.biconomy.io/" }, - ], - } - ], + sidebar: smartAccountsV2Sidebar }); diff --git a/vocs.config.ts.timestamp-1747656041201-6a1bca8369389.mjs b/vocs.config.ts.timestamp-1747656041201-6a1bca8369389.mjs deleted file mode 100644 index bc28648..0000000 --- a/vocs.config.ts.timestamp-1747656041201-6a1bca8369389.mjs +++ /dev/null @@ -1,1046 +0,0 @@ -// vocs.config.ts -import { defineConfig } from "file:///Users/mickey/Development/Biconomy/abstract-docs/abstract-js-by-biconomy/node_modules/vocs/_lib/index.js"; -var smartAccountsV2Sidebar = [ - { link: "/smartAccountsV2/overview", text: "Overview" }, - { link: "/smartAccountsV2/quickstart-react", text: "Quickstart: React" }, - { link: "/smartAccountsV2/quickstart", text: "Quickstart: Core SDK" }, - { - link: "/smartAccountsV2/react", - text: "React", - collapsed: true, - items: [ - { - link: "/smartAccountsV2/react/BiconomyProvider", - text: "BiconomyProvider" - }, - { - link: "/smartAccountsV2/react/useBatchSession", - text: "UseBatchSession" - }, - { - link: "/smartAccountsV2/react/useCreateBatchSession", - text: "UseCreateBatchSession" - }, - { - link: "/smartAccountsV2/react/useCreateSession", - text: "UseCreateSession" - }, - { - link: "/smartAccountsV2/react/useDeploySmartAccount", - text: "UseDeploySmartAccount" - }, - { link: "/smartAccountsV2/react/useGasEstimate", text: "UseGasEstimate" }, - { - link: "/smartAccountsV2/react/useSendGasTokenTransaction", - text: "UseSendGasTokenTransaction" - }, - { - link: "/smartAccountsV2/react/useSendSponsoredTransaction", - text: "UseSendSponsoredTransaction" - }, - { - link: "/smartAccountsV2/react/useSendTransaction", - text: "UseSendTransaction" - }, - { - link: "/smartAccountsV2/react/useSendWithdrawals", - text: "UseSendWithdrawals" - }, - { link: "/smartAccountsV2/react/useSession", text: "UseSession" }, - { - link: "/smartAccountsV2/react/useSmartAccount", - text: "UseSmartAccount" - }, - { link: "/smartAccountsV2/react/useTokenFees", text: "UseTokenFees" }, - { link: "/smartAccountsV2/react/useUserOpWait", text: "UseUserOpWait" } - ] - }, - { - link: "/smartAccountsV2/tutorials", - text: "Tutorials", - collapsed: true, - items: [ - { - link: "/smartAccountsV2/tutorials/sendSimpleTransaction", - text: "Send a simple transaction" - }, - { - link: "/smartAccountsV2/tutorials/sendTransactionsBatch", - text: "Send transactions batch" - }, - { - link: "/smartAccountsV2/tutorials/sendGasless", - text: "Send a gasless transaction" - }, - { - link: "/smartAccountsV2/tutorials/payERC20Token", - text: "Pay gas in ERC20 token" - }, - { - link: "/smartAccountsV2/tutorials/parallelUserOps", - text: "Send parallel userOps" - }, - { - link: "/smartAccountsV2/tutorials/sessions", - text: "Sessions", - items: [ - { - link: "/smartAccountsV2/tutorials/sessions/createSession", - text: "Create Session" - }, - { - link: "/smartAccountsV2/tutorials/sessions/useSession", - text: "Use Session" - }, - { - link: "/smartAccountsV2/tutorials/sessions/createBatchSession", - text: "Create Batch Session" - }, - { - link: "/smartAccountsV2/tutorials/sessions/useBatchSession", - text: "Use Batch Session" - }, - { - link: "/smartAccountsV2/tutorials/sessions/customSessionStorage", - text: "Custom Session Storage" - } - ] - }, - { - link: "/smartAccountsV2/tutorials/customValidationModule", - text: "Custom Validation Module" - }, - { - link: "/smartAccountsV2/tutorials/utils", - text: "Utils", - items: [ - { - link: "/smartAccountsV2/tutorials/utils/offsetGasValues", - text: "Offset Gas Values" - }, - { - link: "/smartAccountsV2/tutorials/utils/transferOwnership", - text: "Transfer Ownership" - } - ] - }, - { - link: "/smartAccountsV2/tutorials/apiIntegration", - text: "API Integration", - collapsed: true, - items: [ - { - link: "/smartAccountsV2/tutorials/apiIntegration/userSponsored", - text: "User sponsored" - }, - { - link: "/smartAccountsV2/tutorials/apiIntegration/paymasterSponsored", - text: "Paymaster Sponsored" - }, - { - link: "/smartAccountsV2/tutorials/apiIntegration/paymasterERC20", - text: "Paymaster ERC20" - }, - { - link: "/smartAccountsV2/tutorials/apiIntegration/signUserOperation", - text: "Sign userOp" - } - ] - }, - { link: "/smartAccountsV2/tutorials/v4Migration", text: "V4 Migration" }, - { - text: "Migrate from stackUp", - link: "/smartAccountsV2/tutorials/migrate" - } - ] - }, - { - link: "/smartAccountsV2/account", - text: "Smart Account", - collapsed: true, - items: [ - { link: "/smartAccountsV2/account/integration", text: "Integration" }, - { link: "/smartAccountsV2/account/methods", text: "Methods" }, - { - link: "/smartAccountsV2/account/signers", - text: "Signers", - items: [ - { - link: "/smartAccountsV2/account/signers/eoa", - text: "Eoa", - items: [ - { - link: "/smartAccountsV2/account/signers/eoa/ethers", - text: "Ethers" - }, - { - link: "/smartAccountsV2/account/signers/eoa/viem", - text: "Viem" - }, - { - link: "/smartAccountsV2/account/signers/eoa/wagmi", - text: "Wagmi" - } - ] - }, - { link: "/smartAccountsV2/account/signers/capsule", text: "Capsule" }, - { link: "/smartAccountsV2/account/signers/dfns", text: "Dfns" }, - { link: "/smartAccountsV2/account/signers/dynamic", text: "Dynamic" }, - { link: "/smartAccountsV2/account/signers/magic", text: "Magic" }, - { - link: "/smartAccountsV2/account/signers/particle", - text: "Particle" - }, - { - link: "/smartAccountsV2/account/signers/passport", - text: "Passport" - }, - { link: "/smartAccountsV2/account/signers/privy", text: "Privy" }, - { link: "/account/signers/turnkey", text: "Turnkey" }, - { - link: "/smartAccountsV2/account/signers/web3auth", - text: "Web3auth" - } - ] - }, - { - link: "/smartAccountsV2/account/fiatonramp", - text: "Enable Fiat On-Ramp" - } - ] - }, - { - link: "/smartAccountsV2/bundler", - text: "Bundler", - collapsed: true, - items: [ - { - link: "/smartAccountsV2/bundler/api", - text: "Api", - items: [ - { link: "/smartAccountsV2/bundler/api/explorer", text: "Explorer" }, - { - link: "/smartAccountsV2/bundler/api/estimate-useroperation-gas", - text: "eth_estimateUserOperationGas" - }, - { - link: "/smartAccountsV2/bundler/api/send-UserOperation", - text: "eth_sendUserOperation" - }, - { - link: "/smartAccountsV2/bundler/api/get-useroperation-receipt", - text: "eth_getUserOperationReceipt" - }, - { - link: "/smartAccountsV2/bundler/api/get-useroperation-by-hash", - text: "eth_getUserOperationByHash" - }, - { link: "/smartAccountsV2/bundler/api/chainId", text: "eth_chainId" }, - { - link: "/smartAccountsV2/bundler/api/supported-EntryPoints", - text: "eth_supportedEntryPoints" - }, - { - link: "/smartAccountsV2/bundler/api/get-gas-fee-values", - text: "biconomy_getGasFeeValues" - }, - { - link: "/smartAccountsV2/bundler/api/get-useroperation-status", - text: "biconomy_getUserOperationStatus" - } - ] - }, - { - link: "/smartAccountsV2/bundler/bundlermethods", - text: "Bundler Methods" - }, - { link: "/smartAccountsV2/bundler/integration", text: "Integration" }, - { link: "/smartAccountsV2/bundler/usingViem", text: "Using Viem" } - ] - }, - { - link: "/smartAccountsV2/paymaster", - text: "Paymaster", - collapsed: true, - items: [ - { - link: "/smartAccountsV2/paymaster/7677", - text: "7677", - items: [ - { - link: "/smartAccountsV2/paymaster/7677/pm_getPaymasterData", - text: "pm_getPaymasterData" - }, - { - link: "/smartAccountsV2/paymaster/7677/pm_getPaymasterStubData", - text: "pm_getPaymasterStubData" - } - // { link: "/paymaster/7677/usingViem", text: "Using Viem" }, - ] - }, - { - link: "/smartAccountsV2/paymaster/api", - text: "Api", - items: [ - { - link: "/smartAccountsV2/paymaster/api/explorer", - text: "Explorer" - }, - { - link: "/smartAccountsV2/paymaster/api/get-fee-quotes", - text: "pm_getFeeQuoteOrData" - }, - { - link: "/smartAccountsV2/paymaster/api/sponsor-useroperation", - text: "pm_sponsorUserOperation" - } - ] - }, - { link: "/smartAccountsV2/paymaster/integration", text: "Integration" }, - { link: "/smartAccountsV2/paymaster/methods", text: "Methods" } - ] - }, - { - link: "/smartAccountsV2/gasEstimations", - text: "Gas Estimations", - collapsed: true, - items: [ - { - link: "/smartAccountsV2/gasEstimations/integration", - text: "Integration" - }, - { link: "/smartAccountsV2/gasEstimations/methods", text: "Methods" } - ] - }, - { - link: "/smartAccountsV2/modules", - text: "Modules", - collapsed: true, - items: [ - { link: "/smartAccountsV2/modules/ecdsa", text: "Ecdsa" }, - { link: "/smartAccountsV2/modules/multichain", text: "Multichain" }, - { - link: "/smartAccountsV2/modules/sessions", - text: "Sessions", - items: [ - { - link: "/smartAccountsV2/modules/sessions/abiSessionValidationModule", - text: "AbiSessionValidationModule" - }, - { - link: "/smartAccountsV2/modules/sessions/BatchedSession", - text: "BatchedSession" - }, - { - link: "/smartAccountsV2/modules/sessions/sessionvalidationmodule", - text: "Sessionvalidationmodule" - } - ] - } - ] - }, - { link: "/smartAccountsV2/contracts", text: "Contracts" }, - { link: "/smartAccountsV2/audits", text: "Audits" }, - { - link: "/smartAccountsV2/troubleshooting", - text: "Troubleshooting", - collapsed: true, - items: [ - { - link: "/smartAccountsV2/troubleshooting/commonerrors", - text: "Common errors" - }, - { link: "/smartAccountsV2/troubleshooting/polyfill", text: "Polyfill" } - ] - }, - { link: "/smartAccountsV2/FAQ", text: "FAQ" }, - { link: "/smartAccountsV2/supportedNetworks", text: "SupportedNetworks" } -]; -var vocs_config_default = defineConfig({ - ogImageUrl: "https://vocs.dev/api/og?logo=%logo&title=%title&description=%description", - description: "Biconomy is the universal interface to all blockchains", - title: "Biconomy", - titleTemplate: "%s | Biconomy Docs", - rootDir: "./docs", - editLink: { - pattern: "https://github.com/bcnmy/documentation/edit/develop/docs/pages/:path", - text: "Edit on GitHub" - }, - iconUrl: { - dark: "https://i.imgur.com/WyX6ebY.png", - light: "https://i.imgur.com/WyX6ebY.png" - }, - logoUrl: { - dark: "https://i.imgur.com/Mt2TmLl.png", - light: "https://i.imgur.com/Mt2TmLl.png" - }, - theme: { - accentColor: "#ec5d31", - variables: { - sidebar: { - width: "350px", - horizontalPadding: "40px", - verticalPadding: "20px" - } - } - }, - socials: [ - { - icon: "x", - link: "https://x.com/biconomy" - } - ], - topNav: [ - { text: "Examples", link: "https://github.com/bcnmy/examples" }, - // { - // text: "API Docs", - // link: "https://bcnmy.github.io/abstractjs", - // }, - { - text: "Biconomy Network", - items: [ - { - text: "Overview", - link: "https://blog.biconomy.io/launching-biconomy-network-the-application-layer-to-make-a-thousand-chains-feel-like-one-2/" - }, - { - text: "Litepaper", - link: "https://blog.biconomy.io/launching-biconomy-network-the-application-layer-to-make-a-thousand-chains-feel-like-one-2/" - } - ] - } - ], - sidebar: [ - { - text: "Why Biconomy?", - link: "/about" - }, - { - text: "Supported Chains", - link: "/supportedNetworks" - }, - { - text: "Pricing", - link: "/pricing" - }, - { - text: "Get API Key", - link: "/api-key" - }, - { - text: "Modular Execution Environment (MEE)", - items: [ - { - text: "What is MEE", - link: "/mee/what-is-mee" - }, - { - text: "MEE vs. ERC-4337", - link: "/mee/mee-vs-4337" - } - ] - }, - { - text: "QuickStart Guides", - items: [ - { - text: "Multichain Orchestration", - link: "/multichain-orchestration/quickstart" - }, - { - text: "Pay for Gas With ERC-20 Tokens", - link: "/multichain-gas-abstraction/for-sca" - }, - { - text: "EIP-7702 for Embedded Wallets", - collapsed: true, - items: [ - { - text: "Gas Abstracted Batch Execute w/ Privy", - link: "/smarteoa/demos/privy-7702-gasless" - }, - { - text: "Gas Abstracted Batch Execute w/ Turnkey", - link: "/smarteoa/demos/turnkey-7702-gasless" - }, - { - text: "In-Depth Tutorial w/ Privy", - link: "/smarteoa/demos/privy-7702-demo" - } - ] - } - // { - // text: 'EIP-7702 for External Wallets', - // collapsed: true, - // items: [ - // { - // text: 'Batch Execute from EOA with ERC-5792', - // link: '/smarteoa/demos/batch-execute-5792-fusion' - // }, - // { - // text: 'Batch Execute from EOA with Fusion' - // } - // ] - // } - ] - }, - { - text: "Multichain Orchestration APIs", - collapsed: true, - items: [ - { - text: "Overview", - link: "/multichain-orchestration/overview" - }, - { - text: "Zero-to-Hero Guide", - link: "/multichain-orchestration/comprehensive" - }, - { - text: "Using Different Account Types", - items: [ - { - text: "Native EOA", - link: "/multichain-orchestration/eoa" - }, - { - text: "Smart Account", - link: "/multichain-orchestration/sca" - }, - { - text: "EIP-7702 EOA", - link: "/multichain-orchestration/eip7702" - } - ] - }, - { - text: "Learn Concepts", - items: [ - { - text: "Runtime Parameter Injection", - link: "/multichain-orchestration/runtimeinjection" - } - ] - }, - { - text: "Instruction Builders", - collapsed: true, - items: [ - { - text: "Overview", - link: "/multichain-orchestration/instruction-builders/overview" - }, - { - text: "Default", - link: "/multichain-orchestration/instruction-builders/default" - }, - { - text: "Multichain", - link: "/multichain-orchestration/instruction-builders/multichain" - }, - { - text: "Composable", - link: "/multichain-orchestration/instruction-builders/composable" - }, - { - text: "Raw CallData", - link: "/multichain-orchestration/instruction-builders/rawcalldata" - } - ] - } - ] - }, - { - text: "Smart EOAs (EIP-7702 & Fusion)", - collapsed: true, - items: [ - { text: "Overview", link: "/smarteoa" }, - { text: "Explained", items: [ - { text: "EIP-7702 Explained", link: "/eip7702/explained" }, - { text: "Companion Accounts Explained", link: "/smarteoa/companion-explained" } - ] }, - { text: "Developer Guides", items: [ - { text: "dApps using External Wallets", link: "/mee/fusion" }, - { text: "dApps using Embedded Wallets", link: "/eip7702/wallet-guide" }, - { text: "MetaMask Delegator Framework", link: "/smarteoa/delegator" } - ] } - ] - }, - { - text: "Signer Guides", - collapsed: true, - items: [ - { text: "Privy", link: "/tutorials/signers/privy" }, - { text: "Web3Auth", link: "/tutorials/signers/web3auth" }, - { text: "Magic", link: "/tutorials/signers/magic" }, - { text: "Particle", link: "/tutorials/signers/particle" }, - { text: "Passport", link: "/tutorials/signers/passport" }, - { text: "Turnkey", link: "/tutorials/signers/turnkey" }, - { text: "Dynamic", link: "/tutorials/signers/dynamic" }, - { text: "Capsule", link: "/tutorials/signers/capsule" }, - { text: "DFNS", link: "/tutorials/signers/dfns" } - ] - }, - { - text: "Smart Accounts", - collapsed: true, - items: [ - { text: "Smart Accounts Overview", link: "/account-providers/overview" }, - { text: "Nexus Smart Account", link: "/overview", collapsed: true }, - { text: "EIP-7702: Smart EOAs Overview", link: "/eip7702/wallet-guide" }, - { text: "Companion Accounts Overview", link: "/mee/fusion" } - ] - }, - { - text: "Gas Abstraction APIs", - collapsed: true, - items: [ - { - text: "Overview", - link: "/multichain-gas-abstraction/overview" - }, - { - text: "Paying for Gas with ERC20 Tokens", - items: [ - { - text: "For EOA Accounts", - link: "/multichain-gas-abstraction/for-eoa" - }, - { - text: "For Smart Accounts", - link: "/multichain-gas-abstraction/for-sca" - } - ] - }, - { - text: "Sponsoring Gas For Users", - link: "/multichain-gas-abstraction/sponsoring-gas" - } - ] - }, - { - text: "Smart Sessions APIs", - collapsed: true, - items: [ - { - text: "Overview", - link: "/multichain-smart-sessions/overview" - }, - { - text: "Single Chain", - items: [ - { - text: "Granting a Smart Session", - link: "/multichain-smart-sessions/grant" - }, - { - text: "Redeeming a Smart Session", - link: "/multichain-smart-sessions/redeem" - } - ] - } - ] - }, - { - text: "Learn Concepts", - collapsed: true, - items: [ - { - text: "EIP-7702 Guide for Apps \u{1F517}", - link: "https://blog.biconomy.io/a-comprehensive-eip-7702-guide-for-apps/" - }, - { - text: "Companion Accounts & Fusion \u{1F517}", - link: "https://blog.biconomy.io/introduction-to-companion-accounts-fusion/" - }, - { - text: "Supertransactions \u{1F517}", - link: "https://blog.biconomy.io/introduction-to-supertransactions-2/" - }, - { - text: "Compsability Stack \u{1F517}", - link: "https://blog.biconomy.io/introduction-to-the-composability-stack/" - }, - { - text: "Modular Execution Environment \u{1F517}", - link: "https://blog.biconomy.io/learn-modular-execution-environment-mee/" - } - ] - }, - { - text: "Resources", - collapsed: true, - items: [ - { text: "Contracts & Audits", link: "/contractsAndAudits" }, - { text: "Supported Networks", link: "/supportedNetworks" } - ] - }, - { - text: "Demos", - collapsed: true, - items: [ - { - text: "#001 SmartSessions", - link: "/demos/smartSessions" - }, - { - text: "#002 Fusion", - link: "/demos/fusion" - } - ] - }, - { - text: "SDK Reference", - collapsed: true, - link: "/sdk-reference", - items: [ - { - text: "MEE Client", - link: "/sdk-reference/mee-client", - collapsed: false, - items: [ - { - text: "Multichain Account", - link: "/sdk-reference/mee-client/account", - collapsed: false, - items: [ - { - text: "build", - link: "/sdk-reference/mee-client/account/methods/build" - }, - { - text: "buildComposable", - link: "/sdk-reference/mee-client/account/methods/buildComposable" - }, - { - text: "more*", - collapsed: true, - items: [ - { - text: "deploymentOn", - link: "/sdk-reference/mee-client/account/methods/more/deploymentOn" - }, - { - text: "addressOn", - link: "/sdk-reference/mee-client/account/methods/more/addressOn" - }, - { - text: "isDelegated", - link: "/sdk-reference/mee-client/account/methods/more/isDelegated" - }, - { - text: "unDelegate", - link: "/sdk-reference/mee-client/account/methods/more/unDelegate" - }, - { - text: "waitForTransactionReceipts", - link: "/sdk-reference/mee-client/account/methods/more/waitForTransactionReceipts" - } - ] - } - ] - }, - { - text: "Methods", - link: "/sdk-reference/mee-client/methods", - collapsed: false, - items: [ - { - text: "getQuote", - link: "/sdk-reference/mee-client/methods/getQuote" - }, - { - text: "executeQuote", - link: "/sdk-reference/mee-client/methods/executeQuote" - }, - { - text: "getFusionQuote", - link: "/sdk-reference/mee-client/methods/getFusionQuote" - }, - { - text: "executeFusionQuote", - link: "/sdk-reference/mee-client/methods/executeFusionQuote" - }, - { - text: "waitForSuperTransactionReceipt", - link: "/sdk-reference/mee-client/methods/waitForSuperTransactionReceipt" - }, - { - text: "more*", - collapsed: true, - items: [ - { - text: "getSuperTransactionReceipt", - link: "/sdk-reference/mee-client/methods/more/getSuperTransactionReceipt" - }, - { - text: "execute", - link: "/sdk-reference/mee-client/methods/more/execute" - }, - { - text: "executeSignedQuote", - link: "/sdk-reference/mee-client/methods/more/executeSignedQuote" - }, - { - text: "signQuote", - link: "/sdk-reference/mee-client/methods/more/signQuote" - }, - { - text: "getGasToken", - link: "/sdk-reference/mee-client/methods/more/getGasToken" - }, - { - text: "getInfo", - link: "/sdk-reference/mee-client/methods/more/getInfo" - }, - { - text: "getOnChainQuote", - link: "/sdk-reference/mee-client/methods/more/getOnChainQuote" - }, - { - text: "getPermitQuote", - link: "/sdk-reference/mee-client/methods/more/getPermitQuote" - }, - { - text: "signOnChainQuote", - link: "/sdk-reference/mee-client/methods/more/signOnChainQuote" - }, - { - text: "signPermitQuote", - link: "/sdk-reference/mee-client/methods/more/signPermitQuote" - }, - { - text: "getPaymentToken", - link: "/sdk-reference/mee-client/methods/more/getPaymentToken" - } - ] - } - ] - }, - { - text: "Helpers", - link: "/sdk-reference/mee-client/helpers", - collapsed: true, - items: [ - { - text: "runtimeERC20BalanceOf", - link: "/sdk-reference/mee-client/helpers/runtimeERC20BalanceOf" - }, - { - text: "runtimeEncodeAbiParameters", - link: "/sdk-reference/mee-client/helpers/runtimeEncodeAbiParameters" - }, - { - text: "getMultichainContract", - link: "/sdk-reference/mee-client/helpers/getMultichainContract" - }, - { - text: "more*", - collapsed: true, - items: [ - { - text: "mcUSDC", - link: "/sdk-reference/mee-client/helpers/more/mcUSDC" - }, - { - text: "getExplorerTxLink", - link: "/sdk-reference/mee-client/helpers/more/getExplorerTxLink" - }, - { - text: "getMeeScanLink", - link: "/sdk-reference/mee-client/helpers/more/getMeeScanLink" - }, - { - text: "getJiffyScanLink", - link: "/sdk-reference/mee-client/helpers/more/getJiffyScanLink" - }, - { - text: "mcAaveV3Pool ", - link: "/sdk-reference/mee-client/helpers/more/mcAaveV3Pool" - }, - { - text: "mcUniswapSwapRouter", - link: "/sdk-reference/mee-client/helpers/more/mcUniswapSwapRouter" - } - ] - } - ] - } - ] - }, - { - text: "Bundler Client", - collapsed: true, - link: "/sdk-reference/bundler-client", - items: [ - { - text: "Account", - link: "/sdk-reference/bundler-client/account" - }, - { - text: "Methods", - link: "/sdk-reference/bundler-client/methods", - collapsed: false, - items: [ - { - text: "sendUserOperation", - link: "/sdk-reference/bundler-client/methods/sendUserOperation" - }, - { - text: "waitForUserOperationReceipt", - link: "/sdk-reference/bundler-client/methods/waitForUserOperationReceipt" - }, - { - text: "debugUserOperation", - link: "/sdk-reference/bundler-client/methods/debugUserOperation" - }, - { - text: "prepareTokenPaymasterUserOp", - link: "/sdk-reference/bundler-client/methods/prepareTokenPaymasterUserOp" - }, - { - text: "sendTokenPaymasterUserOp", - link: "/sdk-reference/bundler-client/methods/sendTokenPaymasterUserOp" - }, - { - text: "upgradeSmartAccount", - link: "/sdk-reference/bundler-client/methods/upgradeSmartAccount" - }, - { - text: "more*", - collapsed: true, - items: [ - { - text: "estimateUserOperationGas", - link: "/sdk-reference/bundler-client/methods/more/estimateUserOperationGas" - }, - { - text: "getUserOperation", - link: "/sdk-reference/bundler-client/methods/more/getUserOperation" - }, - { - text: "getUserOperationReceipt", - link: "/sdk-reference/bundler-client/methods/more/getUserOperationReceipt" - }, - { - text: "getSupportedEntryPoints", - link: "/sdk-reference/bundler-client/methods/more/getSupportedEntryPoints" - }, - { - text: "getChainId", - link: "/sdk-reference/bundler-client/methods/more/getChainId" - }, - { - text: "sendTransaction", - link: "/sdk-reference/bundler-client/methods/more/sendTransaction" - }, - { - text: "writeContract", - link: "/sdk-reference/bundler-client/methods/more/writeContract" - }, - { - text: "signMessage", - link: "/sdk-reference/bundler-client/methods/more/signMessage" - }, - { - text: "prepareUserOperationWithoutSignature", - link: "/sdk-reference/bundler-client/methods/more/prepareUserOperationWithoutSignature" - }, - { - text: "prepareUserOperation", - link: "/sdk-reference/bundler-client/methods/more/prepareUserOperation" - }, - { - text: "getGasFeeValues", - link: "/sdk-reference/bundler-client/methods/more/getGasFeeValues" - }, - { - text: "getUserOperationStatus", - link: "/sdk-reference/bundler-client/methods/more/getUserOperationStatus" - }, - { - text: "waitForConfirmedUserOperationReceipt", - link: "/sdk-reference/bundler-client/methods/more/waitForConfirmedUserOperationReceipt" - }, - { - text: "accountId", - link: "/sdk-reference/bundler-client/methods/more/accountId" - }, - { - text: "getActiveHook", - link: "/sdk-reference/bundler-client/methods/more/getActiveHook" - }, - { - text: "getFallbackBySelector", - link: "/sdk-reference/bundler-client/methods/more/getFallbackBySelector" - }, - { - text: "getInstalledExecutors", - link: "/sdk-reference/bundler-client/methods/more/getInstalledExecutors" - }, - { - text: "getInstalledValidators", - link: "/sdk-reference/bundler-client/methods/more/getInstalledValidators" - }, - { - text: "installModule", - link: "/sdk-reference/bundler-client/methods/more/installModule" - }, - { - text: "isModuleInstalled", - link: "/sdk-reference/bundler-client/methods/more/isModuleInstalled" - }, - { - text: "supportsExecutionMode", - link: "/sdk-reference/bundler-client/methods/more/supportsExecutionMode" - }, - { - text: "supportsModule", - link: "/sdk-reference/bundler-client/methods/more/supportsModule" - }, - { - text: "uninstallModule", - link: "/sdk-reference/bundler-client/methods/more/uninstallModule" - } - ] - } - ] - } - ] - } - ] - }, - { - text: "Account Migrations", - link: "/migrations", - collapsed: false, - items: [ - { - text: "V2 to Nexus Migration", - link: "/migrations/v2ToNexus" - }, - { - text: "Nexus to Nexus Migration", - link: "/migrations/nexusToNexus" - } - ] - }, - { - text: "Legacy Account Abstraction Docs", - collapsed: true, - items: [ - { - collapsed: true, - text: "V2 Accounts & EPv6 Infra", - items: smartAccountsV2Sidebar - }, - { text: "V1 Docs", link: "https://legacy-docs.biconomy.io/" } - ] - } - ] -}); -export { - vocs_config_default as default, - smartAccountsV2Sidebar -}; -//# sourceMappingURL=data:application/json;base64,ewogICJ2ZXJzaW9uIjogMywKICAic291cmNlcyI6IFsidm9jcy5jb25maWcudHMiXSwKICAic291cmNlc0NvbnRlbnQiOiBbImNvbnN0IF9fdml0ZV9pbmplY3RlZF9vcmlnaW5hbF9kaXJuYW1lID0gXCIvVXNlcnMvbWlja2V5L0RldmVsb3BtZW50L0JpY29ub215L2Fic3RyYWN0LWRvY3MvYWJzdHJhY3QtanMtYnktYmljb25vbXlcIjtjb25zdCBfX3ZpdGVfaW5qZWN0ZWRfb3JpZ2luYWxfZmlsZW5hbWUgPSBcIi9Vc2Vycy9taWNrZXkvRGV2ZWxvcG1lbnQvQmljb25vbXkvYWJzdHJhY3QtZG9jcy9hYnN0cmFjdC1qcy1ieS1iaWNvbm9teS92b2NzLmNvbmZpZy50c1wiO2NvbnN0IF9fdml0ZV9pbmplY3RlZF9vcmlnaW5hbF9pbXBvcnRfbWV0YV91cmwgPSBcImZpbGU6Ly8vVXNlcnMvbWlja2V5L0RldmVsb3BtZW50L0JpY29ub215L2Fic3RyYWN0LWRvY3MvYWJzdHJhY3QtanMtYnktYmljb25vbXkvdm9jcy5jb25maWcudHNcIjtpbXBvcnQgeyBkZWZpbmVDb25maWcgfSBmcm9tIFwidm9jc1wiO1xuXG5leHBvcnQgY29uc3Qgc21hcnRBY2NvdW50c1YyU2lkZWJhciA9IFtcblx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvb3ZlcnZpZXdcIiwgdGV4dDogXCJPdmVydmlld1wiIH0sXG5cdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL3F1aWNrc3RhcnQtcmVhY3RcIiwgdGV4dDogXCJRdWlja3N0YXJ0OiBSZWFjdFwiIH0sXG5cdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL3F1aWNrc3RhcnRcIiwgdGV4dDogXCJRdWlja3N0YXJ0OiBDb3JlIFNES1wiIH0sXG5cdHtcblx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3RcIixcblx0XHR0ZXh0OiBcIlJlYWN0XCIsXG5cdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdGl0ZW1zOiBbXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9yZWFjdC9CaWNvbm9teVByb3ZpZGVyXCIsXG5cdFx0XHRcdHRleHQ6IFwiQmljb25vbXlQcm92aWRlclwiLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3JlYWN0L3VzZUJhdGNoU2Vzc2lvblwiLFxuXHRcdFx0XHR0ZXh0OiBcIlVzZUJhdGNoU2Vzc2lvblwiLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3JlYWN0L3VzZUNyZWF0ZUJhdGNoU2Vzc2lvblwiLFxuXHRcdFx0XHR0ZXh0OiBcIlVzZUNyZWF0ZUJhdGNoU2Vzc2lvblwiLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3JlYWN0L3VzZUNyZWF0ZVNlc3Npb25cIixcblx0XHRcdFx0dGV4dDogXCJVc2VDcmVhdGVTZXNzaW9uXCIsXG5cdFx0XHR9LFxuXHRcdFx0e1xuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3QvdXNlRGVwbG95U21hcnRBY2NvdW50XCIsXG5cdFx0XHRcdHRleHQ6IFwiVXNlRGVwbG95U21hcnRBY2NvdW50XCIsXG5cdFx0XHR9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3QvdXNlR2FzRXN0aW1hdGVcIiwgdGV4dDogXCJVc2VHYXNFc3RpbWF0ZVwiIH0sXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9yZWFjdC91c2VTZW5kR2FzVG9rZW5UcmFuc2FjdGlvblwiLFxuXHRcdFx0XHR0ZXh0OiBcIlVzZVNlbmRHYXNUb2tlblRyYW5zYWN0aW9uXCIsXG5cdFx0XHR9LFxuXHRcdFx0e1xuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3QvdXNlU2VuZFNwb25zb3JlZFRyYW5zYWN0aW9uXCIsXG5cdFx0XHRcdHRleHQ6IFwiVXNlU2VuZFNwb25zb3JlZFRyYW5zYWN0aW9uXCIsXG5cdFx0XHR9LFxuXHRcdFx0e1xuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3QvdXNlU2VuZFRyYW5zYWN0aW9uXCIsXG5cdFx0XHRcdHRleHQ6IFwiVXNlU2VuZFRyYW5zYWN0aW9uXCIsXG5cdFx0XHR9LFxuXHRcdFx0e1xuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3QvdXNlU2VuZFdpdGhkcmF3YWxzXCIsXG5cdFx0XHRcdHRleHQ6IFwiVXNlU2VuZFdpdGhkcmF3YWxzXCIsXG5cdFx0XHR9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3QvdXNlU2Vzc2lvblwiLCB0ZXh0OiBcIlVzZVNlc3Npb25cIiB9LFxuXHRcdFx0e1xuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3QvdXNlU21hcnRBY2NvdW50XCIsXG5cdFx0XHRcdHRleHQ6IFwiVXNlU21hcnRBY2NvdW50XCIsXG5cdFx0XHR9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcmVhY3QvdXNlVG9rZW5GZWVzXCIsIHRleHQ6IFwiVXNlVG9rZW5GZWVzXCIgfSxcblx0XHRcdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL3JlYWN0L3VzZVVzZXJPcFdhaXRcIiwgdGV4dDogXCJVc2VVc2VyT3BXYWl0XCIgfSxcblx0XHRdLFxuXHR9LFxuXHR7XG5cdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFsc1wiLFxuXHRcdHRleHQ6IFwiVHV0b3JpYWxzXCIsXG5cdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdGl0ZW1zOiBbXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi90dXRvcmlhbHMvc2VuZFNpbXBsZVRyYW5zYWN0aW9uXCIsXG5cdFx0XHRcdHRleHQ6IFwiU2VuZCBhIHNpbXBsZSB0cmFuc2FjdGlvblwiLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy9zZW5kVHJhbnNhY3Rpb25zQmF0Y2hcIixcblx0XHRcdFx0dGV4dDogXCJTZW5kIHRyYW5zYWN0aW9ucyBiYXRjaFwiLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy9zZW5kR2FzbGVzc1wiLFxuXHRcdFx0XHR0ZXh0OiBcIlNlbmQgYSBnYXNsZXNzIHRyYW5zYWN0aW9uXCIsXG5cdFx0XHR9LFxuXHRcdFx0e1xuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvdHV0b3JpYWxzL3BheUVSQzIwVG9rZW5cIixcblx0XHRcdFx0dGV4dDogXCJQYXkgZ2FzIGluIEVSQzIwIHRva2VuXCIsXG5cdFx0XHR9LFxuXHRcdFx0e1xuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvdHV0b3JpYWxzL3BhcmFsbGVsVXNlck9wc1wiLFxuXHRcdFx0XHR0ZXh0OiBcIlNlbmQgcGFyYWxsZWwgdXNlck9wc1wiLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy9zZXNzaW9uc1wiLFxuXHRcdFx0XHR0ZXh0OiBcIlNlc3Npb25zXCIsXG5cdFx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy9zZXNzaW9ucy9jcmVhdGVTZXNzaW9uXCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcIkNyZWF0ZSBTZXNzaW9uXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvdHV0b3JpYWxzL3Nlc3Npb25zL3VzZVNlc3Npb25cIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiVXNlIFNlc3Npb25cIixcblx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi90dXRvcmlhbHMvc2Vzc2lvbnMvY3JlYXRlQmF0Y2hTZXNzaW9uXCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcIkNyZWF0ZSBCYXRjaCBTZXNzaW9uXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvdHV0b3JpYWxzL3Nlc3Npb25zL3VzZUJhdGNoU2Vzc2lvblwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJVc2UgQmF0Y2ggU2Vzc2lvblwiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy9zZXNzaW9ucy9jdXN0b21TZXNzaW9uU3RvcmFnZVwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJDdXN0b20gU2Vzc2lvbiBTdG9yYWdlXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XSxcblx0XHRcdH0sXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi90dXRvcmlhbHMvY3VzdG9tVmFsaWRhdGlvbk1vZHVsZVwiLFxuXHRcdFx0XHR0ZXh0OiBcIkN1c3RvbSBWYWxpZGF0aW9uIE1vZHVsZVwiLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy91dGlsc1wiLFxuXHRcdFx0XHR0ZXh0OiBcIlV0aWxzXCIsXG5cdFx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy91dGlscy9vZmZzZXRHYXNWYWx1ZXNcIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiT2Zmc2V0IEdhcyBWYWx1ZXNcIixcblx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi90dXRvcmlhbHMvdXRpbHMvdHJhbnNmZXJPd25lcnNoaXBcIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiVHJhbnNmZXIgT3duZXJzaGlwXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XSxcblx0XHRcdH0sXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi90dXRvcmlhbHMvYXBpSW50ZWdyYXRpb25cIixcblx0XHRcdFx0dGV4dDogXCJBUEkgSW50ZWdyYXRpb25cIixcblx0XHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi90dXRvcmlhbHMvYXBpSW50ZWdyYXRpb24vdXNlclNwb25zb3JlZFwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJVc2VyIHNwb25zb3JlZFwiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy9hcGlJbnRlZ3JhdGlvbi9wYXltYXN0ZXJTcG9uc29yZWRcIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiUGF5bWFzdGVyIFNwb25zb3JlZFwiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy9hcGlJbnRlZ3JhdGlvbi9wYXltYXN0ZXJFUkMyMFwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJQYXltYXN0ZXIgRVJDMjBcIixcblx0XHRcdFx0XHR9LFxuXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3R1dG9yaWFscy9hcGlJbnRlZ3JhdGlvbi9zaWduVXNlck9wZXJhdGlvblwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJTaWduIHVzZXJPcFwiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdF0sXG5cdFx0XHR9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvdHV0b3JpYWxzL3Y0TWlncmF0aW9uXCIsIHRleHQ6IFwiVjQgTWlncmF0aW9uXCIgfSxcblx0XHRcdHtcblx0XHRcdFx0dGV4dDogXCJNaWdyYXRlIGZyb20gc3RhY2tVcFwiLFxuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvdHV0b3JpYWxzL21pZ3JhdGVcIixcblx0XHRcdH0sXG5cdFx0XSxcblx0fSxcblx0e1xuXHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hY2NvdW50XCIsXG5cdFx0dGV4dDogXCJTbWFydCBBY2NvdW50XCIsXG5cdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdGl0ZW1zOiBbXG5cdFx0XHR7IGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hY2NvdW50L2ludGVncmF0aW9uXCIsIHRleHQ6IFwiSW50ZWdyYXRpb25cIiB9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvYWNjb3VudC9tZXRob2RzXCIsIHRleHQ6IFwiTWV0aG9kc1wiIH0sXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hY2NvdW50L3NpZ25lcnNcIixcblx0XHRcdFx0dGV4dDogXCJTaWduZXJzXCIsXG5cdFx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL2FjY291bnQvc2lnbmVycy9lb2FcIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiRW9hXCIsXG5cdFx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL2FjY291bnQvc2lnbmVycy9lb2EvZXRoZXJzXCIsXG5cdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJFdGhlcnNcIixcblx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hY2NvdW50L3NpZ25lcnMvZW9hL3ZpZW1cIixcblx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcIlZpZW1cIixcblx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hY2NvdW50L3NpZ25lcnMvZW9hL3dhZ21pXCIsXG5cdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJXYWdtaVwiLFxuXHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XSxcblx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL2FjY291bnQvc2lnbmVycy9jYXBzdWxlXCIsIHRleHQ6IFwiQ2Fwc3VsZVwiIH0sXG5cdFx0XHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvYWNjb3VudC9zaWduZXJzL2RmbnNcIiwgdGV4dDogXCJEZm5zXCIgfSxcblx0XHRcdFx0XHR7IGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hY2NvdW50L3NpZ25lcnMvZHluYW1pY1wiLCB0ZXh0OiBcIkR5bmFtaWNcIiB9LFxuXHRcdFx0XHRcdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL2FjY291bnQvc2lnbmVycy9tYWdpY1wiLCB0ZXh0OiBcIk1hZ2ljXCIgfSxcblx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvYWNjb3VudC9zaWduZXJzL3BhcnRpY2xlXCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcIlBhcnRpY2xlXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvYWNjb3VudC9zaWduZXJzL3Bhc3Nwb3J0XCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcIlBhc3Nwb3J0XCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XHR7IGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hY2NvdW50L3NpZ25lcnMvcHJpdnlcIiwgdGV4dDogXCJQcml2eVwiIH0sXG5cdFx0XHRcdFx0eyBsaW5rOiBcIi9hY2NvdW50L3NpZ25lcnMvdHVybmtleVwiLCB0ZXh0OiBcIlR1cm5rZXlcIiB9LFxuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hY2NvdW50L3NpZ25lcnMvd2ViM2F1dGhcIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiV2ViM2F1dGhcIixcblx0XHRcdFx0XHR9LFxuXHRcdFx0XHRdLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL2FjY291bnQvZmlhdG9ucmFtcFwiLFxuXHRcdFx0XHR0ZXh0OiBcIkVuYWJsZSBGaWF0IE9uLVJhbXBcIixcblx0XHRcdH0sXG5cdFx0XSxcblx0fSxcblx0e1xuXHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9idW5kbGVyXCIsXG5cdFx0dGV4dDogXCJCdW5kbGVyXCIsXG5cdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdGl0ZW1zOiBbXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9idW5kbGVyL2FwaVwiLFxuXHRcdFx0XHR0ZXh0OiBcIkFwaVwiLFxuXHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL2J1bmRsZXIvYXBpL2V4cGxvcmVyXCIsIHRleHQ6IFwiRXhwbG9yZXJcIiB9LFxuXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL2J1bmRsZXIvYXBpL2VzdGltYXRlLXVzZXJvcGVyYXRpb24tZ2FzXCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcImV0aF9lc3RpbWF0ZVVzZXJPcGVyYXRpb25HYXNcIixcblx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9idW5kbGVyL2FwaS9zZW5kLVVzZXJPcGVyYXRpb25cIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiZXRoX3NlbmRVc2VyT3BlcmF0aW9uXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvYnVuZGxlci9hcGkvZ2V0LXVzZXJvcGVyYXRpb24tcmVjZWlwdFwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJldGhfZ2V0VXNlck9wZXJhdGlvblJlY2VpcHRcIixcblx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9idW5kbGVyL2FwaS9nZXQtdXNlcm9wZXJhdGlvbi1ieS1oYXNoXCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcImV0aF9nZXRVc2VyT3BlcmF0aW9uQnlIYXNoXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XHR7IGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9idW5kbGVyL2FwaS9jaGFpbklkXCIsIHRleHQ6IFwiZXRoX2NoYWluSWRcIiB9LFxuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9idW5kbGVyL2FwaS9zdXBwb3J0ZWQtRW50cnlQb2ludHNcIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiZXRoX3N1cHBvcnRlZEVudHJ5UG9pbnRzXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvYnVuZGxlci9hcGkvZ2V0LWdhcy1mZWUtdmFsdWVzXCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcImJpY29ub215X2dldEdhc0ZlZVZhbHVlc1wiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL2J1bmRsZXIvYXBpL2dldC11c2Vyb3BlcmF0aW9uLXN0YXR1c1wiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJiaWNvbm9teV9nZXRVc2VyT3BlcmF0aW9uU3RhdHVzXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XSxcblx0XHRcdH0sXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9idW5kbGVyL2J1bmRsZXJtZXRob2RzXCIsXG5cdFx0XHRcdHRleHQ6IFwiQnVuZGxlciBNZXRob2RzXCIsXG5cdFx0XHR9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvYnVuZGxlci9pbnRlZ3JhdGlvblwiLCB0ZXh0OiBcIkludGVncmF0aW9uXCIgfSxcblx0XHRcdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL2J1bmRsZXIvdXNpbmdWaWVtXCIsIHRleHQ6IFwiVXNpbmcgVmllbVwiIH0sXG5cdFx0XSxcblx0fSxcblx0e1xuXHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9wYXltYXN0ZXJcIixcblx0XHR0ZXh0OiBcIlBheW1hc3RlclwiLFxuXHRcdGNvbGxhcHNlZDogdHJ1ZSxcblx0XHRpdGVtczogW1xuXHRcdFx0e1xuXHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcGF5bWFzdGVyLzc2NzdcIixcblx0XHRcdFx0dGV4dDogXCI3Njc3XCIsXG5cdFx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3BheW1hc3Rlci83Njc3L3BtX2dldFBheW1hc3RlckRhdGFcIixcblx0XHRcdFx0XHRcdHRleHQ6IFwicG1fZ2V0UGF5bWFzdGVyRGF0YVwiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3BheW1hc3Rlci83Njc3L3BtX2dldFBheW1hc3RlclN0dWJEYXRhXCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcInBtX2dldFBheW1hc3RlclN0dWJEYXRhXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XHQvLyB7IGxpbms6IFwiL3BheW1hc3Rlci83Njc3L3VzaW5nVmllbVwiLCB0ZXh0OiBcIlVzaW5nIFZpZW1cIiB9LFxuXHRcdFx0XHRdLFxuXHRcdFx0fSxcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3BheW1hc3Rlci9hcGlcIixcblx0XHRcdFx0dGV4dDogXCJBcGlcIixcblx0XHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcGF5bWFzdGVyL2FwaS9leHBsb3JlclwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJFeHBsb3JlclwiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3BheW1hc3Rlci9hcGkvZ2V0LWZlZS1xdW90ZXNcIixcblx0XHRcdFx0XHRcdHRleHQ6IFwicG1fZ2V0RmVlUXVvdGVPckRhdGFcIixcblx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9wYXltYXN0ZXIvYXBpL3Nwb25zb3ItdXNlcm9wZXJhdGlvblwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJwbV9zcG9uc29yVXNlck9wZXJhdGlvblwiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdF0sXG5cdFx0XHR9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcGF5bWFzdGVyL2ludGVncmF0aW9uXCIsIHRleHQ6IFwiSW50ZWdyYXRpb25cIiB9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvcGF5bWFzdGVyL21ldGhvZHNcIiwgdGV4dDogXCJNZXRob2RzXCIgfSxcblx0XHRdLFxuXHR9LFxuXHR7XG5cdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL2dhc0VzdGltYXRpb25zXCIsXG5cdFx0dGV4dDogXCJHYXMgRXN0aW1hdGlvbnNcIixcblx0XHRjb2xsYXBzZWQ6IHRydWUsXG5cdFx0aXRlbXM6IFtcblx0XHRcdHtcblx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL2dhc0VzdGltYXRpb25zL2ludGVncmF0aW9uXCIsXG5cdFx0XHRcdHRleHQ6IFwiSW50ZWdyYXRpb25cIixcblx0XHRcdH0sXG5cdFx0XHR7IGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9nYXNFc3RpbWF0aW9ucy9tZXRob2RzXCIsIHRleHQ6IFwiTWV0aG9kc1wiIH0sXG5cdFx0XSxcblx0fSxcblx0e1xuXHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9tb2R1bGVzXCIsXG5cdFx0dGV4dDogXCJNb2R1bGVzXCIsXG5cdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdGl0ZW1zOiBbXG5cdFx0XHR7IGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9tb2R1bGVzL2VjZHNhXCIsIHRleHQ6IFwiRWNkc2FcIiB9LFxuXHRcdFx0eyBsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvbW9kdWxlcy9tdWx0aWNoYWluXCIsIHRleHQ6IFwiTXVsdGljaGFpblwiIH0sXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9tb2R1bGVzL3Nlc3Npb25zXCIsXG5cdFx0XHRcdHRleHQ6IFwiU2Vzc2lvbnNcIixcblx0XHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRsaW5rOiBcIi9zbWFydEFjY291bnRzVjIvbW9kdWxlcy9zZXNzaW9ucy9hYmlTZXNzaW9uVmFsaWRhdGlvbk1vZHVsZVwiLFxuXHRcdFx0XHRcdFx0dGV4dDogXCJBYmlTZXNzaW9uVmFsaWRhdGlvbk1vZHVsZVwiLFxuXHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL21vZHVsZXMvc2Vzc2lvbnMvQmF0Y2hlZFNlc3Npb25cIixcblx0XHRcdFx0XHRcdHRleHQ6IFwiQmF0Y2hlZFNlc3Npb25cIixcblx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9tb2R1bGVzL3Nlc3Npb25zL3Nlc3Npb252YWxpZGF0aW9ubW9kdWxlXCIsXG5cdFx0XHRcdFx0XHR0ZXh0OiBcIlNlc3Npb252YWxpZGF0aW9ubW9kdWxlXCIsXG5cdFx0XHRcdFx0fSxcblx0XHRcdFx0XSxcblx0XHRcdH0sXG5cdFx0XSxcblx0fSxcblxuXHR7IGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9jb250cmFjdHNcIiwgdGV4dDogXCJDb250cmFjdHNcIiB9LFxuXHR7IGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi9hdWRpdHNcIiwgdGV4dDogXCJBdWRpdHNcIiB9LFxuXHR7XG5cdFx0bGluazogXCIvc21hcnRBY2NvdW50c1YyL3Ryb3VibGVzaG9vdGluZ1wiLFxuXHRcdHRleHQ6IFwiVHJvdWJsZXNob290aW5nXCIsXG5cdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdGl0ZW1zOiBbXG5cdFx0XHR7XG5cdFx0XHRcdGxpbms6IFwiL3NtYXJ0QWNjb3VudHNWMi90cm91Ymxlc2hvb3RpbmcvY29tbW9uZXJyb3JzXCIsXG5cdFx0XHRcdHRleHQ6IFwiQ29tbW9uIGVycm9yc1wiLFxuXHRcdFx0fSxcblx0XHRcdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL3Ryb3VibGVzaG9vdGluZy9wb2x5ZmlsbFwiLCB0ZXh0OiBcIlBvbHlmaWxsXCIgfSxcblx0XHRdLFxuXHR9LFxuXG5cdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL0ZBUVwiLCB0ZXh0OiBcIkZBUVwiIH0sXG5cdHsgbGluazogXCIvc21hcnRBY2NvdW50c1YyL3N1cHBvcnRlZE5ldHdvcmtzXCIsIHRleHQ6IFwiU3VwcG9ydGVkTmV0d29ya3NcIiB9LFxuXTtcblxuZXhwb3J0IGRlZmF1bHQgZGVmaW5lQ29uZmlnKHtcblx0b2dJbWFnZVVybDpcblx0XHRcImh0dHBzOi8vdm9jcy5kZXYvYXBpL29nP2xvZ289JWxvZ28mdGl0bGU9JXRpdGxlJmRlc2NyaXB0aW9uPSVkZXNjcmlwdGlvblwiLFxuXHRkZXNjcmlwdGlvbjpcblx0XHRcIkJpY29ub215IGlzIHRoZSB1bml2ZXJzYWwgaW50ZXJmYWNlIHRvIGFsbCBibG9ja2NoYWluc1wiLFxuXHR0aXRsZTogXCJCaWNvbm9teVwiLFxuXHR0aXRsZVRlbXBsYXRlOiBcIiVzIHwgQmljb25vbXkgRG9jc1wiLFxuXHRyb290RGlyOiBcIi4vZG9jc1wiLFxuXHRlZGl0TGluazoge1xuXHRcdHBhdHRlcm46XG5cdFx0XHRcImh0dHBzOi8vZ2l0aHViLmNvbS9iY25teS9kb2N1bWVudGF0aW9uL2VkaXQvZGV2ZWxvcC9kb2NzL3BhZ2VzLzpwYXRoXCIsXG5cdFx0dGV4dDogXCJFZGl0IG9uIEdpdEh1YlwiLFxuXHR9LFxuXHRpY29uVXJsOiB7XG5cdFx0ZGFyazogXCJodHRwczovL2kuaW1ndXIuY29tL1d5WDZlYlkucG5nXCIsXG5cdFx0bGlnaHQ6IFwiaHR0cHM6Ly9pLmltZ3VyLmNvbS9XeVg2ZWJZLnBuZ1wiLFxuXHR9LFxuXHRsb2dvVXJsOiB7XG5cdFx0ZGFyazogXCJodHRwczovL2kuaW1ndXIuY29tL010MlRtTGwucG5nXCIsXG5cdFx0bGlnaHQ6IFwiaHR0cHM6Ly9pLmltZ3VyLmNvbS9NdDJUbUxsLnBuZ1wiLFxuXHR9LFxuXHR0aGVtZToge1xuXHRcdGFjY2VudENvbG9yOiBcIiNlYzVkMzFcIixcblx0XHR2YXJpYWJsZXM6IHtcblx0XHRcdHNpZGViYXI6IHtcblx0XHRcdFx0d2lkdGg6ICczNTBweCcsXG5cdFx0XHRcdGhvcml6b250YWxQYWRkaW5nOiAnNDBweCcsXG5cdFx0XHRcdHZlcnRpY2FsUGFkZGluZzogJzIwcHgnXG5cdFx0XHR9LFxuXHRcdH1cblx0fSxcblx0c29jaWFsczogW1xuXHRcdHtcblx0XHRcdGljb246IFwieFwiLFxuXHRcdFx0bGluazogXCJodHRwczovL3guY29tL2JpY29ub215XCIsXG5cdFx0fSxcblx0XSxcblx0dG9wTmF2OiBbXG5cdFx0eyB0ZXh0OiBcIkV4YW1wbGVzXCIsIGxpbms6IFwiaHR0cHM6Ly9naXRodWIuY29tL2Jjbm15L2V4YW1wbGVzXCIgfSxcblx0XHQvLyB7XG5cdFx0Ly8gXHR0ZXh0OiBcIkFQSSBEb2NzXCIsXG5cdFx0Ly8gXHRsaW5rOiBcImh0dHBzOi8vYmNubXkuZ2l0aHViLmlvL2Fic3RyYWN0anNcIixcblx0XHQvLyB9LFxuXHRcdHtcblx0XHRcdHRleHQ6ICdCaWNvbm9teSBOZXR3b3JrJyxcblx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdHtcblx0XHRcdFx0XHR0ZXh0OiAnT3ZlcnZpZXcnLFxuXHRcdFx0XHRcdGxpbms6ICdodHRwczovL2Jsb2cuYmljb25vbXkuaW8vbGF1bmNoaW5nLWJpY29ub215LW5ldHdvcmstdGhlLWFwcGxpY2F0aW9uLWxheWVyLXRvLW1ha2UtYS10aG91c2FuZC1jaGFpbnMtZmVlbC1saWtlLW9uZS0yLydcblx0XHRcdFx0fSxcblx0XHRcdFx0e1xuXHRcdFx0XHRcdHRleHQ6ICdMaXRlcGFwZXInLFxuXHRcdFx0XHRcdGxpbms6ICdodHRwczovL2Jsb2cuYmljb25vbXkuaW8vbGF1bmNoaW5nLWJpY29ub215LW5ldHdvcmstdGhlLWFwcGxpY2F0aW9uLWxheWVyLXRvLW1ha2UtYS10aG91c2FuZC1jaGFpbnMtZmVlbC1saWtlLW9uZS0yLydcblx0XHRcdFx0fSxcblx0XHRcdF1cblx0XHR9XG5cdF0sXG5cdHNpZGViYXI6IFtcblx0XHR7XG5cdFx0XHR0ZXh0OiBcIldoeSBCaWNvbm9teT9cIixcblx0XHRcdGxpbms6IFwiL2Fib3V0XCIsXG5cdFx0fSxcblx0XHR7XG5cdFx0XHR0ZXh0OiBcIlN1cHBvcnRlZCBDaGFpbnNcIixcblx0XHRcdGxpbms6IFwiL3N1cHBvcnRlZE5ldHdvcmtzXCIsXG5cdFx0fSxcblx0XHR7XG5cdFx0XHR0ZXh0OiBcIlByaWNpbmdcIixcblx0XHRcdGxpbms6IFwiL3ByaWNpbmdcIixcblx0XHR9LFxuXHRcdHtcblx0XHRcdHRleHQ6ICdHZXQgQVBJIEtleScsXG5cdFx0XHRsaW5rOiAnL2FwaS1rZXknXG5cdFx0fSxcblx0XHR7XG5cdFx0XHR0ZXh0OiAnTW9kdWxhciBFeGVjdXRpb24gRW52aXJvbm1lbnQgKE1FRSknLFxuXHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0e1xuXHRcdFx0XHRcdHRleHQ6ICdXaGF0IGlzIE1FRScsXG5cdFx0XHRcdFx0bGluazogJy9tZWUvd2hhdC1pcy1tZWUnXG5cdFx0XHRcdH0sXG5cdFx0XHRcdHtcblx0XHRcdFx0XHR0ZXh0OiAnTUVFIHZzLiBFUkMtNDMzNycsXG5cdFx0XHRcdFx0bGluazogJy9tZWUvbWVlLXZzLTQzMzcnXG5cdFx0XHRcdH1cblx0XHRcdF1cblx0XHR9LFx0XG5cdFx0e1xuXHRcdFx0dGV4dDogJ1F1aWNrU3RhcnQgR3VpZGVzJyxcblx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdHtcblx0XHRcdFx0XHR0ZXh0OiAnTXVsdGljaGFpbiBPcmNoZXN0cmF0aW9uJyxcblx0XHRcdFx0XHRsaW5rOiAnL211bHRpY2hhaW4tb3JjaGVzdHJhdGlvbi9xdWlja3N0YXJ0J1xuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ1BheSBmb3IgR2FzIFdpdGggRVJDLTIwIFRva2VucycsXG5cdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLWdhcy1hYnN0cmFjdGlvbi9mb3Itc2NhJ1xuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ0VJUC03NzAyIGZvciBFbWJlZGRlZCBXYWxsZXRzJyxcblx0XHRcdFx0XHRjb2xsYXBzZWQ6IHRydWUsXG5cdFx0XHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdHRleHQ6ICdHYXMgQWJzdHJhY3RlZCBCYXRjaCBFeGVjdXRlIHcvIFByaXZ5Jyxcblx0XHRcdFx0XHRcdFx0XHRsaW5rOiAnL3NtYXJ0ZW9hL2RlbW9zL3ByaXZ5LTc3MDItZ2FzbGVzcydcblx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdHRleHQ6ICdHYXMgQWJzdHJhY3RlZCBCYXRjaCBFeGVjdXRlIHcvIFR1cm5rZXknLFxuXHRcdFx0XHRcdFx0XHRcdGxpbms6ICcvc21hcnRlb2EvZGVtb3MvdHVybmtleS03NzAyLWdhc2xlc3MnXG5cdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHR0ZXh0OiAnSW4tRGVwdGggVHV0b3JpYWwgdy8gUHJpdnknLFxuXHRcdFx0XHRcdFx0XHRcdGxpbms6ICcvc21hcnRlb2EvZGVtb3MvcHJpdnktNzcwMi1kZW1vJ1xuXHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdF1cblx0XHRcdFx0fSxcblx0XHRcdFx0Ly8ge1xuXHRcdFx0XHQvLyBcdHRleHQ6ICdFSVAtNzcwMiBmb3IgRXh0ZXJuYWwgV2FsbGV0cycsXG5cdFx0XHRcdC8vIFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0XHQvLyBcdGl0ZW1zOiBbXG5cdFx0XHRcdC8vIFx0XHR7XG5cdFx0XHRcdC8vIFx0XHRcdHRleHQ6ICdCYXRjaCBFeGVjdXRlIGZyb20gRU9BIHdpdGggRVJDLTU3OTInLFxuXHRcdFx0XHQvLyBcdFx0XHRsaW5rOiAnL3NtYXJ0ZW9hL2RlbW9zL2JhdGNoLWV4ZWN1dGUtNTc5Mi1mdXNpb24nXG5cdFx0XHRcdC8vIFx0XHR9LFxuXHRcdFx0XHQvLyBcdFx0e1xuXHRcdFx0XHQvLyBcdFx0XHR0ZXh0OiAnQmF0Y2ggRXhlY3V0ZSBmcm9tIEVPQSB3aXRoIEZ1c2lvbidcblx0XHRcdFx0Ly8gXHRcdH1cblx0XHRcdFx0Ly8gXHRdXG5cdFx0XHRcdC8vIH1cblx0XHRcdFx0XG5cdFx0XHRdXG5cdFx0fSxcblx0XHR7XG5cdFx0XHR0ZXh0OiAnTXVsdGljaGFpbiBPcmNoZXN0cmF0aW9uIEFQSXMnLFxuXHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0e1xuXHRcdFx0XHRcdHRleHQ6ICdPdmVydmlldycsXG5cdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLW9yY2hlc3RyYXRpb24vb3ZlcnZpZXcnXG5cdFx0XHRcdH0sXG5cdFx0XHRcdHtcblx0XHRcdFx0XHR0ZXh0OiAnWmVyby10by1IZXJvIEd1aWRlJyxcblx0XHRcdFx0XHRsaW5rOiAnL211bHRpY2hhaW4tb3JjaGVzdHJhdGlvbi9jb21wcmVoZW5zaXZlJ1xuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ1VzaW5nIERpZmZlcmVudCBBY2NvdW50IFR5cGVzJyxcblx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiAnTmF0aXZlIEVPQScsXG5cdFx0XHRcdFx0XHRcdGxpbms6ICcvbXVsdGljaGFpbi1vcmNoZXN0cmF0aW9uL2VvYSdcblx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdHRleHQ6ICdTbWFydCBBY2NvdW50Jyxcblx0XHRcdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLW9yY2hlc3RyYXRpb24vc2NhJ1xuXHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0dGV4dDogJ0VJUC03NzAyIEVPQScsXG5cdFx0XHRcdFx0XHRcdGxpbms6ICcvbXVsdGljaGFpbi1vcmNoZXN0cmF0aW9uL2VpcDc3MDInXG5cdFx0XHRcdFx0XHR9XG5cdFx0XHRcdFx0XVxuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ0xlYXJuIENvbmNlcHRzJyxcblx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiAnUnVudGltZSBQYXJhbWV0ZXIgSW5qZWN0aW9uJyxcblx0XHRcdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLW9yY2hlc3RyYXRpb24vcnVudGltZWluamVjdGlvbidcblx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XVxuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ0luc3RydWN0aW9uIEJ1aWxkZXJzJyxcblx0XHRcdFx0XHRjb2xsYXBzZWQ6IHRydWUsXG5cdFx0XHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0dGV4dDogJ092ZXJ2aWV3Jyxcblx0XHRcdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLW9yY2hlc3RyYXRpb24vaW5zdHJ1Y3Rpb24tYnVpbGRlcnMvb3ZlcnZpZXcnXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiAnRGVmYXVsdCcsXG5cdFx0XHRcdFx0XHRcdGxpbms6ICcvbXVsdGljaGFpbi1vcmNoZXN0cmF0aW9uL2luc3RydWN0aW9uLWJ1aWxkZXJzL2RlZmF1bHQnXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiAnTXVsdGljaGFpbicsXG5cdFx0XHRcdFx0XHRcdGxpbms6ICcvbXVsdGljaGFpbi1vcmNoZXN0cmF0aW9uL2luc3RydWN0aW9uLWJ1aWxkZXJzL211bHRpY2hhaW4nXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiAnQ29tcG9zYWJsZScsXG5cdFx0XHRcdFx0XHRcdGxpbms6ICcvbXVsdGljaGFpbi1vcmNoZXN0cmF0aW9uL2luc3RydWN0aW9uLWJ1aWxkZXJzL2NvbXBvc2FibGUnXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiAnUmF3IENhbGxEYXRhJyxcblx0XHRcdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLW9yY2hlc3RyYXRpb24vaW5zdHJ1Y3Rpb24tYnVpbGRlcnMvcmF3Y2FsbGRhdGEnXG5cdFx0XHRcdFx0XHR9XG5cdFx0XHRcdFx0XVxuXHRcdFx0XHR9XG5cdFx0XHRdXG5cdFx0fSxcblx0XHR7XG5cdFx0XHR0ZXh0OiAnU21hcnQgRU9BcyAoRUlQLTc3MDIgJiBGdXNpb24pJyxcblx0XHRcdGNvbGxhcHNlZDogdHJ1ZSxcblx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdHsgdGV4dDogXCJPdmVydmlld1wiLCBsaW5rOiAnL3NtYXJ0ZW9hJyB9LFxuXHRcdFx0XHR7IHRleHQ6ICdFeHBsYWluZWQnLCBpdGVtczogW1xuXHRcdFx0XHRcdHsgdGV4dDogXCJFSVAtNzcwMiBFeHBsYWluZWRcIiwgbGluazogJy9laXA3NzAyL2V4cGxhaW5lZCcgfSxcblx0XHRcdFx0XHR7IHRleHQ6ICdDb21wYW5pb24gQWNjb3VudHMgRXhwbGFpbmVkJywgbGluazogJy9zbWFydGVvYS9jb21wYW5pb24tZXhwbGFpbmVkJ30sXHRcblx0XHRcdFx0XX0sXG5cdFx0XHRcdHsgdGV4dDogJ0RldmVsb3BlciBHdWlkZXMnLCBpdGVtczogW1xuXHRcdFx0XHRcdHsgdGV4dDogJ2RBcHBzIHVzaW5nIEV4dGVybmFsIFdhbGxldHMnLCBsaW5rOiAnL21lZS9mdXNpb24nfSxcblx0XHRcdFx0XHR7IHRleHQ6ICdkQXBwcyB1c2luZyBFbWJlZGRlZCBXYWxsZXRzJywgbGluazogJy9laXA3NzAyL3dhbGxldC1ndWlkZSd9LFxuXHRcdFx0XHRcdHsgdGV4dDogJ01ldGFNYXNrIERlbGVnYXRvciBGcmFtZXdvcmsnLCBsaW5rOiAnL3NtYXJ0ZW9hL2RlbGVnYXRvcicgfVxuXHRcdFx0XHRdfVxuXHRcdFx0XHRcdF1cblx0XHR9LFxuXHRcdHtcblx0XHRcdHRleHQ6IFwiU2lnbmVyIEd1aWRlc1wiLFxuXHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0eyB0ZXh0OiBcIlByaXZ5XCIsIGxpbms6IFwiL3R1dG9yaWFscy9zaWduZXJzL3ByaXZ5XCIgfSxcblx0XHRcdFx0eyB0ZXh0OiBcIldlYjNBdXRoXCIsIGxpbms6IFwiL3R1dG9yaWFscy9zaWduZXJzL3dlYjNhdXRoXCIgfSxcblx0XHRcdFx0eyB0ZXh0OiBcIk1hZ2ljXCIsIGxpbms6IFwiL3R1dG9yaWFscy9zaWduZXJzL21hZ2ljXCIgfSxcblx0XHRcdFx0eyB0ZXh0OiBcIlBhcnRpY2xlXCIsIGxpbms6IFwiL3R1dG9yaWFscy9zaWduZXJzL3BhcnRpY2xlXCIgfSxcblx0XHRcdFx0eyB0ZXh0OiBcIlBhc3Nwb3J0XCIsIGxpbms6IFwiL3R1dG9yaWFscy9zaWduZXJzL3Bhc3Nwb3J0XCIgfSxcblx0XHRcdFx0eyB0ZXh0OiBcIlR1cm5rZXlcIiwgbGluazogXCIvdHV0b3JpYWxzL3NpZ25lcnMvdHVybmtleVwiIH0sXG5cdFx0XHRcdHsgdGV4dDogXCJEeW5hbWljXCIsIGxpbms6IFwiL3R1dG9yaWFscy9zaWduZXJzL2R5bmFtaWNcIiB9LFxuXHRcdFx0XHR7IHRleHQ6IFwiQ2Fwc3VsZVwiLCBsaW5rOiBcIi90dXRvcmlhbHMvc2lnbmVycy9jYXBzdWxlXCIgfSxcblx0XHRcdFx0eyB0ZXh0OiBcIkRGTlNcIiwgbGluazogXCIvdHV0b3JpYWxzL3NpZ25lcnMvZGZuc1wiIH0sXG5cdFx0XHRdLFxuXHRcdH0sXG5cdFx0e1xuXHRcdFx0dGV4dDogXCJTbWFydCBBY2NvdW50c1wiLFxuXHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0eyB0ZXh0OiBcIlNtYXJ0IEFjY291bnRzIE92ZXJ2aWV3XCIsIGxpbms6IFwiL2FjY291bnQtcHJvdmlkZXJzL292ZXJ2aWV3XCIgfSxcblx0XHRcdFx0eyB0ZXh0OiBcIk5leHVzIFNtYXJ0IEFjY291bnRcIiwgbGluazogXCIvb3ZlcnZpZXdcIiwgY29sbGFwc2VkOiB0cnVlIH0sXHRcdFx0XHRcblx0XHRcdFx0eyB0ZXh0OiBcIkVJUC03NzAyOiBTbWFydCBFT0FzIE92ZXJ2aWV3XCIsIGxpbms6ICcvZWlwNzcwMi93YWxsZXQtZ3VpZGUnIH0sXG5cdFx0XHRcdHsgdGV4dDogJ0NvbXBhbmlvbiBBY2NvdW50cyBPdmVydmlldycsIGxpbms6ICcvbWVlL2Z1c2lvbicgfVxuXHRcdFx0XSxcblx0XHR9LFxuXHRcdHtcblx0XHRcdHRleHQ6ICdHYXMgQWJzdHJhY3Rpb24gQVBJcycsXG5cdFx0XHRjb2xsYXBzZWQ6IHRydWUsXG5cdFx0XHRpdGVtczogW1xuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ092ZXJ2aWV3Jyxcblx0XHRcdFx0XHRsaW5rOiAnL211bHRpY2hhaW4tZ2FzLWFic3RyYWN0aW9uL292ZXJ2aWV3J1xuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ1BheWluZyBmb3IgR2FzIHdpdGggRVJDMjAgVG9rZW5zJyxcblx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiAnRm9yIEVPQSBBY2NvdW50cycsXG5cdFx0XHRcdFx0XHRcdGxpbms6ICcvbXVsdGljaGFpbi1nYXMtYWJzdHJhY3Rpb24vZm9yLWVvYSdcblx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdHRleHQ6ICdGb3IgU21hcnQgQWNjb3VudHMnLFxuXHRcdFx0XHRcdFx0XHRsaW5rOiAnL211bHRpY2hhaW4tZ2FzLWFic3RyYWN0aW9uL2Zvci1zY2EnXG5cdFx0XHRcdFx0XHR9XG5cdFx0XHRcdFx0XVxuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ1Nwb25zb3JpbmcgR2FzIEZvciBVc2VycycsXG5cdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLWdhcy1hYnN0cmFjdGlvbi9zcG9uc29yaW5nLWdhcydcblx0XHRcdFx0fVxuXHRcdFx0XVxuXHRcdH0sXG5cdFx0e1xuXHRcdFx0dGV4dDogJ1NtYXJ0IFNlc3Npb25zIEFQSXMnLFxuXHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0e1xuXHRcdFx0XHRcdHRleHQ6ICdPdmVydmlldycsXG5cdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLXNtYXJ0LXNlc3Npb25zL292ZXJ2aWV3J1xuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ1NpbmdsZSBDaGFpbicsXG5cdFx0XHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0dGV4dDogJ0dyYW50aW5nIGEgU21hcnQgU2Vzc2lvbicsXG5cdFx0XHRcdFx0XHRcdGxpbms6ICcvbXVsdGljaGFpbi1zbWFydC1zZXNzaW9ucy9ncmFudCdcblx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdHRleHQ6ICdSZWRlZW1pbmcgYSBTbWFydCBTZXNzaW9uJyxcblx0XHRcdFx0XHRcdFx0bGluazogJy9tdWx0aWNoYWluLXNtYXJ0LXNlc3Npb25zL3JlZGVlbSdcblx0XHRcdFx0XHRcdH1cblx0XHRcdFx0XHRdXG5cdFx0XHRcdH0sXG5cdFx0XHRdXG5cdFx0fSxcblx0XHR7XG5cdFx0XHR0ZXh0OiAnTGVhcm4gQ29uY2VwdHMnLFxuXHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0e1xuXHRcdFx0XHRcdHRleHQ6ICdFSVAtNzcwMiBHdWlkZSBmb3IgQXBwcyBcdUQ4M0RcdUREMTcnLFxuXHRcdFx0XHRcdGxpbms6ICdodHRwczovL2Jsb2cuYmljb25vbXkuaW8vYS1jb21wcmVoZW5zaXZlLWVpcC03NzAyLWd1aWRlLWZvci1hcHBzLydcblx0XHRcdFx0fSxcblx0XHRcdFx0e1xuXHRcdFx0XHRcdHRleHQ6ICdDb21wYW5pb24gQWNjb3VudHMgJiBGdXNpb24gXHVEODNEXHVERDE3Jyxcblx0XHRcdFx0XHRsaW5rOiAnaHR0cHM6Ly9ibG9nLmJpY29ub215LmlvL2ludHJvZHVjdGlvbi10by1jb21wYW5pb24tYWNjb3VudHMtZnVzaW9uLydcblx0XHRcdFx0fSxcblx0XHRcdFx0e1xuXHRcdFx0XHRcdHRleHQ6ICdTdXBlcnRyYW5zYWN0aW9ucyBcdUQ4M0RcdUREMTcnLFxuXHRcdFx0XHRcdGxpbms6ICdodHRwczovL2Jsb2cuYmljb25vbXkuaW8vaW50cm9kdWN0aW9uLXRvLXN1cGVydHJhbnNhY3Rpb25zLTIvJ1xuXHRcdFx0XHR9LFxuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogJ0NvbXBzYWJpbGl0eSBTdGFjayBcdUQ4M0RcdUREMTcnLFxuXHRcdFx0XHRcdGxpbms6ICdodHRwczovL2Jsb2cuYmljb25vbXkuaW8vaW50cm9kdWN0aW9uLXRvLXRoZS1jb21wb3NhYmlsaXR5LXN0YWNrLydcblx0XHRcdFx0fSxcblx0XHRcdFx0e1xuXHRcdFx0XHRcdHRleHQ6ICdNb2R1bGFyIEV4ZWN1dGlvbiBFbnZpcm9ubWVudCBcdUQ4M0RcdUREMTcnLFxuXHRcdFx0XHRcdGxpbms6ICdodHRwczovL2Jsb2cuYmljb25vbXkuaW8vbGVhcm4tbW9kdWxhci1leGVjdXRpb24tZW52aXJvbm1lbnQtbWVlLydcblx0XHRcdFx0fVxuXHRcdFx0XVxuXHRcdH0sXG5cdFx0e1xuXHRcdFx0dGV4dDogXCJSZXNvdXJjZXNcIixcblx0XHRcdGNvbGxhcHNlZDogdHJ1ZSxcblx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdHsgdGV4dDogXCJDb250cmFjdHMgJiBBdWRpdHNcIiwgbGluazogXCIvY29udHJhY3RzQW5kQXVkaXRzXCIgfSxcblx0XHRcdFx0eyB0ZXh0OiBcIlN1cHBvcnRlZCBOZXR3b3Jrc1wiLCBsaW5rOiBcIi9zdXBwb3J0ZWROZXR3b3Jrc1wiIH0sXG5cdFx0XHRdLFxuXHRcdH0sXG5cblx0XHR7XG5cdFx0XHR0ZXh0OiBcIkRlbW9zXCIsXG5cdFx0XHRjb2xsYXBzZWQ6IHRydWUsXG5cdFx0XHRpdGVtczogW1xuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogXCIjMDAxIFNtYXJ0U2Vzc2lvbnNcIixcblx0XHRcdFx0XHRsaW5rOiBcIi9kZW1vcy9zbWFydFNlc3Npb25zXCIsXG5cdFx0XHRcdH0sXG5cdFx0XHRcdHtcblx0XHRcdFx0XHR0ZXh0OiBcIiMwMDIgRnVzaW9uXCIsXG5cdFx0XHRcdFx0bGluazogXCIvZGVtb3MvZnVzaW9uXCIsXG5cdFx0XHRcdH0sXG5cdFx0XHRdLFxuXHRcdH0sXG5cdFx0e1xuXHRcdFx0dGV4dDogXCJTREsgUmVmZXJlbmNlXCIsXG5cdFx0XHRjb2xsYXBzZWQ6IHRydWUsXG5cdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlXCIsXG5cdFx0XHRpdGVtczogW1xuXHRcdFx0XHR7XG5cdFx0XHRcdFx0dGV4dDogXCJNRUUgQ2xpZW50XCIsXG5cdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50XCIsXG5cdFx0XHRcdFx0Y29sbGFwc2VkOiBmYWxzZSxcblx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiBcIk11bHRpY2hhaW4gQWNjb3VudFwiLFxuXHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvYWNjb3VudFwiLFxuXHRcdFx0XHRcdFx0XHRjb2xsYXBzZWQ6IGZhbHNlLFxuXHRcdFx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiYnVpbGRcIixcblx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9hY2NvdW50L21ldGhvZHMvYnVpbGRcIixcblx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiYnVpbGRDb21wb3NhYmxlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvYWNjb3VudC9tZXRob2RzL2J1aWxkQ29tcG9zYWJsZVwiLFxuXHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJtb3JlKlwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0XHRcdFx0XHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiZGVwbG95bWVudE9uXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L2FjY291bnQvbWV0aG9kcy9tb3JlL2RlcGxveW1lbnRPblwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJhZGRyZXNzT25cIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvYWNjb3VudC9tZXRob2RzL21vcmUvYWRkcmVzc09uXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImlzRGVsZWdhdGVkXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L2FjY291bnQvbWV0aG9kcy9tb3JlL2lzRGVsZWdhdGVkXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcInVuRGVsZWdhdGVcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvYWNjb3VudC9tZXRob2RzL21vcmUvdW5EZWxlZ2F0ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJ3YWl0Rm9yVHJhbnNhY3Rpb25SZWNlaXB0c1wiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9hY2NvdW50L21ldGhvZHMvbW9yZS93YWl0Rm9yVHJhbnNhY3Rpb25SZWNlaXB0c1wiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XSxcblx0XHRcdFx0XHRcdFx0XHR9XG5cdFx0XHRcdFx0XHRcdF0sXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiBcIk1ldGhvZHNcIixcblx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L21ldGhvZHNcIixcblx0XHRcdFx0XHRcdFx0Y29sbGFwc2VkOiBmYWxzZSxcblx0XHRcdFx0XHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldFF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvbWV0aG9kcy9nZXRRdW90ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJleGVjdXRlUXVvdGVcIixcblx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9tZXRob2RzL2V4ZWN1dGVRdW90ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJnZXRGdXNpb25RdW90ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L21ldGhvZHMvZ2V0RnVzaW9uUXVvdGVcIixcblx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiZXhlY3V0ZUZ1c2lvblF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvbWV0aG9kcy9leGVjdXRlRnVzaW9uUXVvdGVcIixcblx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwid2FpdEZvclN1cGVyVHJhbnNhY3Rpb25SZWNlaXB0XCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvbWV0aG9kcy93YWl0Rm9yU3VwZXJUcmFuc2FjdGlvblJlY2VpcHRcIixcblx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwibW9yZSpcIixcblx0XHRcdFx0XHRcdFx0XHRcdGNvbGxhcHNlZDogdHJ1ZSxcblx0XHRcdFx0XHRcdFx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldFN1cGVyVHJhbnNhY3Rpb25SZWNlaXB0XCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L21ldGhvZHMvbW9yZS9nZXRTdXBlclRyYW5zYWN0aW9uUmVjZWlwdFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJleGVjdXRlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L21ldGhvZHMvbW9yZS9leGVjdXRlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImV4ZWN1dGVTaWduZWRRdW90ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9tZXRob2RzL21vcmUvZXhlY3V0ZVNpZ25lZFF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcInNpZ25RdW90ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9tZXRob2RzL21vcmUvc2lnblF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldEdhc1Rva2VuXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L21ldGhvZHMvbW9yZS9nZXRHYXNUb2tlblwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJnZXRJbmZvXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L21ldGhvZHMvbW9yZS9nZXRJbmZvXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldE9uQ2hhaW5RdW90ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9tZXRob2RzL21vcmUvZ2V0T25DaGFpblF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldFBlcm1pdFF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L21ldGhvZHMvbW9yZS9nZXRQZXJtaXRRdW90ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJzaWduT25DaGFpblF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L21ldGhvZHMvbW9yZS9zaWduT25DaGFpblF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcInNpZ25QZXJtaXRRdW90ZVwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9tZXRob2RzL21vcmUvc2lnblBlcm1pdFF1b3RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldFBheW1lbnRUb2tlblwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9tZXRob2RzL21vcmUvZ2V0UGF5bWVudFRva2VuXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRdLFxuXHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdF0sXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiBcIkhlbHBlcnNcIixcblx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L2hlbHBlcnNcIixcblx0XHRcdFx0XHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwicnVudGltZUVSQzIwQmFsYW5jZU9mXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvaGVscGVycy9ydW50aW1lRVJDMjBCYWxhbmNlT2ZcIixcblx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwicnVudGltZUVuY29kZUFiaVBhcmFtZXRlcnNcIixcblx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9oZWxwZXJzL3J1bnRpbWVFbmNvZGVBYmlQYXJhbWV0ZXJzXCIsXG5cdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldE11bHRpY2hhaW5Db250cmFjdFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L2hlbHBlcnMvZ2V0TXVsdGljaGFpbkNvbnRyYWN0XCIsXG5cdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcIm1vcmUqXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRjb2xsYXBzZWQ6IHRydWUsXG5cdFx0XHRcdFx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJtY1VTRENcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvaGVscGVycy9tb3JlL21jVVNEQ1wiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJnZXRFeHBsb3JlclR4TGlua1wiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvbWVlLWNsaWVudC9oZWxwZXJzL21vcmUvZ2V0RXhwbG9yZXJUeExpbmtcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiZ2V0TWVlU2NhbkxpbmtcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvaGVscGVycy9tb3JlL2dldE1lZVNjYW5MaW5rXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldEppZmZ5U2NhbkxpbmtcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvaGVscGVycy9tb3JlL2dldEppZmZ5U2NhbkxpbmtcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwibWNBYXZlVjNQb29sXHRcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL21lZS1jbGllbnQvaGVscGVycy9tb3JlL21jQWF2ZVYzUG9vbFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJtY1VuaXN3YXBTd2FwUm91dGVyXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9tZWUtY2xpZW50L2hlbHBlcnMvbW9yZS9tY1VuaXN3YXBTd2FwUm91dGVyXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRdLFxuXHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdF0sXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdF0sXG5cdFx0XHRcdH0sXG5cdFx0XHRcdHtcblx0XHRcdFx0XHR0ZXh0OiBcIkJ1bmRsZXIgQ2xpZW50XCIsXG5cdFx0XHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvYnVuZGxlci1jbGllbnRcIixcblx0XHRcdFx0XHRpdGVtczogW1xuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiBcIkFjY291bnRcIixcblx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9hY2NvdW50XCIsXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHR0ZXh0OiBcIk1ldGhvZHNcIixcblx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzXCIsXG5cdFx0XHRcdFx0XHRcdGNvbGxhcHNlZDogZmFsc2UsXG5cdFx0XHRcdFx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJzZW5kVXNlck9wZXJhdGlvblwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL3NlbmRVc2VyT3BlcmF0aW9uXCIsXG5cdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcIndhaXRGb3JVc2VyT3BlcmF0aW9uUmVjZWlwdFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL3dhaXRGb3JVc2VyT3BlcmF0aW9uUmVjZWlwdFwiLFxuXHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJkZWJ1Z1VzZXJPcGVyYXRpb25cIixcblx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvYnVuZGxlci1jbGllbnQvbWV0aG9kcy9kZWJ1Z1VzZXJPcGVyYXRpb25cIixcblx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwicHJlcGFyZVRva2VuUGF5bWFzdGVyVXNlck9wXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvcHJlcGFyZVRva2VuUGF5bWFzdGVyVXNlck9wXCIsXG5cdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcInNlbmRUb2tlblBheW1hc3RlclVzZXJPcFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL3NlbmRUb2tlblBheW1hc3RlclVzZXJPcFwiLFxuXHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJ1cGdyYWRlU21hcnRBY2NvdW50XCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvdXBncmFkZVNtYXJ0QWNjb3VudFwiLFxuXHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJtb3JlKlwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0XHRcdFx0XHRcdFx0aXRlbXM6IFtcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiZXN0aW1hdGVVc2VyT3BlcmF0aW9uR2FzXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvZXN0aW1hdGVVc2VyT3BlcmF0aW9uR2FzXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldFVzZXJPcGVyYXRpb25cIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9nZXRVc2VyT3BlcmF0aW9uXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldFVzZXJPcGVyYXRpb25SZWNlaXB0XCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvZ2V0VXNlck9wZXJhdGlvblJlY2VpcHRcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiZ2V0U3VwcG9ydGVkRW50cnlQb2ludHNcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9nZXRTdXBwb3J0ZWRFbnRyeVBvaW50c1wiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJnZXRDaGFpbklkXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvZ2V0Q2hhaW5JZFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJzZW5kVHJhbnNhY3Rpb25cIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9zZW5kVHJhbnNhY3Rpb25cIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwid3JpdGVDb250cmFjdFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvYnVuZGxlci1jbGllbnQvbWV0aG9kcy9tb3JlL3dyaXRlQ29udHJhY3RcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwic2lnbk1lc3NhZ2VcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9zaWduTWVzc2FnZVwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJwcmVwYXJlVXNlck9wZXJhdGlvbldpdGhvdXRTaWduYXR1cmVcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9wcmVwYXJlVXNlck9wZXJhdGlvbldpdGhvdXRTaWduYXR1cmVcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwicHJlcGFyZVVzZXJPcGVyYXRpb25cIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9wcmVwYXJlVXNlck9wZXJhdGlvblwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJnZXRHYXNGZWVWYWx1ZXNcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9nZXRHYXNGZWVWYWx1ZXNcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiZ2V0VXNlck9wZXJhdGlvblN0YXR1c1wiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvYnVuZGxlci1jbGllbnQvbWV0aG9kcy9tb3JlL2dldFVzZXJPcGVyYXRpb25TdGF0dXNcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwid2FpdEZvckNvbmZpcm1lZFVzZXJPcGVyYXRpb25SZWNlaXB0XCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvd2FpdEZvckNvbmZpcm1lZFVzZXJPcGVyYXRpb25SZWNlaXB0XCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImFjY291bnRJZFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdGxpbms6IFwiL3Nkay1yZWZlcmVuY2UvYnVuZGxlci1jbGllbnQvbWV0aG9kcy9tb3JlL2FjY291bnRJZFwiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJnZXRBY3RpdmVIb29rXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvZ2V0QWN0aXZlSG9va1wiLFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdFx0XHRcdFx0XHR7XG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0dGV4dDogXCJnZXRGYWxsYmFja0J5U2VsZWN0b3JcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9nZXRGYWxsYmFja0J5U2VsZWN0b3JcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwiZ2V0SW5zdGFsbGVkRXhlY3V0b3JzXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvZ2V0SW5zdGFsbGVkRXhlY3V0b3JzXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImdldEluc3RhbGxlZFZhbGlkYXRvcnNcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9nZXRJbnN0YWxsZWRWYWxpZGF0b3JzXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImluc3RhbGxNb2R1bGVcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHRsaW5rOiBcIi9zZGstcmVmZXJlbmNlL2J1bmRsZXItY2xpZW50L21ldGhvZHMvbW9yZS9pbnN0YWxsTW9kdWxlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcImlzTW9kdWxlSW5zdGFsbGVkXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvaXNNb2R1bGVJbnN0YWxsZWRcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwic3VwcG9ydHNFeGVjdXRpb25Nb2RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvc3VwcG9ydHNFeGVjdXRpb25Nb2RlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH0sXG5cdFx0XHRcdFx0XHRcdFx0XHRcdHtcblx0XHRcdFx0XHRcdFx0XHRcdFx0XHR0ZXh0OiBcInN1cHBvcnRzTW9kdWxlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvc3VwcG9ydHNNb2R1bGVcIixcblx0XHRcdFx0XHRcdFx0XHRcdFx0fSxcblx0XHRcdFx0XHRcdFx0XHRcdFx0e1xuXHRcdFx0XHRcdFx0XHRcdFx0XHRcdHRleHQ6IFwidW5pbnN0YWxsTW9kdWxlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdFx0bGluazogXCIvc2RrLXJlZmVyZW5jZS9idW5kbGVyLWNsaWVudC9tZXRob2RzL21vcmUvdW5pbnN0YWxsTW9kdWxlXCIsXG5cdFx0XHRcdFx0XHRcdFx0XHRcdH1cblx0XHRcdFx0XHRcdFx0XHRcdF1cblx0XHRcdFx0XHRcdFx0XHR9XG5cdFx0XHRcdFx0XHRcdF0sXG5cdFx0XHRcdFx0XHR9LFxuXHRcdFx0XHRcdF0sXG5cdFx0XHRcdH0sXG5cblx0XHRcdF0sXG5cdFx0fSxcblx0XHR7XG5cdFx0XHR0ZXh0OiBcIkFjY291bnQgTWlncmF0aW9uc1wiLFxuXHRcdFx0bGluazogXCIvbWlncmF0aW9uc1wiLFxuXHRcdFx0Y29sbGFwc2VkOiBmYWxzZSxcblx0XHRcdGl0ZW1zOiBbXG5cdFx0XHRcdHtcblx0XHRcdFx0XHR0ZXh0OiBcIlYyIHRvIE5leHVzIE1pZ3JhdGlvblwiLFxuXHRcdFx0XHRcdGxpbms6IFwiL21pZ3JhdGlvbnMvdjJUb05leHVzXCIsXG5cdFx0XHRcdH0sXG5cdFx0XHRcdHtcblx0XHRcdFx0XHR0ZXh0OiBcIk5leHVzIHRvIE5leHVzIE1pZ3JhdGlvblwiLFxuXHRcdFx0XHRcdGxpbms6IFwiL21pZ3JhdGlvbnMvbmV4dXNUb05leHVzXCIsXG5cdFx0XHRcdH0sXG5cdFx0XHRdLFxuXHRcdH0sXG5cdFx0e1xuXHRcdFx0dGV4dDogXCJMZWdhY3kgQWNjb3VudCBBYnN0cmFjdGlvbiBEb2NzXCIsXG5cdFx0XHRjb2xsYXBzZWQ6IHRydWUsXG5cdFx0XHRpdGVtczogW1xuXHRcdFx0XHR7XG5cdFx0XHRcdFx0Y29sbGFwc2VkOiB0cnVlLFxuXHRcdFx0XHRcdHRleHQ6IFwiVjIgQWNjb3VudHMgJiBFUHY2IEluZnJhXCIsXG5cdFx0XHRcdFx0aXRlbXM6IHNtYXJ0QWNjb3VudHNWMlNpZGViYXIsXG5cdFx0XHRcdH0sXG5cdFx0XHRcdHsgdGV4dDogXCJWMSBEb2NzXCIsIGxpbms6IFwiaHR0cHM6Ly9sZWdhY3ktZG9jcy5iaWNvbm9teS5pby9cIiB9LFxuXHRcdFx0XSxcblx0XHR9XG5cdF0sXG59KTtcbiJdLAogICJtYXBwaW5ncyI6ICI7QUFBMFksU0FBUyxvQkFBb0I7QUFFaGEsSUFBTSx5QkFBeUI7QUFBQSxFQUNyQyxFQUFFLE1BQU0sNkJBQTZCLE1BQU0sV0FBVztBQUFBLEVBQ3RELEVBQUUsTUFBTSxxQ0FBcUMsTUFBTSxvQkFBb0I7QUFBQSxFQUN2RSxFQUFFLE1BQU0sK0JBQStCLE1BQU0sdUJBQXVCO0FBQUEsRUFDcEU7QUFBQSxJQUNDLE1BQU07QUFBQSxJQUNOLE1BQU07QUFBQSxJQUNOLFdBQVc7QUFBQSxJQUNYLE9BQU87QUFBQSxNQUNOO0FBQUEsUUFDQyxNQUFNO0FBQUEsUUFDTixNQUFNO0FBQUEsTUFDUDtBQUFBLE1BQ0E7QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsTUFDQTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLE1BQ1A7QUFBQSxNQUNBO0FBQUEsUUFDQyxNQUFNO0FBQUEsUUFDTixNQUFNO0FBQUEsTUFDUDtBQUFBLE1BQ0E7QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsTUFDQSxFQUFFLE1BQU0seUNBQXlDLE1BQU0saUJBQWlCO0FBQUEsTUFDeEU7QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsTUFDQTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLE1BQ1A7QUFBQSxNQUNBO0FBQUEsUUFDQyxNQUFNO0FBQUEsUUFDTixNQUFNO0FBQUEsTUFDUDtBQUFBLE1BQ0E7QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsTUFDQSxFQUFFLE1BQU0scUNBQXFDLE1BQU0sYUFBYTtBQUFBLE1BQ2hFO0FBQUEsUUFDQyxNQUFNO0FBQUEsUUFDTixNQUFNO0FBQUEsTUFDUDtBQUFBLE1BQ0EsRUFBRSxNQUFNLHVDQUF1QyxNQUFNLGVBQWU7QUFBQSxNQUNwRSxFQUFFLE1BQU0sd0NBQXdDLE1BQU0sZ0JBQWdCO0FBQUEsSUFDdkU7QUFBQSxFQUNEO0FBQUEsRUFDQTtBQUFBLElBQ0MsTUFBTTtBQUFBLElBQ04sTUFBTTtBQUFBLElBQ04sV0FBVztBQUFBLElBQ1gsT0FBTztBQUFBLE1BQ047QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsTUFDQTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLE1BQ1A7QUFBQSxNQUNBO0FBQUEsUUFDQyxNQUFNO0FBQUEsUUFDTixNQUFNO0FBQUEsTUFDUDtBQUFBLE1BQ0E7QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsTUFDQTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLE1BQ1A7QUFBQSxNQUNBO0FBQUEsUUFDQyxNQUFNO0FBQUEsUUFDTixNQUFNO0FBQUEsUUFDTixPQUFPO0FBQUEsVUFDTjtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsVUFDUDtBQUFBLFVBQ0E7QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsVUFDQTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsVUFDUDtBQUFBLFFBQ0Q7QUFBQSxNQUNEO0FBQUEsTUFDQTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLE1BQ1A7QUFBQSxNQUNBO0FBQUEsUUFDQyxNQUFNO0FBQUEsUUFDTixNQUFNO0FBQUEsUUFDTixPQUFPO0FBQUEsVUFDTjtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsVUFDUDtBQUFBLFFBQ0Q7QUFBQSxNQUNEO0FBQUEsTUFDQTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLFFBQ04sV0FBVztBQUFBLFFBQ1gsT0FBTztBQUFBLFVBQ047QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsVUFDQTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsVUFDUDtBQUFBLFVBRUE7QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsUUFDRDtBQUFBLE1BQ0Q7QUFBQSxNQUNBLEVBQUUsTUFBTSwwQ0FBMEMsTUFBTSxlQUFlO0FBQUEsTUFDdkU7QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsSUFDRDtBQUFBLEVBQ0Q7QUFBQSxFQUNBO0FBQUEsSUFDQyxNQUFNO0FBQUEsSUFDTixNQUFNO0FBQUEsSUFDTixXQUFXO0FBQUEsSUFDWCxPQUFPO0FBQUEsTUFDTixFQUFFLE1BQU0sd0NBQXdDLE1BQU0sY0FBYztBQUFBLE1BQ3BFLEVBQUUsTUFBTSxvQ0FBb0MsTUFBTSxVQUFVO0FBQUEsTUFDNUQ7QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxRQUNOLE9BQU87QUFBQSxVQUNOO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsWUFDTixPQUFPO0FBQUEsY0FDTjtBQUFBLGdCQUNDLE1BQU07QUFBQSxnQkFDTixNQUFNO0FBQUEsY0FDUDtBQUFBLGNBQ0E7QUFBQSxnQkFDQyxNQUFNO0FBQUEsZ0JBQ04sTUFBTTtBQUFBLGNBQ1A7QUFBQSxjQUNBO0FBQUEsZ0JBQ0MsTUFBTTtBQUFBLGdCQUNOLE1BQU07QUFBQSxjQUNQO0FBQUEsWUFDRDtBQUFBLFVBQ0Q7QUFBQSxVQUNBLEVBQUUsTUFBTSw0Q0FBNEMsTUFBTSxVQUFVO0FBQUEsVUFDcEUsRUFBRSxNQUFNLHlDQUF5QyxNQUFNLE9BQU87QUFBQSxVQUM5RCxFQUFFLE1BQU0sNENBQTRDLE1BQU0sVUFBVTtBQUFBLFVBQ3BFLEVBQUUsTUFBTSwwQ0FBMEMsTUFBTSxRQUFRO0FBQUEsVUFDaEU7QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsVUFDQTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBLEVBQUUsTUFBTSwwQ0FBMEMsTUFBTSxRQUFRO0FBQUEsVUFDaEUsRUFBRSxNQUFNLDRCQUE0QixNQUFNLFVBQVU7QUFBQSxVQUNwRDtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxRQUNEO0FBQUEsTUFDRDtBQUFBLE1BQ0E7QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsSUFDRDtBQUFBLEVBQ0Q7QUFBQSxFQUNBO0FBQUEsSUFDQyxNQUFNO0FBQUEsSUFDTixNQUFNO0FBQUEsSUFDTixXQUFXO0FBQUEsSUFDWCxPQUFPO0FBQUEsTUFDTjtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLFFBQ04sT0FBTztBQUFBLFVBQ04sRUFBRSxNQUFNLHlDQUF5QyxNQUFNLFdBQVc7QUFBQSxVQUVsRTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsVUFDUDtBQUFBLFVBQ0E7QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsVUFDQTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBLEVBQUUsTUFBTSx3Q0FBd0MsTUFBTSxjQUFjO0FBQUEsVUFDcEU7QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsVUFDQTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsVUFDUDtBQUFBLFFBQ0Q7QUFBQSxNQUNEO0FBQUEsTUFDQTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLE1BQ1A7QUFBQSxNQUNBLEVBQUUsTUFBTSx3Q0FBd0MsTUFBTSxjQUFjO0FBQUEsTUFDcEUsRUFBRSxNQUFNLHNDQUFzQyxNQUFNLGFBQWE7QUFBQSxJQUNsRTtBQUFBLEVBQ0Q7QUFBQSxFQUNBO0FBQUEsSUFDQyxNQUFNO0FBQUEsSUFDTixNQUFNO0FBQUEsSUFDTixXQUFXO0FBQUEsSUFDWCxPQUFPO0FBQUEsTUFDTjtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLFFBQ04sT0FBTztBQUFBLFVBQ047QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsVUFDQTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQTtBQUFBLFFBRUQ7QUFBQSxNQUNEO0FBQUEsTUFDQTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLFFBQ04sT0FBTztBQUFBLFVBQ047QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsVUFDQTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsVUFDUDtBQUFBLFFBQ0Q7QUFBQSxNQUNEO0FBQUEsTUFDQSxFQUFFLE1BQU0sMENBQTBDLE1BQU0sY0FBYztBQUFBLE1BQ3RFLEVBQUUsTUFBTSxzQ0FBc0MsTUFBTSxVQUFVO0FBQUEsSUFDL0Q7QUFBQSxFQUNEO0FBQUEsRUFDQTtBQUFBLElBQ0MsTUFBTTtBQUFBLElBQ04sTUFBTTtBQUFBLElBQ04sV0FBVztBQUFBLElBQ1gsT0FBTztBQUFBLE1BQ047QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsTUFDQSxFQUFFLE1BQU0sMkNBQTJDLE1BQU0sVUFBVTtBQUFBLElBQ3BFO0FBQUEsRUFDRDtBQUFBLEVBQ0E7QUFBQSxJQUNDLE1BQU07QUFBQSxJQUNOLE1BQU07QUFBQSxJQUNOLFdBQVc7QUFBQSxJQUNYLE9BQU87QUFBQSxNQUNOLEVBQUUsTUFBTSxrQ0FBa0MsTUFBTSxRQUFRO0FBQUEsTUFDeEQsRUFBRSxNQUFNLHVDQUF1QyxNQUFNLGFBQWE7QUFBQSxNQUNsRTtBQUFBLFFBQ0MsTUFBTTtBQUFBLFFBQ04sTUFBTTtBQUFBLFFBQ04sT0FBTztBQUFBLFVBQ047QUFBQSxZQUNDLE1BQU07QUFBQSxZQUNOLE1BQU07QUFBQSxVQUNQO0FBQUEsVUFDQTtBQUFBLFlBQ0MsTUFBTTtBQUFBLFlBQ04sTUFBTTtBQUFBLFVBQ1A7QUFBQSxVQUNBO0FBQUEsWUFDQyxNQUFNO0FBQUEsWUFDTixNQUFNO0FBQUEsVUFDUDtBQUFBLFFBQ0Q7QUFBQSxNQUNEO0FBQUEsSUFDRDtBQUFBLEVBQ0Q7QUFBQSxFQUVBLEVBQUUsTUFBTSw4QkFBOEIsTUFBTSxZQUFZO0FBQUEsRUFDeEQsRUFBRSxNQUFNLDJCQUEyQixNQUFNLFNBQVM7QUFBQSxFQUNsRDtBQUFBLElBQ0MsTUFBTTtBQUFBLElBQ04sTUFBTTtBQUFBLElBQ04sV0FBVztBQUFBLElBQ1gsT0FBTztBQUFBLE1BQ047QUFBQSxRQUNDLE1BQU07QUFBQSxRQUNOLE1BQU07QUFBQSxNQUNQO0FBQUEsTUFDQSxFQUFFLE1BQU0sNkNBQTZDLE1BQU0sV0FBVztBQUFBLElBQ3ZFO0FBQUEsRUFDRDtBQUFBLEVBRUEsRUFBRSxNQUFNLHdCQUF3QixNQUFNLE1BQU07QUFBQSxFQUM1QyxFQUFFLE1BQU0sc0NBQXNDLE1BQU0sb0JBQW9CO0FBQ3pFO0FBRUEsSUFBTyxzQkFBUSxhQUFhO0FBQUEsRUFDM0IsWUFDQztBQUFBLEVBQ0QsYUFDQztBQUFBLEVBQ0QsT0FBTztBQUFBLEVBQ1AsZUFBZTtBQUFBLEVBQ2YsU0FBUztBQUFBLEVBQ1QsVUFBVTtBQUFBLElBQ1QsU0FDQztBQUFBLElBQ0QsTUFBTTtBQUFBLEVBQ1A7QUFBQSxFQUNBLFNBQVM7QUFBQSxJQUNSLE1BQU07QUFBQSxJQUNOLE9BQU87QUFBQSxFQUNSO0FBQUEsRUFDQSxTQUFTO0FBQUEsSUFDUixNQUFNO0FBQUEsSUFDTixPQUFPO0FBQUEsRUFDUjtBQUFBLEVBQ0EsT0FBTztBQUFBLElBQ04sYUFBYTtBQUFBLElBQ2IsV0FBVztBQUFBLE1BQ1YsU0FBUztBQUFBLFFBQ1IsT0FBTztBQUFBLFFBQ1AsbUJBQW1CO0FBQUEsUUFDbkIsaUJBQWlCO0FBQUEsTUFDbEI7QUFBQSxJQUNEO0FBQUEsRUFDRDtBQUFBLEVBQ0EsU0FBUztBQUFBLElBQ1I7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLE1BQU07QUFBQSxJQUNQO0FBQUEsRUFDRDtBQUFBLEVBQ0EsUUFBUTtBQUFBLElBQ1AsRUFBRSxNQUFNLFlBQVksTUFBTSxvQ0FBb0M7QUFBQTtBQUFBO0FBQUE7QUFBQTtBQUFBLElBSzlEO0FBQUEsTUFDQyxNQUFNO0FBQUEsTUFDTixPQUFPO0FBQUEsUUFDTjtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sTUFBTTtBQUFBLFFBQ1A7QUFBQSxRQUNBO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixNQUFNO0FBQUEsUUFDUDtBQUFBLE1BQ0Q7QUFBQSxJQUNEO0FBQUEsRUFDRDtBQUFBLEVBQ0EsU0FBUztBQUFBLElBQ1I7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLE1BQU07QUFBQSxJQUNQO0FBQUEsSUFDQTtBQUFBLE1BQ0MsTUFBTTtBQUFBLE1BQ04sTUFBTTtBQUFBLElBQ1A7QUFBQSxJQUNBO0FBQUEsTUFDQyxNQUFNO0FBQUEsTUFDTixNQUFNO0FBQUEsSUFDUDtBQUFBLElBQ0E7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLE1BQU07QUFBQSxJQUNQO0FBQUEsSUFDQTtBQUFBLE1BQ0MsTUFBTTtBQUFBLE1BQ04sT0FBTztBQUFBLFFBQ047QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE1BQU07QUFBQSxRQUNQO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sTUFBTTtBQUFBLFFBQ1A7QUFBQSxNQUNEO0FBQUEsSUFDRDtBQUFBLElBQ0E7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLE9BQU87QUFBQSxRQUNOO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixNQUFNO0FBQUEsUUFDUDtBQUFBLFFBQ0E7QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE1BQU07QUFBQSxRQUNQO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sV0FBVztBQUFBLFVBQ1gsT0FBTztBQUFBLFlBQ0w7QUFBQSxjQUNDLE1BQU07QUFBQSxjQUNOLE1BQU07QUFBQSxZQUNQO0FBQUEsWUFDQTtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLFlBQ1A7QUFBQSxZQUNBO0FBQUEsY0FDQyxNQUFNO0FBQUEsY0FDTixNQUFNO0FBQUEsWUFDUDtBQUFBLFVBQ0Y7QUFBQSxRQUNEO0FBQUE7QUFBQTtBQUFBO0FBQUE7QUFBQTtBQUFBO0FBQUE7QUFBQTtBQUFBO0FBQUE7QUFBQTtBQUFBO0FBQUE7QUFBQSxNQWVEO0FBQUEsSUFDRDtBQUFBLElBQ0E7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLFdBQVc7QUFBQSxNQUNYLE9BQU87QUFBQSxRQUNOO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixNQUFNO0FBQUEsUUFDUDtBQUFBLFFBQ0E7QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE1BQU07QUFBQSxRQUNQO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sT0FBTztBQUFBLFlBQ047QUFBQSxjQUNDLE1BQU07QUFBQSxjQUNOLE1BQU07QUFBQSxZQUNQO0FBQUEsWUFDQTtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLFlBQ1A7QUFBQSxZQUNBO0FBQUEsY0FDQyxNQUFNO0FBQUEsY0FDTixNQUFNO0FBQUEsWUFDUDtBQUFBLFVBQ0Q7QUFBQSxRQUNEO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sT0FBTztBQUFBLFlBQ047QUFBQSxjQUNDLE1BQU07QUFBQSxjQUNOLE1BQU07QUFBQSxZQUNQO0FBQUEsVUFDRDtBQUFBLFFBQ0Q7QUFBQSxRQUNBO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixXQUFXO0FBQUEsVUFDWCxPQUFPO0FBQUEsWUFDTjtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLFlBQ1A7QUFBQSxZQUNBO0FBQUEsY0FDQyxNQUFNO0FBQUEsY0FDTixNQUFNO0FBQUEsWUFDUDtBQUFBLFlBQ0E7QUFBQSxjQUNDLE1BQU07QUFBQSxjQUNOLE1BQU07QUFBQSxZQUNQO0FBQUEsWUFDQTtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLFlBQ1A7QUFBQSxZQUNBO0FBQUEsY0FDQyxNQUFNO0FBQUEsY0FDTixNQUFNO0FBQUEsWUFDUDtBQUFBLFVBQ0Q7QUFBQSxRQUNEO0FBQUEsTUFDRDtBQUFBLElBQ0Q7QUFBQSxJQUNBO0FBQUEsTUFDQyxNQUFNO0FBQUEsTUFDTixXQUFXO0FBQUEsTUFDWCxPQUFPO0FBQUEsUUFDTixFQUFFLE1BQU0sWUFBWSxNQUFNLFlBQVk7QUFBQSxRQUN0QyxFQUFFLE1BQU0sYUFBYSxPQUFPO0FBQUEsVUFDM0IsRUFBRSxNQUFNLHNCQUFzQixNQUFNLHFCQUFxQjtBQUFBLFVBQ3pELEVBQUUsTUFBTSxnQ0FBZ0MsTUFBTSxnQ0FBK0I7QUFBQSxRQUM5RSxFQUFDO0FBQUEsUUFDRCxFQUFFLE1BQU0sb0JBQW9CLE9BQU87QUFBQSxVQUNsQyxFQUFFLE1BQU0sZ0NBQWdDLE1BQU0sY0FBYTtBQUFBLFVBQzNELEVBQUUsTUFBTSxnQ0FBZ0MsTUFBTSx3QkFBdUI7QUFBQSxVQUNyRSxFQUFFLE1BQU0sZ0NBQWdDLE1BQU0sc0JBQXNCO0FBQUEsUUFDckUsRUFBQztBQUFBLE1BQ0E7QUFBQSxJQUNIO0FBQUEsSUFDQTtBQUFBLE1BQ0MsTUFBTTtBQUFBLE1BQ04sV0FBVztBQUFBLE1BQ1gsT0FBTztBQUFBLFFBQ04sRUFBRSxNQUFNLFNBQVMsTUFBTSwyQkFBMkI7QUFBQSxRQUNsRCxFQUFFLE1BQU0sWUFBWSxNQUFNLDhCQUE4QjtBQUFBLFFBQ3hELEVBQUUsTUFBTSxTQUFTLE1BQU0sMkJBQTJCO0FBQUEsUUFDbEQsRUFBRSxNQUFNLFlBQVksTUFBTSw4QkFBOEI7QUFBQSxRQUN4RCxFQUFFLE1BQU0sWUFBWSxNQUFNLDhCQUE4QjtBQUFBLFFBQ3hELEVBQUUsTUFBTSxXQUFXLE1BQU0sNkJBQTZCO0FBQUEsUUFDdEQsRUFBRSxNQUFNLFdBQVcsTUFBTSw2QkFBNkI7QUFBQSxRQUN0RCxFQUFFLE1BQU0sV0FBVyxNQUFNLDZCQUE2QjtBQUFBLFFBQ3RELEVBQUUsTUFBTSxRQUFRLE1BQU0sMEJBQTBCO0FBQUEsTUFDakQ7QUFBQSxJQUNEO0FBQUEsSUFDQTtBQUFBLE1BQ0MsTUFBTTtBQUFBLE1BQ04sV0FBVztBQUFBLE1BQ1gsT0FBTztBQUFBLFFBQ04sRUFBRSxNQUFNLDJCQUEyQixNQUFNLDhCQUE4QjtBQUFBLFFBQ3ZFLEVBQUUsTUFBTSx1QkFBdUIsTUFBTSxhQUFhLFdBQVcsS0FBSztBQUFBLFFBQ2xFLEVBQUUsTUFBTSxpQ0FBaUMsTUFBTSx3QkFBd0I7QUFBQSxRQUN2RSxFQUFFLE1BQU0sK0JBQStCLE1BQU0sY0FBYztBQUFBLE1BQzVEO0FBQUEsSUFDRDtBQUFBLElBQ0E7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLFdBQVc7QUFBQSxNQUNYLE9BQU87QUFBQSxRQUNOO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixNQUFNO0FBQUEsUUFDUDtBQUFBLFFBQ0E7QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE9BQU87QUFBQSxZQUNOO0FBQUEsY0FDQyxNQUFNO0FBQUEsY0FDTixNQUFNO0FBQUEsWUFDUDtBQUFBLFlBQ0E7QUFBQSxjQUNDLE1BQU07QUFBQSxjQUNOLE1BQU07QUFBQSxZQUNQO0FBQUEsVUFDRDtBQUFBLFFBQ0Q7QUFBQSxRQUNBO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixNQUFNO0FBQUEsUUFDUDtBQUFBLE1BQ0Q7QUFBQSxJQUNEO0FBQUEsSUFDQTtBQUFBLE1BQ0MsTUFBTTtBQUFBLE1BQ04sV0FBVztBQUFBLE1BQ1gsT0FBTztBQUFBLFFBQ047QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE1BQU07QUFBQSxRQUNQO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sT0FBTztBQUFBLFlBQ047QUFBQSxjQUNDLE1BQU07QUFBQSxjQUNOLE1BQU07QUFBQSxZQUNQO0FBQUEsWUFDQTtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLFlBQ1A7QUFBQSxVQUNEO0FBQUEsUUFDRDtBQUFBLE1BQ0Q7QUFBQSxJQUNEO0FBQUEsSUFDQTtBQUFBLE1BQ0MsTUFBTTtBQUFBLE1BQ04sV0FBVztBQUFBLE1BQ1gsT0FBTztBQUFBLFFBQ047QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE1BQU07QUFBQSxRQUNQO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sTUFBTTtBQUFBLFFBQ1A7QUFBQSxRQUNBO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixNQUFNO0FBQUEsUUFDUDtBQUFBLFFBQ0E7QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE1BQU07QUFBQSxRQUNQO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sTUFBTTtBQUFBLFFBQ1A7QUFBQSxNQUNEO0FBQUEsSUFDRDtBQUFBLElBQ0E7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLFdBQVc7QUFBQSxNQUNYLE9BQU87QUFBQSxRQUNOLEVBQUUsTUFBTSxzQkFBc0IsTUFBTSxzQkFBc0I7QUFBQSxRQUMxRCxFQUFFLE1BQU0sc0JBQXNCLE1BQU0scUJBQXFCO0FBQUEsTUFDMUQ7QUFBQSxJQUNEO0FBQUEsSUFFQTtBQUFBLE1BQ0MsTUFBTTtBQUFBLE1BQ04sV0FBVztBQUFBLE1BQ1gsT0FBTztBQUFBLFFBQ047QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE1BQU07QUFBQSxRQUNQO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sTUFBTTtBQUFBLFFBQ1A7QUFBQSxNQUNEO0FBQUEsSUFDRDtBQUFBLElBQ0E7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLFdBQVc7QUFBQSxNQUNYLE1BQU07QUFBQSxNQUNOLE9BQU87QUFBQSxRQUNOO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixNQUFNO0FBQUEsVUFDTixXQUFXO0FBQUEsVUFDWCxPQUFPO0FBQUEsWUFDTjtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLGNBQ04sV0FBVztBQUFBLGNBQ1gsT0FBTztBQUFBLGdCQUNOO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLFdBQVc7QUFBQSxrQkFDWCxPQUFPO0FBQUEsb0JBQ047QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsa0JBQ0Q7QUFBQSxnQkFDRDtBQUFBLGNBQ0Q7QUFBQSxZQUNEO0FBQUEsWUFDQTtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLGNBQ04sV0FBVztBQUFBLGNBQ1gsT0FBTztBQUFBLGdCQUNOO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLFdBQVc7QUFBQSxrQkFDWCxPQUFPO0FBQUEsb0JBQ047QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsa0JBQ0Q7QUFBQSxnQkFDRDtBQUFBLGNBQ0Q7QUFBQSxZQUNEO0FBQUEsWUFDQTtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLGNBQ04sV0FBVztBQUFBLGNBQ1gsT0FBTztBQUFBLGdCQUNOO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLE1BQU07QUFBQSxnQkFDUDtBQUFBLGdCQUNBO0FBQUEsa0JBQ0MsTUFBTTtBQUFBLGtCQUNOLFdBQVc7QUFBQSxrQkFDWCxPQUFPO0FBQUEsb0JBQ047QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsb0JBQ0E7QUFBQSxzQkFDQyxNQUFNO0FBQUEsc0JBQ04sTUFBTTtBQUFBLG9CQUNQO0FBQUEsa0JBQ0Q7QUFBQSxnQkFDRDtBQUFBLGNBQ0Q7QUFBQSxZQUNEO0FBQUEsVUFDRDtBQUFBLFFBQ0Q7QUFBQSxRQUNBO0FBQUEsVUFDQyxNQUFNO0FBQUEsVUFDTixXQUFXO0FBQUEsVUFDWCxNQUFNO0FBQUEsVUFDTixPQUFPO0FBQUEsWUFDTjtBQUFBLGNBQ0MsTUFBTTtBQUFBLGNBQ04sTUFBTTtBQUFBLFlBQ1A7QUFBQSxZQUNBO0FBQUEsY0FDQyxNQUFNO0FBQUEsY0FDTixNQUFNO0FBQUEsY0FDTixXQUFXO0FBQUEsY0FDWCxPQUFPO0FBQUEsZ0JBQ047QUFBQSxrQkFDQyxNQUFNO0FBQUEsa0JBQ04sTUFBTTtBQUFBLGdCQUNQO0FBQUEsZ0JBQ0E7QUFBQSxrQkFDQyxNQUFNO0FBQUEsa0JBQ04sTUFBTTtBQUFBLGdCQUNQO0FBQUEsZ0JBQ0E7QUFBQSxrQkFDQyxNQUFNO0FBQUEsa0JBQ04sTUFBTTtBQUFBLGdCQUNQO0FBQUEsZ0JBQ0E7QUFBQSxrQkFDQyxNQUFNO0FBQUEsa0JBQ04sTUFBTTtBQUFBLGdCQUNQO0FBQUEsZ0JBQ0E7QUFBQSxrQkFDQyxNQUFNO0FBQUEsa0JBQ04sTUFBTTtBQUFBLGdCQUNQO0FBQUEsZ0JBQ0E7QUFBQSxrQkFDQyxNQUFNO0FBQUEsa0JBQ04sTUFBTTtBQUFBLGdCQUNQO0FBQUEsZ0JBQ0E7QUFBQSxrQkFDQyxNQUFNO0FBQUEsa0JBQ04sV0FBVztBQUFBLGtCQUNYLE9BQU87QUFBQSxvQkFDTjtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxvQkFDQTtBQUFBLHNCQUNDLE1BQU07QUFBQSxzQkFDTixNQUFNO0FBQUEsb0JBQ1A7QUFBQSxrQkFDRDtBQUFBLGdCQUNEO0FBQUEsY0FDRDtBQUFBLFlBQ0Q7QUFBQSxVQUNEO0FBQUEsUUFDRDtBQUFBLE1BRUQ7QUFBQSxJQUNEO0FBQUEsSUFDQTtBQUFBLE1BQ0MsTUFBTTtBQUFBLE1BQ04sTUFBTTtBQUFBLE1BQ04sV0FBVztBQUFBLE1BQ1gsT0FBTztBQUFBLFFBQ047QUFBQSxVQUNDLE1BQU07QUFBQSxVQUNOLE1BQU07QUFBQSxRQUNQO0FBQUEsUUFDQTtBQUFBLFVBQ0MsTUFBTTtBQUFBLFVBQ04sTUFBTTtBQUFBLFFBQ1A7QUFBQSxNQUNEO0FBQUEsSUFDRDtBQUFBLElBQ0E7QUFBQSxNQUNDLE1BQU07QUFBQSxNQUNOLFdBQVc7QUFBQSxNQUNYLE9BQU87QUFBQSxRQUNOO0FBQUEsVUFDQyxXQUFXO0FBQUEsVUFDWCxNQUFNO0FBQUEsVUFDTixPQUFPO0FBQUEsUUFDUjtBQUFBLFFBQ0EsRUFBRSxNQUFNLFdBQVcsTUFBTSxtQ0FBbUM7QUFBQSxNQUM3RDtBQUFBLElBQ0Q7QUFBQSxFQUNEO0FBQ0QsQ0FBQzsiLAogICJuYW1lcyI6IFtdCn0K