Gyblos: an open market for intelligence

Litepaper, draft 0.101.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. Billing requirements, regional restrictions and funding friction can make inference harder to obtain. Meanwhile, idle capacity that could serve it sits in gaming PCs, Macs and servers. Our long-term vision extends inference production to capable smartphones, TVs and parked cars as well.

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, designed to keep control of their funds and recover unused deposits. Ordinary refunds have been tested in our Solana prototype (§8); recovery in exceptional account failures remains under validation. Sellers will set their own net prices; a single 3% protocol fee (initial value) will be added and buyers will see the total before authorizing. 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.

Our long-term vision is for every device capable of running a useful model to become a producer of intelligence. That includes GPUs and computers, smartphones while charging, TVs and parked cars: their owners could produce inference, sell it or give it away. Gyblos is building the open market for that world. Device performance, energy use, operating-system integration and validation determine which devices can participate; mobile, TV and vehicle hosts remain future work.

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 has friction. Billing requirements, regional restrictions and minimum purchases can make inference harder to obtain. People and agent developers need usable ways to choose supply and control spending.
2. Independent supply is hard to make useful. Operators need practical ways to reach buyers, offer suitable models and receive payment. Home-network setup and uneven availability can add friction; buyers also need evidence of service quality.
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.
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 travel over an encrypted peer connection, directly or through a relay; a relay carries ciphertext while the chosen seller and any engine provider it uses can read the request. Payment is metered per inference token; reusable signed-voucher sessions remain planned.
4. Settle. The design aims to pay the seller and protocol and return the unused deposit when the channel settles. Normal refunds were tested in the prototype; exact fee distribution and recovery from exceptional account failures remain under validation.

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.

3.2 Personal wallet and mobile continuity (planned)

Desktop onboarding targets macOS, Windows and Linux, with no separate signup before trying the app. The experimental desktop app now prepares a protected local wallet automatically while showing only the small ASCII loader. Recovery, explicit wallet selection and backup actions live in Settings; restoration keeps the existing identity alongside the recovered one and confirms the same address without replacing retained or partial state. The small ASCII startup window coordinates preparation and closing; exiting during loading must not reveal the main window afterward. Chat and Connect remain simulated. The development app also starts a real local-only transport endpoint and displays its readiness. Local tests and an isolated Apple Silicon Mac check cover startup, retry and shutdown; connecting the desktop to remote providers remains planned. This local readiness feature is integrated into development code, has not been released and does not enable funding.

Private material is stored using platform-specific secret protection, refusing weak or unavailable encryption rather than saving a plaintext key. The app includes a password-encrypted portable backup format, saving and reopening a backup to verify its address, and restoration into an absent wallet destination with protection for the destination system. Previous synthetic backup exchanges preserved the same address across macOS, Windows and Linux; earlier Mac interface checks used simulated protection and file selections. The latest integrated revision passed local tests and independent reviews, while current remote cross-platform automation remains pending an infrastructure restriction. A separate earlier isolated test on an Apple Silicon Mac used Electron development builds with real macOS secure storage: the same newly generated address survived a process restart and restoration from an encrypted backup. File selection and approvals were simulated. This does not establish signed-app installation or update continuity, DPAPI or Linux secret-store acceptance, native Windows/Linux interface acceptance, general ciphertext tamper protection or operational installation/update recovery.

The development desktop app can explicitly check signed zero-price model announcements by an exact model identifier. Local automated checks and isolated Apple Silicon Mac trials cover filtering, bounded results, expiry, the shared selector and orderly shutdown; an anonymous public-index lookup has also been exercised. This establishes access to that index, not provider availability, registry identity or successful desktop inference. The current API cannot list every model. This is integrated development code, not a released application. Chat and external-tool connections remain simulated, funding stays disabled, and native Windows/Linux and released distribution acceptance remain pending.

The experimental desktop interface now includes shared full-page Settings for the public wallet address, address copying and explicit backup actions. Local automated checks and isolated Mac interface checks cover these controls; the displayed zero balance is a placeholder, and the Add funds entry cannot initiate a payment. Chat and external-tool connections remain simulated. Native Windows/Linux interface acceptance and released distribution remain pending.

Within an open desktop session, simulated replies now continue when another conversation is selected or a new chat is created, with a separate draft for each conversation. Stopping retains the partial reply and unsent follow-up. Local automated tests and isolated browser checks cover this behavior. Conversation content remains in memory and clears when the app closes; saved history and mobile synchronization remain planned.

Before enabling app funding, Gyblos must explain custody and require a verified recovery backup. The desktop app can remember a successful saved-file check for the current wallet address and backup version using protected local metadata. Local tests and disposable Mac interface checks cover restart and invalidation; native validation across platforms and signed installations remains pending. This remembered verification is informational: funding remains disabled and the indicator does not prove that the backup file is still available. Losing the backup file or password loses that recovery route. The app cannot prevent external transfers to a known address.

The integrated internal wallet library keeps an existing wallet alongside a restored one, remembers an explicit active address, and keeps backup verification separate for each address. Disposable local tests and independent reviews cover disk reopening, refusal to overwrite and cancellation. The app now uses this library during automatic startup and Settings recovery. Full native validation across the supported operating systems remains pending, and funding remains disabled.

An isolated Apple Silicon Mac test now exercises the integrated Settings interface with real macOS secure storage. A newly generated address survives backup verification, restoration alongside another automatically created wallet and explicit active selection across independent app processes. The original encrypted wallet is preserved, and backup verification remains separate for each address. File selection and confirmation dialogs are simulated; native picker behavior, Windows and Linux secure stores and interface, signed installation/update continuity, system reboot and crash recovery remain pending. The integration is locally tested and independently reviewed; funding remains disabled.

Linking a phone is planned for a later stage, with explicit device authorization and permissions. Conversation continuity, remote desktop control and independent mobile use are separate capabilities still to be designed. Linking devices will not automatically merge wallets, replace keys or move funds. This is a planned experience, not an available recovery or synchronization guarantee.

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.
• Built and tested locally: a unified buyer entry verifies the signed quote before choosing zero-price execution without payment transactions or the existing positive-price payment channel. A spending ceiling does not require spending it. Synthetic local acceptance covers both routes, cancellation and recovery; live seller onboarding and mainnet readiness remain separate, unproven milestones.
• One fee for everyone: 3% of the seller-set net price (initial value), added to it and included in the total shown to the buyer. The exact atomic rounding and distribution mechanism remain under design.
• Designed to charge for delivered usage and return unused deposits. Ordinary refunds have been tested; delivery attribution and recovery in exceptional account failures remain under validation.
• 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.

Illustrative amounts before atomic rounding; the exact distribution remains planned:

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

The planned mainnet launch date remains December 9, 2026; launch timing, readiness and delivery scope are tracked separately in the launch plan. This is a planned date, not evidence of production acceptance.

Planned: invite the first sellers to a beta before mainnet. Seller onboarding and pilot participation remain to be validated.

A real-model free inference over public discovery was demonstrated with Ollama on October 27, 2026. The synthetic acceptance scenarios below exercise newer combined discovery, startup, identity, receipt and telemetry behavior. Their pending real-model or off-host revalidation does not erase the earlier successful inference, and that earlier result does not validate the later additions. These results do not establish acceptance of the experimental desktop chat and external-tool connections.

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. The format and construction of content-free signed usage receipts, including comparisons with available buyer observations, have been implemented and tested with synthetic signers. An optional adapter for aggregate operational metrics has been implemented and tested in memory. Seller and buyer services support optional content-free local event reporting. Operators can enable private local file reporting through startup configuration; it stays off by default. Synthetic local startup tests cover private persistence, restarts, normal completion, cancellation and failures. Storage and shutdown are bounded, and logging failures do not change inference retry policy. A filesystem operation already started may finish after the close deadline. External collection and startup configuration for aggregate exporters remain planned. Free-inference services now produce, privately retain and exchange signed receipts in the background. Complete and streaming responses, buyer countersigning and receipt failures have been tested between local encrypted test peers using simulated engines and isolated private storage. Receipt work is bounded and does not retry prompts or wait on storage before inference responses. Missing or seller-only receipts remain possible, and signatures attest claims rather than prove truthful usage or delivery. A reproducible local test now starts the seller and buyer services, discovers the seller through an in-memory index, executes free requests and confirms private signed receipts over encrypted loopback connections. It uses a simulated provider, an independently verified synthetic local registry and an injected local transport binding. The combined startup test covers registry outage and oversized replies, revocation, explicit manual override and removal, persisted binding replay rejection, rejection of changed-owner bindings and newer-binding recovery alongside private receipts and local reporting. Restarts, receipt-storage failures and cancellation were tested without repeating prompts. This does not validate ordinary relay connectivity, live-registry freshness or completeness, real models or independently measured usage. Collection and penalties remain planned. Recovery from a seller crash, model verification, public reputation scores and broader home-router coverage are also still ahead.

Built and locally tested: private free receipt validation. The private ingestion policy verifies paired node signatures and their linkage, bounds input and concurrent work, rejects conflicting versions of a request and preserves disputed observations. Tests use synthetic signed records and an in-memory storage implementation. The policy has no network endpoint, default persistent backend or runtime upload integration. An optional private file backend is now built and locally tested with synthetic records, including restart verification, concurrent process exclusion, bounded writes and staged replacement. Local startup acceptance now continues from confirmed receipts produced by the seller and buyer to private collector storage, then reopens that storage in a separate process with exact deduplication. Capacity, early cancellation and incomplete pairs are checked without new inference attempts. These are synthetic local tests; the backend remains disconnected from ordinary product startup and network collection. Filesystem permissions are not encryption at rest; power-loss, rollback resistance and Windows ACL behavior are not established. A separately started local-only receiver is now built and locally tested with buyer-scoped access credentials, authorization before reading submitted records and explicit body retention. The combined synthetic startup test reaches this receiver and checks duplicate detection after restart and body expiry. Private replay markers remain within a bounded lifetime budget; the receiver refuses new records when full rather than silently forgetting replay history. Logical body deletion is not secure erasure, and a stopped receiver or failed disk cannot guarantee deletion on schedule. Automatic uploads, human-consent interfaces, externally reachable collection, replay-history rotation and public accounting remain planned. Existing local node receipt storage remains separate. No receipts are sent centrally or added to public usage totals by this policy. Signatures attest observations, not independently proven usage or delivery.

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.