From keystroke to fill
Everything the terminal does is a read against Solana or Jupiter followed by one signed transaction. Here is the whole path.
Reads go through a proxy
The browser never talks to the paid RPC endpoint directly. It posts JSON-RPC to a route handler on this site, which forwards upstream using a key that only exists in the server environment. If no key is configured the same handler falls through to the public cluster, so the app still works with nothing set up.
The proxy forwards only the methods the terminal actually needs. Anything outside that set is refused rather than passed along.
The catalogue is the registry, not a table
A tokenized equity is only tradeable if its mint is the real one, and there are more than fourteen hundred of them. Hardcoding that list would mean hand-copying fourteen hundred addresses, any one of which could be wrong.
So the market list is read from Jupiter's verified registry at request time and filtered to the tokens it tags as tokenized equities. Price, liquidity, and 24-hour change come back in the same response, which is what ranks the list.
Quotes come from every venue at once
Rather than quoting one pool, the terminal asks Jupiter to search across them and return the best path, including splits across multiple venues. The route it chose is shown next to the quote before anything is signed.
Quotes are never cached. They price a trade that is about to be signed, and a stale route is either a failed swap or a bad fill, so the panel re-quotes on a timer while an amount is entered.
The wallet signs what it was shown
These equities are Token-2022 mints carrying transfer hooks, so a swap usually has to create token accounts and attach a compute budget alongside the trade itself. Jupiter builds that transaction server-side from the exact quote the user accepted.
It comes back unsigned. The wallet signs it as-is and the terminal sends it to the cluster — nothing is rebuilt or re-priced between the quote on screen and the transaction that settles.