# 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`. ### Minting FXRP (not a Smart Accounts instruction)[​](#minting-fxrp-not-a-smart-accounts-instruction "Direct link to Minting FXRP (not a Smart Accounts instruction)") User minting does **not** use a Smart Accounts collateral-reservation (CRT) instruction. To mint FXRP, send an XRPL `Payment` to the [Core Vault](/fassets/core-vault) with a memo or destination tag that encodes the Flare recipient, as described in [FAssets minting](/fassets/minting). - Programmatic walkthrough: [Mint FXRP](/fassets/developer-guides/fassets-mint) - Mint and run an action in one flow: [Memo Field Custom Instruction](/smart-accounts/memo-field-custom-instruction) (or [Custom Instruction](/smart-accounts/custom-instruction) for the hash-commitment variant) Legacy The legacy `00` collateral-reservation instruction (`fxrp-cr`) may still exist in older CLI tooling. It is not the recommended user mint path. ### `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` (see [fees](/fassets/minting#fees) and [executor restrictions](/fassets/minting#executor-restrictions)); 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`. ### Mint then deposit[​](#mint-then-deposit "Direct link to Mint then deposit") To mint FXRP and deposit into Firelight, use [FAssets minting](/fassets/minting) first (XRPL payment to the Core Vault with memo or tag), then the deposit-only instruction (`01`) below once FXRP is in the personal account. For mint-and-deposit in a single XRPL payment, use a [memo-field custom instruction](/smart-accounts/memo-field-custom-instruction) that calls the Firelight vault after minting. Legacy The combined `00` collateral-reservation-and-deposit instruction (`firelight-cr-deposit`) is a legacy CRT path. Prefer mint via [FAssets minting](/fassets/minting), then `01` Deposit. ### `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`. Use this after minting FXRP via [FAssets minting](/fassets/minting), or whenever the personal account already holds FXRP. 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`. ### Mint then deposit[​](#mint-then-deposit-1 "Direct link to Mint then deposit") To mint FXRP and deposit into Upshift, use [FAssets minting](/fassets/minting) first (XRPL payment to the Core Vault with memo or tag), then the deposit-only instruction (`01`) below once FXRP is in the personal account. For mint-and-deposit in a single XRPL payment, use a [memo-field custom instruction](/smart-accounts/memo-field-custom-instruction) that calls the Upshift vault after minting. Legacy The combined `00` collateral-reservation-and-deposit instruction (`upshift-cr-deposit`) is a legacy CRT path. Prefer mint via [FAssets minting](/fassets/minting), then `01` Deposit. ### `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`. Use this after minting FXRP via [FAssets minting](/fassets/minting), or whenever the personal account already holds FXRP. 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)