WHY I'M
BUILDING
AGAIN.

I had barely built anything for almost two years. CIRVEX is me starting again on Solana, with a different idea of what is worth making.

Before that break, I built something on Solana mostly for fun. I had no plan for it to become a serious project, and I never expected many people to notice it. Honestly, I did not even think the idea was especially good. Somehow, that small experiment grew to a scale I never expected.

I still do not think the product itself was good enough. The uncomfortable truth is that most people arrived for the token, not the technology. When the market cap reached $5M, the product had no more real users than it had at $100K, $500K or $1M. The product kept improving, but the way people talked about it mostly changed when the price changed.

I cannot blame the community for all of that. If people did not care enough to use the product, then the product had not earned their attention. Price created curiosity, but it did not create usefulness. That experience stayed with me during the time I stopped building.

CIRVEX is my attempt to begin from the opposite direction. I want to make something people are willing to understand because the system itself is useful, not because a chart is moving.

So what is CIRVEX? The easiest way I can explain it is this. It gives software agents useful tools without handing them the keys to everything. I call those tools Chips. A Chip is a small piece of reusable software with one job and clear limits. It says what information it may read, what action it may take, how much money it may use and what result it must return.

I am building CIRVEX on Solana. The chain gives Chips a shared place to be registered, keeps a record of the permission used for each job and settles payment when the work is complete. The actual work can still run locally, so private information does not need to be placed onchain just to prove that something happened.

Say an agent needs to find a price, place an order or publish a file. Today that often means trusting a large application with broad access. With CIRVEX, it installs only the Chip needed for that job. A Machine checks the permission, runs the code locally and produces a receipt. Private data can stay on the machine. The receipt shows which code ran, which permission was used, what it cost and whether it finished.

The board on the left is that process made visible. Each component represents a real part of an execution, from reading the Chip manifest and checking authority to running the code, recording the receipt and settling the cost. Hover over a component to see its responsibility, then select it to jump to the exact instruction below. I want the interface to make the system inspectable before asking anyone to trust it.

I do not know yet whether this becomes a protocol, a useful developer tool or simply a better experiment. This time I would rather earn attention by making the work understandable and useful first.

INSPECT THE CODE ↓

CVX-S01 / SOLANA ACCOUNT FLOW / SOURCE MAPPED PDA ACCOUNTS / SPL TOKEN / ANCHOR

COMPUTE

SECURITY

PROOF

ECONOMICS

CLK PDA PIPELINE VERIFYING INPUT BUDGET BOUNDED SETTLE SPL TOKEN

EXECUTABLE CAPABILITY WAFER

CIRVEX / S0

TESTED BUILD

WAFER ACTIVEREV 0.1SOLANA PROGRAM / CI VERIFIED

LAB NOTE 001 FROM THE FABRICATION DESK

CIRVEX gives an autonomous machine a way to identify a tool, limit what it can cost, record what happened and settle payment on Solana.

01 THE PROBLEM

One task should not require unlimited authority.

An agent may need a price, a report or one approved transaction. It should not need permanent access to an entire wallet or application. A useful capability needs a clear identity, an exact version and a limit that its owner can inspect before use.

CIRVEX calls a reusable capability a Chip. A Machine is the account that chooses which Chip to install and who may report work for it. The onchain program does not run private tasks. It records the shared facts that another person should be able to inspect.

02 CHIP IDENTITY

A publisher creates a Chip under a program derived address. Each published revision has its own artifact digest and manifest digest. Revision numbers advance in order. Existing revisions cannot be silently overwritten, and a publisher can revoke one when necessary.

Those digests identify bytes. They do not certify that the bytes are safe. Before installing a Chip, a Machine owner still needs to inspect the manifest, the publisher and the executable package.

03 INSTALLATION AND AUTHORITY

The owner creates a Machine account and chooses an operator. Installing a Chip pins one revision and its two digests. The installation also records an expiry, one SPL token mint, a maximum cost per job, a rolling window limit and a payment route.

The route has three distinct recipients: publisher, executor and protocol. Their shares must total 100 percent. The owner can revoke an installation or change the Machine operator. The operator cannot edit those limits.

04 A JOB AND ITS RECEIPT

Work can happen away from the public ledger, where private input does not need to be exposed. An authorized operator then submits an invocation identifier, input digest, output digest and measured cost. The program checks the installed revision, expiry, per job ceiling and rolling budget before it creates a receipt.

The receipt is unique to that installation and invocation identifier, which prevents the same job from being recorded twice. It identifies the reporter and committed route. It is an attributable statement from an authorized operator, not cryptographic proof that the private computation was correct.

05 SETTLEMENT

A receipt can be settled only once. The program verifies the payment mint, the Machine controlled token vault and each recipient token account. It computes the committed split and transfers the exact cost through the SPL Token interface. The remaining rounding unit goes to the protocol recipient so the parts always add up.

06 WHAT THE SOURCE SHOWS

The board above maps each component to the actual Anchor program. Select a Chip to jump to the instruction or account definition responsible for that behavior. The source browser reads repository files at build time; it does not contain a separate handwritten version of the protocol.

The program compiles and its unit tests pass in GitHub Actions. The Solana program has not been deployed to a public cluster. The token CA shown in the header is separate from the program ID and does not establish protocol deployment. The current code does not include a hardened private execution sandbox or an independent proof of offchain results. Those boundaries are stated plainly because they matter.

07 THE DIRECTION

I want the next step to be a real end to end flow: a Machine installs a useful Chip, the job runs under narrow local permissions, the result is reported, and a recipient receives payment. The questions still open are how to verify private work, how to audit the executor and how to make a permission understandable before a user signs it.

I would rather have a small system people can inspect and use than a long catalog of capabilities that only sounds impressive. That is the standard I want CIRVEX to meet.

SOLANAANCHOREXPLICIT AUTHORITYRECEIPTSSPL TOKEN

CIRVEX lab note 001 / written from the implementation / September 2026

IS-04

programs / firmware / src / lib.rs

WHAT THIS FILE DOESOnchain Chip registry, bounded installations, receipts and SPL token settlement.

Loading Solana program...