Piteas: Inside the PulseChain DEX Aggregator and the Piteas App

Piteas is a non-custodial DEX aggregator on PulseChain. It holds no liquidity of its own, takes no custody of a trader's funds, and exists to answer one narrow question better than anything else on the network: given this amount of this token, what is the largest possible amount of that token, and which combination of pools delivers it?

There is a particular frustration that every trader on a young blockchain eventually discovers. You find a token you want. You open the exchange everyone uses. You type in an amount, and the interface tells you what you will receive. You accept it, because there is nothing to compare it against. And somewhere else on the same network, in a pool you never checked, on an exchange you have never opened, the same trade would have returned four percent more.

Nobody stole that four percent. It was simply never found. Liquidity on a maturing network does not sit in one place; it scatters across every venue that has managed to attract some, and a single exchange can only ever quote from the pools it owns. It is structurally blind to everything outside its own walls, and the trader inherits that blindness.

Piteas is built on the premise that this blindness is a solvable engineering problem rather than an unavoidable cost of decentralisation. It is an aggregator, which means it owns no pools and quotes no prices of its own. What it owns is the search: a routing engine that looks at the entire liquidity surface of PulseChain at the moment you ask, considers the direct route, the routes that pass through intermediate tokens, and the routes that split one order across several pools at once, prices every one of them net of fees and network costs, and hands back the single best executable path it can find. That search finishes in well under a second, which is why the experience feels like nothing more elaborate than typing a number into a box.

This article is a complete account of how that works and what it means in practice: the routing mathematics underneath the interface, the venues Piteas draws liquidity from, a walkthrough of the Piteas app from wallet connection to confirmed transaction, the real cost structure of an aggregated trade, the security model that makes non-custodial execution more than a marketing phrase, the developer tools built on the same engine, and a plain answer to the questions people actually ask before they trade.

1. What Piteas Is: The Piteas DEX Explained

Piteas is a decentralised exchange aggregator operating natively on PulseChain. The word aggregator is doing a great deal of work in that sentence, and the distinction it draws is the single most important thing to understand about Piteas, so it is worth being precise.

A decentralised exchange, in the automated market maker form that dominates on-chain trading, is a collection of liquidity pools. Each pool holds reserves of two tokens and prices trades between them according to a formula applied to those reserves. When you trade on such an exchange, you are trading against its pools, at prices its pools determine. The exchange's quote is not an opinion about the market; it is an arithmetic fact about its own reserves.

An aggregator sits one layer above that. It holds no reserves, so it has no prices of its own to offer. Instead it treats every pool on the network, across every exchange, as raw material. When you ask for a quote, it reads the current state of that entire liquidity surface, works out which combination of pools will convert your input into the largest possible output, and constructs a single transaction that executes that combination. The aggregator's product is not liquidity. It is the search over liquidity, and the execution of what the search finds.

This is why the phrase Piteas DEX is a slight misnomer that nonetheless describes the trader's experience accurately. You arrive at something that looks and behaves exactly like a decentralised exchange: two token fields, an amount, a rate, a button. But the thing behind the button is not an exchange. It is a router with access to all of them.

The problem Piteas actually solves

Liquidity fragmentation is not a flaw that a particular network failed to avoid. It is the natural consequence of permissionless markets. Anyone can deploy an exchange. Anyone can create a pool. Anyone can decide that their token's primary market will live on the venue that gave them the best incentives. The predictable result is that any reasonably active network ends up with its depth distributed across many venues, in many pairs, at many fee tiers, with no coordinating authority and no reason for any of it to consolidate.

For liquidity providers, this is merely inconvenient. For traders, it is expensive in a way that is almost impossible to detect from inside a single interface. The cost does not appear as a fee. It appears as an absence: output you never received, from a route you never saw, because the venue you were using had no way to tell you about it. Every trade executed on a single exchange in a fragmented market carries this invisible tax, and its size depends on exactly how fragmented the relevant pair happens to be at that moment.

The cost of fragmented liquidity never shows up as a fee. It shows up as output that quietly failed to arrive.

Aggregation attacks this directly. If the depth is scattered, look everywhere at once. If no single pool can absorb the order without moving its price badly, use several. If there is no direct pair between the two tokens, find the chain of pairs that connects them. The trader's job collapses from route research to a single decision about whether to accept the number on the screen, and the routing complexity moves into software where it belongs.

What non-custodial means here, concretely

Non-custodial is an overused term, so here is the specific claim Piteas makes. At no point in a trade does Piteas hold a balance that belongs to you in a way you cannot immediately reclaim. There is no deposit step. There is no internal ledger crediting you with a balance. There is no withdrawal to request and no operator who could refuse it.

What happens instead is that a single atomic transaction, signed by your wallet, moves your input token out, performs every swap in the route, and delivers the output token to your address. Atomic means the whole sequence either completes as specified or has no effect at all. There is no state in which Piteas is holding your tokens and something has gone wrong. Either you have the output, or you still have the input.

This structure eliminates the failure mode that has destroyed the most user funds in the history of crypto trading, which is not clever contract exploitation but simple custody: an intermediary holding assets it should not have been holding, and then failing. An aggregator that never holds assets cannot fail in that way. It can have bugs, it can be front-run at the interface level, it can route you into a bad token if you ask it to, but it cannot lose funds it never had.

The design philosophy, read from the architecture

You can infer a protocol's priorities from what it refuses to do, and the refusals here are consistent. There is no account system, because an account would create a database of users and a party responsible for it. There is no identity verification, because verification would make permissionless access conditional. There is no proprietary liquidity, because owning pools would give the router a reason to prefer them over better ones. There are no tokens that must be held before trading, because that would be a toll on access dressed up as an ecosystem.

What is left is a narrow protocol that does one thing. That narrowness is a design choice with a real payoff: the smaller the surface, the fewer the ways it can fail, and the easier it is for anyone to reason about what will happen when they press the button. Infrastructure earns trust by being boring in exactly this way.

Piteas Labs and the shape of the project

The protocol is built and maintained by Piteas Labs, the team responsible for the routing engine, the trading interface, the router contract, the public API and the embeddable widget. The important structural point is which of those components a trader's funds actually depend on. The routing engine is advisory: it proposes a path, and a bad proposal produces a worse price, not a loss of custody. The interface is a convenience: it constructs a transaction that your wallet displays before you sign it. The contract is the only piece with authority over token movement, and it is open source and constrained by parameters your own signature sets.

That layering matters more than any assurance about the team's intentions, because it means the guarantees do not rest on intentions. They rest on the fact that off-chain components cannot move tokens and on-chain components cannot exceed the limits your signature imposed.

2. Piteas PulseChain DEX: Why This Network

Piteas is not a general multi-chain aggregator that happens to support PulseChain among a list of others. It is a PulseChain-native protocol, and that focus explains several of its design decisions that would look strange in another context.

PulseChain is an EVM-compatible layer-one network operating with chain ID 369. Its native asset, PLS, pays for gas. Its wrapped form, WPLS, is the token that most liquidity pools actually pair against, in the same way that wrapped native assets act as the routing hub on every other EVM network. Anyone familiar with Ethereum development finds the environment immediately legible: the same virtual machine, the same tooling, the same contract standards, the same wallet software.

Cheap gas changes what routing can do

The most consequential difference for an aggregator is transaction cost, and the reason is not the obvious one. Cheap gas is pleasant for traders, but for a router it is architecturally enabling, because it changes which routes are worth taking.

Consider the arithmetic. A split route that divides one trade across four pools does roughly four times the on-chain work of a single-pool swap. On a network where a simple swap costs a meaningful amount in gas, that additional work has to be justified by a substantial improvement in output, which means the router can only justify splitting on large trades. Below some threshold, the optimal strategy collapses back to the single best pool, and the aggregator's sophistication becomes irrelevant to most of the trades people actually make.

Lower the gas cost and the threshold drops with it. Routes that would be uneconomic elsewhere become worth executing. A four-way split that improves output by a fraction of a percent is worth taking when the extra execution cost is negligible. Multi-hop paths through two or three intermediate tokens stay viable. The router's search space effectively expands, because far fewer candidate routes get disqualified on cost grounds before they are even considered. An aggregator on a low-fee network is not doing the same job more cheaply. It is doing a strictly larger job.

Fragmentation as the standing condition

PulseChain's liquidity landscape also happens to be an unusually good fit for aggregation, because it developed the way permissionless ecosystems always develop. Multiple independent automated market makers launched, each attracting depth in different pairs. Some specialise in particular pool designs or fee structures. Token projects seeded liquidity wherever it made sense for them at the time. The result is a network where the best price for a given pair genuinely varies by venue, and varies over time, and cannot be predicted from a rule of thumb.

That is precisely the condition under which routing produces real value. In a hypothetical market where one venue held all the depth for every pair, an aggregator would be a redundant layer adding gas cost for nothing. The more scattered the depth, the more a router earns its place. On a network where any given pair might have its deepest market on a different exchange this week than last, checking everything is not sophistication for its own sake. It is the only way to be reliably correct.

A routing layer rather than another venue

This produces a relationship with the wider ecosystem that is worth stating plainly, because it is not competitive in the way people assume. Piteas does not take liquidity away from the exchanges it routes through. It sends volume to them. A trade routed through four pools pays fees to all four, and those fees accrue to the liquidity providers of those pools exactly as they would have if the trader had arrived directly.

What the router changes is which pools receive the flow. Liquidity gets used in proportion to how competitively it is priced rather than in proportion to how well-known its host interface is. A new exchange with genuinely deep pools in a specific pair starts receiving routed volume as soon as its pools are integrated, without needing to win a marketing battle for user attention first. Aggregation, applied consistently, is a mechanism that rewards depth over distribution.

3. How Piteas Works: The Pathfinder Engine

Everything distinctive about Piteas lives in one component. Pathfinder is the routing engine that converts a trader's intent, expressed as an input token, an output token and an amount, into a specific executable path through PulseChain's liquidity. This section explains what it is actually doing between the moment you finish typing and the moment a quote appears.

Liquidity as a graph

The useful mental model is a graph. Every token that can be traded is a node. Every liquidity pool that exchanges two tokens is an edge connecting the corresponding nodes. Each edge carries properties that determine how expensive it is to traverse: the current reserves on both sides, which set the price and the depth; the pool's fee tier, taken out of every trade passing through; the specific pricing formula the pool implements, which governs how sharply the rate degrades as trade size grows; and the gas cost of interacting with that particular contract.

Framed this way, the routing problem has a clean statement. Find the walk from the input node to the output node that maximises the amount of the output token actually arriving in the trader's wallet. Not the walk with the fewest hops, not the walk through the largest pool, and not the walk with the best headline rate. The walk that maximises the final number after every cost has been subtracted.

The complication that makes this genuinely hard is that edge weights are not constant. They depend on how much you are sending through them. A pool that offers an excellent rate for a small trade may offer a terrible one for a large trade, because consuming a large share of its depth moves its price against you as the trade executes. So the router cannot simply score each edge once and run a standard shortest-path algorithm. It has to evaluate candidate routes at the specific size being traded, and the ranking of routes genuinely changes with size. This is why the same pair can route through completely different pools depending on whether you are selling a small amount or a large one.

The three shapes a route can take

Pathfinder builds candidate routes in three forms, and understanding them explains almost every route breakdown you will ever see in the interface.

Direct routes use one pool that holds both tokens. Simplest, cheapest in gas, and frequently optimal for small trades in well-capitalised pairs. When the interface shows a single-pool route, that is not the router failing to try; it is the router having checked the alternatives and found that none of them beat the obvious answer.

Multi-hop routes chain several pools through intermediate tokens. If you are selling a long-tail token for a stablecoin and no direct pair exists, the route might sell into WPLS, then convert WPLS into the stablecoin. Multi-hop is what makes arbitrary token pairs tradeable at all, but it also frequently wins even when a direct pair does exist, because two deep hops routinely outperform one shallow one. A thin direct pool imposes severe price impact; two liquid pools connected by a major hub token may barely register the same trade.

Split routes divide a single trade across several parallel paths, executing all of them in one transaction. This is the least intuitive shape and the most valuable one, and it follows from a property of automated market makers that is easy to state and easy to underestimate: price impact grows faster than trade size. Push twice the volume through a pool and you suffer more than twice the impact.

The consequence is that concentration is expensive. Sending an entire large order through the single best pool means every incremental unit executes at a worse rate than the one before it. Sending sixty percent through the best pool and forty percent through the second-best means each portion stays in the shallower, cheaper part of its own impact curve. The second pool's starting price is worse, but the trade never pushes either pool as far up its curve, and the total output can exceed what the best single pool alone would have returned. Splitting is not hedging or diversification. It is a direct consequence of the curvature of the pricing formula.

Price impact grows faster than trade size. That single property is the entire mathematical justification for split routing.

In practice these shapes combine. A large trade may split four ways, where one portion goes direct, two portions take different two-hop paths through different intermediate tokens, and the last takes a three-hop path through a venue that happens to hold unusual depth in an unusual pair. The interface presents this as a route breakdown with percentages, and each percentage is a solved allocation rather than a heuristic guess.

How candidates are scored

A route is only as good as the number it produces after everything has been deducted, and the scoring reflects that. Four components matter.

Gross output is what the pricing formulas return for the specified amounts along the path, given current reserves. This is the headline figure, and on its own it is misleading.

Pool fees are removed at every hop. A three-hop route pays three fees. This is why long routes need to be substantially better on price impact to win: they are carrying more fee drag, and the drag compounds along the chain.

Price impact is the movement in each pool's price caused by the trade itself. Correctly accounting for this at the exact size being traded, rather than quoting a spot rate that only holds for an infinitesimal trade, is where most naive routing implementations go wrong.

Gas is the network cost of executing the route, and it is the term that makes the objective function honest. A route that improves gross output by an amount smaller than the additional gas it consumes is a worse route, full stop. Including gas in the score is what keeps the optimiser from producing baroque paths that look impressive and lose money. It is also, as noted earlier, the term whose smallness on PulseChain lets far more elaborate routes clear the bar.

The optimiser compares candidates on net output after all four, and returns the winner. When the interface says it found the best route, the claim is specific: best by expected output net of fees, impact and gas, given the state of the chain when the quote was generated.

Why the search is off-chain

All of this computation happens off-chain, and that is a deliberate architectural decision with clear consequences.

Doing it on-chain would be prohibitive. Evaluating thousands of candidate routes means reading the reserves of a large number of pools and running the pricing arithmetic repeatedly for each one. Performing that inside a transaction would burn more gas on the search than the trade could ever recover, and it would be constrained by block-time limits that a demanding optimisation cannot respect. Off-chain, the engine can read current state from the network, run an expensive search in dedicated compute, and finish comfortably within the sub-second window that keeps the interface feeling instant.

The security question this raises is the right one to ask, and it has a clean answer. If the route is computed off-chain, why trust it? The answer is that you do not have to. The router contract enforces a minimum acceptable output that your own transaction specifies. If the route the engine chose fails to deliver at least that amount, the transaction reverts. The engine's authority extends only to proposing a path; the only thing a bad proposal can produce is a reverted transaction or a worse-but-still-acceptable fill. It cannot exceed the limit your signature set, and it cannot move funds anywhere you did not authorise.

So the trust model is narrow in exactly the place it needs to be. Off-chain computation is trusted for quality of routing. On-chain enforcement is trusted for safety of funds. Those are different concerns, handled by different layers, and conflating them is the mistake that makes people nervous about off-chain routing when they should not be.

From quote to signed transaction

The handoff between the two layers is worth following step by step, because it is the whole mechanism.

The engine, having selected a route, produces call data: an encoded instruction describing exactly which pools to touch, in what order, with what amounts, and what the minimum acceptable output is. This is not a human-readable suggestion. It is a byte string ready to be submitted to the router contract.

The interface presents that route to you in readable form and, when you accept, asks your wallet to sign a transaction carrying the call data to the router. Your wallet shows you the destination contract, the value, and the token approvals involved before anything is signed. Nothing has happened on-chain yet, and nothing can, until you sign.

Once submitted, the router executes the sequence, checks the amount actually received against the minimum your transaction specified, and either delivers the output to your address or reverts the entire thing. The output is measured as the real balance change produced by the swaps, not the amount the route predicted, so the check is against reality rather than against the optimiser's expectations.

Why quotes expire

One behaviour that puzzles new users follows directly from all of this. Quotes go stale, and the interface refreshes them.

A quote is a statement about the state of the chain at the instant it was computed. Every trade that lands in the interim changes some pool's reserves. Enough of those, in the pools your route depends on, and the route is no longer optimal, or no longer able to deliver the output it promised. This is not a defect. It is what it means to compute an exact answer about a system that keeps moving, and the alternative, quoting a stale rate confidently, would be much worse.

Slippage tolerance is the trader's setting for how much of this drift to accept. Set it too tight on a volatile token and normal price movement between quoting and inclusion will cause reverts. Set it too loose on a large trade and you widen the gap between what you expected and what you are willing to accept, which is the gap an adversary can try to exploit. The default balances those cases; adjusting it should be a considered decision about the specific token rather than a reflex when a transaction fails.

4. Piteas Pulse DEX Integrations: Liquidity Sources

An aggregator is only as good as the liquidity it can reach. A perfect optimiser searching two pools will lose to a mediocre one searching twenty. Integration coverage is therefore not a feature list item; it is the ceiling on how good any quote can possibly be.

As a Piteas Pulse DEX router, Piteas draws on the significant automated market makers operating on PulseChain, and because each was built with different priorities, each contributes something the others do not.

PulseX

PulseX is the network's foundational exchange and holds the deepest markets in the pairs that matter most: the native wrapped asset, the major bridged tokens, the stablecoins, and the headline ecosystem assets. For a large proportion of trades, some portion of the optimal route will pass through it, simply because depth is where it is. Its multiple fee tiers also give the router genuine choice on the same nominal pair, since the cheaper tier is not automatically the better one once its shallower depth is priced in at the size being traded.

PHUX

PHUX contributes weighted, multi-token pools rather than the standard two-token design, which means a single pool can hold several assets in a defined ratio. This matters for routing in a way that is easy to miss: a multi-token pool creates exchange paths between every pair of assets it contains, so integrating one such pool can add many usable edges to the graph at once. For trades between assets that share a pool but have no dedicated pair anywhere, these venues sometimes hold the only sensible route on the network.

9inch

9inch runs its own liquidity across a broad set of PulseChain pairs and is frequently competitive in mid-cap and community tokens where the largest venue has not accumulated dominant depth. It is a good illustration of why exhaustive checking beats reasonable assumptions: the best route for a mid-cap token is not predictable from the token's size, and the only way to know is to look.

9mm

9mm brings concentrated-liquidity pool designs, where providers allocate capital within chosen price ranges instead of across the entire curve. Inside an active range, this produces exceptional depth relative to capital deployed, which can make such a pool decisively the best venue for a trade. Outside the range, depth thins sharply. Concentrated pools therefore reward exactly the kind of size-aware evaluation Pathfinder performs, and punish routers that rely on spot quotes.

Tide, pDex and DexTop

These venues serve their own communities and hold depth in their own sets of pairs. Individually, none will feature in the majority of routes. Collectively, they are the difference between a router that handles the network's popular tokens and one that handles the network. The long tail is also where aggregation delivers its most dramatic improvements, because a token whose only real market sits on a smaller venue is precisely the token a single-exchange interface will quote catastrophically or refuse entirely.

Why exhaustive coverage compounds

Adding a venue does not add a linear amount of routing value. It adds every new edge that venue's pools represent, and every new route that becomes possible by combining those edges with edges that already existed. A single new pool pairing an obscure token against a major hub can open viable paths between that token and every other token reachable from that hub. The graph grows in connections, not just in nodes, which is why integration coverage has an outsized effect on quote quality for anything outside the top handful of assets.

Integration is also not a one-time act. Pools are created continuously, depth migrates between venues, ranges in concentrated pools drift in and out of relevance, and new exchanges launch. Keeping the routable set current is ongoing maintenance work, and it is the unglamorous half of running an aggregator well.

5. The Piteas App: A Complete Walkthrough

The Piteas app is the trading interface where all of the preceding machinery becomes a single screen with two token fields. This section walks through the Piteas app end to end, including the parts that go wrong and what to do about them.

The design goal is evident the moment you open it: the interface hides the complexity rather than displaying it. There is no route builder, no venue selector, no advanced mode demanding decisions about pools. You state what you want and the software solves the rest. The sophistication is real, but it is placed underneath rather than in front of you.

Connecting a wallet

The only prerequisite is a Web3 wallet configured for PulseChain. MetaMask and Rabby are the common desktop choices; WalletConnect-compatible mobile wallets and in-app browsers work equally well. There is no sign-up, no email, no password and no account to create. The connection is a permission grant, not a registration.

Two configuration points cause almost all first-time friction. The wallet must be pointed at PulseChain, chain ID 369, and not at a different EVM network. It happens constantly, because every EVM chain looks the same to a wallet, and the symptom is confusing: an interface that appears to work but shows no balances, or quotes nothing. The app will generally prompt for a network switch, which is worth accepting.

The second point is gas. Every transaction on PulseChain is paid for in PLS, so a wallet holding only the token you want to sell cannot transact. Keeping a working balance of PLS aside is basic hygiene, and it is a particularly common trap when selling a position down to zero: the tokens are gone, and so is the ability to do anything else.

Connecting grants no spending authority. It lets the interface read your address and propose transactions. Every movement of value still requires a separate signature.

Selecting tokens and requesting a quote

The two fields are the token you are selling and the token you want. The token list covers assets with real liquidity on the network, and any token can be added by contract address if it is not listed.

That last capability deserves a warning, because it is the sharpest edge in the entire application. Adding a token by address is a necessary feature and a well-worn attack vector. Anyone can deploy a token, name it whatever they like, and give it a symbol identical to something legitimate. The interface cannot tell you that the address you pasted is not the token you think it is; nothing on-chain can, because both are equally valid tokens as far as the network is concerned. Verify addresses from a source you have reason to trust before trading anything you added manually. The router will faithfully execute a swap into a worthless token, because that is what you asked it to do.

Entering an amount triggers a quote. Pathfinder reads current pool state, runs its search, and returns a route within a fraction of a second. The number that appears is not a spot rate multiplied by your amount. It is the modelled output of a specific route at that specific size, net of fees and impact.

Reading the quote properly

Most users look at one number. There are four worth understanding.

The expected output is what the chosen route should deliver if the chain does not move before your transaction is included. It already accounts for pool fees and price impact along the path.

The minimum received is the enforced floor. It is the expected output reduced by your slippage tolerance, and it is the value the contract will check against on-chain. If the trade cannot deliver at least this much, it reverts. This is the number that actually protects you, and it is the one most traders ignore.

The price impact is how much your own trade moves the price of the pools it passes through. Small impact means your trade is comfortably absorbed by available depth. Large impact means you are consuming a significant share of it, and the warning it triggers is not decoration. A double-digit impact figure on a modest trade is telling you something important about that token's liquidity, and the correct response is usually to trade smaller amounts in sequence, or to reconsider.

The route breakdown shows the path or paths selected, with allocation percentages when the trade is split. It is worth glancing at, because it explains the output figure. A trade split four ways through three different exchanges is the visible evidence that the router found something a single venue could not have offered.

Slippage tolerance, and how to think about it

Slippage tolerance is the only meaningful setting in the interface, and it represents a genuine trade-off rather than a value to be maximised or minimised.

Set it too tight and ordinary market movement between quoting and inclusion pushes the result below your floor, and the transaction reverts. You keep your funds but pay gas for the failure, and on a volatile token you can fail repeatedly. Set it too loose and you have authorised a fill materially worse than quoted, which widens the window an adversary can profit from by moving the price against you before your transaction executes.

The practical guidance follows from the token, not from a universal number. Deep, stable pairs execute reliably on tight tolerances. Thin or fast-moving tokens need more room, because their prices genuinely move that much in the time it takes a block to be produced. The default is calibrated for typical conditions, and the right instinct when a swap fails is to ask whether the token's volatility justifies more room, rather than to raise the tolerance until something goes through.

Approval, then swap

Trading an ERC-20 token for the first time requires two transactions, and the distinction between them matters.

The first is an approval, which authorises the router contract to move that token on your behalf. This is a requirement of the token standard rather than a choice Piteas made: contracts cannot take tokens from a wallet that has not approved them. The approval is per token, so it is a one-time step for each new token you sell, not a recurring cost.

The second is the swap itself, carrying the route's call data to the router.

Approvals are worth treating with more care than they usually receive, because they persist after the trade is done. An unlimited approval left in place is a standing authorisation that only remains harmless while the approved contract remains uncompromised. Reviewing and revoking stale approvals periodically, across every protocol you have ever used, is one of the highest-value security habits available to an on-chain trader, and almost nobody does it.

Native PLS trades skip approval entirely, since the native asset is sent with the transaction rather than pulled from a balance.

Confirmation and settlement

After signing, the transaction enters the mempool and waits for inclusion. On PulseChain this is typically quick. The interface tracks the transaction and reports the outcome, and the outcome is binary: the swap executed and the output arrived, or it reverted and your input token is still in your wallet, less the gas spent on the attempt.

There is no partial fill and no intermediate state where Piteas holds something of yours. That is what atomic execution buys you, and it is why a failed swap in the Piteas app is an annoyance rather than an emergency.

When a swap fails

Four causes account for nearly every failure, and each has a specific fix.

The quote went stale. The chain moved after the route was computed, and the route can no longer deliver the minimum. Refresh the quote and submit again. This is the most common failure and the least concerning.

Slippage tolerance was too tight for the token. Normal volatility exceeded the floor. Widen the tolerance deliberately, with the token's behaviour in mind, rather than escalating blindly.

Not enough PLS for gas. The wallet cannot pay for execution. Top up the native balance. Frequently misdiagnosed as an application error.

Missing or insufficient approval. The approval transaction failed, was rejected, or was set below the trade amount. Approve again before retrying.

If a swap fails repeatedly with adequate gas and a sensible tolerance, the honest interpretation is usually that the token is too illiquid or too volatile to execute at that size. Reducing the amount is the remedy, and if that does not work, the market itself is the problem rather than the router.

Mobile

The application is a responsive web app rather than a native download, which means there is no app-store listing to look for and no separate mobile version with reduced capability. Opening it in a mobile browser, or in the in-app browser of a wallet, gives the same routing engine and the same interface at a smaller size. It also means there is nothing to install and nothing to update, which removes an entire category of impersonation risk that plagues native crypto applications.

6. The Piteas PulseChain Website and Official Surfaces

People searching for the Piteas PulseChain website are usually trying to answer one question, and it is the right question to be asking: which address is the real one? In a domain where a convincing clone of a trading interface is a profitable thing to build, knowing how to verify what you are looking at is a genuine skill.

Two surfaces, two purposes

Piteas presents itself through two distinct surfaces, and confusing them is harmless but common.

The main site, at piteas.io, is the Piteas PulseChain website in the narrow sense: the public front page. It explains what Piteas does, summarises the routing approach, and points to the project's resources. It is informational, and no funds move there.

The application, at app.piteas.io, is the trading interface described in the previous section. Wallets connect here and transactions originate here. It is the surface that matters operationally, and the one worth bookmarking.

Both are official. The split is a conventional separation between a marketing site and a production application, and it exists on most serious protocols for the practical reason that the two have very different uptime and change-management requirements.

Verifying that you are in the right place

A handful of habits eliminate most of the risk, and none of them require expertise.

Reach the app from your own bookmark. Not from a search result, not from a message, not from a link in a group chat. Navigate there once by carefully typed address, verify it, bookmark it, and use the bookmark permanently. This single habit defeats nearly every phishing attempt, because phishing depends on controlling how you arrive.

Read the domain character by character. Clone operators register lookalikes exploiting transposed letters, substituted characters, alternative top-level domains and added words. They are designed to survive a glance and fail a careful read, so give them a careful read.

Treat search advertisements as untrusted. Paid placements above organic results have been used to promote cloned interfaces for as long as the tactic has existed. The sponsored slot is not a verification of anything.

Verify token contract addresses independently. If you are trading a specific token, confirm its contract address against a source you trust before you trade, particularly when adding it manually. A fake token with a legitimate symbol is trivial to create.

Read what your wallet shows you before signing. This is the last line of defence and it is genuinely effective, because a clone must eventually ask you to sign something. The wallet displays the contract being called, the value being sent, and the approvals being granted. A signature request that does not match the trade you thought you were making is the clearest warning you will ever get, and it arrives before any funds have moved.

That last point generalises usefully. A non-custodial protocol cannot lose your funds, but it also cannot stop you from signing a transaction that hands them to someone else. The signature is the boundary of the security model, and everything on your side of it is your responsibility.

7. Fees, Costs and Trade Economics

Understanding what a swap on Piteas actually costs requires separating the costs you can see from the one you cannot, because the invisible one is usually the largest.

The three components of a trade's cost

Pool fees are charged by each liquidity pool the route passes through, deducted from the amount moving through it, and paid to that pool's liquidity providers. They are the price of the liquidity itself. A multi-hop route pays a fee at every hop, which is a real cost of longer paths and one of the reasons the optimiser does not simply prefer elaborate routes.

Gas is the network's charge for executing the transaction, paid in PLS. A split route costs more gas than a direct one because it performs more work. On PulseChain this cost is low enough that it rarely dominates the decision, which as discussed is precisely what allows aggressive routing.

Price impact is the cost nobody accounts for and everybody pays. It is not a fee charged by anyone. It is the movement in the pool's price caused by your own trade, and it is the difference between the rate you saw and the average rate you actually got. On a thin pool it can dwarf every explicit fee combined, and it is the specific cost that routing is designed to minimise.

Where the routing actually pays for itself

The economic case for aggregation is straightforward once price impact is properly on the ledger. An aggregated route costs more gas than a single-pool swap and pays fees at more hops. It wins whenever the reduction in price impact exceeds that additional overhead, which is exactly the condition the optimiser evaluates before returning a route.

Two variables determine how large the win is. The first is trade size relative to available depth: a small trade in a deep pair suffers almost no impact anywhere, so there is little to recover and the router will usually return the obvious direct route. The second is fragmentation of the specific pair: when depth is scattered across venues, the gap between the best single pool and the best combination of pools widens considerably.

This produces a useful expectation. On the network's most liquid pairs at modest size, aggregation should return roughly what a direct swap would, because there is nothing left on the table. On large trades, on thinly traded tokens, and on pairs whose liquidity is spread across several venues, the difference can be substantial. Traders who conclude that an aggregator is unnecessary have usually only tested it on the first case.

Compared with a centralised exchange

The comparison is often made and rarely made properly, because the cost structures are not analogous. A centralised exchange charges a percentage commission on the trade and quotes from an order book, where the equivalent of price impact is walking the book and the equivalent of pool fees is the spread. The commission is visible; the book depth cost is not.

The more meaningful differences are structural. A centralised venue takes custody of your assets while you trade, requires identity verification, can restrict withdrawal, and lists only the tokens it chooses to list. An on-chain aggregator takes no custody, requires no verification, cannot restrict anything, and can route any token with a liquidity path. For a large trade in a major asset, a deep centralised book may well execute better. For anything outside the listed universe, or for anyone who considers custody itself the risk being managed, the comparison is not really about execution quality at all.

8. The PTS Token in Brief

Piteas has an associated token, PTS, and the most important fact about it for a trader is that it is entirely optional. Swapping on Piteas requires the token you are selling and enough PLS for gas. Nothing else. There is no holding requirement, no staking prerequisite and no tier system gating access to better routing.

The token exists as an economic layer rather than an access mechanism. Its supply is fixed at a maximum of 100,000,000 with no minting function, so the quantity can decrease but cannot grow. Protocol revenue is directed into buying tokens from the market and burning them, which makes the supply deflationary in proportion to how much the protocol earns. Further utilities have been described as planned rather than live, including governance rights over protocol decisions, paying transaction costs in PTS instead of the native gas asset, and fee reductions scaled to holdings.

That is the appropriate depth for an article about a routing protocol. Anyone evaluating the token as an asset should read the project's own economic material and verify the contract address on-chain rather than relying on any third-party page, including this one.

9. The Piteas API and Widget

The routing engine is also exposed as infrastructure, which turns Piteas from an application into a component other applications are built on. This is the quieter half of Piteas and arguably the more strategically important one.

The swap API

The public API follows the same off-chain model as the interface. An integrating application requests a quote for a token pair and an amount, and receives the selected route along with encoded call data for the router contract. Executing the swap means forwarding that call data from a signer, with the accompanying value and a suitable gas configuration. The integrator does not implement routing logic, does not track pool state, and does not need to understand the graph search; they receive a transaction that is ready to send.

What this collapses is significant. Building competent routing in-house means indexing every pool on the network, keeping reserve data current, implementing the pricing formula of each pool type correctly, solving the split-allocation problem, pricing gas into the objective function, and then maintaining all of it as new venues launch and old ones change. It is a serious ongoing engineering commitment. Consuming an API instead reduces the same capability to a request and a signature.

Access is deliberately not an open public firehose. Quote generation requires substantial computation and network reads, so requests are granted to projects with a genuine integration need rather than issued without limit, and Piteas is explicit that the API is unsuitable for arbitrage bots hammering the endpoint for opportunities. This is an honest constraint rather than an artificial one: unlimited free quoting would degrade quality for the applications actually serving users.

The widget

For teams that want swapping inside their product without building an interface, the embeddable widget provides the trading experience as a component. A wallet can offer in-app swaps. A token project can put a buy interface on its own site instead of sending visitors elsewhere. A game or NFT platform can let users acquire the asset they need without leaving the flow.

The user-facing benefit is the elimination of a context switch, which sounds minor and is not. Every hop between applications is a point where users get confused, get distracted, or land on the wrong domain. Keeping the trade inside the application the user already trusts removes that exposure.

Because the widget uses the same engine, embedded swaps receive the same routing as the flagship interface. There is no degraded tier for integrators, which matters: an embedded experience that quoted worse prices would push informed users out to the main app and defeat its purpose.

What this means at the ecosystem level

When multiple wallets and applications on a network route through one engine, that engine becomes shared infrastructure rather than a competing destination. Its improvements propagate to every integration at once. A newly added venue improves quotes everywhere simultaneously, including in applications whose developers never knew the integration happened.

It also concentrates a meaningful amount of the network's routing decisions in one place, which is worth stating plainly rather than glossing over. The mitigating factor is the one that runs through the whole architecture: the engine can only propose, and every proposal is bounded on-chain by limits the user's own signature sets. Concentration of routing intelligence is not concentration of custody, and the difference is the entire point of the design.

10. Security and the Non-Custodial Architecture

Security in a protocol like Piteas is mostly a question of what the architecture makes impossible, because guarantees that depend on good behaviour are not guarantees at all.

The router contract

The router is the only component with authority to move tokens, and its logic is narrow by design. It receives a swap instruction specifying the source token, the destination token, the amount, the minimum acceptable output and the recipient, together with the call data describing the route. It validates the inputs, executes the route, measures how much of the destination token actually arrived, and compares that against the specified minimum. If the amount meets or exceeds the floor, it transfers the output to the recipient. If it does not, the entire transaction reverts.

Several properties of that flow are worth drawing out. The output is measured as a real balance difference produced by the swaps, not as a figure carried over from the optimiser's prediction, so the check tests reality rather than expectation. The recipient defaults to the sender, so a swap with no explicit destination cannot deliver funds anywhere other than the wallet that initiated it. Zero amounts and empty call data are rejected outright rather than handled ambiguously. And a failed minimum-output check reverts rather than filling at whatever the market happened to offer, which is the behaviour that turns slippage tolerance into a real limit instead of a suggestion.

The contract also includes an owner-controlled switch that can halt swap execution. Administrative controls of this kind are a genuine trade-off and should be described as one. A pause function is centralised authority, and in the wrong hands or through a compromised key it is a denial of service. It is also the only mechanism by which a team can stop a live protocol during an active exploit, and protocols without one have watched funds drain while holding no ability to intervene. The reason this particular trade-off is comparatively benign here is scope: pausing prevents new swaps, it does not seize anything, because there is nothing held to seize. The worst outcome is that you cannot trade, not that you cannot access your assets. Your tokens never left your wallet.

Atomicity as the core guarantee

Atomic execution is the property that most of the safety rests on. A route touching five pools across three exchanges either completes every step and delivers the output, or has no effect beyond the gas spent attempting it.

What this eliminates is the entire category of partial-failure states. There is no scenario in which your tokens made it three hops into a five-hop route and stopped. No stranded intermediate balance in a wrapped asset you did not want. No support process for recovering a half-executed trade. Multi-hop routing without atomicity would be reckless, since each additional hop would multiply the ways a trade could get stuck; with atomicity, hop count affects cost and nothing else.

MEV and sandwich resistance

A public mempool lets observers see pending transactions before they execute, and a large swap visible in advance invites a sandwich attack: buy ahead of it to push the price up, let the victim fill at the worsened rate, sell immediately after to capture the difference.

The minimum-output floor is the structural defence, and its logic is worth being precise about. A sandwich is only profitable to the extent the victim will tolerate a worse fill. The floor caps that tolerance at a value the trader chose. An attacker who pushes the price past it does not extract more value; they cause the transaction to revert and receive nothing for the attempt, having spent gas on both legs of a failed sandwich. The attack does not become impossible, but it becomes bounded, and the bound is set by the victim rather than the attacker.

Split routing adds a second, incidental layer. A trade divided across several pools presents no single large imbalance to exploit; an attacker must sandwich multiple pools simultaneously to capture the same value, multiplying their cost and risk while the available profit stays fixed. Routing chosen for output efficiency turns out to reduce extractable value as a side effect.

The practical implication for traders is that slippage tolerance is a security setting, not merely a convenience setting. Setting it very wide to force a stubborn transaction through is explicitly authorising a worse fill, and the gap you opened is the profit an adversary is permitted to take.

Open source, and what it does and does not provide

The contracts are published as open source, which is the baseline expectation for anything asking users to grant it token approvals. Anyone can read exactly what the router does with the authority it is given, and verify that the deployed bytecode matches.

It is worth being honest about what publication achieves. Open source does not mean audited, and audited does not mean safe. It means the code is available for review, which converts a promise into a checkable claim. Combined with a narrow contract that does one thing, this produces a review surface small enough for a competent reader to actually understand, which is a more meaningful safety property than a large complex system with a certificate attached.

The risks that remain

An accurate security picture includes what the architecture does not protect against.

Smart-contract risk never reaches zero. Open, narrow and reviewed code is far safer than the alternative, but no non-trivial contract is provably free of defects.

Token risk is entirely outside the router's scope. Piteas will happily execute a perfectly routed swap into a token designed to be worthless. Routing quality and asset quality are unrelated, and the trader owns the second one completely.

Front-end and phishing risk is the most common way people actually lose funds. A cloned interface can produce a signature request that drains a wallet, and Piteas has no visibility into a site it does not operate. Bookmarks and reading signature prompts are the defence.

Approval risk accumulates silently. Every unlimited approval you have ever granted, to any protocol, remains a standing authorisation. Periodic review and revocation is unglamorous and genuinely valuable.

Wallet and key risk is yours alone. Non-custodial means no operator can lose your funds, and it equally means no operator can recover them.

Non-custodial cuts both ways. Nobody can freeze your assets, and nobody can give them back.

11. Piteas Compared With Other Aggregators

Aggregation is a mature idea. The routing techniques Piteas uses were developed and proven on Ethereum, where high gas costs and severe liquidity fragmentation made optimal routing valuable enough to justify serious engineering investment. Understanding Piteas against that lineage clarifies what is standard practice and what is specific to its environment.

Against the established Ethereum aggregators

The architectural resemblance is close, and deliberately so. Off-chain route computation, on-chain execution through a minimal router, split and multi-hop path construction, minimum-output enforcement, gas-aware scoring: these are the components any credible aggregator has, because the problem has a known shape and the sensible answers have converged.

The differences are environmental rather than conceptual, and they cut in both directions. Multi-chain aggregators spread engineering effort across many networks, which necessarily means less attention per network; a chain-specific protocol can integrate the smaller venues that a multi-chain team would never prioritise, and on a network where those venues hold the only market for a long tail of tokens, that coverage is decisive. Conversely, the mature aggregators operate at a scale that funds larger security budgets and longer audit histories, and scale is itself a form of battle-testing.

The gas environment also shifts the optimum, as discussed at length earlier. Routing strategies that are uneconomic on an expensive network are routine on a cheap one, which means a PulseChain-native router should be more aggressive about splitting than its Ethereum counterparts, not merely a copy of them running somewhere cheaper.

Against swapping directly on a single PulseChain DEX

This is the comparison that matters for most people, because it is the actual alternative they are choosing between.

A single exchange quotes from its own pools. That is not a limitation its developers failed to overcome; it is what an exchange is. It cannot tell you that a better price exists elsewhere, and it has no commercial reason to look. The quote it gives you is correct and complete with respect to its own liquidity, and silent about everything else.

An aggregator sees every venue and can combine them. The logical consequence is worth stating carefully: a direct swap can never beat a well-implemented aggregated route, it can only match it, and it matches exactly when the best available route happens to be that single pool. When the direct venue is optimal, the aggregator returns that route. When it is not, the aggregator returns something better. The only asymmetry running the other way is gas, since aggregated execution can cost slightly more, which is why gas belongs in the scoring function.

The gap widens under three conditions, all of which are common. Larger trades relative to pool depth suffer more concentration cost. More fragmented pairs leave more value spread across venues. Long-tail tokens are frequently unroutable on any single interface but perfectly tradeable through a chained path. If your trading consists of small amounts in the deepest pairs on the network, you will observe very little difference. That is a statement about your trades, not about the router.

Against centralised alternatives

Covered above under trade economics, and the summary is that the comparison is mostly not about price. It is about custody, access and listing scope. A deep centralised order book may fill a large major-asset trade better. It also requires handing over your assets and your identity, and restricts you to the assets it chose to list. Which of those matters more is a question about what a trader is optimising for, and there is no universally correct answer.

12. Direction of Travel

Roadmaps in this sector are frequently exercises in optimism, so what follows is limited to direction that can be inferred from the architecture rather than restated from promotional material, and no timelines are invented.

Expansion to additional networks is the clearest strategic axis, and the reasoning is that the hard asset is transferable. The genuinely difficult work in building an aggregator is the routing engine: the graph model, the pool-type abstractions, the split-allocation solver, the gas-aware scoring. None of that is chain-specific. Porting it means integrating a new set of venues and deploying a router, which is real work but not the same order of difficulty as building the optimiser in the first place. Any team with a functioning engine has a strong incentive to reuse it, and the described intent to broaden network coverage follows naturally from that.

Continued integration of new liquidity sources is the ongoing baseline rather than a milestone. New venues launch, new pool designs appear, and depth migrates. An aggregator that stops integrating begins degrading immediately, because its quotes are only as good as its coverage on the day you ask.

On the token side, several utilities have been described as planned rather than delivered, including governance, paying transaction costs in the protocol token, and holdings-based fee reductions. The correct way to hold anything in that category is as intention rather than fact until it is live and verifiable on-chain, and that applies to every protocol equally.

The deeper trajectory is the one visible in the developer surface. A protocol that other applications route through becomes infrastructure, and infrastructure competes on reliability and coverage rather than on interface design. Every wallet and application that integrates the engine makes the routing layer more load-bearing for the network as a whole, which raises both the value of getting it right and the cost of getting it wrong.

13. Frequently Asked Questions

What is Piteas?

Piteas is a non-custodial decentralised exchange aggregator built on the PulseChain network. It holds no liquidity of its own. Instead it searches the liquidity available across PulseChain's automated market makers and routes each trade through the combination of pools that returns the most output to the trader, executing the whole route in a single transaction.

Is Piteas a DEX or a DEX aggregator?

It is an aggregator, though it behaves like a DEX from the user's side. A decentralised exchange owns liquidity pools and quotes prices from its own reserves. An aggregator owns no reserves and instead compares every venue on the network, then splits or chains a trade across whichever pools produce the best result. The practical difference is that a DEX can only offer you its own price, while an aggregator offers you the best price available anywhere.

Which blockchain does Piteas run on?

PulseChain, an EVM-compatible layer-one network with chain ID 369. Gas is paid in PLS, and the wrapped form of the native asset, WPLS, serves as the primary routing hub connecting most of the network's liquidity.

Is Piteas custodial? Does it hold my funds?

No. There is no deposit, no internal balance and no withdrawal. Tokens move out of your wallet, through the router and the underlying pools, and into the destination address within one atomic transaction. If the trade cannot satisfy the minimum output your transaction specified, the entire thing reverts and your funds remain where they were.

How does Piteas find the best swap rate?

A routing engine called Pathfinder models the network's liquidity as a graph in which tokens are nodes and pools are edges weighted by reserves, fees and gas cost. It evaluates direct routes, multi-hop routes through intermediate tokens, and split routes that divide one trade across several pools, scores each candidate by expected output after fees, price impact and gas, and returns the highest-scoring path as executable call data.

Why does the route pass through several pools?

Because concentration is expensive. Price impact in an automated market maker grows faster than trade size, so pushing an entire order through one pool means each incremental unit fills at a worse rate. Dividing the order across several pools keeps each portion in the cheaper part of its own impact curve, and chaining through a deeper intermediate pair can beat a shallow direct one outright.

Does Piteas charge a fee?

Your cost consists of the swap fees taken by the pools your route passes through, which go to those pools' liquidity providers, plus the PulseChain gas needed to execute the transaction. Because aggregated routing frequently returns more output than a single-pool swap would, the improvement often covers the extra gas an aggregated route consumes.

Which wallets work with the Piteas app?

Any standard Web3 wallet with PulseChain support, including MetaMask, Rabby, Trust Wallet and WalletConnect-compatible mobile wallets. The requirements are that the wallet is pointed at chain ID 369 and holds some PLS for gas.

Does Piteas require KYC or an account?

No. There is no registration, no email address, no password and no identity verification. Connecting a wallet is the whole onboarding process, and the wallet is the identity.

Is Piteas safe to use?

The architecture removes the largest historical category of loss by never holding user funds, and the on-chain minimum-output check means a trade either delivers what was quoted or reverts entirely. The risks that remain are the ordinary ones of on-chain trading: smart-contract defects, worthless or malicious tokens, phishing front-ends, and over-broad token approvals left in place after trading.

What is the difference between the main Piteas site and the app?

The main Piteas PulseChain website is the public front page and is purely informational. The app subdomain is the Piteas app itself, the trading interface where wallets connect and transactions are signed. Both are official, and the app is the one worth bookmarking, since it is the surface that handles funds.

How do I make sure I am on the real Piteas website?

Navigate there once by carefully typed address, verify the domain character by character, then bookmark it and use only the bookmark from then on. Treat sponsored search results as untrusted, and read every wallet signature prompt before approving it. A cloned interface must eventually ask you to sign something, and the prompt is where the mismatch becomes visible.

Why did my swap fail?

Usually one of four things: the quote went stale because the chain moved before your transaction was included, your slippage tolerance was too tight for the token's volatility, your wallet ran out of PLS for gas, or the token approval was missing or too small. Refreshing the quote resolves most failures, and a reverted swap returns your tokens, minus the gas spent on the attempt.

What slippage tolerance should I use?

It depends on the token rather than on a universal number. Deep, stable pairs execute reliably on tight tolerances. Thin or fast-moving tokens genuinely need more room, because their prices move that much between quoting and inclusion. Widening the tolerance is authorising a worse fill, so it should be a deliberate decision about a specific token, not a reflex after a failed transaction.

Can any token be swapped on Piteas?

Any token with a reachable liquidity path on PulseChain can be routed, including long-tail tokens with no direct pair against the token you want, because the route can chain through hubs such as the wrapped native asset or a stablecoin. Tokens not in the default list can be added by contract address, which is a capability worth using carefully, since a fake token with a legitimate-looking symbol is trivial to deploy.

How does Piteas reduce MEV and sandwich attacks?

The minimum-output value enforced on-chain caps how much a sandwich attack can extract, because any manipulation pushing the result below that floor causes a revert rather than a bad fill, leaving the attacker with wasted gas. Splitting a trade across pools compounds the effect, since an attacker would need to sandwich several pools at once to capture the same value.

Does Piteas have an API for developers?

Yes. A quote endpoint returns the selected route together with ready-to-send call data for the router contract, so an integrating application can execute an optimally routed swap by forwarding that call data from a signer. Access is granted to projects with a real integration need rather than opened without limit, and it is explicitly not intended for arbitrage bots.

Can Piteas be embedded in another application?

Yes. A configurable widget lets wallets, token projects and other dApps embed the swap experience directly in their own interface, using the same routing engine as the main application, so users never have to leave the product they are already in.

What is the PTS token, and do I need it?

PTS is the utility and governance token associated with Piteas, with a fixed maximum supply of 100,000,000 and no minting function, and protocol revenue is used to buy and burn it, making the supply deflationary. You do not need it to trade. Swapping requires only the token you are selling and enough PLS for gas.

Is there a mobile app for Piteas?

There is no native download. The interface is a responsive web application, so it runs in a mobile browser or inside a wallet's in-app browser with the same routing engine and the same features as on desktop. The absence of an installable package is also a security benefit, since there is no app-store listing for an impersonator to imitate.

Does using an aggregator hurt the exchanges it routes through?

No, it sends them volume. A trade routed through four pools pays fees to all four, and those fees reach their liquidity providers exactly as they would have if the trader had arrived directly. What changes is the distribution: flow goes to whichever pools are priced most competitively rather than to whichever interface is best known.

14. Glossary

Aggregator. Software that searches multiple exchanges and routes a trade through the combination of pools returning the most output. It holds no liquidity of its own.

Atomic transaction. A transaction whose steps either all succeed or all have no effect. It removes any state in which a multi-step trade is half-finished.

Automated market maker. An exchange design in which trades price against pooled reserves via a formula rather than matching against an order book.

Call data. The encoded instruction a transaction carries to a contract. Here it describes the exact route: which pools, in what order, with what amounts and what minimum output.

Liquidity pool. A contract holding reserves of two or more tokens against which trades execute. Its reserves determine both price and available depth.

MEV. Maximal extractable value: profit available to whoever can influence transaction ordering, most familiarly through sandwich attacks around a pending trade.

Minimum received. The floor on output that your transaction specifies and the contract enforces. Falling short of it causes a revert instead of a worse fill.

Multi-hop route. A route passing through one or more intermediate tokens, used when no direct pair exists or when the chained path simply returns more.

Price impact. The price movement your own trade causes in the pools it passes through. Not a fee charged by anyone, and frequently the largest real cost of a trade.

Router contract. The on-chain component that executes a route, verifies the output against the minimum and delivers the result, or reverts.

Slippage tolerance. The gap you are willing to accept between the quoted output and the delivered output. It sets the minimum received, which makes it a security setting as much as a convenience one.

Split route. A trade divided across several parallel paths in one transaction, used to avoid concentrating volume in a single pool and paying escalating price impact.

Token approval. Authorisation for a contract to move a specific token from your wallet. Required once per token by the token standard, and worth revoking when no longer needed.

15. The Verdict

Piteas occupies a narrow position and occupies it well. It is not attempting to be an exchange, a lending market, a launchpad or a financial supermarket. It answers one question, and it answers it with more rigour than the question superficially appears to deserve: given this input, what is the maximum possible output, and by which path.

That narrowness is the strongest thing about it. A protocol with one job has one surface to secure, one thing to be measured against, and no ability to hide poor performance behind adjacent features. Either the quote is better than the alternatives or it is not, and the trader can check.

The engineering underneath is more substantial than the interface suggests, which is the correct arrangement. Modelling a network's liquidity as a graph, evaluating direct, chained and split paths at the specific size being traded, scoring them honestly against fees, price impact and gas, and returning an executable answer fast enough to feel instantaneous is genuinely difficult work. Presenting the result as two fields and a button is what that work is for.

The security posture is grounded in structure rather than assurance, which is the distinction that matters. Funds are never held, so they cannot be lost by an operator. Execution is atomic, so trades cannot get stranded halfway. The output floor is enforced on-chain against a measured balance, so the off-chain optimiser can propose but never overreach. Contracts are open, so claims are checkable. What remains uncovered is the part the trader owns: which token you chose, which site you were actually on, and what you agreed to when you signed.

For anyone trading on PulseChain, the argument for routing through an aggregator is close to arithmetic. A single exchange can match the best available route only when it happens to be the best available route, and it can never beat it, because it cannot see past its own pools. The gap is small on deep pairs at modest size and considerable on large trades, fragmented pairs and long-tail tokens. Whether that gap matters is a question about the trades you make. Whether it exists is not really in question at all.