Gyblos: an open market for intelligence

Litepaper, draft 0.20.1. A living document: it is updated as the protocol is built and every claim is marked as built, tested or planned. Not financial or legal advice.

Two kinds of "token" appear in this paper. Inference tokens are the units of text a model reads and writes. GYB is the provisional name of the planned Gyblos network token, which has not been issued. When the paper says "intelligence", it means inference tokens.

Abstract

Access to AI is becoming access to opportunity, and it is unevenly distributed: frontier inference needs a credit card, an account with a lab and the right country. Meanwhile, idle capacity that could serve it sits in gaming PCs, Macs, servers and, soon, phones, TVs and cars.

Gyblos is building a permissionless, peer-to-peer market where anyone will be able to sell, buy or give away inference. Buyers will pay per inference token in USDC on Solana through payment channels, keep control of their funds and get unused deposits back; refunds of unused deposits have been tested on Solana devnet with a test token (§8). Sellers will set their own prices and pay a single 3% protocol fee (initial value). Trust is designed to come from measurement, not identity: there is no KYC, every seller is an address with an automatic service reputation, and open-weight models will be able to earn a verified-model seal from statistical audits. The network will launch with USDC payments and the 3% fee. A network token, GYB, is planned for a later phase, after legal review, with no date set; it has not been issued. It is designed to reward measured honest service, locked and released gradually, and never to be paid for raw volume.

1. Vision: intelligence as a commodity

Our mission is to make intelligence accessible to everyone, by letting anyone produce it, sell it or give it away.

Inference tokens are becoming a basic good, closer to electricity or bandwidth than to software. Whoever can produce them can sell them, and whoever needs them should be able to buy them in any quantity, from anywhere, without permission.

We expect production to spread to every device with a chip. Today the producers are GPUs in homes and data centers. Next are laptops and phones while they charge, and later TVs and parked cars. Each one can be a small producer of intelligence.

Gyblos is building the market layer for that world, for three kinds of participant:

• Those who sell. Any device owner will be able to sell idle capacity.
• Those who buy. People and AI agents will get intelligence with nothing more than a wallet and a few cents of USDC.
• Those who give. Producers will be able to donate capacity to people, schools and communities that would otherwise have no access. People without access to AI risk becoming the illiterate of the future; a market that also lets intelligence be given away is part of the answer.

2. The problem

1. Access is gated. Cards, accounts, regions and minimum purchases exclude billions of people and every autonomous agent.
2. Idle supply has no market. Home hardware cannot easily sell: NAT blocks incoming connections, payments need a company and buyers have no reason to trust an anonymous node.
3. Buyers cannot see what they get. A Stanford audit (ICLR 2025) found 11 of 31 Llama endpoints serving outputs that differ from the reference weights. Routers and P2P markets mostly do not check.
4. Incentives get gamed. Networks that reward volume pay people to buy from themselves, and wash trading follows.

3. How Gyblos works

Sections 3 to 7 describe the design. Section 8 shows what is built, tested or planned.

A session in four steps:

1. Discover. The proxy reads seller identities from the 8004 registry on Solana and fetches signed offers (model, price, region, data policy).
2. Open. The buyer locks a budget in a payment channel. The ceiling is enforced on-chain, so no seller and no prompt injection can raise it.
3. Use. Requests go straight to the seller; prompts never pass through Gyblos servers. Payment is metered per inference token, with signed vouchers (MPP sessions) or per call (x402 upto).
4. Settle. The seller settles on-chain; the program pays the seller, takes the fee and refunds the unused deposit in the same transaction.

Home sellers are first-class: connectivity through NAT uses hole punching with community relays as fallback (planned).

3.1 Sell with what you already have (planned)

• One node, two ways to run it. The same Gyblos node runs as a desktop app, where you choose an engine and a price and press one button to start selling, or headless on a server or VPS from the command line. Buyers see the same offer either way.
• Any engine, by URL. A seller can paste the address of any API compatible with OpenAI or Anthropic: a local Ollama, llama.cpp, vLLM or LM Studio, a rented GPU or a cloud API the seller already pays for. Running the engine, and having the right to resell it, is the seller's responsibility.
• The node checks what the engine can prove. When it connects, it detects whether the engine reports usage, returns log-probabilities and can be cancelled, and it publishes that in the offer. Engines with a native integration can go further and prove which exact model they serve.
• The buyer side is the same button. Buyers press connect and their tools use the network; a phone app works as a chat that pays the network directly.

4. Trust without identity

Gyblos never asks who you are. The network sees addresses. Trust is built from three things that can be checked without personal data.

4.1 Automatic service reputation

The buyer's proxy measures every purchase: whether the answer arrived complete, the inference tokens received against those charged, latency and throughput. Together with public payment events, this produces a service score that anyone can recompute from public inputs and a published formula.

Faults multiply the score down: ghosts (taking a deposit and not serving), repeated overcharging across distinct buyers and circular volume. Measurements are published in aggregate, per session or per day, with anomalies flagged immediately, so a buyer's activity is not exposed purchase by purchase. Manual star ratings are not used.

4.2 What a buyer can check

For open-weight models, auditors recompute random positions of real responses with the public weights and run a statistical test (LOGIC, open source, MIT), plus canary prompts. Offers that pass will carry a verified-model seal (planned). The seal proves the model, not the person. Closed models can be sold under the seller's responsibility, but they cannot earn the seal.

Every offer will show one of three levels (planned). They describe the model and the usage, never the person or the provider: Gyblos does not verify identities.

Buyers can filter by level. Sellers who only paste a URL can still sell, and those who run an engine that proves more earn a stronger badge.

4.3 Optional stake (planned)

A seller will be able to stake USDC in proportion to its monthly sales. Stake is designed to accelerate GYB rewards, unlock more simultaneous capacity and, later, a fee discount. It would be slashed on objective faults or a failed audit, and the slashed amount would compensate affected buyers first. Stake never raises the reputation score, so capital cannot buy trust.

Optional public signals such as a verified domain, a .sol name or address age appear as badges, never as requirements.

5. Economics

• Sellers set prices. Gyblos does not price inference.
• One fee for everyone: 3% of each settled payment (initial value), included in the price the buyer sees and split automatically by the channel. Charged from network launch.
• Buyers pay only what they use; the rest of the deposit returns at settlement.
• Designed for competitive prices. Sellers compete on price, home sellers can run on hardware they already own, and planned token rewards could let sellers price lower without paying buyers to trade with themselves. Prices have not been measured against other services yet, and prices supported by rewards may rise as emission declines.

A managed gateway (planned), for those who prefer an API key and nothing to install, will be a separate custodial route with a 5.5% fee (initial value).

6. The GYB token

6.1 Design

GYB has not been issued and is not part of the network launch, which starts with USDC payments and the 3% fee. GYB is planned for a later phase, after legal review, with no date set. Everything in this section is a planned design, subject to legal review before issuance, and nothing in this paper is a statement about the token's value.

Inference will always be paid in USDC. Nobody will need GYB to buy or sell.

6.2 Token parameters

Supply, emission and allocation parameters will be published after the legal review. The planned design ties emission to verified usage rather than to a fixed schedule, and a buyer wallet would count for nothing until it has spent with at least 3 distinct sellers over at least 2 epochs.

6.3 Why it resists farming

We modeled a network of 40 home sellers, 15 cloud sellers and a 20-node farm with fake buyers (an internal model, to be published with the design records listed in the sources).

• With a fixed emission schedule, rewards would bear no relation to real service, so farming would pay. Tying emission to verified usage removes that surplus.
• Without KYC, per-owner caps do not work, because a farm just splits into more wallets. Weighting buyers does: in the model, fresh sybil wallets weigh zero and the farm earns nothing.
• A farm that "seasons" its buyers has to spend real money with honest sellers first. That makes farming far less attractive than in a fixed schedule, and the spending itself creates real demand for the network.
• Locked rewards would act as stake that sellers never had to deposit: in the model, a cheater detected in the first month forfeits about 80% of what it earned.

The model's inputs are assumptions and will be recalibrated with pilot data. Its results are not price expectations.

6.4 Audits

Audits will be paid from a share of rewards reserved for audits, in three planned stages: first Gyblos audits openly (its audit rewards go to the treasury, not the team); then sellers audit each other, randomly assigned among nodes serving the same open-weight model and never between nodes of the same owner, with disputed results re-audited; finally, open auditors with stake.

7. Giving intelligence away

A market should also let intelligence be given. Planned mechanisms, to be designed with the community:

• Sponsored channels. Anyone can fund a payment channel for someone else, such as a student, a school or a nonprofit, with a ceiling and an expiry. The recipient uses inference without holding crypto.
• Free offers. A seller can publish capacity at price zero, with no payment channel, for anyone or only for chosen recipients, with per-buyer limits and a daily cap. To keep free service from being used to farm, it counts toward reputation only when served to established buyers and earns no token rewards, or only a small capped amount.
• Access fund. Part of the ecosystem rewards and voluntary donations fund access in regions and communities without it.

The hard part is preventing free capacity from being captured by bots. Sponsors choose recipients, budgets are capped and access programs are run by people who know the communities they serve.

8. Status and roadmap

Paid container connectivity tests. Separate buyer and seller containers completed paid inference over a native encrypted peer connection. The buyer verified the signed offer and remote node identity, independently recounted delivered tokens, and reconciled on-chain charges and returned deposits. The seller's model engine and facilitator remained accessible only on its loopback interface. An earlier engine-packaging error was recorded as uncertain and reconciled on-chain before new authorizations; an HTTP error alone never proves a refund. This used a devnet test token, not USDC. Paid inference also completed through relay behind two simulated NAT routers while inbound UDP was blocked. Direct-route readiness was not achieved in the baseline or manually assisted trials, without authorizing payments; the relay result therefore does not prove that blocking caused a direct-to-relay transition. A separate engine failure coincided with an observed out-of-memory kill and was reconciled to zero charge before manual resumption. A later kernel investigation identified global memory exhaustion in the shared Docker virtual machine. Unpaid engine-only cold and warm startup tests passed after the operator increased VM memory; this does not establish full-seller capacity or prevent future memory pressure. Separate unpaid diagnostics reproduced and corrected a router UDP mapping collision. Native direct connectivity passed with manually supplied laboratory candidates, including an idle session; default discovery still used relay. At that container-test stage, automatic recovery, paid direct NAT traversal, off-host relay-only privacy and paid physical-network inference remained unvalidated; the later native physical-network result is described below.

Earlier local failure-case testing. A buyer paid a seller running a real open-weight model (on the same machine, not yet across the internet) for metered inference six times: three honest requests, one where the seller charged more than it delivered, one where it charged less, and one where the model stopped mid-answer. In every case the payment channel enforced the ceiling and returned the unused deposit, the failed request cost nothing, and the buyer's own token count flagged both the overcharge and the undercharge. The run used a test token, not USDC.

What it does not show yet. Detecting an overcharge does not prevent or refund it: that needs signed seller receipts and penalties, which are planned. Recovery from a seller crash, model verification, public reputation scores and broader home-router coverage are also still ahead.

Tested, limited to a simulated WAN. A separate unpaid experiment discovered mapped socket addresses using a temporary, authenticated native observer and random peer ports. Active and idle sessions then selected direct peer paths, with both routers' mappings checked. This observer-assisted laboratory result does not fix public-default discovery through the outer NAT, which still selected relay, or establish why that outer path failed. The test operator still exchanged peer descriptors. That unpaid laboratory result did not establish production seller discovery or paid inference across independent physical networks.

Tested, public IPv4 return-path limitation. Further unpaid tracing showed that public discovery supplied candidates and peers attempted direct UDP probes, but no peer return was observed at the simulated WAN. Other discovery-server responses did arrive. A separate host-only public-address control also failed without Docker; its successful local control stayed inside that host. These results do not identify a specific physical router, provider or host filter, and no production discovery correction is claimed. Network identification and a controlled correction remain pending.

Tested, unpaid connectivity across two physical networks. A Mac on Wi-Fi and a cloud server completed synthetic native peer echoes in both directions. With public-default address discovery, each session initially selected relay and then selected a direct encrypted UDP path. No manual address candidates, laboratory observer, router changes or port forwarding were used. The operator still exchanged public peer descriptors and pinned remote identities; production seller discovery was not tested. This supports a same-public-IP return limitation as an explanation for the earlier local failures, without identifying a particular router, provider or host filter. The original Docker public-return path, other NAT types and mobile hotspot remain unvalidated. Temporary remote test files and processes were removed; existing services retained their running state. That echo experiment tested transport only; the paid application test follows below, while model correctness and production reliability remain planned.

Readiness checks before paid inference across physical networks. A later attempt required a direct connection before authorizing any payment. The Mac seller running in Docker did not meet that route requirement within the deadline; no route samples were retained, so that timeout does not establish relay selection. Native Mac startup then refused to advertise after its private model warmup left too little free-memory reserve. No payment was authorized and no paid request was served. Temporary remote test resources were removed and existing services retained their observed running state. This preserved the earlier unpaid connectivity result; paid inference still awaited sufficient native memory and fresh direct-route readiness at that stage. The transport also rechecks an explicitly required route before forwarding each request, while changes during delivery remain a measurement limit.

A subsequent native attempt distinguished unused RAM from an approximate amount of reclaimable memory and required normal operating-system memory pressure before model work. The operating system reported elevated pressure at startup, so the seller stopped before loading the model, publishing an offer or checking the connection. No payment was authorized. These admission checks reduce one startup risk; they do not reserve memory or guarantee capacity during inference. That attempt still left the native paid cross-network test pending; the subsequent result follows below.

Tested, paid inference across two physical networks. After native memory pressure returned to normal and model warmup passed, the Wi-Fi Mac sold bounded synthetic inference to a cloud-server buyer over a native encrypted peer connection. The buyer verified the owner-signed offer and remote node identity before payment, independently recounted delivered tokens within tolerance, and checked finalized deposits, charges and returned unused token balances. Generation began only after the deposit was confirmed. Buyer SOL remained unchanged; the sponsor paid transaction fees and funded channel-account rent, which remained on-chain. This used a devnet test token, not USDC.

Repeated on the final reviewed code (Oct 21, 2026). After a security review of the whole prototype, the same setup ran again on the exact code that was reviewed. Three paid requests ran one after another over a direct peer connection. Before the next request started, each delivered answer was recounted by the buyer and its payment was checked as final on-chain. The buyer was charged only for what it received, and the rest of each deposit came back. No request was left uncertain. This is still one Mac and one server with a devnet test token: it does not show coverage of mobile hotspots or carrier-grade NAT, production discovery, or protection against many fake identities.

All sampled paid exchanges selected a direct peer path, using public-default discovery without manual address candidates, a laboratory observer or port forwarding. The operator still exchanged public peer descriptors: this does not establish production seller discovery or prove every packet's path. A private audit initially omitted retained rent and paused further authorizations until the account balances were reconciled; an expired offer was manually renewed before the remaining requests, without repeating a settled payment. Temporary runtimes were removed, funded role keys stayed private on their original machines, and existing services retained their observed running state. This is a limited tested configuration; hotspot and broader NAT coverage, automatic recovery, relay-only privacy, authentic model/content verification and production reliability remain planned. Memory admission is not a capacity reservation.

9. Risks and open questions

• Measurement integrity. Buyer measurements are self-reported until sellers sign receipts; until then they count only when a pattern appears across many buyers.
• Audit privacy. Re-executing responses requires sharing some context with an auditor; who receives it and what is kept will be published before launch.
• Token parameters are proposals from a model and will change with real data.
• Regulation. Token and payment rules differ by country; a non-transferable reward token reduces but does not remove that risk.
• Upstream terms. Reselling closed-model subscriptions often breaks provider terms; sellers answer for what they connect.

Sources

• LOGIC, verification of open-weight inference: https://github.com/context-labs/logic
• x402 upto scheme on Solana: https://github.com/x402-foundation/x402/blob/main/specs/schemes/upto/scheme_upto_svm.md
• 8004 agent registry on Solana: https://github.com/QuantuLabs/8004-solana
• Internal design records: the product specification, the token decision and the token model. They will be published with the open-source repositories.