How Routes Are Selected

When a payment arrives, the routing engine does not look up a table. It runs a live computation.

Every possible path from source to destination is evaluated. For a transfer from USDC on Ethereum to pesos in Mexico, that might be fifteen or twenty distinct route combinations when you account for different bridges, different swap paths, and different off-ramp partner options. The engine scores every one of them.

The scoring formula weighs three variables: cost, speed, and success rate. The exact weighting depends on the user's stated preference.

When the user prefers cost:

score = (1/fee × 0.50) + (1/time × 0.30) + (successRate × 0.20)

When the user prefers speed:

score = (1/time × 0.60) + (successRate × 0.30) + (1/fee × 0.10)

The success rate in these formulas is not a historical average. It is a rolling one-hour success rate pulled from the telemetry layer. A bridge that processed transfers fine yesterday but has been failing 30% of the time in the last hour gets a low score. The engine knows this. A static routing table does not.

Any protocol with a success rate below 85% in the last hour is excluded from selection entirely regardless of its cost or speed score. You cannot route your way around a broken protocol.

The top-scoring route becomes the primary. The second and third scoring routes become pre-computed fallbacks. All three are evaluated before execution begins. If the primary fails mid-way, the engine does not need to re-run the computation. It already knows the next move.