Basis: what to build better
Research and product blueprint. 5 September 2026.
For a founder assessing a practical crypto product. Scope: the live Basis site, its linked executor, the arbitrage mechanism, and a stronger product and token model. This is a source review and design analysis, not a contract audit or a forecast of investment returns. Proposed figures are illustrations, not observed business performance.
1. Assessment
Your assessment is substantially right: the core execution technology is conventional and compact. The recommendation is to build a service for token communities that returns recovered arbitrage surplus to their liquidity providers, charges a transparent performance fee, and can allocate part of that fee to a main token. The reason to adopt it should be a measurable improvement in pool economics.
What is actually there
Basis's homepage describes a hook executing within a trader's swap. Its strategy page describes an external bot submitting competing transactions. These are different execution architectures. The homepage showed token and vault addresses as not yet deployed when inspected. That limits what can be established about the complete product.
| Evidence | What it establishes |
|---|---|
| Verified XpoolExecutor source | A 120-line file, including interfaces and comments, implements owner-authorized, atomic routes that return to the starting currency. Positive swap surplus goes to the owner. |
| A successful transaction | The PoolManager paid the operator 22.801661 USDG. The transaction used 181,905 gas; its fee was 0.00007439114118 ETH, displayed as approximately $0.18. |
| Distribution logic | The executor contains no BASIS buyback, burn, or vault logic. Separate transactions could implement these, but this contract does not enforce them. |
The sampled token address matches Robinhood's canonical USDG. Working execution is therefore supported by more than a landing-page claim. However, one payout does not establish aggregate net profit, where the dislocation originated, or that profits funded burns. Source comments refer to a testing harness; controlled experiments and independent market opportunities need separate accounting. This is an evidence requirement, not a finding of misconduct.
The competitive question is adoption. Another competent team can reproduce this execution pattern. A stronger business needs partners who provide liquidity or order flow because the service leaves them better off, plus a ledger that makes the benefit verifiable.
2. The mechanism, without the mystique
The opportunity is a disagreement between executable exchange rates. A token can trade in a COIN/USDG pool and a COIN/stock-token pool. A change in the stock token's dollar price can change the second pool's implied dollar price for COIN before the pools rebalance.
A complete trade must close the currency loop
Suppose, purely illustratively, the available quotes permit:
100 USDG -> 100 COIN -> 1 stock token -> 102 USDG
That is two units of gross surplus before any omitted fees and costs. Merely finishing with a stock token valued at 102 dollars is different: a reference valuation does not repay a USDG obligation. The third conversion must be available at an executable price. Quote each leg at the actual proposed size.
Uniswap v4 can account for multiple swaps internally and settle their net balances at the end of an unlock callback. Every currency debt must be resolved before it finishes. This enables some closed arbitrage routes without pre-funding the full notional. It does not create free inventory or make any externally priced route executable.
Direction follows price, not the asset's label
If the stock rises and the stock pool now values COIN more highly, buy COIN in the cheaper cash pool, sell into the richer stock pool, then convert the stock proceeds back to cash. If the stock pool is cheaper, reverse the route. A strategy that always buys the stock pair excludes the opposite opportunity.
Use units that cannot silently invert the trade
If r is stock tokens per COIN and p is dollars per stock token, the implied
price is P = r * p. If r is COIN per stock token, it is P = p / r.
Basis's prose defines the latter units while displaying the former
multiplication. This is a documentation inconsistency, not evidence that its
unpublished bot makes the same mistake.
For v4, also normalize token ordering and decimals. The squared square-root-price value gives a raw token1/token0 ratio; human-unit conversion requires the decimal adjustment. A ticker string is not an asset identifier: use chain ID and canonical token address.
Evaluate the complete route
Let F(q) be the final amount of starting currency returned by the complete
route for input q, including its actual pool fees and price impact. Choose a
size that maximizes F(q) - q - execution costs. Require the conservative
result to exceed a margin for uncertainty. A spot-price percentage alone cannot
select that size.
3. Where the economics get difficult
Reverting protects swap state; it does not eliminate spending
A reverted transaction can still consume gas. Positive surplus measured inside the executor also excludes the cost of other failed attempts and the operation of the bot. A profitable successful trade and a profitable business are separate measurements.
For a batch of attempts, use:
Net capture = total swap surplus - all attempt fees - direct costs
Then deduct hosting, engineering, distribution, and other operating costs to estimate business profit. When converting ETH fees to USDG for reporting, disclose the price source and timestamp. Preserve losses across reporting periods; resetting a dashboard must not erase them.
A large displayed gap can disappear after fees
In an idealized route with a 4% gross rate advantage and three input-fee factors of 0.997, 0.997, and 0.9995, 1,000 units return approximately 1,033.25. The surplus is 33.25 before gas and any unmodeled impact, rather than 40. If a quote already incorporates fees, do not subtract them again.
Adding fee percentages is only a small-fee approximation. With two 20% input
fees, the no-impact gross exchange-rate advantage must exceed
1 / (0.8 * 0.8) - 1 = 56.25%. A 40% gap is insufficient under that model.
Real hook charges can use different fee semantics, so simulate the actual
contracts.
Depth determines useful capacity
The cheapest visible unit is not the average price for a large purchase. In concentrated liquidity, crossing a tick can materially alter the next unit's price and available liquidity. More nominal pools can mean less depth per route. Creating extra pools simply to manufacture gaps can increase costs for the same users whose liquidity funds the system.
Arbitrage has a payer
When a pool quotes stale prices, an arbitrageur trades against its inventory. Pool fees compensate liquidity providers for some of this, but recovering surplus for an unrelated token does not automatically improve their returns. Compare LP wealth, including inventory value and distributions, against an appropriate alternative. A positive rebate can coexist with a losing LP position.
The principal unresolved evidence
The full, reconciled opportunity ledger: every attempt, route, related-wallet cost, realized payout, and subsequent distribution. Basis's linked Dune query could not be inspected because the browser remained at a security-verification screen. Published volume and gap figures therefore should not be multiplied into a revenue forecast. The strategy also labels fine-grained latency rows as interpolated; they are not direct measurements of every timing point.
4. The product I would build
A pool service that pays recovered value back to the communities supplying liquidity. Start with one launch platform or a few existing token communities. Offer a clear pool dashboard and a performance-based service. The customer proposition is: see what your market earns, what execution costs, and what returns to your liquidity providers.
| Product choice | Advantage | Constraint | Decision |
|---|---|---|---|
| Standalone arbitrage bot and burn token | Fastest technical experiment | Public routes are copyable; little reason for other communities to promote it | Use as an internal pilot |
| Partner pools with surplus distributions | Partners receive a measurable benefit; fees can grow with adoption | Needs liquidity partners and accurate allocation | Recommended product |
| Auction of execution or management rights | Competing operators may pay more than one in-house bot earns | Requires enforceable rights and real bidders | Add only after evidence |
Keep the first market configuration narrow
Support an existing USDG market and, where there is real demand and depth, one stock-token market. Reuse available stock/USDG liquidity for the closing leg. Expand only when a new market improves useful trading capacity. A long list of stock tickers is a poor substitute for executable depth.
For traders, the interface should show expected output, minimum output, total fees, and available routes. For LPs, show their position value, trading fees, recovery distributions, and performance against a disclosed benchmark. For creators, show funded liquidity, volume quality, service cost, and actual distributions. Internal terms such as callbacks and square-root prices belong in technical documentation.
Win distribution through the party who creates pools
A launcher integration can make the service available when markets are created. Existing-pool integrations can start with a bot and transparent payouts, while new hooked pools require an explicit liquidity decision. Do not depend on users migrating purely to support the main token.
Precedents, carefully read
The am-AMM research proposes auctioning temporary pool management, with rent paid to LPs; it also identifies sandwich and centralization tradeoffs. MEV Blocker returns 90% of the winning bid to the originating user, not 90% of all searcher profit. These support the principle of making execution providers compete for value that can be returned to users. They do not establish ready-made compatibility with this chain.
A generic better-price interface is also not an empty market. Uniswap's current documentation lists Robinhood Chain in its RFQ and exclusive Dutch auction model. Differentiate through partner-pool economics and verifiable distributions, then use existing routing where suitable.
5. A small architecture that can grow
Version one needs four components. An offchain watcher maintains relevant pool states; a route simulator estimates complete execution; a minimal onchain executor enforces settlement and limits; a public ledger reconciles every attempt and distribution. Keep customer liquidity outside the bot's discretionary custody where the chosen pool design permits it.
| Component | Concrete responsibility |
|---|---|
| Watcher and simulator | Index allowlisted pools, update affected routes, normalize units, size trades locally, reject routes without a viable closing conversion |
| Executor | Validate caller or signed authorization, deadline, route, supported tokens and minimum surplus; finish in the starting asset |
| Revenue distributor | Receive realized proceeds, apply the published allocation, expose recipient balances and distribution events |
| Ledger and interface | Reconcile transaction receipts, gas, failures, proceeds, allocated fees and executed buybacks; link each aggregate to evidence |
Improve performance before introducing new machinery
Recompute only routes affected by a pool update. Cache topology, fee settings, tick state and decimals with explicit invalidation. Simulate locally instead of repeatedly requesting remote sizing searches. Limit competing submissions by their expected incremental profit, not by a fixed preference to send more transactions. Maintain a daily execution budget and an automatic stop on abnormal failure rates.
Hooks are a later distribution integration
A v4 hook is fixed when its pool is initialized; it cannot simply be attached to thousands of existing pools. One hook can serve many new pools, but it triggers only for pools configured with it, and routing through those pools is not guaranteed. This is a customer-acquisition constraint as much as a coding constraint.
In a hooked version, preserve the trader's signed minimum output and test the entire transaction, including incremental gas. If optional surplus capture fails, isolate that failure or skip capture so that it does not unnecessarily break the underlying swap. Avoid a catch mechanism that leaves unresolved token debts. Hook ordering, nested callbacks, partial fills, and accounting need dedicated invariants and review.
An auction needs something enforceable to sell
Public arbitrage opportunities are visible to competitors. Posting an auction does not prevent someone else taking them. Auction a genuine permission or economic advantage supplied by a partner pool, or filling rights in an appropriately signed user order. Start with one operator; introduce competing operators when measured surplus justifies the integration and independent bidders actually participate.
Separate execution from buying the main token
Accumulate a disclosed allocation in a distributor and execute bounded buybacks separately. A thin main-token market or a failed purchase should not stop profitable pool settlement. Show pending allocation separately from completed purchases and supply destruction.
6. Give the main token a clear economic connection
The execution engine does not need a new token. A main token can receive a defined economic benefit from the service, but inserting it into every trade adds friction without improving the arbitrage. Let customers use the service because its results are useful. Let token demand, if any, arise from disclosed revenue-funded purchases and other defensible benefits.
An illustrative allocation of 100 USDG of capture remaining after direct execution costs:
| Recipient or purpose | Allocation | Meaning |
|---|---|---|
| Participating LPs | 80 USDG | Recovery credited to the pools providing the opportunity, under a disclosed attribution rule |
| Service operations | 10 USDG | Revenue retained to support the service; it is not necessarily operating profit |
| Main-token purchases | 10 USDG | Half of the 20% service fee; purchases and any actual burns are independently traceable |
The 80/10/10 split is a starting hypothesis, not an optimized rate. A smaller service fee may attract more liquidity. A larger nominal burn share can weaken the product if it leaves LPs with too little value or the operator unable to cover costs. If the execution ledger is negative, there is no earned revenue allocation; published budgets should define who bears those losses.
Enforce the part that can be enforced
Route proceeds to a distribution contract rather than relying on discretionary transfers from an ordinary owner wallet. Put allocation rules, recipients and administrative powers in public view. Offchain costs remain a trust boundary: cap reimbursable costs or use a transparent fixed/operator-bid fee model. An arbitrary cost deduction can otherwise consume the entire supposed surplus.
For routes involving several partner pools, specify how credit is divided. A simple fixed split is easy to audit but approximate. A measured contribution model may be fairer but is more complex and can be gamed. This is a real design choice; claiming to return value without specifying the beneficiary calculation leaves the product incomplete.
Publish a dollar budget, not a promised price effect
In this illustration, 1,000 USDG of daily net capture permits 100 USDG of daily purchases. Thirty identical days would permit 3,000 USDG. Those assumptions are not a forecast. Token issuance, unlocks, seller demand and purchase slippage can outweigh that demand. Burning existing tokens is not automatically a reduction in total outstanding supply if new issuance exceeds burns.
A later LP receipt could represent a proportional, redeemable claim on a defined pool position. That gives tokenization a concrete meaning. A project coin merely traded against a stock token does not thereby become redeemable for shares or acquire stock backing. Keep the LP claim, project coin and main service token distinct in the product description.
The test is whether customers would still use the pool service if they never bought the main token. If the answer is yes and the service produces distributable revenue, the token has a more credible connection to activity. It still has no guaranteed market value.
7. Prove it before scaling
Run a narrow pilot with explicit stop conditions. Choose a few liquid routes and one community partner. Follow simulation with a budgeted, reviewed live experiment. Include market-open, after-hours and weekend periods. Fourteen days is an initial measurement window, not proof of durability.
| Test | Decision it should resolve |
|---|---|
| Complete net execution ledger | Does revenue survive all successful and failed transaction fees, rather than only selected winning trades? |
| Opportunity provenance | Does the result persist after excluding self-induced dislocations, related-wallet transfers and any unreconciled funding? |
| Capacity and concentration | Does increasing trade size improve net dollars, and do results survive removing the largest day or a single dominant pool? |
| Customer outcome | Do LP economics and trader execution improve against an appropriate control, including extra gas and inventory changes? |
| Adoption | Does a partner keep meaningful liquidity or routing after introductory incentives end? |
| Distribution integrity | Can an outsider reconcile earned proceeds, cost deductions, recipient credits, purchases and burns? |
Predefine a maximum experiment loss and a minimum economic hurdle. Continue only if conservative measured revenue can cover the intended service model and partners prefer the outcome. If public-route arbitrage is profitable but partners do not value the service, operate it as a trading business. If neither is true, a token launch will not fix the missing economics.
Effort
The core is quick; a dependable service takes longer. For an experienced EVM developer: days for a demonstrator, several weeks for a monitored pilot, and further weeks or months for a hardened service. External review, legal work and acquiring liquidity partners are additional work.
Three integrations deserve explicit handling
- An oracle is a reference price, not a standing promise to buy a stock token at that price.
- Robinhood's stock-token feeds incorporate the shares-per-token multiplier; applying it again would misprice the asset.
- Feeds update on the documented market schedule and can pause for corporate actions. Check freshness and status rather than treating every unchanged price as an opportunity.
Robinhood describes its stock tokens as debt securities giving economic exposure, not ownership rights in the underlying issuer, and limits direct primary issuance to authorized participants. If offered in Australia, pool receipts and revenue-linked tokens also need assessment as a complete arrangement: ASIC considers actual rights, benefits, marketing and use, not simply the label "utility token." Those constraints affect what can be offered, even when the contracts are straightforward.
The build I would choose
A minimal executor, a reconciled ledger, one pool partner and a fixed performance fee. Add hooks when adoption supports them, auctions when bidders support them, and a revenue-connected token when revenue supports it.
First decision gate
Does measured profit survive all execution costs, and does a real pool partner benefit enough to keep using it?