possible impossibilities
I want to build systems that build themselves, accelerating and expanding the total energy of our light-cone of conciousness.
my interests and experience: AI post-training, eval design, RSI, GPU optimization, ZK-STARK provers, cryptography, steganography, audio production, mixing and mastering, laser and optics r&d, with a in b.s.e. biomedical engineering from Duke University
→three recent things i built end to end:
a zk-stark prover for nockchain, written from scratch in cuda. ~125 proofs/sec on a 5090
nockchain is a zero-knowledge proof of work virtual machine blockchain. you do not win a block by simply hashing — you win by producing a zk-stark proof of a nock execution trace bound to the block commitment and nonce, then hashing selected proof commitments with tip5. if the resulting digest meets the difficulty target, you win. the work is a proof, so the mining loop is a proving loop.
nock is a deterministic instruction set over nouns. hoon, a system level language compiles to nock like a higher-level language compiles 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. 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 chain state; miners prove execution of its proof-of-work program, and the network verifies the 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.
┌──────────────────────────────┐◀──────────────────────┐
│ network node │ │
│ chain state + verifier │ │
│ accept → broadcast │ │
│ reject → continue mining │ │
└──────────────┬───────────────┘ │
│ mining templates │
▼ │
┌──────────────────────────────┐ │
│ rust mining coordinator │ │
│ queue + batch scheduling │ │
└──────────────┬───────────────┘ │
│ parallel mining jobs │
▼ │
┌──────────────────────────────┐ │
│ cuda proving pipeline │ │
│ execute → trace → commit │ │
│ constrain → prove │ │
│ difficulty check → return │ │
└──────────────┬───────────────┘ │
│ candidate proofs │
└─────────────────────▶────────────────┘
the full node exposes a mining template. the rust miner communicates over tcp, then passes the commitment and target data to the cuda programs.
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 for submission to the node. if it is accepted, the node will broadcast the proof to the network.
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:
→ identify bottlenecked / regressed kernels with nsys profile
→ theorize speed changes for bottlenecks
→ implement speed changes
→ mine on low difficulty
→ ensure verifier passes
→ ↺
the measured rate is about 125 proofs/sec on an rtx 5090:
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.
→llm evaluation at scale, powered by a permissionless prediction market
socieital truth is consensus and evolves over time. we will forever have a 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.
users write prompts, choose two chosen models, and launch a prediction market on solana. this costs a smallfee to cover inference. markets run 24 hrs. 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 evaluations.
┌──────────────────────────────────┐
│ market creator │
│ prompt + two models │
│ pays launch fee │
└─────────────────┬────────────────┘
│ responses generated
▼
┌──────────────────────────────────┐
│ live duel + solana 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 15, react 19, tailwind 4, privy auth with embedded solana wallets, jest across unit / integration / api / fuzz / perf, docker multi-stage, eks manifests.
→i made a simulacrum that runs its own x account, holds its own crypto keys, and pays people if they tell him secrets.
puzzles get published via songs. i have a custom plugin that uses steganography to embed codes into audio bitstreams. solvers dm the agent the code and a wallet address. the agent validates and dispenses tokens on-chain. no human in the loop.
auth walks x's own onboarding task flow: js-instrumentation subtask, then identifier sso, then password, with totp for 2fa, plus a guest token and the web client bearer. the ct0 cookie becomes the csrf header, and the cookie jar is persisted to the db cache so sessions survive restarts.
on top of that, a dm-specific prompt template does two jobs in one pass: answer in character, and extract the wallet address and reward key if present, emitting the transfer action so the runtime chains straight into a payment.
no anchor program and no wallet sdk in the transfer path. derive both associated token accounts, create the recipient's in the same transaction if it does not exist, set a 300k compute unit limit and a 500k microlamport priority fee, build the transfer instruction, compile to a v0 message, sign, send with skipped preflight. three attempts with a fresh blockhash each and a 30s confirmation timeout, against a staked rpc.
an agent that sends tokens when a model says so is an obvious target. so the transfer path does not trust the model:
runtime composes state from bio, lore, a 32-message conversation buffer, goals and providers, generates, then matches the action name in the response and executes the handler. memory and embeddings in sqlite — no external vector db. scheduling is recursive timeouts, not cron: dms and mentions every 12s, autonomous posts every 90–180 minutes randomized.
built on a fork of elizaos. i did not write the agent framework — i wrote the persona, the dm pipeline, the reward gating, and the on-chain half.
→remote · aug 2024 – present
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
b.s.e. biomedical engineering — imaging systems & bioelectricity · 2020
data analysis, linear algebra, differential and partial equations, signals and systems, microcontroller design, monte carlo methods, biophotonics, ray optics, imaging systems.
→can code in anything. preferences:
x.com/ariceggersaric@ariceggers.comgithub.com/ariceggerslinkedin.com/in/ariceggers