# FAsset Instructions > Using Flare Smart Accounts in the FAssets workflow. > For the complete documentation index, see [llms.txt](/llms.txt). Markdown versions of documentation pages are available by appending `.md` to the page URL. Source: https://dev.flare.network/smart-accounts/fasset-instructions 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). The instructions fall under three types: `FXRP`, `Firelight`, and `Upshift`. Each type supports different instruction commands. The `FXRP` commands allow interaction with the base FAssets system, whereas `Firelight` and `Upshift` give access to actions pertaining to the corresponding vault architectures. The first byte of each encoded instruction is the instruction ID. It is further subdivided into the instruction type (first half-byte), and instruction command (second half-byte). The values for the instruction type Id nad the command ID range from `0` to `f` (`15` in hexadecimal); thus the instruction IDs range from `00` to `ff`. The second byte is the `walletID`. This value is assigned individually by the Flare, and is intended for wallet identification by the operator. ## FXRP[​](#fxrp "Direct link to FXRP") The commands of the `FXRP` type give access to base FAsset actions. The ID of the `FXRP` type is `0`. ### `00` Collateral reservation[​](#00-collateral-reservation "Direct link to 00-collateral-reservation") 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 collateral reservation action reserves a `value` of lots of collateral in the agent vault with the `agentVaultId`. The `MasterAccountController` keeps a registry of agent vault addresses, and the `agentVaultId` corresponds to one of the keys of that registry. The process is performed by an `executor` with `executorFee` (explained in the [minting guide](/fassets/minting#executor-role)); it is defined by the `MasterAccountController` contract. A collateral reservation payment reference is a 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `00` in the first nibble, - command ID `00` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - byte representation of `agentVaultId` in the next two bytes - the remaining 18 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the collateral reservation action.](/img/docs/smart-accounts/bytes-fxrp-collateral-reservation-light.png)![Breakdown of bytes in payment reference for the collateral reservation action.](/img/docs/smart-accounts/bytes-fxrp-collateral-reservation-dark.png) ### `01` Transfer[​](#01-transfer "Direct link to 01-transfer") Transfer `value` of drops of FXRP to the `recipientAddress`. The FXRP is sent from the personal account that belongs to the XRPL address that sent the instruction, if the FXRP balance is sufficient. A transfer payment reference is a 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `00` in the first nibble, - command ID `01` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - `recipientAddress` in the remaining 20 bytes ![Breakdown of bytes in payment reference for the transfer action.](/img/docs/smart-accounts/bytes-fxrp-transfer-light.png)![Breakdown of bytes in payment reference for the transfer action.](/img/docs/smart-accounts/bytes-fxrp-transfer-dark.png) ### `02` Redeem[​](#02-redeem "Direct link to 02-redeem") Redemption is the process of converting FXRP back to XRP. A `value` of lots of FXRP are burned from the personal account belonging to the XRPL address that sent the instruction; and the same `value` 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. A redeem payment reference is the 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `00` in the first nibble, - command ID `02` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - the remaining 20 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the redeem action.](/img/docs/smart-accounts/bytes-fxrp-redeem-light.png)![Breakdown of bytes in payment reference for the redeem action.](/img/docs/smart-accounts/bytes-fxrp-redeem-dark.png) ## Firelight[​](#firelight "Direct link to Firelight") The commands of the `Firelight` type allow interaction with Firelight-type vaults. The ID of the `Firelight` type is `1`. ### `00` Collateral reservation and deposit[​](#00-collateral-reservation-and-deposit "Direct link to 00-collateral-reservation-and-deposit") Reserve the collateral for `value` lots of FXRP with the agent's vault, registered with the `agentVaultId` with the `MasterAccountController` contract. When minting is completed, deposit `value` lots of FXRP into a Firelight-type vault at the address registered with the `MasterAccountController` contract with the `vaultId`. Essentially, this allows an XRPL user to signal intent for two actions at once; it is equivalent to sending a collateral reservation instruction first, and afterwards a deposit instruction. This cuts the total waiting time in half and reduces the total number of transactions by one. A collateral reservation and deposit instruction payment reference is the 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `01` in the first nibble, - command ID `00` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - byte representation of `agentVaultId` in the next 2 bytes - byte representation of `vaultId` in the next 2 bytes - the remaining 16 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the collateral reservation and deposit action.](/img/docs/smart-accounts/bytes-firelight-collateral-reservation-and-deposit-light.png)![Breakdown of bytes in payment reference for the collateral reservation and deposit action.](/img/docs/smart-accounts/bytes-firelight-collateral-reservation-and-deposit-dark.png) ### `01` Deposit[​](#01-deposit "Direct link to 01-deposit") Deposit `value` lots of FXRP into a Firelight-type vault at the address registered with the `MasterAccountController` contract with the `vaultId`. A deposit instruction payment reference is the 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `01` in the first nibble, - command ID `01` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - the next two bytes are ignored and can have an arbitrary value - byte representation of `vaultId` in the next 2 bytes - the remaining 16 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the deposit action.](/img/docs/smart-accounts/bytes-firelight-deposit-light.png)![Breakdown of bytes in payment reference for the deposit action.](/img/docs/smart-accounts/bytes-firelight-deposit-dark.png) ### `02` Redeem[​](#02-redeem-1 "Direct link to 02-redeem-1") The first part of the withdrawal process from a Firelight vault. Initiate a withdrawal request of `value` of FXRP from the Firelight vault at the address registered with the `MasterAccountController` contract with the `vaultId`. A redeem instruction payment reference is the 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `01` in the first nibble, - command ID `02` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - the next two bytes are ignored and can have an arbitrary value - byte representation of `vaultId` in the next 2 bytes - the remaining 16 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the redeem action.](/img/docs/smart-accounts/bytes-firelight-redeem-light.png)![Breakdown of bytes in payment reference for the redeem action.](/img/docs/smart-accounts/bytes-firelight-redeem-dark.png) ### `03` Claim withdraw[​](#03-claim-withdraw "Direct link to 03-claim-withdraw") The second part of the withdrawal process from a Firelight vault. Claim the pending withdrawal from the `value` period, from the Firelight vault at the address registered with the `MasterAccountController` contract with the `vaultId`. The assets are transferred to the user's smart account. The action can only be performed after one full period has passed. The `value` is a parameter, emitted by the Firelight vault upon a redemption request. A claim withdrawal payment reference is a 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `01` in the first nibble, - command ID `03` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - the next two bytes are ignored and can have an arbitrary value - byte representation of `vaultId` in the next 2 bytes - the remaining 16 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the claim withdraw action.](/img/docs/smart-accounts/bytes-firelight-claim-withdraw-light.png)![Breakdown of bytes in payment reference for the claim withdraw action.](/img/docs/smart-accounts/bytes-firelight-claim-withdraw-dark.png) ## Upshift[​](#upshift "Direct link to Upshift") The commands of the `Upshift` type allow interaction with Upshift-type vaults. The ID of the `Upshift` type is `2`. ### `00` Collateral reservation and deposit[​](#00-collateral-reservation-and-deposit-1 "Direct link to 00-collateral-reservation-and-deposit-1") Reserve the collateral for `value` lots of FXRP with the agent's vault, registered with the `agentVaultId` with the `MasterAccountController` contract. When minting is completed, deposit `value` lots of FXRP into an Upshift-type vault at the address registered with the `MasterAccountController` contract with the `vaultId`. Essentially, this allows an XRPL user to signal intent for two actions at once; it is equivalent to sending a collateral reservation instruction first, and afterwards a deposit instruction. This cuts the total waiting time in half and reduces the total number of transactions by one. A collateral reservation and deposit instruction payment reference is the 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `02` in the first nibble, - command ID `00` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - byte representation of `agentVaultId` in the next 2 bytes - byte representation of `vaultId` in the next 2 bytes - the remaining 16 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the collateral reservation and deposit action.](/img/docs/smart-accounts/bytes-upshift-collateral-reservation-and-deposit-light.png)![Breakdown of bytes in payment reference for the collateral reservation and deposit action.](/img/docs/smart-accounts/bytes-upshift-collateral-reservation-and-deposit-dark.png) ### `01` Deposit[​](#01-deposit-1 "Direct link to 01-deposit-1") Deposit `value` lots of FXRP into an Upshift type vault at the address registered with the `MasterAccountController` contract with the `vaultId`. A deposit instruction payment reference is the 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `02` in the first nibble, - command ID `01` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - the next two bytes are ignored and can have an arbitrary value - byte representation of `vaultId` in the next 2 bytes - the remaining 16 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the deposit action.](/img/docs/smart-accounts/bytes-upshift-deposit-light.png)![Breakdown of bytes in payment reference for the deposit action.](/img/docs/smart-accounts/bytes-upshift-deposit-dark.png) ### `02` Request redeem[​](#02-request-redeem "Direct link to 02-request-redeem") The first part of the withdrawal process from an Upshift vault. Initiate a withdrawal request of `value` of FXRP from the Upshift vault at the address registered with the `MasterAccountController` contract with the `vaultId`. A request redeem instruction payment reference is the 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `02` in the first nibble, - command ID `02` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - the next two bytes are ignored and can have an arbitrary value - byte representation of `vaultId` in the next 2 bytes - the remaining 16 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the request redeem action.](/img/docs/smart-accounts/bytes-upshift-request-redeem-light.png)![Breakdown of bytes in payment reference for the request redeem action.](/img/docs/smart-accounts/bytes-upshift-request-redeem-dark.png) ### `03` Claim[​](#03-claim "Direct link to 03-claim") The second part of the withdrawal process from an Upshift vault. Claim the pending withdrawal from the `value` period, from the Upshift vault at the address registered with the `MasterAccountController` contract with the `vaultId`. The assets are transferred to the user's smart account. The action can only be performed after one full period has passed. The `value` represents the date when the redemption was requested. It is an 8-digit number `YYYYMMDD`, where `YYYY` is the year, `MM` the month (from `01` to `12`), and `DD` the day (from `01` to `31`, with additional monthly constraints) of the request. A claim payment reference is a 32-byte value: - byte representation of the instruction ID in the first byte: - type ID `02` in the first nibble, - command ID `03` in the second nibble, - byte representation of `walletId` in the second byte - byte representation of `value` in the next 10 bytes - the next two bytes are ignored and can have an arbitrary value - byte representation of `vaultId` in the next 2 bytes - the remaining 16 bytes are ignored and can have an arbitrary value ![Breakdown of bytes in payment reference for the claim action.](/img/docs/smart-accounts/bytes-upshift-claim-light.png)![Breakdown of bytes in payment reference for the claim action.](/img/docs/smart-accounts/bytes-upshift-claim-dark.png)