1-click+gas-step 11: using orby for in-wallet gas and single-click

[felimadu]

This PR is step 3 of the steps to add Orby and support 1-click transactions and gas abstraction on the Zerion Chrome Extension. The same steps and similar code can be used on other Chrome Extension wallets.

[✅] Step 0 PR (#4) : Setup feature flags

• create a remotely configurable feature flag called one_click_transactions_and_gas_abstraction
• we will use this feature flag to gate access to the one click transactions and gas abstraction as we do progressive rollout of the feature.
• Zerion uses firebase but you can feature flag system of your choice such as launch darkly

[✅] Step 1 [(No PR needed)]: Get EVM and SVM testing accounts and set them up.

• The accounts need to have some funds, though they do not need to be native funds but at least USDC on the chain you want to test on.
• Delete all approvals for EVM accounts using something like revoke cash (https://revoke.cash/)
• Add your accounts to the flag test / development group of the feature created above

[✅] Step 2 PR (#5): Get the Orby API keys for an instance and add them to your environment variables.

• The team will give you keys and urls that look like:

    ORBY_PRIVATE_API_KEY=
    ORBY_PUBLIC_API_KEY=
    ORBY_BASE_URL=
  

• Note: the private and public keys correspond to a particular instance with specific features enabled on that instance. Given that we're working on 1-click transactions and gas abstraction, make sure that only those 2 features are be enabled.

[✅] Step 3 PR (#6): Add OrbyProvider to the root of your app

• add the @orb-labs/orby-react npm package
• move some components around so that we can add OrbyProvider easily
• initialize the OrbyProvider using the current wallet address
• OrbyProvider: Adding OrbyProvider to the root of the app setups all the context and variables that will be used in hooks and function calls to communicate with Orby.
• Note: If you prefer not to use the Orby React package, you can also create your own functions and classes for calling Orby and setting/managing up context; we're also happy to walk you through the process / code if that's preferred.

[✅] Step 4 PR (#7): Configure Orby to handle communication with app frontends

• this is perhaps the most involved step of the integration. Generally, we want to inject scripts to into dapps that the user is connected to, and remove it when the user disconnect from the app.
• Also, we need to use virtual node for all node requests (e.g. eth_call) that are routed to the apps from the wallet (some apps do this).

1. make sure the extension has the right permissions. Most extensions have them already so, you probably do not need to do anything but you need "activeTab", "scripting", and unlimitedStorage permissions in the src/manifest.json file
2. add webpage.js and core-webpage.js to the manifest's web_accessible_resources
3. add core-webpage-injector.js to the manifest's content_scripts
4. In your package.json add a command to copy the webpage.min.js to webpage.js, core_webpage.min.js to core-webpage.js and core_webpage_injector.min.js to core-webpage-injector.js. Put this files in the location where they can be build together with other content script files or you can copy them directly into the location of the content script files after build has completed. For Zerion extension, we add them to the ./src/content-script/ before building, and meaning the files are build together with the other content script files.
5. Call the unifyBalancesOnApps function your background script with the first argument being the location of the files from step 4 above relative to the root of the build output directory
6. Whenever the app starts get all active app sessions and then call the useBulkConnectAppSessions to register them to the background script. Similarly, call the getVirtualNodeRpcUrlsForSupportedChains function to get virtual nodes, and add them to your RPC state as the primary way to forward RPC requests from apps the orby. This is necessary because some apps still call wallets for balances, and even generic eth_calls. For the Zerion Extension, this is done in the new RegisterSessions component, which is conditionally rendered if the feature flag is set.
7. Whenever a app is connected to the wallet, call the updateConnectedAppSession function
8. Whenever a app is disconnected to the wallet, call the removeConnectedAppSession function

Testing: At this point, we want to test that the wallet is function as expected.

1. Testing gas abstraction:

• Control: Using the Zerion wallet on App store, connect to uniswap with an account that does not have native funds on a chain like BNB Chain, ETH Mainnet, Arbitrum, Base or Optimism. You should be blocked with a "Insufficient funds for gas" error when you attempt a swap.
• Orby Enabled: Now, switch to this Orby enabled Zerion wallet but with the same account. You should not be blocked with a "Insufficient funds for gas" any error when you attempt a swap, and instead you should be able to send the transaction to the wallet for signing.

1. Testing 1-click transactions:

• Control: Using the Zerion wallet on App store, connect to uniswap with an account with sufficient funds on a chain like BNB Chain, ETH Mainnet, Arbitrum, Base or Optimism, and attempt a swap with an ERC20 token (e.g. USDC) that has not been approved on uniswap. You should see an "Approve and Swap" CTA when you attempt to swap. Clicking the button sends an ERC20 approval request to the wallet.
• Orby Enabled: Now, switch to this Orby enabled Zerion wallet but with the same account. You should see "Swap" with no approvals needed. Clicking the CTA sends a permit2 typedData to the wallet and not an approval transaction.

[✅] Step 5 PR (#8): Ping Orby to get operations for every send transaction from apps

• We add a useIsOrbyEnabled hook to check if a chain is orby enabled and if a user has the feature flag enabled
• if orby is enabled, we call the useGetOperationsToExecuteTransaction with the transaction data from the user.
• Once we get the operations from Orby, we display them to the user under the details tab
• we also allow the user to pick custom gas tokens from the list of tokens that the user has

Testing:

• connect to uniswap and initiate a transaction.
• when the transaction is rendered by the wallet, there should be a way to pick a gas token based on the balances you have on that chain (as shown below)

• when you click the details tab, you should see the tokens going in and out of your account

• when you click the gas dropdown, you should be able to choose the token of choice for paying for gas

• when a custom gas token is chosen, the native token does not show on the input tokens of the details page (e.g. the image below using DAI).

• if you pick a token that is not enough to pay for gas or if there is not enough native tokens for gas, an error is shown

[✅] Step 6 PR (#9): Ping Orby to get operations for every send transaction from apps

• We useuseIsOrbyEnabled hook to check if a chain is orby enabled and if a user has the feature flag enabled
• if orby is enabled, we call the useGetOperationsToSignTransactionOrSignTypedData with the typeddata from the user.
• Once we get the operations from Orby, we display them to the user under the details tab
• we also allow the user to pick custom gas tokens from the list of tokens that the user has

Testing: Follow the same steps as those above but using typeddata instead. Use Uniswap or Morpho for testing

[❌] Step 7: Verify operations using transaction verification systems such as Blockaid.

[✅] Step 8 PR (#10): Sign and submit operations

• Create a functions that can be used to sign operations. For signing, we iterate through the operations and sign them one by one. To the user, it seems like they just signed one transaction. We create the signOperation, signTransaction, and signUserOperation functions in src/shared/core/orb.ts file. The functions call the actual wallet signing functions in src/background/Wallet/Wallet.ts.
• When the user clicks submit or sign, send operations to Orby using the virtual nodes’ ‘sendOperationSet’ function
• Subscribe to the statuses of these operations from Orby using the subscribeToOperationStatuses function
• When the final operation has been successfully submitted, return the result to the user

[✅] Step 9: Fetch and render batched user activity.

• when the orby is enabled, fetch and display batched activuty.
• this means an approve+swap will show as one row

[✅] Step 10: Add Support for Solana

• Auto detect the VM from the address before passing the address to the OrbyProvider.
• Use the useGetOperationsToSignTransactionOrSignTypedData hook to interact with Orby when isOrbyEnabled is true. The encoded SVM serialized transaction is passed as a data to the hook along with options to tell the Orby the SVM RPC function we are handling.
• Add helper functions to signOperation to support signing of SVM operations
• Add ability to select gas tokens
• when user clicks confirm, send operations to Orby using the virtual nodes’ ‘sendOperationSet’ function , and then return right value to the app. Note that for signAllTransactions and signTransaction calls, the Orby library does not send the primary operation to Orby. Instead, return the serialized transaction to the app so that the relevant relayer will submit this to the blockchain.

[👉] Step 11: Support 1-click transactions and gas abstraction for in-wallet Swap, Bridge and Sends
Similar to transactions from dapps, we want to support 1-click transactions and gas abstraction for in-wallet actions like swap, send and bridge. More importantly, we want to keep the existing 3rd-party services we have been using for bridging swapping and sends. So, for each action, we do the following:

• formulate the bridging, swapping and sending transactions like we always did
• after we get this transaction, pass it to Orby using the useGetOperationsToSignTransactionOrSignTypedData for all users were Orby is enabled. We also allow the user to pick a gas token that Orby can use when orchestrating the delivery of the transaction.
• After we get the operations from Orby, we sign and submit them like we do in steps 8 and 10 above.

[github-actions]

📦 build.zip [updated at Aug 15, 7:25:26 PM UTC]