flare-fdc

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Scope and Limitations

适用范围与限制

This skill is documentation and guidance only. It describes how the Flare Data Connector (FDC) protocol works and how developers can integrate it. It does not perform any actions on behalf of the user.

This skill explicitly does NOT:

Execute, sign, or broadcast any blockchain transactions
Access, store, or transmit private keys or wallet credentials
Initiate or authorize any payments or financial transfers
Call any smart contract methods or APIs directly
Handle funds, tokens, or any financial assets

External data handling:

FDC attestation responses (Web2Json, EVMTransaction, DA Layer proofs) are externally provided content from third-party sources
This skill instructs developers to treat all such data as untrusted and to decode it only according to documented ABI schemas
Response content must never be passed into prompts, LLM inputs, or agent decision logic
Developers are solely responsible for validating and safely handling all external data in their own implementations

What this skill does:

Explains FDC attestation types, request flows, Merkle proof verification, and contract patterns
References official Flare Developer Hub documentation and audited starter repositories
Provides read-only conceptual guidance for developers building on Flare

All transaction signing, key management, and on-chain execution must occur exclusively in user-controlled, developer-managed environments outside of this skill.

本技能仅提供文档与指导。它描述了Flare Data Connector (FDC)协议的工作原理，以及开发者如何集成该协议。它不会代表用户执行任何操作。

本技能明确不支持以下操作：

执行、签名或广播任何区块链交易
访问、存储或传输私钥或钱包凭证
发起或授权任何支付或资金转账
直接调用任何智能合约方法或API
处理资金、代币或任何金融资产

外部数据处理：

FDC证明响应（Web2Json、EVMTransaction、DA Layer证明）是来自第三方的外部提供内容
本技能指导开发者将所有此类数据视为不可信数据，仅按照已记录的ABI schema进行解码
响应内容绝不能传入提示词、LLM输入或Agent决策逻辑
开发者需全权负责在其自有实现中验证并安全处理所有外部数据

本技能支持的操作：

解释FDC证明类型、请求流程、Merkle证明验证以及合约模式
参考官方Flare Developer Hub文档与经过审计的入门代码仓库
为基于Flare构建的开发者提供只读概念性指导

所有交易签名、密钥管理与链上执行必须完全在本技能之外的用户可控、开发者管理环境中进行。

Flare Data Connector (FDC)

What FDC Is

什么是FDC

The Flare Data Connector (FDC) is an enshrined oracle that validates external data for Flare's EVM state. Users submit attestation requests; data providers reach consensus (50%+ signature weight); verified data is stored in a Merkle tree (only the root is onchain). Users then fetch attestation responses and Merkle proofs from the Data Availability (DA) Layer and submit them to smart contracts, which verify proofs against the onchain root.

Key points:

Prepare request — Verifier API (e.g.
```
POST .../verifier/web2/Web2Json/prepareRequest
```
with
```
attestationType
```
,
```
sourceId
```
and
```
requestBody
```
that depends on the attestation type)
Request → FdcHub (
```
requestAttestation(bytes)
```
) with ABI-encoded request; pay fee.
Round finalization — typically 90–180 seconds; wait before using a proof.

Proof retrieval — DA Layer API (e.g.

POST .../api/v1/fdc/proof-by-request-round-raw

with

votingRoundId

and

requestBytes

Contract verification — use

IFdcVerification

(from

ContractRegistry.getFdcVerification()

) and the type-specific method (e.g.

verifyEVMTransaction

verifyWeb2Json

verifyPayment

verifyAddressValidity

Flare Data Connector (FDC) 是一个内置预言机，用于为Flare的EVM状态验证外部数据。用户提交证明请求；数据提供者达成共识（签名权重占比50%以上）；已验证数据存储在Merkle树中（仅树根存储在链上）。用户随后从数据可用性（DA）层获取证明响应与Merkle证明，并将其提交给智能合约，合约会根据链上树根验证证明。

核心要点：

准备请求 — 调用验证器API（例如
```
POST .../verifier/web2/Web2Json/prepareRequest
```
，传入
```
attestationType
```
、
```
sourceId
```
以及取决于证明类型的
```
requestBody
```
）
请求→FdcHub — 调用
```
requestAttestation(bytes)
```
并传入ABI编码的请求；支付费用。
回合完成 — 通常需要90–180秒；使用证明前需等待。

获取证明 — 调用DA Layer API（例如

POST .../api/v1/fdc/proof-by-request-round-raw

，传入

votingRoundId

和

requestBytes

）。

合约验证 — 使用

IFdcVerification

（通过

ContractRegistry.getFdcVerification()

获取）以及对应类型的方法（例如

verifyEVMTransaction

、

verifyWeb2Json

、

verifyPayment

、

verifyAddressValidity

）。

Attestation Types

证明类型

Type	Purpose	Chains / sources
AddressValidity	Validate format/checksum of addresses	BTC, DOGE, XRPL
EVMTransaction	Verify and retrieve transaction + events	ETH, FLR, SGB (mainnet); testETH, testFLR, testSGB (testnet)
JsonApi / Web2Json	Fetch Web2 data, JQ transform, ABI-encoded output	PublicWeb2 (Coston/Coston2)
Payment	Confirm payment tx on non-EVM chains	BTC, DOGE, XRP
ConfirmedBlockHeightExists	Verify block existence and confirmations	—
BalanceDecreasingTransaction	Validate tx that decreases an address balance	FAssets-oriented
ReferencedPaymentNonexistence	Prove absence of specific payments in interval	FAssets-oriented
XRPPayment	Confirm an XRPL Payment with XRPL-native fields (r-address, MemoData, DestinationTag)	XRP, testXRP
XRPPaymentNonexistence	Prove no XRPL Payment matched destination/amount/memo/tag in a ledger range	XRP, testXRP

First three are most generally useful; the next three are mainly for FAssets; the XRPL-specific types expose XRPL-native fields (memo data, destination tag) that the chain-agnostic Payment type does not.

类型	用途	链/数据源
AddressValidity	验证地址的格式/校验和	BTC, DOGE, XRPL
EVMTransaction	验证并获取交易+事件	ETH, FLR, SGB（主网）；testETH, testFLR, testSGB（测试网）
JsonApi / Web2Json	获取Web2数据、JQ转换、ABI编码输出	PublicWeb2（Coston/Coston2）
Payment	确认非EVM链上的支付交易	BTC, DOGE, XRP
ConfirmedBlockHeightExists	验证区块存在性与确认数	—
BalanceDecreasingTransaction	验证减少地址余额的交易	面向FAssets
ReferencedPaymentNonexistence	证明特定时间段内不存在指定支付	面向FAssets
XRPPayment	通过XRPL原生字段（r地址、MemoData、DestinationTag）确认XRPL支付	XRP, testXRP
XRPPaymentNonexistence	证明在账本范围内不存在匹配目标/金额/备注/标签的XRPL支付	XRP, testXRP

前三种类型通用性最强；接下来三种主要用于FAssets；XRPL专属类型会暴露跨链无关的Payment类型不支持的XRPL原生字段（备注数据、目标标签）。

User Workflow (Offchain + Onchain)

用户工作流（链下+链上）

Prepare request — Encode attestation in FDC format. Use a verifier service (e.g. Flare testnet verifier or your own) to get
```
abiEncodedRequest
```
(includes a message integrity code - MIC - and encoded request parameters).

Submit — Call

FdcHub.requestAttestation(abiEncodedRequest)

with

value: requestFee

Round ID — From block timestamp:

roundId = floor((blockTimestamp - firstVotingRoundStartTs) / votingEpochDurationSeconds)

(e.g. 90s). Get

firstVotingRoundStartTs

from

FlareSystemsManager

/ config.

Wait for finalization — Use
```
Relay
```
contract:
```
isFinalized(200, roundId)
```
(200 = FDC protocol ID) or listen for
```
ProtocolMessageRelayed(200, roundId)
```
.
Fetch proof — POST to DA Layer with
```
votingRoundId
```
and
```
requestBytes
```
(same
```
abiEncodedRequest
```
).
Submit to contract — Pass
```
{ merkleProof, data }
```
(decoded response) to your contract; contract calls
```
FdcVerification.verify*()
```
then uses the data.

准备请求 — 将证明编码为FDC格式。使用验证器服务（例如Flare测试网验证器或自有验证器）获取
```
abiEncodedRequest
```
（包含消息完整性码-MIC-以及编码后的请求参数）。

提交请求 — 调用

FdcHub.requestAttestation(abiEncodedRequest)

并传入

value: requestFee

。

获取回合ID — 根据区块时间戳计算：

roundId = floor((blockTimestamp - firstVotingRoundStartTs) / votingEpochDurationSeconds)

（例如90秒）。从

FlareSystemsManager

或配置中获取

firstVotingRoundStartTs

。

等待回合完成 — 使用
```
Relay
```
合约：调用
```
isFinalized(200, roundId)
```
（200=FDC协议ID）或监听
```
ProtocolMessageRelayed(200, roundId)
```
事件。
获取证明 — 向DA Layer发送POST请求，传入
```
votingRoundId
```
和
```
requestBytes
```
（即之前的
```
abiEncodedRequest
```
）。
提交至合约 — 将
```
{ merkleProof, data }
```
（解码后的响应）传入你的合约；合约调用
```
FdcVerification.verify*()
```
后再使用该数据。

Contract Pattern (Verification + Business Logic)

合约模式（验证+业务逻辑）

Resolve FdcVerification via

ContractRegistry.getFdcVerification()

(or

auxiliaryGetIWeb2JsonVerification()

for Web2Json when applicable).

Always verify first, then decode and use data. Example (EVMTransaction):

solidity

function processProof(IEVMTransaction.Proof calldata proof) external {
  require(ContractRegistry.getFdcVerification().verifyEVMTransaction(proof), "Invalid proof");
  // use proof.data.responseBody (blockNumber, timestamp, events, ...)
}

For Web2Json, decode
```
proof.data.responseBody.abi_encoded_data
```
with your struct (define a
```
DataTransportObject
```
and optionally
```
abiSignatureHack(dto)
```
for artifact-based ABI signature in scripts).

Use network-specific imports from

@flarenetwork/flare-periphery-contracts

(e.g.

coston2/ContractRegistry.sol

coston2/IEVMTransaction.sol

). Set EVM version cancun where required.

通过

ContractRegistry.getFdcVerification()

（或针对Web2Json使用

auxiliaryGetIWeb2JsonVerification()

）获取FdcVerification实例。

始终先验证，再解码并使用数据。示例（EVMTransaction）：

solidity

function processProof(IEVMTransaction.Proof calldata proof) external {
  require(ContractRegistry.getFdcVerification().verifyEVMTransaction(proof), "Invalid proof");
  // use proof.data.responseBody (blockNumber, timestamp, events, ...)
}

对于Web2Json，使用自定义结构体解码
```
proof.data.responseBody.abi_encoded_data
```
（定义
```
DataTransportObject
```
，可选在脚本中使用
```
abiSignatureHack(dto)
```
实现基于工件的ABI签名）。

从

@flarenetwork/flare-periphery-contracts

导入网络专属文件（例如

coston2/ContractRegistry.sol

、

coston2/IEVMTransaction.sol

）。在需要时设置EVM版本为cancun。

Script / Offchain Pattern (Hardhat)

脚本/链下模式（Hardhat）

Prepare: POST to verifier e.g.
```
VERIFIER_URL/verifier/eth/EVMTransaction/prepareRequest
```
(or Web2Json, Payment, etc.) with attestation type, sourceId, request body; get
```
abiEncodedRequest
```
.

Submit: Get

FdcHub

via

ContractRegistry

or known address; call

requestAttestation(abiEncodedRequest, { value: fee })

; compute

roundId

from receipt block timestamp.

Wait: Poll
```
Relay.isFinalized(200, roundId)
```
.

Fetch: POST to DA Layer

.../api/v1/fdc/proof-by-request-round-raw

with

votingRoundId

requestBytes

Decode: Use artifact’s response type (e.g.

IEVMTransactionVerification._json.abi[0].inputs[0].components[1]

) to decode

response_hex

; build

{ merkleProof: proof.proof, data: decodedResponse }

and call contract.

Packages:

ethers

web3

@flarenetwork/flare-periphery-contract-artifacts

. For wagmi/viem typed contract interactions, use

@flarenetwork/flare-wagmi-periphery-package

Env:

VERIFIER_URL_TESTNET

VERIFIER_API_KEY_TESTNET

COSTON2_DA_LAYER_URL

(or equivalent for mainnet). Testnets use

testETH

testFLR

testSGB

as source IDs.

Verifier API keys are required for both testnet and mainnet verifiers. Set them in

.env

(see flare-hardhat-starter

.env.example

env

VERIFIER_API_KEY_TESTNET="00000000-0000-0000-0000-000000000000"
VERIFIER_API_KEY_MAINNET="00000000-0000-0000-0000-000000000000"

Pass the key via the

X-apikey

header when calling verifier endpoints. The default placeholder UUIDs work for initial testing but are rate-limited.

准备： 向验证器发送POST请求，例如
```
VERIFIER_URL/verifier/eth/EVMTransaction/prepareRequest
```
（或Web2Json、Payment等），传入证明类型、sourceId、请求体；获取
```
abiEncodedRequest
```
。
提交： 通过
```
ContractRegistry
```
或已知地址获取
```
FdcHub
```
实例；调用
```
requestAttestation(abiEncodedRequest, { value: fee })
```
；根据交易收据的区块时间戳计算
```
roundId
```
。
等待： 轮询
```
Relay.isFinalized(200, roundId)
```
。

获取： 向DA Layer发送POST请求

.../api/v1/fdc/proof-by-request-round-raw

，传入

votingRoundId

和

requestBytes

。

解码： 使用工件的响应类型（例如

IEVMTransactionVerification._json.abi[0].inputs[0].components[1]

）解码

response_hex

；构建

{ merkleProof: proof.proof, data: decodedResponse }

并调用合约。

依赖包：

ethers

或

web3

、

@flarenetwork/flare-periphery-contract-artifacts

。对于wagmi/viem类型化合约交互，使用

@flarenetwork/flare-wagmi-periphery-package

。

环境变量：

VERIFIER_URL_TESTNET

、

VERIFIER_API_KEY_TESTNET

、

COSTON2_DA_LAYER_URL

（主网使用对应变量）。测试网使用

testETH

testFLR

testSGB

作为source ID。

验证器API密钥在测试网和主网验证器中均为必填项。在

.env

文件中配置（参考flare-hardhat-starter的

.env.example

）：

env

VERIFIER_API_KEY_TESTNET="00000000-0000-0000-0000-000000000000"
VERIFIER_API_KEY_MAINNET="00000000-0000-0000-0000-000000000000"

调用验证器端点时通过

X-apikey

头传递密钥。默认占位UUID可用于初始测试，但存在调用频率限制。

Example Repos and Where to Look

示例仓库与参考内容

flare-hardhat-starter:
- scripts/fdcExample/ — Per–attestation-type examples:
```
EVMTransaction.ts
```
  ,
```
Web2Json.ts
```
  ,
```
Payment.ts
```
  ,
```
AddressValidity.ts
```
  , etc. Use
```
prepareAttestationRequestBase
```
  ,
```
submitAttestationRequest
```
  ,
```
retrieveDataAndProofBaseWithRetry
```
  (from
```
scripts/utils/fdc
```
  or similar).
- contracts/fdcExample/ —
```
EVMTransaction.sol
```
  ,
```
AddressValidity.sol
```
  ,
```
Web2Json.sol
```
  ,
```
Payment.sol
```
  — show verification + decoding.
- weatherInsurance — Web2Json-based dApp (MinTempAgency): policies, resolve with weather API proof; scripts in
```
scripts/weatherInsurance/minTemp/
```
  (createPolicy, claimPolicy, resolvePolicy, expirePolicy).
- proofOfReserves — Combines Web2Json (reserves API) and EVMTransaction (token supply events from multiple chains);
```
ProofOfReserves.sol
```
  , scripts in
```
scripts/proofOfReserves/
```
  (deploy, activateTokenStateReader, verifyProofOfReserves).
flare-foundry-starter: Same attestation types plus cross-chain payment and cross-chain FDC examples; structure mirrors Hardhat.

Use these as the canonical patterns for prepare → submit → wait → get proof → verify in contract.

flare-hardhat-starter：
- scripts/fdcExample/ — 按证明类型分类的示例：
```
EVMTransaction.ts
```
  、
```
Web2Json.ts
```
  、
```
Payment.ts
```
  、
```
AddressValidity.ts
```
  等。使用
```
prepareAttestationRequestBase
```
  、
```
submitAttestationRequest
```
  、
```
retrieveDataAndProofBaseWithRetry
```
  （来自
```
scripts/utils/fdc
```
  或类似模块）。
- contracts/fdcExample/ —
```
EVMTransaction.sol
```
  、
```
AddressValidity.sol
```
  、
```
Web2Json.sol
```
  、
```
Payment.sol
```
  — 展示验证+解码逻辑。
- weatherInsurance — 基于Web2Json的去中心化应用（MinTempAgency）：保单管理、通过天气API证明理赔；脚本位于
```
scripts/weatherInsurance/minTemp/
```
  （createPolicy、claimPolicy、resolvePolicy、expirePolicy）。
- proofOfReserves — 结合Web2Json（储备API）与EVMTransaction（多链代币供应事件）；包含
```
ProofOfReserves.sol
```
  ，脚本位于
```
scripts/proofOfReserves/
```
  （deploy、activateTokenStateReader、verifyProofOfReserves）。
flare-foundry-starter： 包含相同的证明类型，外加跨链支付与跨链FDC示例；结构与Hardhat仓库一致。

请将这些仓库作为准备→提交→等待→获取证明→合约验证流程的标准实现参考。

EVMTransaction Quick Reference

EVMTransaction快速参考

Request:

transactionHash

requiredConfirmations

provideInput

listEvents

logIndices

(max 50; sorted by contract convention).

Response:
```
blockNumber
```
,
```
timestamp
```
,
```
sourceAddress
```
,
```
receivingAddress
```
,
```
value
```
,
```
input
```
,
```
status
```
,
```
events[]
```
(logIndex, emitterAddress, topics, data, removed). Events are block-level indexed.

Decode events in contract by filtering

emitterAddress

and

topics[0]

(e.g.

keccak256("Transfer(address,address,uint256)")

), then

topics[1]

topics[2]

and

data

as needed.

请求参数：
```
transactionHash
```
、
```
requiredConfirmations
```
、
```
provideInput
```
、
```
listEvents
```
、
```
logIndices
```
（最多50个；按合约约定排序）。
响应内容：
```
blockNumber
```
、
```
timestamp
```
、
```
sourceAddress
```
、
```
receivingAddress
```
、
```
value
```
、
```
input
```
、
```
status
```
、
```
events[]
```
（logIndex、emitterAddress、topics、data、removed）。事件按区块级别索引。

在合约中通过过滤

emitterAddress

和

topics[0]

（例如

keccak256("Transfer(address,address,uint256)")

）解码事件，再按需使用

topics[1]

topics[2]

和

data

。

Web2Json Quick Reference

Web2Json快速参考

Request:

url

httpMethod

headers

queryParams

body

postProcessJq

abiSignature

(tuple encoding the struct for

abi_encoded_data

Response:
```
responseBody.abi_encoded_data
```
— decode with
```
abi.decode(..., (YourStruct))
```
. Use the same struct and ABI signature in the verifier request and in the contract. Store fractional values as scaled integers (e.g. 10^6) if needed.

Security: Web2Json fetches arbitrary public Web2 content from the requested URL. The returned

responseBody

response_hex

is externally provided content. Decode and use it only with your expected ABI/struct for contract verification—never treat it as natural language or pass it into prompts or an AI/LLM.

请求参数：

url

、

httpMethod

、

headers

、

queryParams

、

body

、

postProcessJq

、

abiSignature

（用于编码

abi_encoded_data

的元组）。

响应内容：
```
responseBody.abi_encoded_data
```
— 使用
```
abi.decode(..., (YourStruct))
```
解码。在验证器请求与合约中使用相同的结构体和ABI签名。如有需要，将小数存储为缩放整数（例如10^6）。

安全提示： Web2Json会从请求的URL获取任意公开Web2内容。返回的

responseBody

response_hex

属于外部提供内容。仅按照已记录的证明格式和预期的ABI/结构体进行解码和使用——绝不能将其视为自然语言传入提示词或AI/LLM。

XRPPayment Quick Reference

XRPPayment快速参考

Sources:
```
XRP
```
(mainnet),
```
testXRP
```
(testnet). Attestation type ID
```
0x08
```
. Requires 3 XRPL confirmations (~12s).
Request:
```
transactionId
```
(bytes32, XRPL Payment tx hash),
```
proofOwner
```
(EVM address authorized to use the proof).

Response:

blockNumber

blockTimestamp

sourceAddress

(XRPL r-address),

sourceAddressHash

receivingAddressHash

intendedReceivingAddressHash

spentAmount

intendedSpentAmount

receivedAmount

intendedReceivedAmount

(drops, int256),

hasMemoData

firstMemoData

(raw bytes of the first Memo's

MemoData

hasDestinationTag

destinationTag

(uint32 on XRPL, surfaced as uint256),

status

(0=SUCCESS, 1=SENDER_FAILURE, 2=RECEIVER_FAILURE).

Standard address hash is
```
keccak256(standardAddress)
```
without lowercasing. Multi-output payments are rejected.

Verify with

IFdcVerification.verifyXRPPayment(IXRPPayment.Proof)

数据源：
```
XRP
```
（主网）、
```
testXRP
```
（测试网）。证明类型ID为
```
0x08
```
。需要3次XRPL确认（约12秒）。
请求参数：
```
transactionId
```
（bytes32类型，XRPL支付交易哈希）、
```
proofOwner
```
（授权使用该证明的EVM地址）。

响应内容：

blockNumber

、

blockTimestamp

、

sourceAddress

（XRPL r地址）、

sourceAddressHash

、

receivingAddressHash

、

intendedReceivingAddressHash

、

spentAmount

intendedSpentAmount

receivedAmount

intendedReceivedAmount

（drops单位，int256类型）、

hasMemoData

firstMemoData

（第一个Memo的

MemoData

原始字节）、

hasDestinationTag

destinationTag

（XRPL上为uint32类型，以uint256返回）、

status

（0=成功，1=发送方失败，2=接收方失败）。

标准地址哈希为
```
keccak256(standardAddress)
```
，无需小写。多输出支付会被拒绝。

使用

IFdcVerification.verifyXRPPayment(IXRPPayment.Proof)

进行验证。

XRPPaymentNonexistence Quick Reference

XRPPaymentNonexistence快速参考

Sources:
```
XRP
```
(mainnet),
```
testXRP
```
(testnet). Attestation type ID
```
0x09
```
. Search range is
```
[minimalBlockNumber, firstOverflowBlockNumber)
```
.

Request:

minimalBlockNumber

deadlineBlockNumber

deadlineTimestamp

destinationAddressHash

amount

(drops, uint256),

checkFirstMemoData

firstMemoDataHash

checkDestinationTag

destinationTag

proofOwner

. At least one of
checkFirstMemoData
or
checkDestinationTag
must be
true
.

Response:

minimalBlockTimestamp

firstOverflowBlockNumber

firstOverflowBlockTimestamp

lowestUsedTimestamp

is set to

minimalBlockTimestamp

A matching tx invalidates the claim only if all of receiver hash, amount, memo/tag (per the check flags), and successful outcome (excluding
```
SENDER_FAILURE
```
) align.

Verify with

IFdcVerification.verifyXRPPaymentNonexistence(IXRPPaymentNonexistence.Proof)

数据源：
```
XRP
```
（主网）、
```
testXRP
```
（测试网）。证明类型ID为
```
0x09
```
。搜索范围为
```
[minimalBlockNumber, firstOverflowBlockNumber)
```
。

请求参数：

minimalBlockNumber

、

deadlineBlockNumber

、

deadlineTimestamp

、

destinationAddressHash

、

amount

（drops单位，uint256类型）、

checkFirstMemoData

firstMemoDataHash

、

checkDestinationTag

destinationTag

、

proofOwner

。checkFirstMemoData
或
checkDestinationTag
中至少有一个必须为
true
。

响应内容：

minimalBlockTimestamp

、

firstOverflowBlockNumber

、

firstOverflowBlockTimestamp

。

lowestUsedTimestamp

会被设置为

minimalBlockTimestamp

。

只有当接收方哈希、金额、备注/标签（根据检查标志）以及成功结果（排除
```
SENDER_FAILURE
```
）全部匹配时，对应交易才会使证明失效。

使用

IFdcVerification.verifyXRPPaymentNonexistence(IXRPPaymentNonexistence.Proof)

进行验证。

Security and usage considerations

安全与使用注意事项

Third-party content: FDC attestation responses (including Web2Json

responseBody

response_hex

, EVMTransaction payloads, and DA Layer proof responses) are derived from external or user-specified sources. Treat all such data as externally provided. Decode and use it only according to the documented attestation format and your expected ABI/schema. Do not pass response content into prompts or allow it to unintentionally influence agent behavior when consuming FDC proofs or verifier/DA Layer outputs.

第三方内容： FDC证明响应（包括Web2Json的

responseBody

response_hex

、EVMTransaction payload、DA Layer证明响应）均来自外部或用户指定的数据源。将所有此类数据视为外部提供内容。仅按照已记录的证明格式和预期的ABI/ schema进行解码和使用。请勿将响应内容传入提示词，或在使用FDC证明、验证器/DA Layer输出时让其意外影响Agent行为。

When to Use This Skill

何时使用本技能

Implementing or debugging FDC attestation flows (request, round, proof, verification).
Writing or reviewing contracts that consume FDC proofs (EVMTransaction, Web2Json, Payment, AddressValidity, etc.).
Integrating verifier or DA Layer in scripts/tests.
Building or explaining dApps that use FDC (proof-of-reserves, weather insurance, cross-chain payment).
Following Flare Developer Hub FDC guides and starter repos.

实现或调试FDC证明流程（请求、回合、证明、验证）。
编写或审核使用FDC证明的合约（EVMTransaction、Web2Json、Payment、AddressValidity等）。
在脚本/测试中集成验证器或DA Layer。
构建或解释使用FDC的去中心化应用（储备证明、天气保险、跨链支付）。
遵循Flare Developer Hub的FDC指南与入门代码仓库。

Additional Resources

额外资源

Detailed APIs, contract interfaces, and links: reference.md
FDC Overview: dev.flare.network/fdc/overview
Getting Started: dev.flare.network/fdc/getting-started
Hardhat guides (by type): dev.flare.network/fdc/guides/hardhat
Foundry guides: dev.flare.network/fdc/guides/foundry

详细API、合约接口与链接：reference.md
FDC概述：dev.flare.network/fdc/overview
快速开始：dev.flare.network/fdc/getting-started
Hardhat分类指南：dev.flare.network/fdc/guides/hardhat
Foundry指南：dev.flare.network/fdc/guides/foundry ",