This was probably the longest internal debate we had during the whole build. Not about the algorithm, not about which bridges to support, not about any technical decision. Whether to open-source.
The playbook everyone follows: build in private, launch with an API, gate access, maybe open-source later when you've got a moat. It works. There's nothing wrong with it. We almost did exactly that.
The Fork Argument
The case against was simple and hard to argue with: "If we publish the routing algorithm, someone forks it by next week. We spent two months on this. They copy it in an afternoon. What exactly is our advantage after that?"
We sat with that for a while. Genuinely considered it. The scenario is real — someone absolutely will fork this. Probably already has by the time you're reading this.
But the more we thought about it, the less it mattered. Alpha-beta pruning is from 1975. The math is in textbooks. Our application to cross-chain routing is specific, but anyone who reads the docs could rebuild it from scratch without our code. Keeping it closed protects nothing except a time advantage that shrinks to zero eventually.
What Can't Be Forked
The code is maybe 20% of what makes this work. The rest is context that doesn't live in any file:
- Bridge adapter maintenance — APIs change, rate limits change, edge cases surface weekly. Allbridge changed their fee calculation method mid-February and broke our adapter. We caught it because we were running live tests. A fork would just be silently wrong.
- Scoring weights — calibrated on weeks of real transfer data. The 2.0x slippage multiplier, the $500 hop penalty in move ordering, the reliability decay curves. You can copy the constants but not the process that produced them.
- Operational context — knowing that Allbridge liquidity on the SOL-ETH pair tends to thin out on weekends. That LayerZero DVN verification slows down during Ethereum gas spikes. That deBridge DLN fills get competitive during high-volatility periods because fillers are also trading. This stuff comes from running the system daily, not reading the source code.
A fork gets you the snapshot. It doesn't get you the ongoing maintenance, the calibration, or the operational knowledge. Those are the actual moat. Not the search algorithm.
The Trust Problem
Here's what actually tipped it. We're building something that says "give me your transfer, I'll pick the route." On large amounts. The entire value proposition is "trust our decision."
How do you ask for that trust while hiding the decision logic? "Trust us, the algorithm is good, but you can't see it." That's what every black-box system says. We've lost money to systems like that. We didn't want to build another one.
If someone wants to verify that our worst-case scoring actually works the way we say it does, they can open src/router/scoring.ts and read it. If someone thinks our stress multipliers are too aggressive, they can check the constants in src/constants.ts. If someone wants to audit the Wormhole adapter to make sure we're not doing anything weird with their transaction, it's right there in src/bridges/wormhole.ts.
That's the minimum bar for a system that handles other people's routing decisions.
What Happened After
Selfishly, the practical benefits showed up fast. More eyes on the code means more bugs caught before they cost someone money. We're not a large team. We can't catch everything.
Two bugs were found within the first week:
1Bug #1: LayerZero adapter was double-counting DVN fees on2 multi-hop routes that transited through Arbitrum.3 Impact: overestimating LayerZero cost by ~$15-40 on4 affected routes. Not critical but would have caused5 the engine to unfairly deprioritize LayerZero on6 those paths.7
8Bug #2: Slippage model used linear interpolation below 1%9 pool impact, but the constant product curve is already10 nonlinear at 0.8%. Edge case that only matters on11 very large transfers into medium-depth pools.12 Impact: underestimating slippage by ~0.02-0.05% on13 transfers >$200K. Small but systematic.Neither was critical. Both would have been annoying in production. Both were caught by people reading the code who we've never met. Worth it.
The Repo
- Core routing engine — minimax search, alpha-beta pruning, move ordering
- Bridge adapters — Wormhole, deBridge, LayerZero, Allbridge
- 5-dimension scoring with configurable weights and strategy profiles
- TypeScript SDK with full type definitions
- Test suite
- Docs, architecture diagrams, examples