A tunnel flag, a residential proxy, and a quote cache that outlives the price

The documented dev path tunnels a local builder with permissions off

Read the trading section of the example environment rather than the quick start and the shape of the project changes. `VYBE_API_KEY=` ships empty, with the comment to leave it empty for a local Rust service with permissions off, and `VYBE_API_BASE` is documented as a local Rust or proxy address for development. So the endpoints that quote and build transactions can be pointed at a process on the developer's own machine that is not itself authorising anything. Then there is `TUNNEL`, documented as set to `1` to run behind a Cloudflare Tunnel. Put together, that is a documented arrangement in which an unpermissioned local transaction builder can be given a public URL. One more capability belongs in the same reading: the third execution mode, Paste & Sign, takes an arbitrary base64 transaction, refreshes its blockhash, and hands it to the wallet to sign. Signing is described as working with a Phantom-compatible wallet, so the wallet support is one family.

The last-resort price is a scraped page behind a rotating residential proxy

The optional section that follows the documented variables is about price resolution for pump.fun tokens, and it is the most consequential block in the file. The fallback is described as running after Vybe and Jupiter, so it only matters when both priced APIs fail or have not indexed the token. Its configuration is a personal JWT in `PUMPFUN_AUTH_TOKEN`, a path to captured request headers in `PUMPFUN_HEADERS_PATH`, and an HTTP proxy given as `geo.iproyal.com:12321` with credentials in the form `user:pass_country-us`, named as a rotating residential proxy and cross-referenced to defaults in a scraper module. Three things follow. A price used in a swap quote is arriving from a scraped page rather than an authenticated price feed. It is being fetched with one person's logged-in session, replayed from a header file. And it is arriving through a residential address pool with the country selected in the credential string. Any of those can change the answer without changing the market, and the code cannot tell the difference.

A denylist of route shapes, in short protocol-pair keys

One documented variable exists purely to suppress quote paths: `DISABLED_QUOTE_BRIDGE_HOP_COMBOS`, a comma-separated list of short keys, with the worked example `damm2-damm2` described as ignoring Meteora DAMM2 to Meteora DAMM2 two-hop quote bridges. That is a denylist of route shapes where the same venue appears on both ends of a hop, which is the shape that tends to produce a quote the router cannot actually fill or prices badly through its own liquidity twice. Having the switch at all is an admission that the aggregator will offer routes that need turning off per deployment, and it is expressed as short keys rather than venue identifiers, so the mapping from key to venue lives in code. A sibling mechanism exists on the catalogue path, where `CATALOG_FILTER_RESET_DENYLIST=1` clears a denylist before a refresh, which tells you the same idea is applied twice in the tooling.

Quotes come back when you switch routers, along with their timers

The cache behaviour is specific enough to matter. Switching between the Vybe, Jupiter and Titan tabs restores that router's last quote, its route plan and its timers, and the timers are tracked separately for getting a quote and for building. On top of that, a built transaction is reused without rebuilding while a 30 second Build and Sign window is active, with a shorter 10 second hot reuse when the parameters have not changed. Reusing a built transaction for 10 to 30 seconds is a defensible choice against rebuilding on every click, and the blockhash is what actually limits it. The consequence is that the interface is built to keep a price visible and usable after the act of fetching it, so a quote obtained, then a router tab change, then a click is a path the UI actively supports. The sign dialog is honest about one thing it does not know yet, showing a dash for transaction size until the build completes.

A blocked quote button whose reason is off by default

There is a lock during fetching. While a quote is in flight the token pickers, the amount, slippage, the build options, the router tabs, the mode tabs and the wallet tray are all disabled until it finishes, which prevents you from changing the request underneath a request already running. The feature list also names an inline debug element: a `Get quote blocked` meta line shown under the quote button, controlled by `ENABLE_SWAP_QUOTE_BTN_DEBUG`, which the example environment marks as defaulting to off. So there is a state in which the button refuses to act and the interface says nothing about why, unless you started the process with a flag set. That is a reasonable default for a demo and a poor default for anything you intend to debug under time pressure, since the flag is read at startup rather than at the moment of failure.

npm start does not run the output npm build produces

The manifest declares `main` as `dist/server.js`, and the build script is `tsc`, so the compiled output goes where a library consumer would expect it. The start script is `tsx src/server.ts`, which runs the TypeScript source directly through a loader and never touches `dist/`. A `prestart` hook runs the frontend build first, so `npm start` compiles the browser bundle and executes the uncompiled server. Both are defensible choices, but together they mean the artifact named in `main` is not the artifact you run, which will confuse anyone containerising this by copying a `dist` directory. The frontend is a single page with no framework, built from `src/frontend/` into `public/app.js` by a small bundler script and type-checked through a second tsconfig, so there is no React, no bundler dependency and no second toolchain. The manifest is an ES module package on Express 4, and the recorded primary language for the repository is JavaScript.

Twelve tooling scripts, a benchmark aimed at the live demo, and no licence file

For something described as a reference implementation or starter kit, the tooling is a research harness. Installation is four commands from a clean clone:

git clone https://github.com/vybenetwork/solana-swap-api.git
cd solana-swap-api
npm install
cp .env.example .env

Beyond the three run scripts there are scripts to fetch a token catalogue, filter it by SOL quote, refresh it locally with a denylist reset, download token icons, scrape Solscan markets, compare routes against Solscan, analyse filter failures, run a hundred-quote benchmark against a chosen SWAP_API, and two prod-like local harnesses including a local Vybe proxy. The benchmark script defaults to pointing at the vendor's live deployment rather than your own, so running it as written sends traffic to somebody else's instance. On licensing, the manifest says MIT and there is no LICENSE file in the tree, while the licence attached to the repository reads as unknown. That is a partial answer rather than none, and it is worth resolving before you copy the code. One smaller trap in the same file: the data key is shipped as the literal string `your_api_key_here` rather than left blank, so a copied configuration sends that text as a credential.

Editorial conclusion

It fits a developer building a swap interface who wants to see how quote, route and signing fit together across three aggregators, and who will replace the vendor with their own backend before anything real is traded. It does not fit a deployment where the price path and the signing path are as shipped, because the documented fallback price comes from a scraped page reached through a rotating residential proxy, and the documented dev arrangement points the transaction builder at a local service with permissions disabled behind a tunnel flag. Before building on it, decide where prices come from and remove the scraping path if you cannot vouch for it, keep the trading key unset only while the base URL is local, and read the caching behaviour so a quote cannot be signed after the price behind it has moved.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. vybenetwork/solana-swap-api on GitHub