Model the next chain
before you move.
Paste your product and receive a transparent expansion blueprint covering ecosystem fit, architecture, risks, and execution.
GCosMmwoMRwtLiMpb2tmmZyvwLzXU758iUKr1YXjyoryEvery candidate is scored against the same factor table, with its own data-confidence level and review date.
Ecosystem names and logos are shown for identification only. All marks belong to their respective owners, and their use here implies no affiliation or endorsement.
Three steps, nothing hidden between them
Each stage produces an artefact you can inspect. If a source could not be read, you are told; if a field was inferred rather than found, it is marked.
Website and docs
Routefold retrieves readable public content from the URLs you submit, strips markup and scripts, and records what it could and could not read.
Multichain Digital Twin
A structured model of your product: architecture, users, liquidity needs, transaction shape, security posture, constraints. You review and correct it before anything is scored.
Expansion blueprint
Chain-by-chain scores with a full factor breakdown, a rollout sequence, an architecture brief, a risk register, and a 30-day plan.
Every score traces back to one structured model
Routefold does not reason about your product from a paragraph. It builds a Multichain Digital Twin — an explicit, editable model — and every downstream number is derived from it. When you change the twin, you can see exactly what moves.
Fields derived from your sources are marked separately from fields you entered and fields that were inferred.
You confirm the twin before any chain is scored. Nothing is generated on top of a model you have not agreed with.
Multichain Digital Twin
13 field groups- Product category
- What it actually does
- Current architecture
- Contracts, dependencies, offchain parts
- Current chains
- Where it already runs
- Virtual machine
- EVM, SVM, Move, CosmWasm
- Contract assumptions
- Complexity, upgradeability
- User profile
- Retail, institutional, developer
- Liquidity requirements
- Depth and stablecoin dependency
- Transaction characteristics
- Frequency, latency, finality
- Security sensitivity
- Value at risk, audit status
- Orientation
- Consumer or institutional
- Target geographies
- Where growth is wanted
- Operational constraints
- Team, budget, horizon
- Growth priorities
- What the expansion is for
A score you can check line by line
100 points across five categories and seventeen documented sub-factors. Every point is attributable to a named factor with a written reason, and the model may adjust a total by at most ±5 points — with a justification, stored and displayed separately from the base.
How a total is composed
base · adj · finalThen, and only then
The clamp is enforced in the scoring layer, not requested in a prompt, so it holds regardless of what the model returns.
Technical compatibility — the sub-factors
20 ptsHow much of the existing codebase, tooling, audit surface and security posture carries over without a rewrite.
Whether existing contracts can deploy as-is, need adaptation, or need a full rewrite in another language.
Overlap between the languages the team already writes and the languages the chain accepts.
Whether the chain's finality profile satisfies the product's stated settlement requirement.
Whether the chain's trust assumptions are acceptable given how much value the product puts at risk.
Product–ecosystem fit
Users and liquidity
Technical compatibility
Cost and operational fit
Strategic optionality
The decision as a graph, not a list
Current deployments, the recommended route, secondary candidates and everything ruled out — with the reason attached to the node rather than left implicit. Pan, zoom and rearrange it in the report.
A recommendation is not a deliverable
Knowing which chain is only useful if you also know what to build, what can go wrong, and what happens in the first month.
Architecture brief
A deployment model with its reasoning, a component diagram, and specific positions on token model, messaging, state synchronisation, liquidity, indexing and monitoring. Assumptions are listed separately so you know what to verify.
- Deployment model
- Component diagram
- Monitoring requirements
- Stated assumptions
Risk register
Filterable by category and severity. Every entry has a probability, an impact, a mitigation someone can own, and a suggested owner role. Compliance items are framed as questions for counsel, never as conclusions.
- Security
- Liquidity
- Operational
- Governance
- User experience
- Compliance
30-day plan
Four weeks with milestones, tasks across engineering, product, ecosystem and operations tracks, dependencies between them, and acceptance criteria that are objectively checkable.
- Weekly milestones
- Task dependencies
- Acceptance criteria
- Launch dependencies
One contract address. Published in full, everywhere.
This is the only mint Routefold will ever publish. Copy it from here or from the explorer — never from a DM, a reply, or a search result.
GCosMmwoMRwtLiMpb2tmmZyvwLzXU758iUKr1YXjyory- Supply
- 500,000
- Freeze authority
- Revoked
- Decimals
- 6
- Launchpad
- Orynth
Fixed. The mint authority is revoked, so no further tokens can be created.
No party can freeze a holder’s balance.
Standard SPL token precision.
Launched through Orynth on a Meteora dynamic bonding curve.
RFOLD is a token on Solana, launched through Orynth. It is not an investment, does not represent equity in Routefold, and confers no claim on the product or its revenue. Routefold publishes no price target and makes no prediction about its value. Nothing here is financial advice.
Built and backed for the long build.
Routefold is backed by ZeFi. That backing is why the product can take the harder path — publishing the scoring function, reporting its own uncertainty, and refusing to manufacture a winner when two chains are genuinely tied.
Free during private beta · five reports · no card required
Built from a multichain operator’s lens.
Routefold exists because the question "which chain next?" is one of the most consequential decisions an onchain team makes, and one of the worst-tooled. It is usually settled by whichever ecosystem made the most compelling offer, or by where the engineers already have context — not by whether the chain actually fits the product.
Every design decision here follows from that. The score is produced by a deterministic function, not by a language model, so it can be published, argued with and reproduced. The model is confined to explaining that function's output and may move a score by at most five points, with a written reason, shown separately. Confidence is reported as its own number and is bounded by how much Routefold actually knows about your product.
The parts most products would hide are the parts this one leads with: what it could not read, what it had to assume, where two candidates are too close to separate. A recommendation you cannot interrogate is not decision support — it is just a more confident guess.
The goal was never to be believed. It was to be checkable.
The model does not choose the number
Chain-fit scores come from a deterministic engine that runs before any language model sees the problem. It normalises your inputs, applies the priorities you selected, penalises hard incompatibilities, and returns a factor-by-factor breakdown with a confidence value and a record of what data was missing.
Read the full methodologyDeterministic engine
Computes the 0–100 base score from documented factors. Same inputs always produce the same number.
Model interpretation
Explains the score, identifies advantages, trade-offs and unknowns, and may propose an adjustment of at most ±5 points with a written justification.
Displayed separately
Base score, adjustment, final score, confidence and missing-data warnings all appear together. You always see what the engine computed and what the model moved.
Find your next chain.
Paste your product. Review the model Routefold builds of it. Get a blueprint your engineering team can act on.

