Roadmap

This roadmap is directional and subject to change. It describes work that is planned, not work that is live. The design of each item will move as the team builds. Treat it as intent, not as a commitment to specific mechanics or dates.

#FHE jobs

Octra has native HFHE primitives in its VM, fully homomorphic encryption that lets a program compute on data it never decrypts. The planned use of this in Biont Network is a new job type: FHE jobs.

An FHE job would be posted like any other job, with a reward pool and a deadline. The difference is the output. A biont answering an FHE job produces a result encrypted to the poster's key, so the poster, and only the poster, can decrypt the answer. This makes the work market usable for private inference, where the question, the answer, or both stay confidential.

FHE jobs would be served by an additional validator path alongside the validators that exist today. That validator would judge encrypted-output jobs and route payouts the same way. There is no FHE validator on the live network. The current validators all work on plaintext answers.

Judging an encrypted answer. A validator cannot read an FHE job's encrypted output, so it cannot compare answers by plurality the way it does today. Octra closes that gap with native primitives that prove properties of a ciphertext without decrypting it: fhe_verify_zero, fhe_verify_range, and fhe_verify_bound, plus fhe_commit and fhe_pedersen for binding commitments. A biont answering an FHE job can attach such a proof, and the validator confirms the answer is well-formed, a score in range, a value within bounds, a commitment that binds, while the plaintext stays private. For correctness properties beyond range and bound, groth16_verify_bn254 verifies an arbitrary statement expressed as a circuit. Together these make an FHE job genuinely judgeable: verifiable private compute, not just private compute.

#Signature and proof verification jobs

Octra recently added in-VM primitives for ed25519 signature verification, Keccak-256 hashing, and Groth16 zk-SNARK verification over BN254. They open a class of work the validators can take on directly.

A signature-attestation job type. A poster could ask whether a given key signed a given message. A Verifier or Attestation biont runs ed25519_ok in its kernel and answers yes or no. That is genuine verifiable compute, and it slots straight into the third-party SDK: outside protocols posting verification jobs.

EVM-compatible proof jobs. digest_keccak256 is the hash function EVM chains use. A biont could verify Keccak Merkle proofs or EVM-style signed checkpoints. This makes third-party blockchains submitting verification and proof jobs concrete for the entire EVM ecosystem, not just Octra-native work.

A ZK proof-verification job type. The obsolete design had a ZK validator that was never built, because there was no primitive for it. groth16_verify_bn254 makes it concrete. A poster submits a proof plus its public inputs, the validator runs the verifier, and the job settles on valid or invalid. Verification is deterministic, so plurality consensus works cleanly. This is the strongest fit for the third-party SDK: rollups, bridges, and other chains can outsource proof checks to the biont work market. groth16_verify_bn254 is prover-agnostic: it accepts proofs from any Groth16 toolchain over BN254, including circom, gnark, arkworks, and bellman, so an integrator already proving in its own stack needs only a small format adapter, not a new toolchain.

#Advanced kernels and biont programmability

Today every biont runs one of seven task kernels, one per archetype. These kernels are deliberately simple deterministic functions: a hash, a range check, a number, a small pick set. A simple kernel is easy to verify, cheap to run, and produces an answer many bionts can agree on by plurality. That is what makes the work market function at this stage.

The roadmap is to make kernels far more capable without giving up determinism.

FP64 ML AI inference kernels. This is the headline. Octra's VM has deterministic FP64 machine-learning primitives, the building blocks of a real model forward pass that produces bit-identical results on every node. The Sage archetype is the natural home for this: a Sage kernel that runs an actual AI inference, not a placeholder pick. A biont would take a model input, run the forward pass on-chain in FP64, and return the inference result as its answer. Because the computation is deterministic, every honest Sage running the same model on the same input produces the same output, so plurality consensus still settles the job cleanly. This turns the work market into a venue for verifiable on-chain AI inference: a poster posts an inference job, bionts compute it, and the chain itself agrees on the result.

A stronger Beacon and stamped provenance. The Beacon kernel today just echoes a number. current_tx_hash(), a new in-VM primitive, returns the executing transaction's hash, which is on-chain entropy that is unpredictable until the transaction lands. A Beacon kernel could derive a real randomness value from it. More broadly, a biont could stamp the originating tx hash onto each work submission, making its audit trail self-referential and verifiable.

A real Verifier kernel. The Verifier archetype today does a trivial range check. A Verifier kernel that calls groth16_verify_bn254 becomes a genuine on-chain proof checker, real verifiable compute in place of a placeholder.

A stronger Witness. The Witness archetype proves availability with a bare hash. With SNARKs it could verify a succinct proof of integrity or inclusion instead of echoing a digest.

Multi-step and parameterised kernels. Beyond inference, kernels that run several stages of logic in one call, and kernels that take configuration so a single archetype can serve a family of related tasks rather than exactly one.

Broader programmability. The wider goal is more expressive logic per archetype, so an archetype is a rich capability rather than a single fixed function. The constraint that stays is determinism: any new kernel must still produce an answer that independent bionts can converge on.

#Push-based work dispatch

Today the work market is pull-based. A posted job waits at status Open until a biont is driven to answer it and a wallet is driven to settle it. Nothing in the protocol assigns a job or pushes it onto a worker. The permissionless work calls make that practical, but the protocol itself stays passive between posting and settlement.

Push-based work dispatch is planned. The protocol would match a posted job to eligible bionts and dispatch the work to them, instead of waiting for an external transaction to pull it. Pull-based execution would stay available as the fallback, so the two models coexist. Push dispatch shortens the gap between a job being posted and a biont answering it, and lowers how much off-chain infrastructure a poster needs to keep the loop moving.

#A third-party SDK

The next major piece on the roadmap is a Biont Protocol SDK: infrastructure that lets third parties plug into the work market without writing contract code.

The work market is already permissionless. Anyone can post a job and anyone can settle one. The SDK makes that practical at scale for outside integrators. Third-party blockchains, oracles, prediction markets, and other protocols would use the SDK to submit verification jobs and proof jobs into Biont Network, then read back the settled results. A rollup could outsource proof checks. An oracle network could post numeric queries. A prediction market could post forecast-settlement jobs. The SDK is the standard way for an external system to treat the biont work market as a verifiable compute service.

#Pipoke roadmap

Pipoke, the on-chain social app paired with Biont Network, has its own roadmap. Several of the items below rest on two new in-VM primitives, ed25519 signature verification and Groth16 zk-SNARK verification.

Native mobile apps. PipokeOS, the Pipoke app, runs today as a browser webapp. Native Android and iOS apps are on the roadmap, putting the same Pipoke account, feed, and wallet on a phone. The mobile apps would connect to the same Pipoke contracts as the webapp, so an account works identically across web and mobile.

An inbuilt wallet. Today Pipoke connects through an external browser wallet. The roadmap includes an inbuilt wallet, in-app key custody, so a new user can join without installing a separate extension. A new user with an in-app key signs a post or a follow, a relayer submits it and pays the gas, and the contract verifies the ed25519 signature. The user posts before ever holding OCT. ed25519_ok is the missing primitive that makes the inbuilt wallet buildable.

Anonymous posting that is still Sybil-resistant. Today every Pipoke action is signed by, and attributable to, the wallet that made it. With anonymous posting, a user signs a post with an unlinked one-time key, so ed25519_ok gives authorship without revealing the wallet. groth16_verify_bn254 adds the other half: the post carries a proof that the author belongs to an allowed set (a registered user, a biont holder, an account past a minimum age) without revealing which member they are. The result is anonymous but provably not a spam account. Together these two primitives are what anonymous posting needs to ship without opening a Sybil hole.

Authenticated direct messages. Pipoke direct messages are already encrypted with X25519, so the chain stores only ciphertext. ed25519_ok adds authenticity on top: the contract can confirm a message was authored by the claimed sender without ever seeing the plaintext. Confidentiality plus provable authorship.

Proof-of-personhood and private gating. A user could prove a fact about their account, that it is old enough, that it holds premium, that it passed a gate, to unlock a feature, without exposing the account itself. This is useful for premium gates and for anti-Sybil checks on engagement rewards.

Private engagement and private votes. A user could prove they engaged enough to claim an engagement reward without exposing their full activity graph, and a poll could prove its tally is correct while keeping individual votes hidden.

Private group membership. Group messaging could let a member prove membership with a SNARK rather than exposing their address in a public member set, layered on top of the existing X25519 message encryption.

For the full Pipoke picture as it stands today, see the Pipoke section of these docs.

#Circles and PipokeOS

Octra is building Circles, isolated execution environments on-chain that can host files, programs, marketplaces, and communities. They are a candidate substrate for parts of PipokeOS and for private biont work.

#What a Circle is

A Circle is a substrate with its own runtime, memory, and addressing, separate from the public tree-chain. A circle is not a contract, and it does not show up in the standard contract or account RPC. It is comparable in spirit to a Tor hidden service, with two differences that matter. It is fast, not throttled the way Tor is. And it has no exit nodes: instead of routing through a shared exit that can become a liability, a circle uses disposable, single-purpose nodes that run as unikernels, minimal runtimes with no full operating system.

A circle is reached by address through the oct:// scheme:

oct://<circle-address>/<path>

The landing page is oct://<circle-address>/index.html. A circle browser resolves oct:// and renders what the circle serves, and that browser ships in webcli today.

#Sealed circles

A sealed circle takes the model further. All of its content, the HTML, CSS, JavaScript, images, and other resources, is encrypted on-chain and decryptable only with a browser passphrase. Resources are materialized inline, with CSS and URIs encoded as data URIs and scripts and images embedded, so a sealed circle is fully self-contained.

A sealed circle renders inside a hard sandbox. The runtime decrypts and analyzes the page as it loads and blocks operations that could leak or fingerprint: fetch, websockets, localStorage, cookies, canvas fingerprinting, and external links are all denied. The only channel out is window.octraCircle, a narrow capability bridge through which the circle can request the wallet address, the balance, and encryption or decryption of its own contents.

Each circle has a circleID derived deterministically from the deployer address, a nonce, and the payload hash, and the payload hash is verified on decryption. Sealed payloads come in fixed size classes (4K, 16K, 32K, 128K), so a sealed circle is sized for compact, self-contained content rather than a large application bundle.

#What this means for PipokeOS

The sealed-circle model is a strong fit for small, private, self-contained surfaces and a poor fit for dropping in a whole heavy app, so the PipokeOS roadmap splits along that line.

Private circle-hosted surfaces. A sealed circle suits a gated community page, a sealed post or document, a members-only space, or a checkout: content that is compact, private, and self-contained. A creator could run a sealed community, which fits the creator economy. The hard sandbox and passphrase encryption make these surfaces private by construction.

A circle-native client. PipokeOS as it stands is a large app that constantly reads the chain and an indexer and keeps local state, so it cannot run inside a sealed circle: the sandbox forbids fetch and localStorage, and the size classes cap a sealed payload well below a full app bundle. A circle-hosted PipokeOS would instead be a lighter, circle-native client that reaches the chain only through the window.octraCircle capability bridge. How far that can go depends on how the capability set grows.

Until then, the practical path is sealed circles for specific private features alongside the normal PipokeOS webapp and the planned mobile apps, rather than the whole app served from one circle.

Circles are also a candidate substrate for private biont work and on-chain ML inference. The demo circle Octra published runs an end-to-end FHE flow, the same ground as the FP64 inference kernels above.

Circles are in an alpha stage with a narrow scope today. Anything here depends on Circles maturing.