Infinity logoInfinity acquisition brief · updated 2026-07-21
For acquirers

One purchase. Both venues.
A finished terminal.

Infinity is a production Telegram trading terminal covering Hyperliquid perpetuals, spot and copy-trading plus Polymarket prediction markets — written in Rust by a single author, proven on mainnet with real funds, and sold as a complete, transferable package. This page is the brief a buyer can forward to their technical reviewer.

By the numbers

Every figure below is re-checkable during due diligence — nothing is rounded up for marketing.

77,328 lines of Rust in src/ 110,801 incl. vendored SDKs 813 tests green in the merge gate 74 forward-only migrations 8 languages — EN RU ZH ES TH KO JA PT 2 venues · 18+ markets traded 94 mainnet fills on the public dossier account

What the sale includes

Architecture

Five layers with a single dependency direction — Telegram surface → use-cases → venue adapters → storage — over a pure domain core. Money movements follow a strict tri-state contract: every fund-moving call returns Confirmed, Unconfirmed or Failed; ambiguous outcomes are frozen and escalated, and only provably-unsent operations are ever retried. Money paths are idempotent end-to-end: deterministic client order IDs, fill de-duplication, mark-first settlement, clear-before-send payouts.

The interactive layer map lives on the main page; the full picture opens under NDA.

Custody model — stated plainly

Each account gets its own dedicated on-chain wallet, generated server-side and never pooled. Private keys are stored AES-256-GCM-encrypted under an operator master key; users can export their key at any time, and the operator holds offline export and rotation tooling. Every key decryption is written to the audit log at Critical severity.

This is encrypted per-account custody with self-export — the same model the largest Telegram trading bots run at scale. It is not a trustless design, and we never describe it as one: operator key hygiene is part of the trust model, and the documentation says so.

Monetization rails

All fee rails are built, wired and exercised on mainnet. Receiver addresses are set per deployment via environment — they switch to the buyer's wallets on day one.

RailMechanismShipped rate
PerpetualsHyperliquid builder code, attached to every order0.05%
Spot & HIP-4 outcome marketsBuilder code0.25%
Polymarket predictionsCLOB builder fee on taker orders0.50%
Copy-tradingPerformance fee on realised profit, high-water-mark9%

Honest status: the product is pre-revenue. The rails above are live and proven with real funds; what the asset lacks is distribution, and that is exactly what a buyer with an existing audience supplies. Builder-code revenue is independently verifiable on public ecosystem dashboards, so post-acquisition earnings need no trust in the seller's screenshots.

IP & licensing

The core is proprietary (LicenseRef-Proprietary, publish = false), written solely by one author — no contractors, no copied code. Dependency hygiene is CI-gated with cargo-deny and cargo-audit.

Two SDK forks are vendored and disclosed up front: the Polymarket SDK fork is MIT; the Hyperliquid SDK fork carries MPL-2.0 obligations at file level. Both forks document every patch in a FORK.md. A server-side bot does not distribute these files to end users, and the full licence memo is part of the data room — disclosed before you find it, not after.

Acquisition process

  1. Intro call + NDA. Scope, questions, mutual fit. The NDA template is ready.
  2. Live walkthrough. Screen-share of the bot trading on mainnet, then the data room: architecture, security memo, licence memo, known-issues disclosure.
  3. Escrow. Funds held at Escrow.com (or an escrow agent of your choice). 100% cash at close — no earn-out gymnastics unless you want them.
  4. Transfer runbook. Executed together in one session: repository transfer, BotFather handover with immediate token rotation, master-key rotation with the offline tool, domain auth-code, database and infrastructure handover, builder-wallet key escrow so accrued approvals survive the transfer.
  5. Post-close. Written runbook stays with you; hand-over support from the author to get your team fluent.

Questions buyers actually ask

Is there revenue today?
No — pre-revenue, and the listing says so everywhere. What you are buying is 6–9 months of senior Rust engineering with both venues already integrated, fee rails already wired, and mainnet proof that the money paths work. Revenue starts when your audience meets these rails.
Why is it for sale?
Solo author, finished product, no distribution. The asset's next chapter needs an operator with users — building an audience from zero is a different business than engineering, and the honest move is to sell to someone who already has one.
Who holds the keys?
The operator, encrypted — see the custody section above. Users can export theirs at any time. If you want user-held key derivation, the storage layer is the single place to change.
What does it cost to run?
Today the entire stack — bot, Postgres, Redis, this site — runs on a single small VM. Costs scale with usage, not with idle time.
How fast is the transfer?
The runbook itself executes in under a day once escrow funds. The pace of NDA, review and escrow is up to you — the seller side is prepared in advance.

Start the conversation

Serious inquiries get the data room and a live screen-share of the bot trading. Escrow-friendly, NDA on request.