Corridor Telemetry - The Learning Layer

This is the part of the routing engine that compounds over time.

Every completed transfer - successful or failed - writes a data record back to the telemetry layer. The record contains: The corridor. Which source chain and destination chain. Which source token and destination token. Which bridge was used. Which swap protocol was used. Which off-ramp partner handled delivery. Whether it succeeded. The estimated fee and the actual fee. The estimated time and the actual time.

The estimated slippage and the actual slippage. If it failed, at which hop and what the error was. Over hundreds of transfers, patterns emerge that are invisible in public data. The CCTP bridge to Polygon degrades slightly between 2pm and 4pm UTC on weekdays because of network congestion from European trading hours. Yellow Card's NGN corridor has a higher success rate for transfers initiated on weekdays than weekends because of Nigerian banking rail availability. The 1inch aggregator consistently beats Uniswap V3 on USDC-to-USDT swaps above $10,000 but loses on smaller amounts because of fee structure.

None of this is in any public dataset. It exists because Papillae is running real transfers and recording what actually happens, not what the protocol documentation says should happen.

The routing engine uses this telemetry to continuously update its scoring weights per corridor, per time of day, per amount range. A route that scored well three months ago might score lower now because the telemetry has accumulated enough failure data to down-weight a specific protocol combination.

This is the moat that compounds. An aggregator using public data sees the same information as everyone else. Papillae's routing intelligence comes from proprietary transfer data that cannot be replicated without running the transfers.