Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 75 additions & 18 deletions docs/smart-accounts/guides/01-fsa-cli.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -52,9 +52,23 @@ You can then run the script with the command:
smart_accounts [-h] [--version] {bridge,debug} ...
```

## `encode` command

The `encode` command prints encoded memo fields that can be used in XRPL transactions to instruct the operator to perform certain actions on Flare.
It allows for the following positional arguments: `deposit`, `withdraw`, `redeem`, `mint`, `claim-withdraw`, and `custom`.
The command produces a payment reference corresponding to each instruction type.

For example, the following command

```sh
./smart_accounts.py encode mint -l 1
```

would result in the payment reference `0100000000000000000000000000000000000000000000000000000000000001`.
The first `01` here signals that it is a `mint` instruction, while the remaining bytes give the amount - in this case `1`.

## `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.

Expand Down Expand Up @@ -89,14 +103,18 @@ That number of lots of FXRP are burned from the user's smart account, and the sa
### `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` (if you are unsure what agent to choose on coston2, use `0x55c815260cBE6c45Fe5bFe5FF32E3C7D746f14dC`), by sending a `reserveCollateral` instruction.
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 <address> -l <lots>
```

:::info
On Coston2, you can use `0x55c815260cBE6c45Fe5bFe5FF32E3C7D746f14dC` as the agent address.
:::

### `claim-withdraw`

Complete the withdrawal process from the Firelight vault by claiming the funds.
Expand All @@ -123,18 +141,67 @@ Then, it calls the `registerCustomInstruction` function of the `MasterAccountCon

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.

You can also use the command with json file containing an array of custom instructions.
Two provided json files in `json_examples/` directory demonstrate the expected format.
Instead of the `address`, `value` and `calldata` parameters, a JSON file with an array of custom instructions can be used.
The command then reads as follows:

```sh
./smart_accounts.py bridge custom <json_file>
```

## `personal-account` command

The `personal-account` command gives insight into personal accounts of XRPL addresses.
{/* TODO:(Nik) is it equivalent to calling getPersonalAccount */}

It allows for the following positional arguments: `print` and `faucet`.

### `print`

Prints the Flare address of the personal account belonging to the `xrpl_address`.

```sh
./smart_accounts.py personal-account print <xrpl_address>
```

### `faucet`

{/* TODO:(Nik) fix the bellow text once it can faucet */}
Prints the Flare address of the personal account belonging to the `xrpl_address` and the faucet instructions.
In the future, it will faucet funds to the address instead.

```sh
./smart_accounts.py bridge custom json_example/sendFXRPCoston.json
./smart_accounts.py personal-account faucet <xrpl_address>
```

## `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-print`

Prints the Flare address of the personal account created by the mock `MasterAccountController` contract from the `seed` string.
The personal account is created by the `createFundPersonalAccount` developer function.
It represents the XRPL "address" of the concatenated string of `msg.sender` and `seed`.
This allows for easier creation of multiple personal accounts with invocative names, for easier development.

```sh
./smart_accounts.py debug mock-print -s <seed>
```

### `mock-create-fund`

Creates a personal account for the `seed` address string through the `MasterAccountController` contract, and sends to it the `value` amount.
The personal account is created by the `createFundPersonalAccount` developer function.
It represents the XRPL "address" of the concatenated string of `msg.sender` and `seed`.
This allows for easier creation of multiple personal accounts with invocative names, for easier development.

```sh
./smart_accounts.py debug mock-create-fund -s <seed> -v <value>
```

The `value` can be expressed as as `flr` (ex. `42flr`).

### `mock-custom`

Simulate a custom instruction with the mock `MasterAccountController` contract.
Expand All @@ -148,10 +215,10 @@ The `seed` is a string representing an XRPL account.
./smart_accounts.py debug mock-custom -s <seed> -a <address> -v <value> -d <calldata>
```

As with the `custom` command, you can also use a json file containing an array of custom instructions.
As with the `custom` command, a JSON file containing an array of custom instructions can be used.

```sh
./smart_accounts.py debug mock-custom -s <seed> json_example/sendFXRPCoston.json
./smart_accounts.py debug mock-custom -s <seed> <json_file>
```

### `check-status`
Expand All @@ -164,8 +231,7 @@ Check the status of the XRPL transaction with the `xrpl_hash`.

### `simulation`

{/* Run the simulation of the [FAsset cycle](/smart-accounts/guides/fassets-cycle). */}
Run the simulation of the FAsset cycle.
Run the simulation of the [FAsset cycle](/smart-accounts/guides/fassets-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
Expand All @@ -181,12 +247,3 @@ This is equivalent to running the following commands:
./smart_accounts.py bridge claim-withdraw
./smart_accounts.py bridge redeem -l <mint>
```

## `encode` command

The `encode` command prints encoded memo fields that can be used in XRPL transactions to instruct the operator to perform certain actions on Flare.

```sh
./smart_accounts.py encode custom json_example/requestRedemption.json
./smart_accounts.py encode mint -l 1
```
38 changes: 19 additions & 19 deletions docs/smart-accounts/guides/02-custom-instructions.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -17,15 +17,15 @@ keywords:
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. */}
{/* 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 with 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 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.
In a typical workflow, the user 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.

Expand All @@ -36,22 +36,22 @@ It implements two additional functions:
- `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.
It accepts as its argument a string `_xrplAddress`, which represents an 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 "address" is combined with their Flare address, so that they can give meaningful names to their "addresses" without the 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.
And funds sent with the transaction are deposited into 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.
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.

Expand All @@ -61,37 +61,37 @@ Then, it retrieves the `PersonalAccount` representing that address, and calls it

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.
The `bar` function accepts a `uint256` value as input, and adds 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;
mapping(uint256 => uint256) public map;

function bar(uint256 a) public payable {
map[a] = map[a] + msg.value;
}
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`.
We want to send `1 FLR` to the contract, and save it under the 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`.
Using an online ABI-encoding tool, we get the following hash for the `bar` function, with `42` as input: `0x0423a132000000000000000000000000000000000000000000000000000000000000002a`.

:::warning
Encoding calldata by hand is error prone.
Encoding calldata by hand is error-prone.
It is recommended to use established libraries, or an [online tool](https://abi.hashex.org/) (if you want to quickly check something).
:::

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.
We will start with an approach that is what the production code would take.
Afterwards, we will use 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.
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.

Expand Down Expand Up @@ -129,7 +129,7 @@ This will only work if our Flare address has sufficient funds.
./smart_accounts.py debug mock-create-fund --seed "mockAccount" --value 1
```

Here we arbitrarily chose the name `mockAccount` as the account address.
Here, we arbitrarily chose the name `mockAccount` as the account address.
Behind the scenes, the string `mockAccount` will be concatenated with our Flare address.

You can check the associated account with the command:
Expand Down
90 changes: 90 additions & 0 deletions docs/smart-accounts/guides/03-fassets-cycle.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
---
sidebar_position: 1
slug: fassets-cycle
title: FAssets Cycle
authors: [nikerzetic, filipkoprivec]
description: An overview of the FAssets cycle with the use of 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";

In this guide, we will walk you through all aspects of the [FAssets](/fassets/overview) process.
We will start with an account on XRPL, we will send its assets to Flare, and then return them to XRPL.
The steps we will take will be as follows:

1. `mint`: convert XRP to FXRP
2. `deposit`: deposit FXRP to the Firelight vault
3. `withdraw`: withdraw FXRP from the Firelight vault
4. `redeem`: convert FXRP back to XRP

We will do all of that through the [Flare Smart Accounts CLI](/smart-accounts/guides/fsa-cli).
The CLI allows us to make XRPL transactions through terminal commands.

:::note
The idea behind the Flare Smart Accounts is that we perform actions on the Flare chain through instructions sent on XRPL.
:::

## Mint

First, we mint FXRP by reserving the necessary collateral and then sending XRP to the agent's underlying address.
We will mint `1` lot of FXRP, with the agent at the address `0x55c815260cBE6c45Fe5bFe5FF32E3C7D746f14dC`.
The CLI command that does this is:

```sh
./smart_accounts.py bridge mint -a 0x55c815260cBE6c45Fe5bFe5FF32E3C7D746f14dC -l 1
```

The CLI sends both the `reserveCollateral` instruction and the `Payment` transaction to the agent's underlying address.

## Deposit

Next, we deposit `1` FXRP into the Firelight vault, specified by the `MasterAccountController` contract.
Here, the CLI sends the `deposit` instruction.
The command is:

```sh
./smart_accounts.py bridge deposit -a 1
```

## Withdraw

We withdraw the same number of tokens that we have just deposited from the Firelight vault.
The process involves two steps.
The CLI first sends the `withdraw` instruction, and afterwards, the `claimWithdraw`.
The first instruction starts the withdrawal process, and the second claims the FXRP once it is released.

We use the command:

```sh
./smart_accounts.py bridge withdraw -a 1
```

## Redeem

The last step is to convert FXRP back to XRP.
We will redeem the `1` lot of FXRP we minted in the first step back to XRP.
We will invoke the CLI with the following command.

```sh
./smart_accounts.py bridge redeem -a 1
```

## Simulation

The above cycle can be simulated with a single CLI command:

```sh
./smart_accounts.py debug simulation -a 0x55c815260cBE6c45Fe5bFe5FF32E3C7D746f14dC -m 1 -d 1
```
Loading
Loading