mcpField
F
flare-smart-accounts

flare-smart-accounts

github.com/flare-foundation开发22117 次安装2 周前更新
代码仓库

关于 flare-smart-accounts

介绍 Flare Smart Accounts 的信息类技能,使 XRPL 钱包持有者无需持有 FLR 即可在 Flare 发起操作。文档涵盖 Payment 与 memo 指令格式、金库操作和自定义合约调用;不会执行交易或处理签名密钥。

主要功能

  1. 01XRPL 到 Flare 的账户抽象说明
  2. 02Payment reference 指令格式
  3. 03FXRP 转账与赎回指令
  4. 04Firelight 和 Upshift 金库操作
  5. 05通过 memo 指令调用自定义合约
  6. 06安全与恢复指南

适用场景

  1. 01构建 XRPL Payment 指令支持
  2. 02集成 FXRP 金库存入与提取
  3. 03为 Flare 账户准备自定义调用
  4. 04检查交易流程与安全约束

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/flare-foundation/flare-ai-skills --skill flare-smart-accounts

安装后在 Claude Code 中输入/flare-smart-accounts确认已加载。

附带文件reference.md

详细介绍

安全与安全使用

此技能仅提供信息性指南。

  • 它不会执行区块链交易
  • 它不会存储或传输签名密钥
  • 所有签名都必须在用户控制的钱包中进行
  • 开发者应验证外部数据
  • 用户有责任安全管理密钥

不包含可执行代码或自动化金融操作。

Flare 智能账户

什么是智能账户

Flare 智能账户提供账户抽象,使 XRPL 用户无需持有任何 FLR 代币即可在 Flare 链上执行操作。

每个 XRPL 地址在 Flare 上都有一个专属智能账户,且仅该地址能够控制此账户。

主要优势:

  • 无需 FLR: 用户只需使用自己的 XRPL 钱包即可与 Flare 交互
  • 单笔交易: 所有指令都编码在一笔 XRPL Payment 交易中
  • 由运营方管理 Gas: 中继服务负责在 Flare 上执行交易
  • 基于证明的安全性: 使用 Flare Data Connector (FDC) 进行支付证明和验证

工作原理

Flare 智能账户支持两种互补的流程:

基于证明的流程(支付引用)
  1. XRPL 指令: 用户向运营方的 XRPL 地址发送 Payment,将 32 字节指令编码为 memo 字段中的支付引用。
  2. 生成证明: 运营方从 FDC 请求 Payment 证明。
  3. 链上执行: 运营方在 MasterAccountController 上调用 executeInstruction(或 reserveCollateral),并传入 FDC 证明。

合约会验证证明,获取(或创建)用户的智能账户,解码支付引用,并执行请求的操作。

直接铸造(memo)流程
  1. 用户按照 FAssets 铸造 中的说明,向 FAssets Core Vault XRPL 地址发送 Payment,以便将 FXRP 铸造到智能账户中,并在 memo 字段中携带指令。
  2. 执行器调用 executeDirectMinting;FAssets AssetManager 将 FXRP 铸造到 MasterAccountController,并回调 handleMintedFAssets。
  3. MasterAccountController 将 FAssets 转发到用户的 PersonalAccount,可选择支付执行器费用,并分派任何 memo 指令(参见 Memo 操作码)。

铸造是 FAssets 铸造,不是 CRT 指令。 用户铸造 FXRP 不再使用 Smart Accounts 抵押品预留(CRT)指令。要进行铸造,请按照 FAssets 铸造 中的说明,向 Core Vault 发送带有 memo 或目标标签的 XRPL Payment。旧版 CRT 指令(下方的 0x00、0x10、0x20)及其 CLI 编码器可能仍存在于较旧的工具中,但并非推荐的铸造方式。要在一笔支付中完成铸造和操作,请使用 memo 字段自定义指令。

重要: 目标为智能账户的 XRPL 交易不得使用目标标签。目标标签会导致 FAssets 直接铸造时将资产记入标签持有者,而不是智能账户。

支付引用结构(32 字节)

所有指令都遵循以下结构:

字节位置字段说明
第 1 字节指令 ID第一个半字节 = 类型(0-F),第二个半字节 = 命令(0-F)
第 2 字节钱包 ID由运营方分配的钱包标识符(若未分配则使用 0)
第 3-12 字节数值10 字节编码金额(FXRP 或 XRP 的整数份额)
第 13 字节及之后参数指令特定数据

指令类型 — 详细字节格式

FXRP 指令(类型 0x0_)
0x00 — 抵押品预留 (legacy CRT)

为铸造 FXRP 预留抵押品。**Legacy:**建议使用 FAssets 铸造(向 Core Vault 进行 XRPL 付款)。此处记录供旧版工具和历史集成参考。

字节字段描述
10x00指令 ID
2walletId钱包标识符
3-12value要铸造的批次数(10 字节)
13-14agentVaultIdAgent 金库标识符(2 字节)
15-32—任意值(忽略)

示例: 0x0000000000000000000000010001000000000000000000000000000000000000

  • 指令:00(FXRP 抵押品预留)
  • 钱包 ID:00
  • 数值:00000000000000000001(1 批)
  • Agent 金库 ID:0001
0x01 — 转账 FXRP

将 FXRP 转至 Flare 地址。

字节字段描述
10x01指令 ID
2walletId钱包标识符
3-12value要转账的 FXRP 数量(10 字节)
13-32recipientAddress目标 Flare 地址(20 字节)

示例: 0x01000000000000000000000af5488132432118596fa13800b68df4c0ff25131d

  • 指令:01(FXRP 转账)
  • 数值:000000000000000000000a(10 FXRP)
  • 收款方:0xf5488132432118596fa13800b68df4c0ff25131d
0x02 — 赎回 FXRP

将 FXRP 赎回为 XRPL 上的 XRP。

字节字段描述
10x02指令 ID
2walletId钱包标识符
3-12value要赎回的批次数(10 字节)
13-32—任意值(忽略)
Firelight 指令(类型 0x1_)

Firelight 是一种用于获取 stXRP 收益的金库协议。

0x10 — 抵押品预留 + 存款 (legacy CRT)

组合执行 FXRP 铸造并存入 Firelight 金库。**Legacy:**建议使用 FAssets 铸造,然后使用 0x11 存款指令;或者使用 备忘录字段自定义指令,在一笔付款中完成铸造和存款。

字节字段描述
10x10指令 ID
2walletId钱包标识符
3-12value批次数(10 字节)
13-14agentVaultIdAgent 金库标识符(2 字节)
15-16vaultIdFirelight 金库标识符(2 字节)
17-32—任意值(忽略)
0x11 — 存款

将已有 FXRP 存入 Firelight 金库。

字节字段描述
10x11指令 ID
2walletId钱包标识符
3-12value要存入的 FXRP 数量(10 字节)
13-14—任意值(忽略)
15-16vaultIdFirelight 金库标识符(2 字节)
17-32—任意值(忽略)
0x12 — 赎回(发起提款)

开始从 Firelight 金库提款。

字节字段描述
10x12指令 ID
2walletId钱包标识符
3-12value要提取的数量(10 字节)
13-14—任意值(忽略)
15-16vaultIdFirelight 金库标识符(2 字节)
17-32—任意值(忽略)
0x13 — 领取提款

完成 Firelight 金库中待处理的提款。

字节字段描述
10x13指令 ID
2walletId钱包标识符
3-12value要领取的数量(10 字节)
13-14—任意值(忽略)
15-16vaultIdFirelight 金库标识符(2 字节)
17-32—任意值(忽略)
Upshift 指令(类型 0x2_)

Upshift 是另一种采用定时锁定提款机制的金库协议。

0x20 — 抵押品预留 + 存款 (legacy CRT)

组合执行 FXRP 铸造和 Upshift 金库存款。旧版: 建议先使用 FAssets 铸造,再使用 0x21 存款指令;如需通过一笔付款完成铸造和存款,可使用 备忘录字段自定义指令。

字节字段描述
10x20指令 ID
2walletId钱包标识符
3-12value批次数量(10 字节)
13-14agentVaultIdAgent 金库标识符(2 字节)
15-16vaultIdUpshift 金库标识符(2 字节)
17-32—任意内容(忽略)
0x21 — 存款

将现有 FXRP 存入 Upshift 金库。

字节字段描述
10x21指令 ID
2walletId钱包标识符
3-12value存入的 FXRP 数量(10 字节)
13-14—任意内容(忽略)
15-16vaultIdUpshift 金库标识符(2 字节)
17-32—任意内容(忽略)
0x22 — 请求赎回

请求从 Upshift 金库提取资金(开始等待期)。

字节字段描述
10x22指令 ID
2walletId钱包标识符
3-12value提取金额(10 字节)
13-14—任意内容(忽略)
15-16vaultIdUpshift 金库标识符(2 字节)
17-32—任意内容(忽略)
0x23 — 领取

等待期结束后完成提取。

字节字段描述
10x23指令 ID
2walletId钱包标识符
3-12valueYYYYMMDD 格式的日期(例如,2025 年 12 月 18 日对应 20251218)
13-14—任意内容(忽略)
15-16vaultIdUpshift 金库标识符(2 字节)
17-32—任意内容(忽略)
备忘录操作码(直接铸造流程)

通过 FAssets 直接铸造路径将 FXRP 直接铸造到智能账户时,XRPL 备忘录的第一个字节会携带以下操作码之一:

备忘录操作码操作描述
0xFE自定义指令42 字节的备忘录,包含 keccak256(PackedUserOperation) 承诺;执行器通过链下方式传递字节
0xFF备忘录字段自定义指令在备忘录中内联携带完整的 abi.encode(PackedUserOperation)(上限约为 1024 字节)
0xE0跳过备忘录标记目标 XRPL 交易的备忘录,使其在下一次直接铸造时被跳过。用于在 executeDirectMintingWithData 回滚后恢复 FXRP — 参见故障处理与恢复
0xE1快进 nonce当个人账户的备忘录指令 nonce 在流程部分完成或中止后卡住时,将其推进 — 参见快进卡住的 nonce
0xE2替换执行器费用为卡住的 XRPL 交易设置替代执行器费用
0xD0固定执行器将特定执行器地址固定到个人账户
0xD1取消固定执行器从个人账户取消固定执行器

自定义指令 — 深入介绍

自定义指令允许 XRPL 用户通过 XRPL Payment 在 Flare 上执行任意合约调用。个人账户提供一个 EIP-4337 风格的 executeUserOp 入口点。

调用结构
struct Call {
    address target;   // Contract address to call
    uint256 value;    // FLR to send with the call
    bytes data;       // Encoded function calldata
}

function executeUserOp(Call[] calldata _calls) external payable;
PackedUserOperation

自定义指令以 EIP-4337 PackedUserOperation 的形式打包。只需设置三个字段:

  • sender — 必须等于个人账户地址(getPersonalAccount(xrplAddress))
  • nonce — 必须等于当前备忘录 nonce(getNonce(personalAccount))
  • callData — abi.encodeCall(IPersonalAccount.executeUserOp, (calls))
两种变体

自定义指令(0xFE)——推荐:

42 字节的备忘录布局:

字节字段描述
00xFE指令 ID
1walletId钱包标识符
2-9executorFeeUBA执行器费用(大端序 uint64)
10-41userOpHashkeccak256(abi.encode(userOp))

用户在链下将完整的 PackedUserOperation 字节数据发送给执行器。执行器在 AssetManager 上调用 executeDirectMintingWithData(proof, data),并设置 msg.value = sum(call.value)。控制器会在执行前验证 keccak256(_data) == userOpHash。无论批次大小如何,这都能使 XRPL 备忘录保持为 42 字节。

executeDirectMintingWithData 是完全原子化的:它会在一笔 Flare 交易中将 FXRP 铸造到个人账户,并分发用户操作。如果任何步骤回滚(哈希不匹配、nonce 无效、内部调用失败、msg.value 不足),整笔交易都会回滚——不会铸造 FXRP,也不会触发 UserOperationExecuted 事件。请参阅失败处理与恢复。

备忘录字段自定义指令(0xFF)——更简单,单参与方:

备忘录布局(10 字节头部 + 完整负载):

字节字段描述
00xFF指令 ID
1walletId钱包标识符
2-9executorFeeUBA执行器费用(大端序 uint64)
10+userOpDataabi.encode(PackedUserOperation)

完整的 PackedUserOperation 内嵌在备忘录中。任何索引器都可以通过 executeDirectMinting(proof) 转发。受 XRPL 备忘录 1024 字节上限的限制。

TypeScript 示例(自定义指令 0xFE)
import { encodeFunctionData } from "viem";

const calls = [
  {
    target: counterAddress,
    value: 0n,
    data: encodeFunctionData({
      abi: counterAbi,
      functionName: "increment",
      args: [],
    }),
  },
];

const callData = encodeFunctionData({
  abi: personalAccountAbi,
  functionName: "executeUserOp",
  args: [calls],
});

const nonce = await publicClient.readContract({
  address: MASTER_ACCOUNT_CONTROLLER_ADDRESS,
  abi: masterAccountControllerAbi,
  functionName: "getNonce",
  args: [personalAccountAddress],
});

const userOp = {
  sender: personalAccountAddress,
  nonce,
  callData,
  // remaining fields empty — not validated on-chain
  initCode: "0x",
  callGasLimit: 0n,
  verificationGasLimit: 0n,
  preVerificationGas: 0n,
  gasFees: "0x",
  paymasterAndData: "0x",
  signature: "0x",
};

// Deliver userOp bytes to executor off-chain, build 42-byte memo with keccak256 hash

**适用 0xFE 的情况:**批次较大、调用负载应在 XRPL 上保持私密,或你运行着执行器。 **适用 0xFF 的情况:**调用批次不超过约 1024 字节,且你不想与执行器协调。

有关详细的权衡指南,请参阅自定义指令对比。

不铸造代币,仅转移 ERC-20 余额:仅支付费用的自定义指令

个人账户可能已经持有与 FXRP 铸造无关的 ERC-20 余额(例如 USDT0)。若要转移或兑换该余额,请构建一条 0xFE 自定义指令,并设置 netMintAmountXrp: 0——XRPL 支付仅用于支付直接铸造费用和执行器费用,因此 executeDirectMintingWithData 会分发用户操作,而不会铸造任何 FXRP:

const memoOnlyAmountXrp = await computeDirectMintingPaymentAmountXrp({
  netMintAmountXrp: 0,
});

其余流程与 0xFE 协议的三步流程相同:对 Call[] 批次进行编码(例如 USDT0.transfer(recipient, amount),或使用 approve + SparkDEX exactInputSingle 将 USDT0 兑换为 FXRP),在 42 字节备忘录中提交 keccak256(PackedUserOperation),发送仅支付费用的 XRPL 付款,然后让执行器获取 FDC 证明并调用 executeDirectMintingWithData。请参阅基于 flare-viem-starter 构建的 Control USDT0 指南,其中提供了完整的可运行示例(余额检查、转账和兑换脚本)。

失败处理与恢复

0xFE / 0xFF 自定义指令直接铸造流程在 Flare 侧是原子化的。当 executeDirectMintingWithData(或 0xFF 的 executeDirectMinting)回滚时,整笔 Flare 交易都会回滚:

  • 不会在 Flare 上铸造 FXRP,也不会运行用户操作——不会触发 UserOperationExecuted 事件。
  • XRPL 付款不会被撤销——在成功完成直接铸造之前,底层 XRP 会留在 Core Vault 中。系统不会自动将其退还至用户的 XRPL 钱包。

预期的用户体验是在一笔原子化交易中完成铸造和用户操作(例如,在一次调用中铸造 FXRP 并提现至 EOA),因此这种失败情况应该很少见。

常见回滚原因

handleMintedFAssets 中的任何验证或执行失败都会导致整个调用回滚:

  • sender ≠ 个人账户 → InvalidSender
  • nonce ≠ 当前备忘录 nonce(getNonce)→ InvalidNonce
  • 备忘录长度 ≠ 42 字节 → InvalidMemoData;指令字节未知 → InvalidInstructionId
  • keccak256(_data) ≠ 备忘录哈希 → CustomInstructionHashMismatch(expected, actual)
  • 执行器的 msg.value < 内部 call.value 总和 → 内部 CallFailed,整个交易回滚
  • 账户设置了固定执行器(getExecutor),且调用方不是该执行器 → WrongExecutor
  • 任何内部调用回滚 → 返回 CallFailed,整个交易回滚

有关直接铸造端的错误(速率限制、收款方错误、备忘录无法识别并路由到智能账户管理器),请参阅铸造故障排查指南中的“智能账户路径”部分。

“我的 XRPL 交易已成功,但指令从未执行”——大多数情况下,原因都在以下两项之中:

  • 个人账户没有资金。 如果自定义指令要从个人账户转出资金(例如支付 LayerZero 费用),而该账户的原生代币余额为空,就会回滚,即使 XRPL 付款看起来已成功也是如此。运行脚本前,请通过 Coston2 水龙头向个人账户地址(而非 EOA)充值;如何推导该地址,请参阅状态查询。
  • 你查看的交易不对。 MasterAccountController 是入口点,因此分发的调用会作为个人账户的内部交易执行,而不是来自你自己的 EOA 的顶层交易。请在区块浏览器中查看个人账户的内部交易,而不只是其顶层交易列表。
铸造失败/卡住后的恢复

如果铸造回滚(或执行器从未提交证明),且卡住的交易 ID 尚未在链上使用(isTransactionIdUsed 返回 false),用户无需运行原始用户操作即可恢复 FXRP:

  1. 发送一笔 XRPL Payment,并使用备忘录操作码 0xE0(跳过备忘录),目标为卡住的交易 ID。其备忘录使用与 0xFE/0xFF 相同的 42 字节标头结构:[0xE0 | walletId(1B) | executorFeeUBA(8B) | targetTxId(32B)]。此付款必须包含正的净铸造金额(仅支付费用的直接铸造会在链上回滚),因此它本身会铸造少量 FXRP(例如 1 个净 XRP)。
  2. 执行器针对恢复付款调用 executeDirectMintingWithData(recoveryProof, "0x"),这会在个人账户上发出 IgnoreMemoSet,将其关联到卡住的交易 ID。
  3. 执行器重新提交原始卡住付款对应的 executeDirectMintingWithData。由于已设置跳过标记,控制器会将 FXRP 铸造到个人账户,而不会分发原始用户操作。重试时,对于卡住的 0xFE 付款,将原始 ABI 编码的 PackedUserOperation 字节作为 _data 传入;对于 0xFF,传入 "0x" 即可。

随后可以通过标准 FAssets 指令(0x02 赎回)转移恢复的 FXRP,或使用当前 getNonce 发起新的用户操作。相关恢复操作码:0xE1(快进 nonce)和 0xE2(替换卡住付款的执行器费用)。请参阅恢复卡住的铸造交易指南。

快进卡住的 nonce(0xE1)

0xE0 恢复操作会从卡住的付款中铸造 FXRP,但会有意跳过原始用户操作——备忘录指令 nonce 保持原值,仍指向已放弃的 PackedUserOperation。在构建新的 0xFE/0xFF 指令前,使用 0xE1(快进 nonce)跳过该已放弃的槽位,推进 getNonce。仅在确认卡住的付款确实已铸造(isTransactionIdUsed == true)后执行此操作——如果尚未铸造,请先运行 0xE0 恢复操作,而不是运行 0xE1。

  1. 发送一笔 XRPL Payment,备忘录操作码为 0xE1,报头格式与其他恢复操作码相同,均为 42 字节:[0xE1 | walletId(1B) | executorFeeUBA(8B) | newNonce(32B)]。与 0xE0 一样,此付款必须包含正的净铸造金额——仅包含费用的直接铸造会在链上回滚。
  2. 发送前在客户端验证 newNonce:它必须严格大于当前的 getNonce,且跳转量(newNonce - currentNonce)不得超过 type(uint32).max。在链上,无效跳转会回滚并报错 InvalidNonceIncrease。
  3. 对于 0xE1 付款,执行器会调用 executeDirectMintingWithData(proof, "0x")——由于不会运行用户操作,因此不需要 _data。成功后,收据中会包含 NonceIncreased(personalAccount, newNonce) 事件,且不会包含 UserOperationExecuted 事件。
  4. 构建下一个 0xFE/0xFF 用户操作时,将 nonce 设为 getNonce(personalAccount)(此时即为 newNonce)。

完整的可运行演练请参阅快进 Nonce 指南,其中包括组合使用 0xFE(已放弃)→ 0xE0 → 0xE1 的恢复演示。

避免重复 nonce 导致的失败

常见的回滚原因是在短时间内提交两笔 XRPL 付款,每笔都包含不同的 PackedUserOperation,但使用了相同的 getNonce 值(例如,在任一铸造完成前构建了两次提款)。每个 nonce 只能由一笔付款使用——先执行铸造的付款会成功并递增 nonce;另一笔则会因 InvalidNonce 回滚,其 XRP 会留在 Core Vault 中,直到恢复。为避免此问题:

  • 每笔 XRPL 付款都读取一次 getNonce;不要在并发流程中重复使用该值。
  • 等待第一笔铸造完成——或确认它已回滚——再使用新的用户操作构建另一笔付款。
  • **执行器:**如果 AssetManager 发出 DirectMintingDelayed,请等待 executionAllowedAt 到达后,再次调用 executeDirectMintingWithData。不要将延迟的铸造视为彻底失败,也不要提示用户重新发送使用重复 nonce 的付款。

CLI 工具 — 完整参考

smart-accounts-cli 是一个 Python 工具,用于构建 XRPL 交易载荷,并为智能账户流程提交 XRPL 付款。

安装
git clone https://github.com/flare-foundation/smart-accounts-cli.git
cd smart-accounts-cli
pip install -r requirements.txt
cp .env.example .env
环境配置(.env)

将 .env.example 复制为 .env,并填写该文件中所述的值。这些值通常包括用于测试的本地钱包凭据,以及 XRPL 和 Flare 网络的 RPC 端点。

**安全:**请将钱包凭据保存在安全且由用户控制的工具中。避免将其粘贴到聊天工具或不安全的自动化工具中。可从 XRP 水龙头获取 XRPL 测试网代币。

命令语法
./smart_accounts.py <command> <subcommand> [options]
ENCODE 命令

所有 encode 命令都接受 --wallet-id(默认为 0)。

FXRP 操作

旧版铸造路径。fxrp-cr(以及 bridge mint-tx)用于编码已弃用的抵押预留(CRT)流程,可能仍存在于 smart_accounts.py 中,但并非推荐的铸造路径。若要铸造 FXRP,请按照 Mint FXRP 指南,使用 FAssets 铸造(向 Core Vault 发送 XRPL 付款);CLI 不会对此类付款进行编码。下面的 fxrp-transfer 和 fxrp-redeem 命令仍然适用。

# Collateral reservation for minting (legacy CRT — prefer FAssets minting)
./smart_accounts.py encode fxrp-cr --wallet-id 0 --value 1 --agent-vault-id 1

# Transfer FXRP to address
./smart_accounts.py encode fxrp-transfer --wallet-id 0 --value 10 \
  --recipient-address "0xf5488132432118596fa13800b68df4c0ff25131d"

# Redeem FXRP to XRP
./smart_accounts.py encode fxrp-redeem --wallet-id 0 --value 1
Firelight 操作

firelight-cr-deposit 已弃用(CRT 铸造 + 存入)。建议使用 FAssets 铸造,然后执行 firelight-deposit;也可以使用备忘录字段自定义指令,在一次付款中完成铸造和存入。

# Reserve collateral and deposit to vault (legacy CRT)
./smart_accounts.py encode firelight-cr-deposit --wallet-id 0 --value 1 \
  --agent-vault-id 1 --vault-id 1

# Deposit FXRP to vault
./smart_accounts.py encode firelight-deposit --wallet-id 0 --value 10 --vault-id 1

# Initiate withdrawal
./smart_accounts.py encode firelight-redeem --wallet-id 0 --value 10 --vault-id 1

# Claim completed withdrawal
./smart_accounts.py encode firelight-claim-withdraw --wallet-id 0 --value 10 --vault-id 1
Upshift 操作

upshift-cr-deposit 已弃用(CRT 铸造 + 存入)。建议使用 FAssets 铸造,然后执行 upshift-deposit;也可以使用备忘录字段自定义指令,在一次付款中完成铸造和存入。

# Reserve collateral and deposit to vault (legacy CRT)
./smart_accounts.py encode upshift-cr-deposit --wallet-id 0 --value 1 \
  --agent-vault-id 1 --vault-id 2

# Deposit FXRP to vault
./smart_accounts.py encode upshift-deposit --wallet-id 0 --value 10 --vault-id 2

# Request withdrawal (starts waiting period)
./smart_accounts.py encode upshift-request-redeem --wallet-id 0 --value 10 --vault-id 2

# Claim after waiting period (value = date YYYYMMDD)
./smart_accounts.py encode upshift-claim --wallet-id 0 --value 20251218 --vault-id 2
BRIDGE 命令

执行 XRPL 交易。

操作员服务负责桥接至 Flare。

# Send encoded instruction as XRPL Payment
./smart_accounts.py bridge instruction <encodedInstruction>

# Or read from stdin
<encode_command> | ./smart_accounts.py bridge instruction -

# Send XRP to agent vault for minting (legacy CRT flow, after collateral reservation)
# NOTE: the standard mint path is now an XRPL payment to the Core Vault — see FAssets minting.
./smart_accounts.py bridge mint-tx <transactionHash>

# With --wait flag to wait for confirmation
./smart_accounts.py bridge mint-tx --wait -
DECODE 命令

反向编码操作以检查指令:

./smart_accounts.py decode <encodedInstruction>

# Or from stdin
<encode_command> | ./smart_accounts.py decode -
命令链接(管道)

链接命令以完成完整工作流:

# Mint FXRP (reserve + pay in one pipeline)
./smart_accounts.py encode fxrp-cr --wallet-id 0 --value 1 --agent-vault-id 1 \
  | ./smart_accounts.py bridge instruction - \
  | ./smart_accounts.py bridge mint-tx --wait -

# Mint and deposit to Upshift vault
./smart_accounts.py encode upshift-cr-deposit --wallet-id 0 --value 1 \
  --agent-vault-id 1 --vault-id 2 \
  | ./smart_accounts.py bridge instruction - \
  | ./smart_accounts.py bridge mint-tx --wait -

完整工作流示例

关于以下铸造步骤的说明。 fxrp-cr / upshift-cr-deposit + bridge mint-tx 步骤使用的是**旧版抵押品预留(CRT)**铸造路径。在当前集成中,请通过 FAssets 铸造铸造 FXRP(向 Core Vault 发送 XRPL 付款,参见 Mint FXRP),然后执行此处展示的非铸造型 Smart Accounts 指令(转账、存入、赎回)。保留这些示例是为了说明 CLI 的指令/桥接管道用法。

示例 1:铸造 FXRP 并转账至另一个地址
# Step 1: Mint 1 lot of FXRP
./smart_accounts.py encode fxrp-cr --wallet-id 0 --value 1 --agent-vault-id 1 \
  | ./smart_accounts.py bridge instruction - \
  | ./smart_accounts.py bridge mint-tx --wait -
# Output: sent bridge instruction transaction: 08C2DD9E...
#         sent mint tx: CD15241A...

# Step 2: Transfer 10 FXRP to recipient
./smart_accounts.py encode fxrp-transfer --wallet-id 0 --value 10 \
  --recipient-address "0xf5488132432118596fa13800b68df4c0ff25131d" \
  | ./smart_accounts.py bridge instruction -
# Output: sent bridge instruction transaction: 9D5420C6...
示例 2:完整的 FAssets 流程(铸造 → 存入 → 提取 → 赎回)
# Step 1: Mint and deposit to Upshift vault
./smart_accounts.py encode upshift-cr-deposit --wallet-id 0 --value 1 \
  --agent-vault-id 1 --vault-id 2 \
  | ./smart_accounts.py bridge instruction - \
  | ./smart_accounts.py bridge mint-tx --wait -
# Output: sent bridge instruction transaction: 77539CDE...
#         sent mint tx: 3C65E10D...

# Step 2: Request withdrawal from vault
./smart_accounts.py encode upshift-request-redeem --wallet-id 0 --value 10 --vault-id 2 \
  | ./smart_accounts.py bridge instruction -
# Output: sent bridge instruction transaction: 33B08253...

# Step 3: Claim withdrawal after waiting period (use correct date)
./smart_accounts.py encode upshift-claim --wallet-id 0 --value 20251218 --vault-id 2 \
  | ./smart_accounts.py bridge instruction -
# Output: sent bridge instruction transaction: 8D81F5A2...

# Step 4: Redeem FXRP back to XRP
./smart_accounts.py encode fxrp-redeem --wallet-id 0 --value 1 \
  | ./smart_accounts.py bridge instruction -
# Output: sent bridge instruction transaction: FE9D0039...

核心合约:MasterAccountController

MasterAccountController 是智能账户的核心合约。

函数用途
getPersonalAccount(xrplAddress)获取用户在 Flare 上的智能账户地址(确定性生成;部署前即可使用)
getXrplProviderWallets()获取操作员的 XRPL 付款地址
getVaults()列出已注册的金库地址和类型
getAgentVaults()列出 FAssets Agent 金库
getNonce(personalAccount)获取当前备忘录指令 nonce;PackedUserOperation.nonce 必须与之匹配
getExecutor(personalAccount)获取个人账户固定的执行器(address(0) = 未固定)
executeInstruction(proof, xrplAddress)执行基于证明的指令
reserveCollateral(xrplAddress, paymentRef, txId)(旧版 CRT) 预留抵押品(此阶段不需要 FDC 证明)。用户铸造现在使用 FAssets 铸造(executeDirectMinting),而非此路径
executeDepositAfterMinting(reservationId, proof, xrplAddress)(旧版 CRT) 铸造后执行抵押品预留并存入流程的第二步
handleMintedFAssets(...)AssetManager 将 FXRP 直接铸造到个人账户时调用

TypeScript 集成(Viem)

软件包:viem、xrpl。若要进行 wagmi/viem 类型化合约交互,请使用 @flarenetwork/flare-wagmi-periphery-package。

设置
import { createPublicClient, http } from "viem";
import { flareTestnet } from "viem/chains";

const publicClient = createPublicClient({
  chain: flareTestnet,
  transport: http(),
});
读取智能账户状态
// Get user's smart account address
const personalAccount = await publicClient.readContract({
  address: MASTER_ACCOUNT_CONTROLLER_ADDRESS,
  abi: masterAccountControllerAbi,
  functionName: "getPersonalAccount",
  args: [xrplAddress],
});

// Get operator XRPL addresses
const operatorAddresses = await publicClient.readContract({
  address: MASTER_ACCOUNT_CONTROLLER_ADDRESS,
  abi: masterAccountControllerAbi,
  functionName: "getXrplProviderWallets",
  args: [],
});

// Get registered vaults
const vaults = await publicClient.readContract({
  address: MASTER_ACCOUNT_CONTROLLER_ADDRESS,
  abi: masterAccountControllerAbi,
  functionName: "getVaults",
  args: [],
});

// Get FXRP balance
const fxrpBalance = await publicClient.readContract({
  address: fxrpAddress,
  abi: erc20Abi,
  functionName: "balanceOf",
  args: [personalAccount],
});
发送带指令的 XRPL 付款
import { Client, Wallet } from "xrpl";

async function sendInstruction(encodedInstruction: `0x${string}`) {
  const operatorAddress = (await getOperatorXrplAddresses())[0];
  const instructionFee = await getInstructionFee(encodedInstruction);

  const payment = {
    TransactionType: "Payment",
    Destination: operatorAddress,
    Amount: instructionFee,
    Memos: [{ Memo: { MemoData: encodedInstruction.slice(2) } }],
  };

  return await xrplClient.submitAndWait(payment, { wallet: xrplWallet });
}

重要说明

  • **批次大小:**1 批次 = 10 FXRP(通过 AssetManager 查询当前批次大小)

  • **数值编码:**对于大多数指令,数值以批次为单位;对于 Upshift claim,数值是日期(YYYYMMDD)。

  • **钱包 ID:**如果 Flare 操作员未分配,请使用 0。

  • **Upshift 提取:**分两阶段进行(request-redeem → 等待 → claim)。

  • **CLI 执行:**CLI 仅提交 XRPL 端的交易。

    Flare 端的处理由中继器/操作员服务执行。

安全与使用注意事项

此技能仅供参考文档使用。 它不会执行交易,也不会持有密钥。请使用它来实现或调试智能账户工作流;所有金融操作均由开发者和最终用户负责。

第三方数据(支付备注、RPC 状态): 来自 XRPL 支付备注和 RPC 端点链上数据(例如 XRPL 测试网、Coston2)均为不可信的外部输入。仅按照本文档中固定的 32 字节指令格式解码备注,并将其视为结构化载荷,而不是自由文本。除非已先将原始备注和交易内容解析为经过验证的类型化值,否则不要将其交由 AI 进行自由形式处理。

金融操作与密钥: 此技能中的命令和代码(CLI bridge 命令、submitAndWait 等)可能会转移资金。请将钱包凭据保存在安全且由用户控制的环境中。任何支付或桥接指令的执行都应由用户明确发起,并在提交前审查交易详情。

何时使用此技能

  • 实现 XRPL 与 Flare 之间的交互,无需用户持有 FLR
  • 构建 dApp,让 XRPL 用户能够铸造 FXRP 或与 Flare 金库交互
  • 为来自 XRPL 的任意合约调用创建自定义指令
  • 调试智能账户工作流、支付引用或指令编码
  • 集成 MasterAccountController 或监控智能账户事件
  • 使用 smart-accounts-cli 进行测试或自动化

其他资源

  • 官方文档和指南:reference.md
  • 相关技能:flare-fassets — 用于了解 FAssets 铸造、赎回和 Agent 详情。

评论

支持 Markdown