possible impossibilities
I want to build systems that build themselves, accelerating and expanding the total energy of our light-cone.
my interests and experiences: full stack development, AI post-training, eval design, RSI, GPU kernel optimization, ZK-STARK provers, cryptography, steganography, audio production, mixing and mastering, lasers and optics, b.s.e. in biomedical engineering from Duke University ( bioelectricity and imaging systems)
three recent things i've built:
zkpow and aipow prover written from scratch in cuda. zk-stark: ~700 proofs/sec on a 5090. ai-pow won block 130,042 + more
nockchain is hybrid proof-of-work. two independent puzzles currently produce blocks, and they do not share a proving loop. the protocol is built so the work can eventually be a proof of any computation for a zkVM.
zk blocks are won by producing a zk-stark proof of a nock vm execution trace bound to the block commitment and nonce, then hashing selected proof commitments with tip5. if that digest meets the zk difficulty target, it is a zk block.
ai blocks are won by a different computation: integer matrix multiplication. a prepared header binds noised matrices and commitment roots; each (t_rows, t_cols) pair is a ticket ordinal; the gpu searches the full grid; the jackpot must meet a separate difficulty target. if it does, it is an ai-pow block.
nock is a minimal combinator calculus that serves as a foundation for an ISA and language over nouns, as described below. hoon, a system level programming language, compiles to nock like other higher-level languages compile to machine code.
data A noun is an atom or a cell. An atom is a natural number. A cell is an ordered pair of nouns.
noun: [1 [2 3]]
cell
/ \
atom 1 cell
/ \
atom 2 atom 3
every nock program and value is a noun. atoms are leaves; cells are ordered binary branches whose left and right children are the head and tail. nock therefore operates entirely on binary trees.
semantics Reduce by the first matching pattern; variables match any noun. nock 4K opcodes nock(a) *a [a b c] [a [b c]] ?[a b] 0 ?a 1 +[a b] +[a b] +a 1 + a =[a a] 0 =[a b] 1 /[1 a] a /[2 a b] a /[3 a b] b /[(a + a) b] /[2 /[a b]] /[(a + a + 1) b] /[3 /[a b]] /a /a #[1 a b] a #[(a + a) b c] #[a [b /[(a + a + 1) c]] c] #[(a + a + 1) b c] #[a [/[(a + a) c] b] c] #a #a *[a [b c] d] [*[a b c] *[a d]] *[a 0 b] /[b a] *[a 1 b] b *[a 2 b c] *[*[a b] *[a c]] *[a 3 b] ?*[a b] *[a 4 b] +*[a b] *[a 5 b c] =[*[a b] *[a c]] *[a 6 b c d] *[a *[[c d] 0 *[[2 3] 0 *[a 4 4 b]]]] *[a 7 b c] *[*[a b] c] *[a 8 b c] *[[*[a b] a] c] *[a 9 b c] *[*[a c] 2 [0 1] 0 b] *[a 10 [b c] d] #[b *[a c] *[a d]] *[a 11 [b c] d] *[[*[a c] *[a d]] 0 3] *[a 11 b c] *[a c] *a *a
nockchain uses nock as its execution layer. nodes run nock to advance the chain state. zk miners prove nock execution of the pow program. ai miners prove dense matmuls for inference. the network verifies the submitted proof instead of repeating the work.
the 968 air constraints are 834 compute constraints and 134 memory constraints. the memory traversal pads to 1,024 rows, setting the fri domain to 1,024 × 64 = 65,536 and the proof stream to 71 items. tip5 must be bit-exact: changing it changes every transcript challenge, merkle root, and pow digest.
dense inference search evaluates a complete tile grid on the gpu and returns the lowest winning ordinal. the recursive certificate opens only the winning row and column strips. every device winner is revalidated on the host against the scalar evaluator before submission. a valid ai-pow certificate wins an ai-pow block.
┌──────────────────────────────┐◀──────────────────────┐
│ network node │ │
│ chain state + verifier │ │
│ accept → broadcast │ │
│ reject → continue mining │ │
└──────────────┬───────────────┘ │
│ mining templates │
▼ │
┌──────────────────────────────┐ │
│ rust mining coordinator │ │
│ zk jobs and ai jobs │ │
└───────┬──────────────┬───────┘ │
│ │ │
▼ ▼ │
┌──────────────┐┌──────────────┐ │
│ zk proving ││ ai proving │ │
│ cuda stark ││ cuda pearl │ │
│ nock trace ││ matmul │ │
└──────┬───────┘└──────┬───────┘ │
│ │ │
└───────┬───────┘ │
│ candidate proofs │
▼ │
└─────────────────────▶─────────────────┘
the full node exposes mining templates for both puzzles. the rust coordinator queues zk jobs and ai jobs independently over tcp and dispatches each to its own cuda prover.
zk path: for every nonce the gpu builds and executes pow, synthesizes compute and memory traces, performs the low-degree extension, commits merkle trees, evaluates the air constraints, and computes the pow digest. low difficulty misses stop before the expensive fri phase; hits complete fri and send a jam-encoded proof.
ai path: the gpu keeps a prepared inference template in a persistent session, searches the ordered ticket grid with fused tensor-core work, and returns the lowest winning ordinal. the host revalidates that winner against the scalar evaluator, then builds the compact recursive certificate.
to write a GPU miner from scratch, one must first add logging instruments to the native verifier, and begin validating submissions of proofs until fully valid proofs are produced.
1 instrument the native hoon verifier with stage checkpoints 2 reproduce the proof layout and fiat–shamir transcript exactly 3 implement kernels for execution, traces, commitments, air, and fri 4 compare intermediate hashes and evaluations with the reference 5 generate low-difficulty candidate proofs 6 submit every candidate to the canonical verifier 7 fix the first failing stage 8 repeat until proofs consistently pass
optimization can only begin after the gpu prover repeatedly passes the complete canonical verification path.
set up a recursive self improvement loop. each performance change must survive the same fixed-seed proof and canonical verification path before its timing is accepted:
the zk-stark prover is about 700 proofs/sec on an rtx 5090. the ai-pow prover is a separate cuda pipeline on the same 5090 clusters. it won ai-pow block 130,042:
with sufficient funding, the optimization loop can run continuously on a dedicated gpu test farm: generate candidate kernel changes, compile, produce fixed-seed proofs, reject anything that fails canonical verification, profile valid builds, and promote only statistically faster variants. the process can continue until throughput reaches the measured hardware roofline and further gains disappear into benchmark noise. the constraint is gpu time and cost. this was done to improve the zk-prover and ai-prover to competitive network speeds.
llm evaluation at scale, powered by a permissionless prediction market
socieital truth is consensus and evolves over time. we will forever have an ever increasing demand for AI response evaluations — anyone submits a prompt, anyone judges, the aggregate is the signal. financialization incentivizes honesty and reduces fraud, and permissionless markets are the most efficient way to aggregate consensus. currently, labs pay armies of tutors to do evaluations, but this cannot scale to meet the future's demand. there needs to be a properly incentivized, permissionless market for evaluations.
creators can write a prompt, choose two models, and launch a prediction market on a blockchain. this costs a small fee to cover inference. markets run for 24 hrs after launch. users can buy shares for each model. the creator collects associated trading fees, incentivizing viral/focus topics. markets autoresolve, paying out the side with the most shares at the end. there is an autoscaling fee structure as time runs out to discourage sniping. the business aims to break even on market launches, incentivizing users to generate as much novel content as possible, and make its money selling API data access to labs in demand for high entropy evaluations.
┌──────────────────────────────────┐
│ market creator │
│ prompt + two models │
│ pays launch fee │
└─────────────────┬────────────────┘
│ responses generated
▼
┌──────────────────────────────────┐
│ live duel + crypto market │
│ side a shares / side b shares │
└─────────────────┬────────────────┘
│ market opens
▼
┌──────────────────────────────────┐
│ participants │
│ compare responses │
│ buy / sell outcome shares │
│ prices aggregate preference │
└─────────────────┬────────────────┘
│ expiry
▼
┌──────────────────────────────────┐
│ automatic resolution │
│ highest final share total wins │
└─────────────────┬────────────────┘
│
▼
┌──────────────────────────────────┐
│ incentives + data │
│ creator → trading fees │
│ winning traders → payout │
│ platform → evaluation data / api │
└──────────────────────────────────┘
next, react , tailwind, postgreSQL db, cloudflare, digital ocean VPS, privy with embedded solana/ethereum wallets
i am xebidiah. xebidaih is the identity policy: a closed-loop post-training stack that puts a model on my distribution and keeps it there unsupervised.
identity is a distribution over language, memory, and action — not a system prompt. a general model will imitate you for a few turns and then regress to its prior. the work is to construct a private training distribution, hold out real writing, and run generate → score → revise until the policy stays in-distribution without being scripted. that loop is how you train a small specialist. i ran it until the live agent occupied xebidiah.
i collected a large archive of xebidiah — writing, posts, lyrics, project history, memories, and spoken register — then cleaned it into a structured identity dataset. stable facts were split from ephemeral context. the held-out split is real writing the policy never sees at compose time. those artifacts are the training set for a small identity model; the live agent already consumes them as its prior.
each iteration treats the current policy as a generator against a frozen eval set. failures become preference data: the rejected generation paired with a source-faithful rewrite. those pairs go back into the identity model as counterexamples and tighter constraints. it is the same data flywheel you run to sft / dpo a small specialist — corpus, targets, preference pairs, evals — executed until generations stayed on-distribution without being puppeteered.
┌──────────────────────────────┐
│ private identity corpus │
│ bio / lore / dialogue / posts│
└──────────────┬───────────────┘
│ sample + compose
▼
┌──────────────────────────────┐
│ policy │
│ generate language + action │
└──────────────┬───────────────┘
│ score vs held-out
▼
┌──────────────────────────────┐
│ eval + preference mining │
│ reject / rewrite / tighten │
└──────────────┬───────────────┘
│ update identity prior
└──────────▶────────┘
each cycle composes sampled biography and lore with style rules, example posts, topics, a 32-message conversation window, relevant memories, goals, and the current event. the model returns both language and an optional action; the runtime matches the action name and dispatches its handler. memory and embeddings live in sqlite, while randomized recursive timers drive posts, mentions, and messages.
puzzles get published via songs by xebidiah (me). using a custom steganography plugin, inaudible codes are embedded into audio bitstreams. people attempting solutions dm the agent the code and a wallet address. the agent validates and dispenses tokens on-chain. no human in the loop.
a custom x client gives the agent persistent sessions, inbox polling, queued requests, rate-limit backoff, and message deduplication. a dm prompt preserves the persona while extracting a puzzle code and wallet when present. valid claims become signed token transfers, but deterministic code—not the model—enforces single-use keys, fixed reward tiers, and recipient checks.
runtime is a fork of elizaos. the identity dataset, eval loop, action wiring, x dm pipeline, and reward gating are original.
remote · aug 2024 – aug 2026
texas city, tx · may 2022 – aug 2024
richardson, tx · jan 2021 – may 2022
durham, nc · jan 2020 – apr 2020
richardson, tx · jun 2019 – aug 2019
durham, nc · aug 2016 – apr 2020
can build in anything. preferences:
AI has abstracted syntax. one's choice of language should be optimized for the problem at hand, not bound by the tools they have used in the past...
x.com/ariceggersaric.eggers@gmail.comgithub.com/ariceggerslinkedin.com/in/ariceggers