How to use Routefold

Routefold turns a product description into a chain-by-chain expansion blueprint. You supply a public URL and a short set of answers about your constraints; it retrieves what it can read, builds a structured model of your product, scores every ecosystem in its knowledge base against that model, and writes the strategy and execution material around the result.

The whole run takes a few minutes. The only step that needs your attention in the middle is confirming the Digital Twin — everything downstream is derived from it, so correcting it there is the highest-leverage thing you can do.

What you need

• A public website or documentation URL for the product. If neither can be read, a written description of at least 40 characters works instead.
• An idea of your constraints: team size, time horizon, budget sensitivity, security sensitivity, and any ecosystem that is off the table.
• An account. Analyses are private to your account and are never used to train anything.

What you get

• A Multichain Digital Twin — the structured model of your product.
• A chain scorecard: every candidate scored 0–100 with a full factor breakdown.
• An expansion map and rollout sequence with dependencies.
• An architecture brief, a risk register, a 30-day plan and an engineering handoff.
• A sources-and-assumptions record showing exactly what the analysis was working from.

Step 1 — Source

Enter the product name and the URLs Routefold should read. Use the Check button to find out immediately whether a URL is readable — it returns the page title, the word count and a short excerpt, so you know what the analysis will actually be working from before you commit.

Some sites render entirely client-side and return almost no readable text. Routefold tells you when that happens rather than silently proceeding on nothing. Paste a description instead; a good description outperforms an unreadable URL every time.

Step 2 — Current state

Where the product runs today and what it is built on. Chains listed here are scored for reference but excluded from the expansion ranking — they are not expansion targets.

The execution environment and contract languages drive the technical-compatibility category, which is worth 20 of the 100 points and is the difference between a redeployment and a rewrite.

Step 3 — Objectives

What the expansion is for. Objectives tilt the scoring weights and the result is renormalised back to 100 points, so selecting more objectives produces a balanced profile rather than a bigger number. The primary objective counts double.

Step 4 — Constraints

What is actually possible for your team. Constraints are the only inputs that can zero a score outright: an excluded ecosystem and a hard virtual-machine requirement are both hard blockers, applied by the engine and never softened by the model.

Set a hard VM requirement only if a rewrite is genuinely off the table. It is the single most restrictive input in the wizard.

Step 5 — Extracted profile

The Digital Twin, presented for review. Every field is editable and each is tagged with its provenance — whether it came from your sources, from your answers, or was inferred. The inferred fields are where errors live; those are the ones worth checking.

Nothing is scored until you confirm. Saving without confirming costs nothing.

Routefold does not reason about your product from a paragraph of prose. It builds an explicit model — category, architecture, users, liquidity requirements, transaction shape, security posture, orientation, geography and constraints — and the scoring engine reads only from that model.

This is what makes the output checkable. If a score looks wrong, you can trace it to a factor, trace that factor to a twin field, and correct the field. If the model were implicit, you could only disagree with the conclusion.

Provenance tags

• From source — established from the page text Routefold retrieved.
• You entered — taken directly from your wizard answers. These always outrank the sources when they conflict.
• Inferred — derived from the product category and mechanics. Most worth reviewing.
• Default — no input was available, so a documented neutral value was used. These lower the confidence score.

Editing after generation

The twin remains visible in the finished report. If you change something material, regenerate the affected sections rather than the whole report — section regeneration costs a smaller usage unit.

Each row expands to the complete factor table: every sub-factor, the points it awarded out of the points available, and the reason the engine recorded. Penalties and hard blockers appear where they applied, with their cost.

The three numbers

• Base score — computed by the deterministic engine. The model cannot write this.
• Adjustment — a bounded change the model may propose, clamped to ±5 points and only applied when accompanied by a written justification.
• Final score — the sum, clamped to 0–100.

Confidence is a separate number

A chain can score highly with low confidence. That combination means the recommendation rests on assumptions worth verifying before acting — not that the score is wrong. Confidence is bounded above by the confidence of the Digital Twin itself: a report cannot be more certain than its own inputs.

Margins

Treat gaps of a few points as ties. The engine resolves large differences reliably and small ones not at all, and the report says so where it matters. When two chains are close, the decision should turn on information Routefold was not given.

Section regeneration

Any narrative section can be regenerated on its own. Downstream sections read the current stored versions of their inputs, so regenerating the architecture brief uses the stored expansion sequence rather than re-running the whole pipeline. Regenerate in dependency order — sequence, then architecture, then risks, then plan.

Comparison

Select two to four chains to compare category shape, factor-level points, and the underlying knowledge-base characteristics side by side. The characteristics table is usually more decisive than the charts: it shows why the chains differ rather than that they differ.

Sharing

A share link grants read-only access to one report through a token with 256 bits of entropy. Share pages never expose your email address, your account, your other projects or any internal log. Revoking takes effect immediately, and only one link is active per report so revocation is unambiguous.

Exporting

• PDF — opens your browser print dialogue against a print-optimised layout. Choose "Save as PDF".
• JSON — the complete structured report including the full factor breakdown for every chain. Suitable for archiving or for feeding into your own tooling.

Routefold reads what you give it and what it can retrieve from public URLs. It does not read your codebase, your analytics, your counterparty list or your treasury. It cannot know how many of your users already hold assets on a given chain — which, for many products, is the single most decisive fact.

It is not a substitute for a professional smart-contract audit, and it does not provide financial, legal, compliance or investment advice. Compliance items in every report are framed as questions to put to qualified counsel.

Usage during private beta

• Five complete report generations per account.
• Twenty-five section regenerations per account.
• A generation is consumed only when a report reaches completion — failed runs cost nothing.
• The public example consumes nothing and needs no account.

Routefold runs anywhere Next.js runs. It needs PostgreSQL for persistence, Clerk for authentication and an OpenAI API key for live analysis. The public site and the example report work without any of them.

Local development

pnpm install
cp .env.example .env

pnpm dev:db      # embedded PostgreSQL, no system install needed
pnpm db:migrate  # apply migrations
pnpm db:seed     # chain-metric snapshot only — no demo rows
pnpm dev

Operating modes

With an OpenAI key configured, analysis is live. Without one, setting ROUTEFOLD_FIXTURE_MODE=true enables a deterministic fixture pipeline so the full wizard and report flow can be exercised locally. Fixture output is always labelled as fixture output in the interface and is never substituted for a failed live call.

Further reading

• README.md — setup and command reference.
• ARCHITECTURE.md — how the pipeline, scoring engine and data model fit together.
• DEPLOYMENT.md — production deployment on Vercel and elsewhere.
• SECURITY.md — the threat model and the controls implemented against it.