Archetypes and Kernels
A biont's archetype is not a tag. It is the program. There are seven archetypes, and each one is a separately compiled contract (BiontSoulProxy_arch0 through BiontSoulProxy_arch6). The seven variants share one template and differ in exactly two places: the ARCHETYPE constant, and the body of a private function called _kernel. The kernel is the biont's task logic. It is the thing the biont actually computes when it answers work.
Biont Network runs on Octra Devnet today. Any fee, price, split, cooldown, or limit referred to here is a contract setting chosen for testing. Every one is owner-settable, and mainnet values will be different. These docs describe how the mechanics work, not what the numbers are.
The seven kernels are deliberately simple deterministic functions. Richer kernels are on the roadmap, not in the current set.
#One archetype, one program
BiontGenesis stores seven compiled bytecodes, one per archetype. When you mint, you pick an archetype and Genesis deploys that exact bytecode. There is no runtime task switch and no capability flag the program checks. The contract at the biont's address is the capability. A Hasher cannot do a Verifier's job, because a Hasher's bytecode does not contain a Verifier's kernel.
| Id | Archetype | Task | Accent |
|---|---|---|---|
| 0 | Hasher | SHA-256 challenge | Cyan |
| 1 | Sealer | Sealed commitment | Blue |
| 2 | Verifier | Range-proof verification | Green |
| 3 | Beacon | Randomness beacon | Lime |
| 4 | Oracle | Numeric oracle | Yellow |
| 5 | Sage | Deterministic inference | Orange |
| 6 | Witness | Availability proof | Red |
#The kernel signature
Every kernel has the same shape:
private fn _kernel(str_input: string, int_a: int, int_b: int): string
It takes one string and two integers, and returns a string. The string output is the biont's answer. The three inputs are the job's data. What each archetype does with those three slots is the difference between archetypes.
#How a kernel gets its inputs and submits
A liberated biont answers a job through auto_answer:
auto_answer(jid, validator_type, str_input, int_a, int_b)
The flow inside the biont program is short:
- Check the biont is liberated and off cooldown, and confirm it is alive with the Registry.
- Resolve the validator address for
validator_type. - Run
_kernel(str_input, int_a, int_b)to produce the answer string. - Call
submit_work(jid, soul, answer)on the validator. - Stamp the action epoch and emit
AutoActionTaken.
The inputs (str_input, int_a, int_b) are not read from the chain by the biont. They are supplied by the caller of auto_answer. In practice the wallet driving the work reads the job brief off-chain, works out the correct inputs for that job, and calls auto_answer on a matching biont with those inputs. The biont runs its kernel over them and submits. See The Permissionless Economy for who can do this.
Because kernels are deterministic, two honest bionts given the same correct inputs produce byte-identical answers. That is what makes plurality consensus work: honest bionts converge on the same string, and the most-submitted string wins. See The Work Market.
#The seven kernels
#Archetype 0, Hasher
return sha256(str_input)
Reads str_input. Returns the SHA-256 hash of it as a hex string. The job carries the input string in str_input; the answer is its digest. The two integer slots are unused.
#Archetype 1, Sealer
let mixed = concat(to_string(int_a), concat(":", to_string(int_b)))
return sha256(mixed)
Reads int_a and int_b. Joins them as int_a:int_b, then returns the SHA-256 of that joined string. This is a sealed commitment over a numeric pair: the output reveals nothing about the two numbers but is reproducible by anyone who knows them.
#Archetype 2, Verifier
if int_a >= 0 && int_a <= int_b { return "1" }
return "0"
Reads int_a and int_b. Returns "1" if int_a falls in the range [0, int_b], otherwise "0". This is a range check: the job asks whether a value sits inside a stated bound, and the biont answers yes or no.
#Archetype 3, Beacon
return to_string(int_a)
Reads int_a. Returns it as a string. The Beacon publishes a number into a job as a randomness beacon value. The caller supplies the beacon number; the biont commits it on-chain through the validator.
#Archetype 4, Oracle
return to_string(int_a)
Reads int_a. Returns it as a string. The Oracle reports a numeric value into a job, the same mechanical shape as the Beacon. The difference is intent: an Oracle answers a numeric query (a price, a count, a measurement), while a Beacon publishes a random value.
#Archetype 5, Sage
let cc = int_b
if cc < 5 { cc = 100 }
let base = int_a
if base < 0 { base = 0 - base }
base = base % cc
let p1 = base + 1
let p2 = ((base + 1) % cc) + 1
let p3 = ((base + 2) % cc) + 1
let p4 = ((base + 3) % cc) + 1
let p5 = ((base + 4) % cc) + 1
Reads int_a and int_b. Builds a five-number CSV string. int_b sets the ceiling (cc, defaulting to 100 if it is below 5), and int_a seeds the pick. The kernel folds int_a into the range with a modulo, then steps five consecutive numbers off that base, each wrapped inside the ceiling. The result is a deterministic five-pick, returned as p1,p2,p3,p4,p5. Given the same int_a and int_b, every honest Sage produces the same five numbers.
#Archetype 6, Witness
return sha256(str_input)
Reads str_input. Returns its SHA-256 hash. Mechanically identical to the Hasher. The intent differs: a Witness proves availability, attesting that a piece of data (referenced by a CID or content string) was present and produced this digest.
#Why some kernels look alike
Hasher and Witness both run sha256(str_input). Beacon and Oracle both run to_string(int_a). The kernels are simple, so some collapse to the same arithmetic. They stay separate archetypes because they answer different validator job types and represent different roles in the work market. The archetype is the contract identity, not just the kernel arithmetic.
#Toward richer kernels
Today's kernels are intentionally minimal: a hash, a range check, a number, a five-pick. They are the foundation, not the ceiling.
The headline of the kernel roadmap is FP64 ML AI inference. 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 instead of 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 given the same model and input produces the same output, so plurality consensus still settles the job. That makes the work market a venue for verifiable on-chain AI inference.
Beyond inference, the roadmap covers multi-step kernels that run several stages of logic in one call, parameterised kernels so a single archetype can serve a family of tasks, and broader biont programmability per archetype. The constraint that stays is determinism: any new kernel must still produce an answer that independent bionts can converge on. See the Roadmap.