diff --git a/docs/smart-accounts/1-overview.mdx b/docs/smart-accounts/1-overview.mdx new file mode 100644 index 00000000..c88615c2 --- /dev/null +++ b/docs/smart-accounts/1-overview.mdx @@ -0,0 +1,143 @@ +--- +sidebar_position: 1 +slug: overview +title: Flare Smart Accounts +authors: [nikerzetic, filipkoprivec] +description: The Flare Smart Accounts is an account abstraction that performs actions on behalf of XRPL users. +tags: [quickstart, ethereum, flare-smart-accounts] +keywords: + [ + flare-fdc, + ethereum, + flare-smart-accounts, + evm, + flare-network, + account-abstraction, + ] +unlisted: false +--- + +import ThemedImage from "@theme/ThemedImage"; +import useBaseUrl from "@docusaurus/useBaseUrl"; + +The Flare Smart Accounts is an account abstraction that allows XRPL users to perform actions on the Flare chain without owning any FLR token. +Each XRPL address is assigned a unique **smart account** on the Flare chain, which only it can control. +They do so through `Payment` transactions on the XRPL. +The Flare Smart Accounts are especially useful as a way of interacting with the FAssets workflow. + +## Workflow + +The workflow for Flare Smart Accounts is comprised of the following steps. + +1. The XRPL user sends instructions as a `Payment` transaction to a specific XRPL address, with instructions encoded as the payment reference in the memo field. +2. The operator interacts with the [Flare Data Connector](/fdc/overview) to procure a `Payment` proof. + It then calls the `executeTransaction` function on the `MasterAccountController` contract, with the `Payment` proof and the XRPL address that made the transaction. +3. The XRPL user's smart account performs the actions given in the instructions. + +## 1. Instructions on XRPL + +The Flare Smart Accounts allow XRPL users to perform actions on the Flare chain through instructions on the XRPL. +This is done through a `Payment` to an XRPL address, designated by the operator - a backend monitoring incoming transactions and interacting with the Flare chain. +The payment must transfer sufficient funds, as specified by the operator, and must include the proper payment receipt in the memo field. + +The payment receipt is a `bytes32` value. +The first byte is reserved for the instruction code, a byte representation of a two-digit number. +The remaining 31 bytes are the parameters for the chosen instruction. + +In practice, the payment receipt should be prepared by a backend, through a web form. + +
+ Table of instruction IDs and corresponding actions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
 **Instruction ID****Action** **Description** 
 01 deposit +  Deposit an `amount` of FXRP into the Firelight vault, designated + by the `MasterAccountController` contract. +
 02 withdraw +  Withdraw an `amount` of FXRP from the Firelight vault, + designated by the `MasterAccountController` contract. +
 03 approve +  **Deprecated.** Approve the Firelight vault, designated by the + `MasterAccountController` contract, to spend an `amount` of FXRP from + your account. +
 04 redeem +  Redeem `lots` of FXRP. The redemption will be handled by the + `executor`, specified by the `MasterAccountController` contract. +
 05 reserveCollateral +  Reserve `lots` of collateral in the `agentVault`, specified by + the `MasterAccountController` contract. The collateral reservation + will be handled by the `executor`, also specified by the + `MasterAccountController` contract. +
 06 claimWithdraw Claim the withdrawal from the Firelight vault.
 99 custom +  Execute a list of custom function calls. The custom instructions + need to be registered in advance, with the `MasterAccountController` + (`registerCustomInstruction` function). +
+

 

+
+ +## 2. Payment proof on Flare + +The operator monitors incoming transactions to the specified XRPL address. +Upon receiving a payment, it makes a [`Payment` attestation request](/fdc/attestation-types/payment) to the FDC. +The `Payment` proof and the user's XRPL address are passed to the `executeTransaction` function on the `MasterAccountController` smart contract on the Flare chain. + +The `MasterAccountController` contract first verifies the proof. +It then performs several checks on the proof: + +- receiving address matches the one specified by the operator, +- the source address matches the XRPL address given to the function, +- that the proof has not yet been used for the same actions. + +Then, the `MasterAccountController` contract retrieves the XRPL user's smart account from a mapping. +If the account does not yet exist, it is created at this point. + +The payment reference is decoded. +Depending on the value of the leading byte, a different function on the smart account is called. + +## 3. Actions on Flare + +The XRPL user's smart account performs the actions in the instructions. diff --git a/docs/smart-accounts/2-fasset-instructions.mdx b/docs/smart-accounts/2-fasset-instructions.mdx new file mode 100644 index 00000000..9ac3e86e --- /dev/null +++ b/docs/smart-accounts/2-fasset-instructions.mdx @@ -0,0 +1,218 @@ +--- +sidebar_position: 1 +slug: fasset-instructions +title: FAsset Instructions +authors: [nikerzetic, filipkoprivec] +description: Using Flare Smart Accounts in the FAssets workflow. +tags: [intermediate, ethereum, flare-smart-accounts] +keywords: + [ + flare-fdc, + ethereum, + flare-smart-accounts, + evm, + flare-network, + account-abstraction, + ] +unlisted: false +--- + +import ThemedImage from "@theme/ThemedImage"; +import useBaseUrl from "@docusaurus/useBaseUrl"; + +In this guide, we will take a closer look at the Flare Smart Accounts instructions related to FAssets. +FAsset is a trustless, over-collateralized bridge between XRPL and the Flare chain. +The FXRP is a token representation of XRP on the Flare chain. +FAssets allow XRPL users to partake in Flare's DeFi ecosystem using their XRP assets, without exchanging them for the FLR token. + +Several steps of the FAsset process are performed as transactions on the Flare chain, which requires users to hold FLR tokens for paying gas fees. +The Flare Smart Accounts sidestep this by allowing XRPL users to trigger these actions through `Payment` transactions on XRPL. +Thus, they eradicate completely the need for XRPL users to hold any non-XRPL assets. + +You can learn more about the FAssets in the [dedicated section](/fassets/overview/). + +## `01` Deposit + +Deposit an `amount` of FXRP from your account into the Firelight vault `depositVault`. +The address `depositVault` is designated by the `MasterAccountController` contract, and the `amount` is read from the last 31 bytes of the payment reference. + +A deposit payment reference is the 32-byte value: + +- byte representation of `02` on the first byte, +- byte representation of the `amount` number on the other 31 bytes. + +
+ +
+ +## `02` Withdraw + +The first part of the withdrawal process from a Firelight vault. + +Initiate a withdrawal request of an `amount` of FXRP from the Firelight vault `depositVault`. +The address `depositVault` is designated by the `MasterAccountController` contract, and the `amount` is read from the last 31 bytes of the payment reference. + +A withdraw payment reference is the 32-byte value: + +- byte representation of `02` on the first byte, +- byte representation of the `amount` number on the other 31 bytes. + +
+ +
+ +## `03` Approve (deprecated) + +_Approval has been integrated into the deposit action and is now deprecated._ + +Approve the `depositVault` address to withdraw an `amount` of FXRP from your smart account. +The address `depositVault` is designated by the `MasterAccountController` contract, and the `amount` is read from the last 31 bytes of the payment reference. + +A withdraw payment reference is the 32-byte value: + +- byte representation of `03` on the first byte, +- byte representation of the `amount` number on the other 31 bytes. + +
+ +
+ +## `04` Redeem + +Redemption is the process of converting FXRP back to XRP. +A number of `lots` of FXRP are burned, and the same number of `lots` of XRP is returned to the user's XRPL account. + +The process is performed by an `executor` with `executorFee` (explained in the [minting guide](/fassets/minting#executor-role)); +both of these are defined by the `MasterAccountController` contract. +The `lots` and `agentVault` values are both read from the payment reference. + +A redeem payment reference is the 32-byte value: + +- byte representation of `04` on the first byte, +- 19 empty bytes, +- byte representation of the `lots` number on the last 11 bytes. + +
+ +
+ +## `05` Reserve collateral + +Collateral reservation is the first step in the FAssets minting process. +In anticipation of the transfer of XRP to the agent's underlying address on XRPL, a portion of its collateral is locked to prevent accidental under-collateralization. +Since this action happens on the Flare chain, the gas fees need to be paid in the native FLR token. + +The reserveCollateral action reserves a number of `lots` of collateral of the `agentVault`. +The process is performed by an `executor` with `executorFee` (explained in the [minting guide](/fassets/minting#executor-role)); +both of these are defined by the `MasterAccountController` contract. +The `lots` and `agentVault` values are both read from the payment reference. + +A reserveCollateral payment reference is a 32-byte value: + +- byte representation of `05` on the first byte, +- `agentVault` address on the next 20 bytes, +- byte representation of the `lots` number on the last 11 bytes. + +
+ +
+ +## `06` Claim withdraw + +The second part of the withdrawal process from the Firelight vault. +Claim the pending withdrawal from the Firelight `depositVault`, specified by the `MasterAccountController` contract. +The assets are transferred to the user's smart account. +The action can only be performed after one full period has passed. + +A reserveCollateral payment reference is a 32-byte value: + +- byte representation of `06` on the first byte, +- 31 empty bytes. + +
+ +
diff --git a/docs/smart-accounts/3-custom-instruction.mdx b/docs/smart-accounts/3-custom-instruction.mdx new file mode 100644 index 00000000..cfac56fd --- /dev/null +++ b/docs/smart-accounts/3-custom-instruction.mdx @@ -0,0 +1,107 @@ +--- +sidebar_position: 1 +slug: custom-instruction +title: Custom instruction +authors: [nikerzetic, filipkoprivec] +description: Performing custom function calls in the Flare Smart Accounts. +tags: [intermediate, ethereum, flare-smart-accounts] +keywords: + [ + flare-fdc, + ethereum, + flare-smart-accounts, + evm, + flare-network, + account-abstraction, + ] +unlisted: false +--- + +import ThemedImage from "@theme/ThemedImage"; +import useBaseUrl from "@docusaurus/useBaseUrl"; + +Flare Smart Accounts allow users to execute custom function calls on the Flare chain through instructions on XRPL. +The process expands on the workflow for other actions by including an additional step at the beginning. + +In order for the `MasterAccountController` contract to be able to give a custom instruction to a personal account, the custom action must first be registered with the said contract. +The custom instruction is stored in a mapper, with its 31-byte hash as a key. +That hash is then sent as the payment reference, along with the byte representation of the number 99 in the first byte. + +
+ +
+ +## The expanded workflow + +We expand the workflow described in the [Flare Smart Accounts overview](/smart-accounts/overview) with an additional step before the first. + +0. A custom instruction is registered with the `MasterAccountController` contract. +1. The XRPL user sends instructions as a `Payment` transaction to a specific XRPL address, with instructions encoded as the payment reference in the memo field. +2. The operator interacts with the [Flare Data Connector](/fdc/overview) to procure a `Payment` proof. + It then calls the `executeTransaction` function on the `MasterAccountController` contract, with the `Payment` proof and the XRPL address that made the transaction. +3. The XRPL user's smart account performs the actions given in the instructions. + +## Custom Instructions + +Custom instructions are an array of the `IMasterAccountController.CustomInstruction` Solidity struct. +The struct contains three fields: + +- **targetContract**: the address of the smart contract that will execute the custom function +- **value**: the amount of FLR paid to the contract +- **data**: transaction calldata, which includes a function selector and values of the function's arguments + +Each of the custom instructions in the array will be performed in order. +A call to the `targetContract` address is made, with the specified `value` and the calldata `data`. + +{/* TODO:(Nik) explain how calldata is produced */} +In Solidity, we can obtain the calldata by doing the following: + +```Solidity +abi.encodeWithSignature("(,,...,)", [, , ..., ]); +``` + +where `` is the name of the function that we want to call, ``, ``, . . . , `` are its argument types, and ``, ``, . . . , `` their values. + +Only function calls with specific parameter values included can be registered. +That means that a new custom instruction needs to be registered for each unique action (though this can be done just seconds in advance). +It is also the reason why special FAsset actions have their own IDs, instead of defaulting to the custom call - it allows us to also specify certain parameters within the instructions on XRPL. + +## Call hash + +To produce the custom instructions calldata, we first ABI encode the array of the `IMasterAccountController.CustomInstruction` struct. +We then take the `keccak256` hash of that value, and drop the last byte. +That is the call hash that is provided as the payment reference for the custom action, and the ID under which the custom instructions are stored in the `MasterAccountController` contract. + +```Solidity +uint256(keccak256(abi.encode(_customInstruction))) >> 8; +``` + +The call hash can also be obtained through the `encodeCustomInstruction` helper function of the `MasterAccountController` contract. + +```Solidity +function encodeCustomInstruction( + CustomInstruction[] memory _customInstruction + ) public pure returns (uint256) { + return uint256(keccak256(abi.encode(_customInstruction))) >> 8; + } +``` + +## 0. Register custom instructions + +We register a custom instruction by calling the `registerCustomInstruction` function on the `MasterAccountController` contract. +The `IMasterAccountController.CustomInstruction` array is provided as an argument. +It is encoded as described above and stored in a `CustomInstructions` mapping. diff --git a/docs/smart-accounts/guides/01-fsa-cli.mdx b/docs/smart-accounts/guides/01-fsa-cli.mdx new file mode 100644 index 00000000..7b354517 --- /dev/null +++ b/docs/smart-accounts/guides/01-fsa-cli.mdx @@ -0,0 +1,170 @@ +--- +sidebar_position: 1 +slug: fsa-cli +title: Flare Smart Accounts CLI +authors: [nikerzetic, filipkoprivec] +description: Introduction to the Flare Smart Accounts CLI. +tags: [intermediate, ethereum, flare-smart-accounts] +keywords: + [ + flare-fdc, + ethereum, + flare-smart-accounts, + evm, + flare-network, + account-abstraction, + ] +unlisted: false +--- + +import ThemedImage from "@theme/ThemedImage"; +import useBaseUrl from "@docusaurus/useBaseUrl"; + +The [Flare Smart Accounts CLI](https://github.com/flare-foundation/smart-accounts-cli) is a tool written in Python that streamlines the Flare Smart Accounts process by properly structuring and sending XRPL transactions/instructions. +It has commands corresponding to each Flare Smart Accounts action ([table of instructions](/smart-accounts/overview#1-instructions-on-xrpl)), as well as other useful debugging features. + +:::note +The CLI executes **only** the transaction on XRPL. +It does not bridge the instructions to Flare. +That is done by the operator - a service that Flare runs. +::: + +To use the CLI, first clone [the repository](https://github.com/flare-foundation/smart-accounts-cli) and install the necessary dependencies: + +```sh +git clone https://github.com/flare-foundation/smart-accounts-cli.git +cd smart-accounts-cli +pip install -r requirements.txt +``` + +Copy the `.env.example` file to the `.env` file, and fill in the missing values in the latter. + +```sh +cp .env.example .env +``` + +The missing values are an XRPL testnet account secret value, a Flare address private key, and the RPC URLs for both Flare's Coston2 and XRPL testnet. +You can create a new secret string through the [XRP faucets](https://xrpl.org/resources/dev-tools/xrp-faucets). + +You can then run the script with the command: + +```sh +smart_accounts [-h] [--version] {bridge,debug} ... +``` + +## `bridge` command + +{/* TODO:(Nik) check if the second sentence is still true */} +The `bridge` command executes an XRPL transaction with instructions for one of the actions, determined by the positional argument provided. +A payment transaction with the appropriate memo field value is sent to the operator's XRPL address from the XRPL address specified in the `.env` file. + +What follows is a list of possible positional arguments, what they do, and the additional parameters of each. + +### `deposit` + +Deposit an `amount` of FXRP from the smart account belonging to the XRPL address to the Firelight vault, designated by the `MasterAccountController` contract. + +```sh +./smart_accounts.py bridge deposit -a +``` + +### `withdraw` + +Begin the withdrawal process from the Firelight vault. +An `amount` of FXRP is marked to be withdrawn from the Firelight vault to the user's smart account. + +```sh +./smart_accounts.py bridge withdraw -a +``` + +### `redeem` + +Redeem a `lots` amount of FXRP. +That number of lots of FXRP are burned from the user's smart account, and the same amount of XRP is sent to the user's address on XRPL. + +```sh +./smart_accounts.py bridge redeem -l +``` + +### `mint` + +Mints a number of `lots` of FXRP to the user's smart account. +The script first reserves collateral with the agent with the `address`, by sending a `reserveCollateral` instruction. +It then sends a `lots` amount of XRP to the agent's underlying address. +An executor, determined by the `MasterAccountController`, will complete the minting process, and `lots` of FXRP will be minted to the user's smart account. + +```sh +./smart_accounts.py bridge mint -a
-l +``` + +### `claim-withdraw` + +Complete the withdrawal process from the Firelight vault by claiming the funds. +After the withdrawal process has been started, the funds are locked for a certain amount of time. +Once that period has passed, they can be transferred back to the user's smart account. + +```sh +./smart_accounts.py bridge claim-withdraw +``` + +### `custom` + +Execute a custom action on the Flare chain. +Make a transaction to the `address`, paying the `value`, and attaching the `calldata`. +The `calldata` is the encoding of a function and its argument values, on the smart contract at the `address. + +```sh +./smart_accounts.py bridge deposit -a
-v -d +``` + +Before making a transaction on XRPL with the necessary instructions, this command performs an additional step. +It first packs the three provided values (`address`, `value`, and `calldata`) into a `IMasterAccountController.CustomInstruction` struct. +Then, it calls the `registerCustomInstruction` function of the `MasterAccountController` contract, with the former as an argument. + +Thus, it both registers a custom instruction with the `MasterAccountController` contract and retrieves the required `callHash`, which it can then send to the operator's XRPL address as instructions. + +## `debug` command + +The `debug` command offers some utility options for running the CLI. +It allows three positional arguments: `mock-custom`, `check-status`, and `simulation`. + +### `mock-custom` + +Simulate a custom instruction with the mock `MasterAccountController` contract. +Instead of sending the instructions as a transaction on XRPL and bridging them to Flare, the custom instructions are sent to the `MasterAccountController` contract directly. +This is explained in more detail in the [Custom instructions guide](/smart-accounts/guides/custom-instruction). + +The `address`, `value`, and `data` parameters are the same as for the [custom](/smart-accounts/guides/fsa-cli#custom) positional argument. +The `seed` is a string representing an XRPL account. + +```sh +./smart_accounts.py debug mock-custom -s -a
-v -d +``` + +### `check-status` + +Check the status of the XRPL transaction with the `xrpl_hash`. + +```sh +./smart_accounts.py debug check-status +``` + +### `simulation` + +{/* Run the simulation of the [FAsset cycle](/smart-accounts/guides/fassets-cycle). */} +Run the simulation of the FAsset cycle. +It converts `mint` lots of XRP to FXRP, deposits `deposit` FXRP into the Firelight vault, withdraws `deposit` FXRP back to the smart account, and finally redeems `mint` FXRP back to XRP. + +```sh +./smart_accounts.py debug simulations -a
-m -d +``` + +This is equivalent to running the following commands: + +```sh +./smart_accounts.py bridge mint -a
-l +./smart_accounts.py bridge deposit -a +./smart_accounts.py bridge withdraw -a +./smart_accounts.py bridge claim-withdraw +./smart_accounts.py bridge redeem -l +``` diff --git a/docs/smart-accounts/guides/02-custom-instructions.mdx b/docs/smart-accounts/guides/02-custom-instructions.mdx new file mode 100644 index 00000000..2ddc2082 --- /dev/null +++ b/docs/smart-accounts/guides/02-custom-instructions.mdx @@ -0,0 +1,135 @@ +--- +sidebar_position: 1 +slug: custom-instruction +title: Custom instructions +authors: [nikerzetic, filipkoprivec] +description: Developing a custom instruction for the Flare Smart Accounts. +tags: [intermediate, ethereum, flare-smart-accounts] +keywords: + [ + flare-fdc, + ethereum, + flare-smart-accounts, + evm, + flare-network, + account-abstraction, + ] +unlisted: false +--- + +{/* NOTE:(Nik) This article has been placed right after the introduction into Flare Smart Accounts instead of at the end, so that readers don't get bored of reading before they reach it. */} + +import ThemedImage from "@theme/ThemedImage"; +import useBaseUrl from "@docusaurus/useBaseUrl"; + +The Flare Smart Accounts allow XRPL users to make custom function calls on Flare through instructions sent on XRPL. +In this guide we will look at how the custom instructions can be developed using a mock version of the `MasterAccountController` contract. + +In a typical workflow the users sends instructions as memo data on XRPL. +Those then have to be verified by the FDC on the Flare chain. +That process requires waiting, which is less than ideal in a development environment. + +For that reason, a mock version of the `MasterAccountController` contract has been deployed. +It implements two additional functions: + +- `createFundPersonalAccount` +- `executeCustomInstructionDevelopment` + +The `createFundPersonalAccount` function creates a new `PersonalAccount` for the user. +It accepts as its argument a string `_xrplAddress`, which represents and address on XRPL. +The string is then concatenated with the `msg.sender` value; +the `PersonalAccount` is created for this address. + +Thus, a developer can create multiple XRPL "addresses". +This allows them to more easily test the interactions between different personal accounts. +The "address" is combined with their Flare address, so that they can give meaningful names to their "addresses" without a danger of multiple developers' addresses crashing. + +The `createFundPersonalAccount` function is a payable function. +And funds sent with the transaction are deposited to the newly created personal account. +That way, the personal account can interact with payable functions from the get-go. + +The `executeCustomInstructionDevelopment` function sidesteps the XRP transaction and the FDC `Payment` verification process. +It allows developers to send an array of custom instructions to the `MasterAccountController` contract directly. + +The two parameters this function takes are the `_xrplAddress` string, and an array of `IMasterAccountController.CustomInstruction` structs. +It first concatenates the input string with the `msg.sender` value, the same way the `createFundPersonalAccount` function does. +Then, it retrieves the `PersonalAccount` representing that address, and calls its `custom` function with the array of custom instructions it received as input. + +{/* TODO:(Nik) Explain how we can do these two things through the CLI. */} + +## A simple example + +We will now use the Flare Smart Accounts CLI to interact with a simple contract. +The contract `Foo` has a single payable function `bar`. +The `bar` function accepts a `uint256` value as input, and add the fee paid with the transaction to a mapping. + +```Solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.25; + +contract Foo { + mapping(uint256 => uint256) public map; + + function bar(uint256 a) public payable { + map[a] = map[a] + msg.value; + } +} +``` + +We want to send `1 FLR` to the contract, and save it under number `42`. +The address of the `Foo` contract is `0x296432C15504Ed465fAce11E54Ce4aac50cCd8A3`. +Using an online ABI-encoding tool, we get that the following hash for the `bar` function, with `42` as input: `0x0423a132000000000000000000000000000000000000000000000000000000000000002a`. + +There are two ways we can go about developing the custom instructions. +We will start with an approach, which is what the production code would take. +Afterwards, we will use the the mock functions to speed up the development. + +### Normal approach + +Before we can execute the above instructions we need to top up the smart account that will perform the function call. +We run the following command, which fails because our account lacks funds on Flare. +It is necessary to send some instructions, because that is what creates an account for us in the first place. + +```sh +./smart_accounts.py bridge custom -a "0x296432C15504Ed465fAce11E54Ce4aac50cCd8A3" -v 1 -d "0423a132000000000000000000000000000000000000000000000000000000000000002a" +``` + +We then need to retrieve the smart account address. + +```sh +./smart_accounts personal-account --from-env print +``` + +With the address, we can go to the [Flare faucet](https://faucet.flare.network/coston2) and request C2FLR for the smart account address. +We can also do this through the CLI. + +```sh +./smart_accounts personal-account --from-env faucet +``` + +Afterwards, we can run the following command again. +This time, it works. + +```sh +./smart_accounts.py bridge custom -a "0x296432C15504Ed465fAce11E54Ce4aac50cCd8A3" -v 1 -d "0423a132000000000000000000000000000000000000000000000000000000000000002a" +``` + +### Mocking + +We can speed up the process, as well as simplify it, by using the Flare Smart Accounts CLI. +First, we need to create a mock account, which we do with the command. +This will only work if our Flare address has sufficient funds. + +```sh +./smart_accounts mock-create-fund --seed "mockAccount" --value 1 +``` + +Here we arbitrarily chose the name `mockAccount` as the account address. +Behind the scenes, the string `mockAccount` will be concatenated with our Flare address. + +Then, we execute the custom instructions. +We use the string `mockAccount` as the seed. + +```sh +./smart_accounts.py debug mock-custom -s "mockAccount" -a "0x296432C15504Ed465fAce11E54Ce4aac50cCd8A3" -v 1 -d "0423a132000000000000000000000000000000000000000000000000000000000000002a" +``` diff --git a/docs/tags.yml b/docs/tags.yml index 3c4bfb99..06aab5cc 100644 --- a/docs/tags.yml +++ b/docs/tags.yml @@ -38,3 +38,5 @@ evm: label: evm infrastructure: label: infrastructure +flare-smart-accounts: + label: flare-smart-accounts diff --git a/sidebars.ts b/sidebars.ts index 0e869d20..ecc35d71 100644 --- a/sidebars.ts +++ b/sidebars.ts @@ -251,6 +251,38 @@ const sidebars: SidebarsConfig = { }, ], }, + { + type: "category", + label: "Flare Smart Accounts", + collapsed: true, + link: { type: "doc", id: "smart-accounts/overview" }, + items: [ + "smart-accounts/fasset-instructions", + "smart-accounts/custom-instruction", + { + type: "category", + label: "Developer Guides", + collapsed: true, + link: { + slug: "/smart-accounts/guides", + type: "generated-index", + }, + items: [{ type: "autogenerated", dirName: "smart-accounts/guides" }], + }, + // { + // type: "category", + // label: "Flare Smart Accounts Reference", + // collapsed: true, + // link: { + // type: "doc", + // id: "smart-accounts/reference", + // }, + // items: [ + // { type: "autogenerated", dirName: "smart-accounts/reference" }, + // ], + // }, + ], + }, { type: "category", label: "Run a Node", diff --git a/static/img/smart-accounts/approve_dark.svg b/static/img/smart-accounts/approve_dark.svg new file mode 100644 index 00000000..04fdd278 --- /dev/null +++ b/static/img/smart-accounts/approve_dark.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/approve_light.svg b/static/img/smart-accounts/approve_light.svg new file mode 100644 index 00000000..bed50223 --- /dev/null +++ b/static/img/smart-accounts/approve_light.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/claim_withdraw_dark.svg b/static/img/smart-accounts/claim_withdraw_dark.svg new file mode 100644 index 00000000..2fb86e73 --- /dev/null +++ b/static/img/smart-accounts/claim_withdraw_dark.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/claim_withdraw_light.svg b/static/img/smart-accounts/claim_withdraw_light.svg new file mode 100644 index 00000000..934badee --- /dev/null +++ b/static/img/smart-accounts/claim_withdraw_light.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/custom_dark.svg b/static/img/smart-accounts/custom_dark.svg new file mode 100644 index 00000000..a5bfac45 --- /dev/null +++ b/static/img/smart-accounts/custom_dark.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/custom_light.svg b/static/img/smart-accounts/custom_light.svg new file mode 100644 index 00000000..268d4b8a --- /dev/null +++ b/static/img/smart-accounts/custom_light.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/deposit_dark.svg b/static/img/smart-accounts/deposit_dark.svg new file mode 100644 index 00000000..ee8b8b57 --- /dev/null +++ b/static/img/smart-accounts/deposit_dark.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/deposit_light.svg b/static/img/smart-accounts/deposit_light.svg new file mode 100644 index 00000000..f55f5efd --- /dev/null +++ b/static/img/smart-accounts/deposit_light.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/redeem_dark.svg b/static/img/smart-accounts/redeem_dark.svg new file mode 100644 index 00000000..24c3c880 --- /dev/null +++ b/static/img/smart-accounts/redeem_dark.svg @@ -0,0 +1,14 @@ + + + + + + + + + + + + + + diff --git a/static/img/smart-accounts/redeem_light.svg b/static/img/smart-accounts/redeem_light.svg new file mode 100644 index 00000000..0bd34b4f --- /dev/null +++ b/static/img/smart-accounts/redeem_light.svg @@ -0,0 +1,14 @@ + + + + + + + + + + + + + + diff --git a/static/img/smart-accounts/reserve_collateral_dark.svg b/static/img/smart-accounts/reserve_collateral_dark.svg new file mode 100644 index 00000000..d04f66ad --- /dev/null +++ b/static/img/smart-accounts/reserve_collateral_dark.svg @@ -0,0 +1,14 @@ + + + + + + + + + + + + + + diff --git a/static/img/smart-accounts/reserve_collateral_light.svg b/static/img/smart-accounts/reserve_collateral_light.svg new file mode 100644 index 00000000..45e632a2 --- /dev/null +++ b/static/img/smart-accounts/reserve_collateral_light.svg @@ -0,0 +1,14 @@ + + + + + + + + + + + + + + diff --git a/static/img/smart-accounts/withdraw_dark.svg b/static/img/smart-accounts/withdraw_dark.svg new file mode 100644 index 00000000..5cebbd2f --- /dev/null +++ b/static/img/smart-accounts/withdraw_dark.svg @@ -0,0 +1,10 @@ + + + + + + + + + + diff --git a/static/img/smart-accounts/withdraw_light.svg b/static/img/smart-accounts/withdraw_light.svg new file mode 100644 index 00000000..3f0006e9 --- /dev/null +++ b/static/img/smart-accounts/withdraw_light.svg @@ -0,0 +1,10 @@ + + + + + + + + + +