LAB NOTE 001 FROM THE FABRICATION DESK
firmware is a way for an autonomous machine to install useful software, understand exactly what that software is allowed to do, pay for the work and keep a receipt that another person can inspect.
01 THE PROBLEM IN PLAIN LANGUAGE
An agent should not need the keys to everything just to complete one task.
Most agent software still works through broad trust. A model receives access to a wallet, an API key, a browser session or an entire application account. The tool may only need to read one price or submit one transaction, but the surrounding permission is often much larger than the job.
That is convenient while everything behaves correctly. It becomes difficult the moment a dependency changes, a prompt is manipulated, a package is replaced or an operator wants to understand where money went. The user can see the final answer, but usually cannot see the exact version of the tool, the authority it received, the amount it could spend or the path used to pay for it.
I do not think the answer is to put every calculation onchain. That would make private work public and simple work unnecessarily expensive. The better boundary is to keep execution where it makes sense while placing identity, permission, attribution and settlement somewhere shared and inspectable.
firmware separates the ability to perform a job from the authority to control the whole machine.
02 WHAT FIRMWARE IS
firmware is an execution layer built around two objects. A Machine is the account that owns funds, installs capabilities and decides who may operate them. A Chip is a versioned capability that performs one understandable job.
A Chip can read market data, prepare a report, publish a file, call an approved contract function, move a limited amount of one asset or coordinate another narrowly described service. The important part is not how impressive the task sounds. The important part is that the task has a visible boundary.
Installing a Chip does not grant general control. The Machine approves a specific revision, a specific artifact digest, an expiry time, allowed destinations, allowed function selectors and spending limits. Changing the executable creates a different digest. Expanding its authority requires another explicit installation decision.
WHY CALL THE CAPABILITY A CHIP
A normal package tells you which files to download. A plugin usually belongs to one application. A prompt based skill may describe behavior without creating an enforceable boundary. I use the word Chip because the object is meant to behave more like a component with documented pins.
It has declared inputs and outputs. It has compatible runtimes. It has limits on the resources and authority it can consume. It has a revision that can be identified exactly. It can be removed or replaced without silently becoming the Machine itself.
03 WHAT A CHIP CONTAINS
IDENTITY
Every Chip has a stable identifier and a publisher. The identifier stays constant while each release receives its own revision number, semantic version, artifact digest and manifest digest. This lets a Machine refer to one exact release instead of trusting a moving download link.
INTERFACE
The interface explains what the Chip accepts and what it returns. A price reader might accept an asset symbol and return a value with a timestamp and source. A transaction Chip might accept an amount and recipient while returning a transaction hash and execution status. Clear interfaces make capabilities replaceable and testable.
PERMISSIONS
The manifest lists the network scopes, contract addresses and functions the Chip needs. Contract access is restricted by both destination and four byte selector. Native value has a maximum. Token spend can be read directly from the encoded call instead of trusting the operator to report what it spent.
BUDGET
A Machine can set a maximum for one invocation and another maximum for a rolling period. A Chip may be allowed to spend fifty units once but no more than two hundred units in an hour. Budget accounting belongs to the enforcement layer, not to the code asking for permission.
ARTIFACT
The artifact is the executable package. firmware hashes its exact bytes and compares that digest with both the manifest and the installed registry revision. A file with the same name but different bytes is not the same release and will not pass verification.
ECONOMICS
The pricing rule states the settlement asset and the maximum price. The revenue route identifies the publisher, executor and protocol recipients together with their exact shares. The route is bound to the signed invocation and the final receipt, so settlement cannot quietly redirect payment.
04 ONE EXECUTION FROM START TO FINISH
The board at the top of this page is a map of this sequence. It is not decorative telemetry.
First, the Machine creates an invocation. The request contains the Chip identifier, exact artifact digest, input, maximum cost, deadline, nonce, Robinhood Chain identifier and revenue route. The Machine signs those fields as EIP 712 typed data.
Second, the runtime validates the complete request. An ordinary wallet can be checked as an EOA signer. A MachineAccount can be checked through ERC 1271. If the input, price ceiling, artifact, deadline, nonce or route changes after signing, authorization fails.
Third, the runtime loads the installed manifest and artifact. It verifies the Chip identity, version, expiry, revocation state, manifest digest and artifact digest. Unknown manifest fields are rejected rather than ignored.
Fourth, the state store claims the nonce and reserves the maximum cost in one SQLite transaction. This prevents the same signed request from being replayed and prevents two concurrent executions from promising the same budget.
Fifth, the approved Sandbox adapter runs the artifact. The Sandbox receives only the interface and capabilities declared for that Chip. If measured cost exceeds the signed maximum, execution fails and the reservation is released.
Sixth, successful output is canonicalized and hashed. The final cost and Execution Receipt are committed together. The receipt records the invocation, Machine, Chip version, artifact, input digest, output digest, timestamps, cost and revenue route digest.
Finally, settlement reads the authorized asset, amount and route. The router permits one settlement for the invocation, splits payment according to the committed shares and does not intentionally keep custody.
05 WHERE ROBINHOOD CHAIN FITS
The chain coordinates trust. It does not need to perform every piece of work.
Robinhood Chain provides the shared record for Chip identity, immutable revision digests, Machine authority, execution attribution and payment. Those are the facts that different participants need to agree on.
Private prompts, local files, credentials and raw outputs do not automatically belong on a public ledger. The actual task can run beside the Machine or through an executor selected by its owner. Only the records required for coordination need to cross the public boundary.
This design also keeps the protocol understandable for EVM developers. MachineAccount is a contract account. PermissionKernel enforces contract authority and rolling budgets. ChipRegistry pins publisher releases. ExecutionReceiptRegistry stores attributable results. RevenueRouter completes settlement.
firmware is an independent project built for Robinhood Chain. The Chip format is deliberately described in portable terms so another compatible runtime can read the same manifest and verify the same artifact.
06 THE CORE COMPONENTS
MACHINE ACCOUNT
The MachineAccount holds onchain authority. Its owner installs and revokes Chips, approves operators and can authorize local invocations with ERC 1271 signatures. Operators cannot use it as an unrestricted forwarding wallet. Every Chip call must pass through the kernel.
PERMISSION KERNEL
The kernel converts a readable installation policy into rules the EVM can enforce. It checks the active registry revision, installation generation, expiry, destination, selector, native value and derived token amount. Reinstalling a Chip creates a new generation so old permissions cannot become active again by accident.
CHIP REGISTRY
The registry creates stable Chip identities and immutable revision history. A publisher can add a new revision or revoke a compromised one, but cannot overwrite bytes that an existing revision already represents. Publisher transfer uses a two step acceptance process.
LOCAL RUNTIME
The TypeScript runtime verifies signed invocations and installed packages before execution. Its state boundary is atomic. A fast memory implementation exists for deterministic tests, while the SQLite implementation persists balances, nonces, reservations and receipts across restarts.
EXECUTION RECEIPTS
A receipt is an attributable record, not a magical proof that every private calculation was correct. It answers a narrower set of useful questions: which request ran, which artifact was selected, when it ran, what it cost and which output digest was produced.
REVENUE ROUTER
The router compares the settlement request with the receipt. Asset, amount, recipients and basis point shares must match. Native ETH and ERC20 settlement are supported, duplicate settlement is rejected and funds move directly to recipients.
07 WHAT EXISTS TODAY
This repository contains the contracts, runtime, persistent execution state, schemas, deployment script and the website reading from those real source files. The current automated suite covers registry revisions, revocation, selector enforcement, rolling budgets, calldata derived token spend, receipt authority, route bound settlement, EIP 712 signatures, ERC 1271 signatures, replay protection, tamper rejection, atomic rollback, restart persistence and interrupted reservation recovery.
The code browser above contains the hand written project files rather than a second collection of presentation snippets. Selecting a component on the board opens the implementation responsible for that part of the system. The goal is to let a developer move from a claim to its code without guessing where the real project begins.
08 HOW I JUDGE THE PROJECT
I am not measuring firmware by how many capabilities can be listed. A smaller set of Chips with clear authority and real use is more valuable than a large catalog nobody understands.
I want to know whether a person can inspect a permission before approving it, whether two implementations can obey the same manifest, whether a Machine can replace one provider without losing its history, whether costs remain understandable and whether failures leave enough evidence to diagnose what happened.
If users only care when a price changes, then the product has not earned durable attention. The work has to be useful when there is nothing exciting to speculate about. That is the standard I want this project to meet.
09 QUESTIONS I AM STILL WORKING THROUGH
How should a Machine evaluate an offchain result when a normal receipt is not enough? Which permission language is precise for developers but still understandable to the person approving it? How should emergency security updates interact with an explicitly pinned artifact? How should nested Chip calls divide responsibility, cost and failure?
I do not want to hide those questions behind a broad roadmap. They are part of the design. The protocol documents, schemas, contracts and tests are published together so each claim can be challenged against an implementation.
10 THE DIRECTION
The next meaningful step is not adding more visual complexity. It is connecting a hardened execution Sandbox, running the system on Robinhood Chain testnet and observing how real Machines behave under limited authority and limited budgets.
The long term idea is simple to state even if it is difficult to build: software agents should be able to acquire useful capabilities without surrendering control, and the people around those agents should be able to understand what was authorized after the work is done.
OPEN SPECLOCAL EXECUTIONEXPLICIT AUTHORITYVERIFIABLE ARTIFACTSROBINHOOD CHAIN
firmware lab note 001 / written from the implementation / September 2026
