|
| 1 | +--- |
| 2 | +sidebar_position: 6 |
| 3 | +title: Troubleshooting |
| 4 | +description: Common issues and solutions when working with the Flare Data Connector. |
| 5 | +keywords: |
| 6 | + [ |
| 7 | + fdc, |
| 8 | + troubleshooting, |
| 9 | + errors, |
| 10 | + flare-data-connector, |
| 11 | + flare-network, |
| 12 | + smart-contracts, |
| 13 | + web2json, |
| 14 | + consensus, |
| 15 | + ] |
| 16 | +--- |
| 17 | + |
| 18 | +This page covers common issues developers encounter when working with the Flare Data Connector (FDC) and how to resolve them. |
| 19 | + |
| 20 | +## DA Layer Returns 400 Bad Request |
| 21 | + |
| 22 | +One of the most common issues developers face is receiving a `400 Bad Request` error from the Data Availability (DA) Layer when trying to retrieve a proof. |
| 23 | + |
| 24 | +### Symptoms |
| 25 | + |
| 26 | +- Your attestation request is prepared successfully by the verifier (status: `VALID`). |
| 27 | +- The request is submitted to the FDC Hub and a transaction hash is returned. |
| 28 | +- The voting round finalizes without errors. |
| 29 | +- When you query the DA Layer for the proof, you receive a `400 Bad Request` error. |
| 30 | + |
| 31 | +### Root Cause: Attestation Consensus Failure |
| 32 | + |
| 33 | +This error occurs when the attestation providers could not reach consensus on your request. |
| 34 | +For an attestation to be included in a voting round, a majority of providers must independently verify the same data and agree on the response. |
| 35 | + |
| 36 | +The most common cause is **non-deterministic API responses**—when the data source returns different values to different attestation providers. |
| 37 | + |
| 38 | +### Why This Happens with Web2Json |
| 39 | + |
| 40 | +When using the `Web2Json` attestation type, each attestation provider independently queries your specified API endpoint. |
| 41 | +If the API returns values that change between requests (even by small amounts), providers will compute different response hashes. |
| 42 | +Since the hashes don't match, consensus cannot be reached, and the attestation is not included in the Merkle tree. |
| 43 | + |
| 44 | +**Example scenario:** |
| 45 | + |
| 46 | +1. Provider A queries the API at timestamp T and receives: `{"value": "44,442,373.09"}` |
| 47 | +2. Provider B queries the API at timestamp T+2s and receives: `{"value": "44,442,375.12"}` |
| 48 | +3. Provider C queries the API at timestamp T+5s and receives: `{"value": "44,442,380.00"}` |
| 49 | + |
| 50 | +Each provider computes a different hash, consensus fails, and your proof is not available. |
| 51 | + |
| 52 | +### Solution: Stabilize Your API Response |
| 53 | + |
| 54 | +To ensure consensus, your API response must be deterministic—all providers must receive the exact same data. |
| 55 | +Here are several approaches: |
| 56 | + |
| 57 | +#### 1. Round Values in Your JQ Filter |
| 58 | + |
| 59 | +Use the `postProcessJq` filter to round values to a coarser granularity that won't change between provider queries. |
| 60 | + |
| 61 | +**Before (exact values, consensus-breaking):** |
| 62 | + |
| 63 | +```json |
| 64 | +{ |
| 65 | + "postProcessJq": "{amount: .value | gsub(\",\"; \"\") | tonumber}" |
| 66 | +} |
| 67 | +``` |
| 68 | + |
| 69 | +**After (rounded to nearest $100k, consensus-safe):** |
| 70 | + |
| 71 | +```json |
| 72 | +{ |
| 73 | + "postProcessJq": "{amount: (.value | split(\",\") | join(\"\") | split(\".\") | .[0] | .[:-5] + \"00000\")}" |
| 74 | +} |
| 75 | +``` |
| 76 | + |
| 77 | +This transforms `"44,442,373.09"` → `"44400000"`, which remains stable even if the exact value fluctuates. |
| 78 | + |
| 79 | +#### 2. Use Timestamp-Based API Endpoints |
| 80 | + |
| 81 | +If you control the API, provide an endpoint that returns data for a specific timestamp or block. |
| 82 | +This ensures all providers query the same historical state. |
| 83 | + |
| 84 | +**Example:** |
| 85 | + |
| 86 | +``` |
| 87 | +https://api.example.com/reserves?timestamp=1700000000 |
| 88 | +``` |
| 89 | + |
| 90 | +#### 3. Use Snapshot Endpoints |
| 91 | + |
| 92 | +Design your API to return values that only update at specific intervals (e.g., hourly, daily). |
| 93 | +Include the snapshot timestamp in the response so providers know they're querying the same data point. |
| 94 | + |
| 95 | +**Example response:** |
| 96 | + |
| 97 | +```json |
| 98 | +{ |
| 99 | + "snapshot_time": "2024-02-05T00:00:00Z", |
| 100 | + "value": "44,400,000.00" |
| 101 | +} |
| 102 | +``` |
| 103 | + |
| 104 | +#### 4. Extract Only Stable Fields |
| 105 | + |
| 106 | +If the API returns multiple fields, use `postProcessJq` to extract only the fields that don't change frequently. |
| 107 | + |
| 108 | +**Example:** |
| 109 | + |
| 110 | +```json |
| 111 | +{ |
| 112 | + "postProcessJq": "{status: .status, lastUpdated: .metadata.lastUpdated}" |
| 113 | +} |
| 114 | +``` |
| 115 | + |
| 116 | +### Debugging Checklist |
| 117 | + |
| 118 | +1. **Test your JQ filter locally:** |
| 119 | + |
| 120 | + ```bash |
| 121 | + curl -s "https://your-api.com/endpoint" | jq '{your: .filter}' |
| 122 | + ``` |
| 123 | + |
| 124 | + Run this multiple times and verify you get identical output. |
| 125 | + |
| 126 | +2. **Check the voting round on the Systems Explorer:** |
| 127 | + Visit `https://coston2-systems-explorer.flare.rocks/voting-round/{roundId}?tab=fdc` to see if any attestations were included. |
| 128 | + If your round shows "0 attestation requests," your request wasn't included. |
| 129 | + |
| 130 | +3. **Verify the verifier accepts your request:** |
| 131 | + |
| 132 | + ```bash |
| 133 | + curl -X POST "https://fdc-verifiers-testnet.flare.network/verifier/web2/Web2Json/prepareRequest" \ |
| 134 | + -H "Content-Type: application/json" \ |
| 135 | + -d '{"attestationType": "0x...", "sourceId": "0x...", "requestBody": {...}}' |
| 136 | + ``` |
| 137 | + |
| 138 | + A `VALID` status means the request format is correct, but doesn't guarantee consensus. |
| 139 | + |
| 140 | +4. **Check API accessibility:** |
| 141 | + Ensure your API endpoint is publicly accessible and not rate-limited. |
| 142 | + Attestation providers must be able to reach it from their infrastructure. |
| 143 | + |
| 144 | +## Attestation Request Rejected by Verifier |
| 145 | + |
| 146 | +If the verifier returns an error when preparing your request, check the following: |
| 147 | + |
| 148 | +### Invalid JQ Filter |
| 149 | + |
| 150 | +The FDC verifier uses a limited subset of JQ. |
| 151 | +Some operations like `tonumber` or arithmetic may not work as expected. |
| 152 | + |
| 153 | +**Workaround:** |
| 154 | +Return values as strings and parse them in your smart contract. |
| 155 | + |
| 156 | +### API Not Whitelisted |
| 157 | + |
| 158 | +For `Web2Json` attestations, the API domain must be whitelisted by the Flare Network. |
| 159 | +On testnets, common APIs like GitHub Pages and public REST APIs are typically allowed. |
| 160 | + |
| 161 | +Contact the Flare team if you need a specific domain whitelisted for production use. |
| 162 | + |
| 163 | +### Malformed ABI Signature |
| 164 | + |
| 165 | +Ensure your `abiSignature` field is valid JSON and matches the Solidity struct you'll use to decode the data. |
| 166 | + |
| 167 | +**Common mistakes:** |
| 168 | + |
| 169 | +- Missing quotes around field names |
| 170 | +- Using `int` instead of `int256` |
| 171 | +- Incorrect nesting for complex structs |
| 172 | + |
| 173 | +## Proof Verification Fails Onchain |
| 174 | + |
| 175 | +If your proof retrieves successfully but fails verification in your smart contract: |
| 176 | + |
| 177 | +### Merkle Proof Mismatch |
| 178 | + |
| 179 | +Ensure you're passing the proof to the correct verification function for your attestation type. |
| 180 | + |
| 181 | +```solidity |
| 182 | +// For Web2Json |
| 183 | +bool valid = fdcVerification.verifyWeb2Json(proof); |
| 184 | +``` |
| 185 | + |
| 186 | +### Response Data Mismatch |
| 187 | + |
| 188 | +The response data you submit must exactly match what was attested. |
| 189 | +Don't modify or re-encode the data after retrieving it from the DA Layer. |
| 190 | + |
| 191 | +### Wrong Voting Round |
| 192 | + |
| 193 | +Ensure you're querying the correct voting round ID. |
| 194 | +The round ID is calculated from the block timestamp when you submitted the request. |
| 195 | + |
| 196 | +## Best Practices |
| 197 | + |
| 198 | +1. **Design for consensus from the start.** |
| 199 | + When integrating external APIs, always consider how to ensure deterministic responses. |
| 200 | + |
| 201 | +2. **Use coarse granularity for frequently-changing values.** |
| 202 | + Round to the nearest unit that makes sense for your use case (e.g., nearest $1000 for financial data). |
| 203 | + |
| 204 | +3. **Test on testnet first.** |
| 205 | + The testnet FDC behaves identically to mainnet but allows for faster iteration. |
| 206 | + |
| 207 | +4. **Monitor your attestation requests.** |
| 208 | + Use the Systems Explorer to track whether your requests are being included in voting rounds. |
| 209 | + |
| 210 | +5. **Cache proofs appropriately.** |
| 211 | + Once a proof is generated, it remains valid indefinitely. |
| 212 | + Cache successful proofs to avoid redundant queries. |
0 commit comments