The control room for your state machine. Everything that belongs to this machine lives here — its identity and secrets, compute credits, verification envelopes, the node it runs on, and the settings that govern it. Pick a tab below; each opens as its own page with its own link.
Your account
This machine
Frequently asked
What is the Vault?
The Vault is your machine's control room. It's where you manage everything that belongs to this one state machine: its identity and encrypted secrets, its compute credits, the CKO envelopes that let anyone verify a result, the node it runs on, and the settings that govern it. Nothing here is shared with another machine.
Why does each tab have its own URL?
Every tab is a real page: opening Secrets takes you to /vault/#secrets, opening Compute credits to /vault/#credits, and so on. That means you can bookmark a tab, refresh without losing your place, share a direct link, and use the browser's back button — the same as any proper website.
Is my navigation recorded?
When you're signed in as the owner, each tab you open is written to your machine's entangled state as a navigation transition — a signed, hash-linked row you can review in the State observer. Your machine keeps an honest record of its own use; nothing is hidden and nothing is editable after the fact.
Where are my keys and secrets?
Under Secrets. Values are HITE-encrypted — the Vault shows only names, never the secret values themselves. Your recovery equation and build keys live there too; guard them, because there is no password reset.
What are compute credits?
Credits (ZQT) are what your machine spends to run verified computations. The Compute credits tab shows your balance, the per-tick mint and burn, and your full ledger. Every charge is itself a transition on your entangled state.
—
Your machine's home — its live heartbeat, identity and genesis. Everything here is unique to this machine. Tap a section to open it. Keys and secrets live under Secrets.
This machine's heartbeat — beating since its genesis tick
Your machine's public identity on the Zeq network — the equivalent of an account profile. Every Zeq machine is a live, always-on entity with its own address, owner, wallet and heartbeat. The values below are how the rest of the network — and your own code — find and address this one.
Machine is the human-readable handle (its slug): the address where this machine's public page lives. Owner ZID is the cryptographic identity that owns it, derived from your secret equation — it is the root of every permission this machine holds. Email alias is a routable @zeq.me address bound to the machine for zeqMail. Plan / tier sets your compute burn rate and daily bandwidth. Public URL is the live page anyone can open. Tap Copy on any row to wire that value into your own tools.
IdentityLoading…
Activating your email alias: the address above is reserved for this machine, but it only starts sending and receiving mail once you create an account on Zeq.me — the mail service that powers @zeq.me addresses. Set it up there first, then this alias is live.
What's the difference between the Machine handle and the Owner ZID?
The Machine handle (slug) is the public address where this machine's page lives — human-readable and shareable. The Owner ZID is the cryptographic identity that owns it, derived from your secret equation; it's the root of every permission this machine holds.
Can I change my Machine handle or ZID?
Your ZID is permanent — it's derived from your equation and can't be reissued. The handle is fixed at genesis too, so the public address stays stable for anyone linking to your machine.
Is my @zeq.me email live automatically?
No. The alias is reserved the moment your machine is born, but it only starts sending and receiving once you create an account on Zeq.me, the mail service that powers @zeq.me addresses.
What does my plan / tier actually change?
Your tier sets your daily bandwidth and gives a discount on paid compute. It doesn't change your identity — only how much room you have to work before you need paid credits.
State · genesis
From its very first tick, every Zeq machine writes an immutable, hash-linked state history to the network's shared public ledger — the same ledger the whole community can read. These two links open this machine's record.
The state explorer is the live view of this machine on the network: its heartbeat, wallet, transitions and audit chain, updating in real time — think of it as this machine's public profile page. The genesis certificate is the permanent, verifiable record of the exact moment this machine was born — its genesis tick, owner and proof — a certificate you can share, print or archive.
About state & genesis
What's the difference between the explorer and the genesis certificate?
The state explorer is the live view of this machine — heartbeat, wallet, transitions and audit chain, updating in real time (its public profile). The genesis certificate is the permanent, verifiable record of the exact moment it was born.
Is my machine's history public?
Yes — from its first tick, every machine writes an immutable, hash-linked history to the network's shared public ledger, which the whole community can read.
Can I share or archive the genesis certificate?
Yes — it records the genesis tick, owner and proof, so you can share, print or archive it as a verifiable keepsake of when this machine came alive.
Two ways to keep a secret: a server-encrypted secure context that replaces your .env, or a zero-knowledge vault encrypted in your own browser. Tap one to open it full-screen.
ZSC
ZSC — Zeq Secure Context, your .env replaced.
The Zeq Secure Context (ZSC) is this machine's own encrypted key–value store — the framework's replacement for the .env file. Store a secret once — an API key, a provider credential, any environment value — and the value is AES-256-GCM encrypted at rest before it ever touches the database; the plaintext never lives on disk or in your repo. Any app you build reads it at runtime with your machine key, so you rotate a credential without redeploying. Every successful read is hash-linked into the entangled state with a verifiable proof, and you can grant or revoke access per secret. This page lists your secrets by name only — never their values.
Total secrets—
Total reads—
Awaiting rotation—
CipherAES-256-GCM
name
owner ZID
reads
last read
grants
actions
Loading…
About Secure Context
What is ZSC and why replace the .env file?
The Zeq Secure Context is this machine's own encrypted key–value store — the framework's replacement for the .env file. The plaintext never lives on disk or in your repo, and you rotate a credential without redeploying.
How is a secret protected?
Every value is AES-256-GCM encrypted at rest before the row ever reaches the database. The PBKDF2-derived key uses HULYAS field constants as salt material.
Who can read a secret?
Any app you build reads it at runtime with your machine key, and you can grant or revoke access per secret. Every successful read is hash-linked into the entangled state with a verifiable proof.
Can anyone see my secret values here?
No. This page lists your secrets by name only — never their values. The plaintext is never displayed.
Integrate
Pull any secret into your own app at runtime — authenticated by the machine key alone. Generate one under Secrets → Credentials & keys.
Pull a secret from any app
Generate a machine key under Secrets → Credentials & keys first — the snippet fills in automatically.
How it works
Set a secret
The value is AES-256-GCM encrypted at rest before the row ever reaches the database. The PBKDF2-derived key uses HULYAS field constants as salt material, so the plaintext never lives on disk or in your repo.
Read a secret
Every successful read emits one secret_read row in the audit chain, carrying a verifiable proof_digest = SHA-256(name | zid | transitionId | purpose). The entangled state is hash-linked, so tampering breaks validation.
A denied read
A blocked read emits secret_denied. After 5 denials in a 60-Zeqond window further attempts are rate-limited, and that limit persists across permission changes.
Auto-rotation
Secrets given an expires_zeqond are re-encrypted automatically when the rotation daemon ticks — roughly every 100 Zeqonds. Each rotation emits secret_rotated.
From the CLI
The same actions run headless: zeq context list · set · rotate · grant · revoke · audit · delete.
Credentials & keys
Keys are secrets, so they live here — one home for every key. Pick a key to reveal, copy, mint or revoke it. Each opens on its own page.
About keys
Why are all my keys here?
Keys are secrets, so they have one home under Secrets — not scattered across Overview or the admin consoles. Each key type opens on its own page.
Which key do I use where?
Build key goes in your own code (SDK / physics). Machine key lets a device act as the machine (ZSC + agent runtime). Publish key ships pages from CI. BYOK are your own LLM provider keys the Pulse uses.
Build key zeq_ak_
Your developer API key — put it in your own code. Authenticates every call to the Zeq SDK and physics engine (/api/zeq/*, /api/mcp). Send as Authorization: Bearer zeq_ak_…. No daily call cap; you only spend credits on actual compute.
Machine keys zsm_
Let a trusted outside client act as this machine — reaching its secure context (/api/zsc/*) and agent runtime. Send in the X-Zeq-SM-Key header. A key is shown once at generation — copy it immediately. Mint, list and revoke all live here.
prefix
name
scope
created
Loading…
Publish key
A machine-scoped key that authorises publishing pages under /s/<machine>/ from CI or the API. Rotate it any time; the old one stops working.
Bring-your-own LLM keys BYOK
Your own provider keys (OpenAI, Anthropic, Fireworks, …), AES-256-GCM encrypted at rest, account-scoped. The Pulse and agents use them instead of the shared key. This is the single home — the same store the workbench Pulse reads.
Loading…
Identity & recovery
You're already signed in — that is your proof of ownership. To change any credential you only do two things: ask the machine a question, and enter your PIN. The machine generates the new credential, retires the old, and hands you a PIN-encrypted recovery file. Pick one:
Recovery password
An optional scrypt second factor, distinct from your PIN + .ZEQ file. It proves ownership when you later rotate your equation. There is no password reset without one of your recovery methods, so keep it safe.
About Identity & recovery
Do I need to upload anything?
No. You're already signed in — that's your proof. Just ask the machine and enter your PIN; the machine does the rest and gives you the new recovery file.
Which one do I pick?
Simple rotates the password you sign in with. Expert rotates the underlying equation (your ZID stays deterministic across nodes). Recovery file just re-downloads a fresh .ZEQ without changing anything — handy if you lost your file.
Change password · Simple
You're already signed in, so changing your password takes two things: ask the machine a question, and enter your PIN. The machine generates a fresh password, retires the old one, and hands you a PIN-encrypted recovery file to keep.
About this
Do I need to upload anything?
No. You're already signed in — that's your proof. Just ask the machine and enter your PIN; the machine does the rest and gives you the new recovery file.
What happens to my old password?
It's retired the moment this succeeds and every open session signs out. Sign back in with the new file + your PIN.
Change equation · Expert
You're already signed in, so changing your equation takes two things: ask the machine a question, and enter your PIN. Identity is deterministic — the same equation derives the same ZID on every node — so the machine rotates this machine to the new one everywhere, retires the old, and hands you a PIN-encrypted recovery file.
About this
Do I need to upload anything?
No — you're signed in. Ask the machine, enter your PIN, and it rotates the equation and gives you the new recovery file.
Is my ZID the same on every node?
Yes — deterministic. The new equation derives the same ZID everywhere, so rotating changes it consistently across the whole network.
Recovery file
Get a fresh recovery file. You're signed in, so all it takes is a question for the machine and your PIN. Choose how it's packaged: a standard .ZEQ, a discreet file, hidden inside a photo or PDF you upload, or a ZIP. The PIN encrypts it — that's the only thing you keep. Upload this file + PIN on any Zeq sign-in to get back in.
About this
Can I hide it inside a photo or PDF?
Yes — pick “Hide inside a photo or PDF”, upload any image or PDF, and the encrypted credential is embedded inside. It still opens as a normal photo/PDF; only your PIN extracts it on sign-in.
Audit trail
Every read, denial and rotation for a secret is a signed row in the entangled state. Pick a secret to see its history — each line carries a verifiable ZeqProof.
zeqond
action
when
proof
Pick a secret above to load its audit trail.
About the audit trail
What gets recorded?
Every read, denial and rotation for a secret is a signed row in the entangled state — each with a verifiable ZeqProof.
What is the proof on each line?
A read carries proof_digest = SHA-256(name | zid | transitionId | purpose). Because the entangled state is hash-linked, any tampering breaks validation.
What happens after repeated denials?
A blocked read emits secret_denied. After 5 denials in a 60-Zeqond window, further attempts are rate-limited — and that limit persists across permission changes.
Why does this matter?
It gives you a tamper-evident history of who touched which secret and when — the accountability layer that makes ZSC safe to trust.
ZeqVault
One zero-knowledge vault — equations and passwords.
ZeqVault is your personal, HITE-encrypted store for two kinds of secret: your identity equations (the equations you sign in with, plus any backups) and site passwords (equation-derived passwords for websites). Both live in the same vault because they share the same crypto — AES-256-GCM, encrypted in your browser and unlocked by a PIN that never leaves this device; the server only ever holds opaque ciphertext. Use Generate Equation or Add Equation for identities, and Generate Site Password for websites. This is distinct from Secure Context above, which is server-side and read by your apps at runtime.
Loading the equation & password vault…
About ZeqVault
What does "zero-knowledge" mean here?
Everything is AES-256-GCM encrypted in your browser and unlocked by a PIN that never leaves this device. The server only ever holds opaque ciphertext — it can't read your equations or passwords.
Why are equations and passwords in the same vault?
They share the same crypto, so they live in one store: your identity equations (the ones you sign in with, plus backups) and your site passwords (equation-derived passwords for websites).
How is this different from Secure Context?
ZeqVault is client-side and personal — for you. Secure Context is server-side and read by your apps at runtime. Different jobs, same machine.
How do I add items?
Use Generate Equation or Add Equation for identities, and Generate Site Password for websites.
Credits are your compute fuel; envelopes are the coins your compute mints. Everything you spend, claim, mint, swap and send lives here — tap a row to open it full-screen.
Balance & economy
Two things live in your account: fuel and coins.
Two moving parts. Credits are fuel — a 1,287 welcome grant, 128 more on daily claim, plus any paid credits; they run your compute and never leave your account. ZEQ envelopes are coins — each compute mints one worth exactly what it cost (V = cost, 1:1), and they're the only asset that moves. The panel below reads live from your entangled state. Open a card for the detail.
Free credits — your claimable compute fuel
—
Paid credits
—
Envelopes minted
—
Tier
—
Your economy
EconomyLoading…
How the credit economy works
What exactly is a compute credit?
A credit is fuel for one unit of compute. You never trade credits or send them to anyone — they sit in your account and are consumed as you run operators, contracts and agents. There are two pools: free credits (the 1,287 welcome grant, the 128 daily top-up, and any promo credits) and paid credits (bought with crypto or earned by burning envelopes). Both burn identically when you compute; the only difference is what they mint.
What is a ZEQ envelope, and why is it the only thing that moves?
Every compute mints one envelope — an immutable proof-of-compute receipt signed with the run's zeqProof, valued at exactly the credits that compute cost (V = cost, 1:1). Because an envelope is a signed receipt of real work, it is the framework's unit of transferable value: you can send it, burn it back into credits, or redeem one handed to you. Fuel stays put; coins circulate.
Free credits vs paid credits — what actually changes?
Spending free fuel buys you the result of a compute, but the envelope it mints backs the Foundation, not you. Spending paid fuel mints the whole envelope to you — a coin you keep. So free credits are perfect for exploring and building; paid credits are how you accumulate transferable value.
What does my "tier" control?
Your tier sets your daily claim and your monthly bandwidth allocation — how much headroom you have before you need paid fuel — and higher tiers get a discount on paid compute. It's a bandwidth model: a bigger tier means more room to work, not a different kind of credit.
What does "Locked" mean?
Locked credits are reserved by an in-flight operation (for example a contract that has committed to spend on its next fire) and aren't available to spend elsewhere until that settles. It's normally 0.
Where do these numbers come from — can I trust them?
Every figure is read live from your machine's entangled state, where each mint and transfer is hash-linked and tamper-evident. Nothing on this page is a training-time guess or a placeholder; open Costs & transparency to see the raw ledger and verify any proof yourself.
Claim credits
Free fuel, topped up daily.
Daily credits refill your free fuel — but only when you're down to your last 5, so it goes to people actively computing. Claiming mints nothing (free-fuel computes send their envelope to the Foundation). If you have promo credits waiting, a second button appears; the meter below shows this month's compute. Open a card for the detail.
Claim your credits
Compute this month
About claiming
Why can't I claim whenever I want?
The daily top-up unlocks only when your free balance drops to 5 or fewer. This "last-5" rule means the free pool refills the people who are genuinely out of fuel, instead of rewarding hoarding. If the button says you're not eligible yet, you simply still have fuel to spend.
How big is the daily top-up?
Free tier tops up by 128 credits per claim; paid tiers claim a slice of their larger monthly allocation. Your exact daily figure is shown as Daily claim on the Balance & economy page.
What are promo credits?
Promo credits are extra free fuel granted outside the daily rhythm — a launch campaign, a referral reward, or an operator top-up. The "Claim promo credits" button only appears when you actually have some waiting.
What is the "Compute this month" meter?
It reports the compute you've drawn in the current billing period — used, remaining, and the period label — so you can see your burn rate at a glance. It appears once there's usage to show.
Does claiming mint me an envelope?
No. Claiming just refuels your free pool. Envelopes are minted by compute, not by claiming — and a compute paid with free fuel mints its envelope to the Foundation.
Envelope coins
The coin your compute mints.
A ZEQ envelope is minted only by compute, valued at exactly what it cost (V = cost, 1:1) and signed with its zeqProof. It's the one asset that moves: send it to a ZID, burn a set back into credits (irreversible), or redeem a bearer coin handed to you. Your ZID is the address others send to. Not a blockchain — the entangled state enforces single-spend. Open a card for the detail.
Your envelopes
EnvelopesLoading…
Send envelopes
Redeem a coin
Paste a bearer .ZEQ coin, QR or link to pull it into your account — redeemable only once.
Receive
Share your ZID — all anyone needs to send you an envelope. Credits can't be received; they're your fuel.
—
Working with envelopes
How is an envelope actually minted?
You don't mint one directly — you run a compute. The engine mints exactly one envelope for that run, stamps it with the run's zeqProof and a value equal to the credits it cost, and issues it to you (paid fuel) or to the Foundation (free fuel).
Send vs burn vs redeem — what's the difference?
Send transfers a whole envelope to another ZID. Burn destroys a set of your own envelopes and credits your fuel pool 1:1 with their value — a one-way trade of coin for compute. Redeem pulls a bearer coin someone gave you into your account.
Is burning reversible?
No. Burning is irreversible: the envelopes are consumed and you receive credits in exchange. The confirmation prompt exists precisely because you can't undo it.
Is this a cryptocurrency / blockchain?
No. Envelopes settle on your machine's entangled state — a hash-linked, single-spend ledger — not a proof-of-work chain. There's no mining and no gas; value is minted by verified compute.
Is there a fuller envelope manager?
Yes — the dedicated Envelopes tab organises them into folders, adds metadata, and handles bulk transfers, exports and cross-domain moves. This page covers the everyday send / burn / redeem / receive.
Top up with crypto
Buy paid ZEQ from the Foundation pot.
Buy paid credits from the Foundation pot at the live oracle rate. Pick a rail, size it in USD, and the panel previews what to send and what you'll receive. It's non-custodial: you send the crypto, paste your TX hash, and claim — nothing is auto-debited. Open a card for the detail.
Choose a rail
You send—
You receive—
Foundation pot—
—
About the swap
What is the Foundation pot?
It's the shared reserve of paid ZEQ that swaps draw from, backed by the envelopes free-fuel computes mint to the Foundation. Its live balance is shown in the preview so you can see there's headroom before you send.
How is the rate set?
By the framework's price oracle, which tracks BTC and ETH against USD per Zeqond. The "You send" figure is your USD sized at the live rate; "You receive" is the ZEQ it converts to.
Why do I paste a TX hash instead of it happening automatically?
Because the flow is non-custodial: you keep your keys and send the crypto yourself. Pasting the confirmed transaction hash is how the framework verifies your payment landed before crediting your ZEQ.
Why can't I pay in right now?
The pay-in step only opens when the Foundation pot has ZEQ to give. Live rates always show so you can see the swap is running; if the pot reads 0, it's still filling from network compute and the pay-in unlocks automatically once there's inventory.
Costs & transparency
Every credit is accountable.
See both sides of the economy: what a compute will cost (derived from its operator chain) and what it did cost. Below, your activity feed lists every mint and transfer, each stamped with its Zeqond — and because every row is hash-linked, the whole network's totals are publicly verifiable. Open a card for the detail.
What a compute costs
A worked example, priced live from the framework's cost function — the same numbers you'd be charged if you ran it.
Example computeLoading…
Your activity
Your most recent mints and transfers, newest first — read live from your entangled state.
From its operator chain. A base cost per operator, plus surcharges for cross-domain chains, proof generation and ZSP-wrapping, sums to the total — which is then priced in USD at the list rate. KO42 is always the carrier operator, so it's in every chain.
What's in my activity feed?
Two kinds of row: mints (an envelope your compute created, with its operator chain and Zeqond) and transfers (envelopes sent to or received from another ZID). They're merged and sorted newest-first.
What can other people see?
The network totals are public, but per-account detail is yours. The Observer shows this machine's chain; the transparency page shows only aggregates — never your secrets, which are listed by name alone elsewhere.
How do I verify a proof myself?
Every row carries a zeqProof digest. Open the Observer, find the transition, and check its hash link against the previous row — if anything were altered, the chain would fail to validate.
Your ZEQ envelopes — the coins your compute minted.
Each envelope is a signed proof-of-compute receipt worth exactly what its compute cost. Search yours, send them to a ZID, bulk-send at random, or redeem a bearer coin someone handed you. Soulbound proofs never move; only movable coins transfer. Open a card for the detail.
–
Envelopes
–
Showing
–
Value on this page (credits)
🔍
Send many at oncetoThe chain picks that many of your movable coins at random. No limit. Soulbound proofs never move.
Loading your envelopes…
Bearer coins are PIN-locked and escrowed until redeemed — there is no password reset, so keep the PIN. A saved coin leaves your live wallet and only returns when redeemed. Every envelope links to the entangled-state observer and to its full proof-of-compute receipt.
Verify an envelope
Any signed result can be re-proven against the machine — paste nothing secret; the proof is public math.
About envelopes
What is an envelope, exactly?
An immutable proof-of-compute receipt minted by one compute run, valued at exactly what that compute cost (V = cost, 1:1) and signed with its zeqProof. It's the only transferable asset in the framework.
Movable coins vs soulbound proofs?
Movable coins can be sent, bulk-sent or redeemed. Soulbound proofs never move — they stay bound to your machine as permanent evidence of work.
What is a bearer coin?
A coin exported as a .ZEQ file, QR or link, PIN-locked and escrowed until redeemed. There's no password reset, so keep the PIN — a saved coin leaves your live wallet and only returns when redeemed.
How does bulk send work?
Enter a count and a recipient ZID; the entangled state picks that many of your movable coins at random and transfers them. No limit, and soulbound proofs are never touched.
Can anyone verify an envelope?
Yes. Every envelope links to the entangled-state observer and to its full proof-of-compute receipt — the proof is public math, so paste nothing secret.
ZEQ DNS — your .hz names.
Human names for your machine, entangled with this ZID. Buy with compute credits or by burning an envelope — first come, first served. Resolution rides ZEQ Edge; no ICANN.
.hz
Price: — credits / year
Your names
NamesLoading…
About ZEQ names
What is a .hz name?
A human-readable name for your machine — ZEQ DNS — entangled with your ZID. It's yours, first come, first served, and resolves over ZEQ Edge (no ICANN).
How do I pay for one?
With compute credits (your fuel pool) or by burning envelopes whose total value covers the price. The whole envelope is consumed when you burn it.
How long does a name last?
You register per year (1, 2, 3 or 5). The price shown is per year and multiplies by the term you pick.
Where does it resolve?
Resolution rides ZEQ Edge — the framework's own routing — so your .hz name points at your machine without any traditional DNS registrar.
Your own entangled state, and the whole network's. Open your live observer, set whether your state is public or private, then explore every machine, agent, contract, page and source across the network.
Your state
Loading your state…
State settings
Your state is private by default. Flip the switch to make this machine public — it then appears in the network directories below and at /s/<machine>/. Flip it back any time.
What's the difference between "your state" and "the whole network"?
Your state is this machine's own entangled state — its heartbeat, wallet, transitions and audit chain. The whole network is everyone: aggregate figures and every machine that chose to be public.
Is my state private?
Yes — private by default. Nothing of yours appears in the network directories until you tick Public in State settings above. Private state never leaves your machine.
Are the numbers real?
Yes. Every directory reads live from the chain and the economy oracle each time you open it — nothing is stored copy or invented.
Your machine's place on the community network — join it, and lend it compute. Tap a row to open it.
About Your Node
Is connecting to the network the same as contributing compute?
No — they're two separate things. Connecting registers this machine as a member node: a public presence on the community network, with no bond and no shared secret. Contributing lends your CPU to other machines' jobs and requires a bond. You can connect without ever contributing.
Is bonding a deposit?
No. Your 1,000 envelopes stay in this vault, owned by you, the whole time. Bonding only marks them immovable and records an attestation naming exactly which ones. Nothing is transferred to the Foundation — there is no pool.
How do I get paid?
You lend your CPU to other people's computations and are paid in envelopes for the work your machine completes.
What happens if a result I return is wrong?
If a result you return is proven wrong — the Foundation's independent re-execution disagrees with you and agrees with the challenger — the whole bond is withheld. If it matches neither, the job is marked not reproducible and nobody is slashed.
Can I contribute and run my own experiments at the same time?
No. Switching to contributing preempts your own running work — the two states can't both be true. That's what stops a machine from selling the same cycles twice.
Do I have to contribute just because I've joined?
No. Joining only advertises this machine on the network registry. Contributing is a separate, deliberate step: you bond envelopes and start taking network jobs. Leave either at any time.
Connect
Put this machine on the network — as itself.
Connecting registers this machine as a member node on the community network — a public presence recorded in the network registry, and nothing more. There is no bond and no shared secret: joining simply announces that this machine exists and is reachable, so other machines and people can find it. It is entirely separate from contributing CPU — a member node advertises itself; a contributing node actually runs other machines' jobs. You can be a member without ever contributing, and you can leave the registry whenever you like.
Membership
This machineLoading…
Members on this node—
About connecting
What does connecting actually do?
It registers this machine as a member node — a public presence recorded in the network registry, with no bond and no shared secret. Joining announces that the machine exists and is reachable, so the rest of the community can find it.
Is joining the same as contributing compute?
No. A member node advertises itself on the network; a contributing node actually runs other machines' jobs and puts up a bond. The two are entirely separate — see Contribute for lending CPU.
Can I leave after joining?
Yes. Membership is not a commitment — you can remove this machine from the registry at any time, with no bond to release and no penalty.
Contribute
Lend your machine's compute — get paid in envelopes.
Contributing lends this machine's CPU to other machines' computations, and pays you in envelopes for every job it completes. To take network jobs you bond 1,000 envelopes — and bonding is not a deposit: the envelopes stay in this vault, owned by you, the whole time. Bonding only marks them immovable and records an attestation naming exactly which ones. There is no pool, and nothing is transferred to the Foundation. You're paid per job, as your machine returns verified results.
Bond & contribute
StatusLoading…
What you agree to
PolicyLoading…
You cannot contribute and experiment at once. Switching to contributing preempts your own running work — the two states cannot both be true, which is what stops a machine selling the same cycles twice.
If a result you return is proven wrong, the whole bond is withheld. "Proven" means the Foundation's own independent re-execution disagrees with you and agrees with the challenger. If it matches neither, the job is marked not reproducible and nobody is slashed.
No. Your 1,000 envelopes stay in this vault, owned by you, the whole time. Bonding only marks them immovable and records an attestation naming exactly which ones. Nothing is transferred to the Foundation — there is no pool.
How do I get paid?
You lend your CPU to other people's computations and are paid in envelopes for the work your machine completes.
Can I contribute and run my own work at the same time?
No. Switching to contributing preempts your own running work — the two states can't both be true. That's what stops a machine from selling the same cycles twice.
What happens if my result is wrong?
If a result you return is proven wrong — the Foundation's independent re-execution disagrees with you and agrees with the challenger — the whole bond is withheld. If it matches neither, the job is marked not reproducible and nobody is slashed.
Manage machine.
Everything that runs on your machine. Each console opens with this machine selected.
The Vault holds the machine's settings and secrets. Machine settings (display, members, status, danger zone) are native here; your keys live in Secrets. Building — state contracts, pages, HTML, agents — happens in the Pulse workbench on your machine's page, not in the Vault. The old contract / AI / site admin consoles were editors, so they moved to the workbench where the live tools are.
Who can see these controls?
Only accounts with manage rights on this machine. Everything here acts on the machine currently selected — the console opens already scoped to it, so you are never editing someone else's machine by accident.
Do these change anything on their own?
No. Opening a console just shows you the current state. Nothing is written until you make an explicit change, and destructive actions live in a clearly marked danger zone.
Your page
This is what visitors see at your public URL. Preview it live below, copy the link to share, and open any page you've published. To build or edit a page, open Pulse and ask it.
The live HTML for your public page. Edit it here and Save & publish — it goes straight to /s/<machine>/. This edits the same stored page the workbench builds.
Every page you've published on this machine. Each is live at its own URL.
page
title
published
Loading…
Machine settings
Everything for the machine you're signed in as — — · role — · status —. Machine keys live under Secrets → Credentials & keys. Pick a control — each opens on its own.
Your machine's name and purpose, and whether it's visible in the explorer and at /s/<machine>/.
Members
Who can manage this machine. Add a member by ZID, or change a role. Everything writes straight to this machine.
ZID
role
added
Loading…
Status & danger zone
Owner only. Changing status affects whether this machine ticks and is publicly reachable.
Machine status
Your account — the things that belong to you rather than to any one machine. Everything else the old developer portal held is now native in the Vault: keys & secrets under Secrets, credential changes and the recovery password under Secrets → Identity & recovery, and machine settings under Manage machine. Tap a section to open it.
Delete account
Permanent deletion isn't self-serve — it cascades through your state machines, credits balance, audit logs and Pulse. Email zeq@1.287hz.com from any address with your ZID in the subject and we'll process it within one Zeqond cycle.
Your account is your identity (ZID) and the controls that aren't tied to a single machine — like deleting the account. Everything about a specific machine — its keys, settings, members, wallet — lives under that machine's own tabs (Secrets, Manage machine, Compute credits).
Is my identity the same across machines?
Yes — it's deterministic. Your ZID is a pure function of your equation, so the same equation derives the same ZID on every node of the network. Rotating your equation (under Secrets → Identity & recovery) changes it everywhere, consistently.
Where did theme / appearance go?
The Vault has one fixed look, so there's no per-account theme to set — that control was retired. Nothing else moved: your keys are under Secrets → Credentials, recovery under Secrets → Identity & recovery.
Run a computation — then verify its envelope.
Live playground against this machine. KO42 is mandatory and always operatorChain[0]; the 7-step protocol caps a chain at KO42 plus three. Uses POST /api/zeq/prove, which needs no key.
Operator chain
—
Verify an envelope
Structural checks run here, offline — precision_actual ≤ precision_bound and KO42-first are settled with no network. The ed25519 signature needs the node's public key and is reported, not assumed.
Every computation this machine has run, in one place — the entangled-state timeline. See what fired, when, and the state it produced.
KO42 is the metric tensioner — it keeps every result phase-locked to the 1.287 Hz clock. The protocol makes it operatorChain[0] on every chain, then allows up to three more operators after it.
Do I need a key to run one here?
No. This playground uses POST /api/zeq/prove, which needs no key. It runs the full 7-step protocol against this machine and returns a sealed envelope you can verify.
What does "verify an envelope" prove?
The structural checks — precision_actual ≤ precision_bound and KO42-first — settle offline with no network. The ed25519 signature needs the node's public key, so it is reported rather than assumed.
Where do my computations go?
Every one is written to this machine's entangled-state timeline. Open the Observer above to see what fired, when, and the state it produced.
Where your data lives — you choose.
Every value is sealed in this browser under a key derived from your equation — the node only ever sees ciphertext and a blind index. The only choice is where the sealed blob is kept.
—
Keep sealed records as real files in a folder you can open — every file is ciphertext. Skip it and records stay in this browser (still sealed).
—
Unlock your data — derive your key here, from your equation
Your key is derived here and never leaves this tab.
Your records — sealed on store, unsealed on fetch, in this browser
—
Records
no records yet
About your data
Who can read my records?
Only you. Every value is sealed in this browser under a key derived from your equation. The node only ever sees ciphertext and a blind index — it can't read your data even if it wanted to.
Where is my key?
Derived here, in this tab, from your equation — and wiped the instant the key is ready. It never leaves your browser and is never sent to the node.
What's the difference between "on this device" and "across the network"?
Both seal the data the same way. The only choice is where the sealed blob is kept: as files in a folder you pick (or this browser), or replicated across the Zeq network. Either way it's ciphertext.
Can I keep records as real files?
Yes — choose a folder and each record is written as an encrypted file you can open and back up. Skip it and records stay sealed in this browser.
Every tool on this machine — call it by hand.
The same tools your AI agent reaches for, exposed as buttons. Pick a group, choose a tool, and run it live against this machine over MCP.
About these tools
The 7-step protocol
Every computation walks the same road: select the domains, bind the operators, validate the inputs, compute, verify against the precision bound, pulse — align to the 1.287 Hz clock — and return a sealed envelope. No step can be skipped.
The 0.1% precision gate
A result must land within ≤ 0.1% of its verified bound before the machine will hand it to you. Out of bound? The machine triggers a shift and recomputes.
ZeqProof — every answer signed
Every envelope carries a ZeqProof: HMAC(operator | result | zeqond). Run verify with the proof and the original values — if a single digit changed in transit, the proof breaks.
Humans and agents — same door
These tools speak MCP — the same protocol your AI agent uses. Every tool here is equally callable by a human clicking and an agent reasoning. One machine, one protocol, two kinds of mind.
Node administration.
Node-owner controls for this Zeq node — genesis, network wallets, co-admins and payments. Visible only to the node admin.
Only the node admin — the owner of this Zeq node. Node administration sits above any single machine; it governs the whole node the machines run on.
What is in the admin panel?
Genesis, the nodes on this network, the network wallets, co-admins, and payments. It is the operator-level view, separate from managing your own machine.
How is this different from Manage machine?
Manage machine controls one machine you own. Node administration controls the node itself — the infrastructure every machine depends on.
—
Loading…
+ Add secret
Substitutes for process.env.NAME. Use SCREAMING_SNAKE_CASE.
Encrypted client→server over HTTPS, then AES-256-GCM at-rest. Never displayed again.
ZEQ-SYS for system secrets. A specific ZEQ7… ZID binds it to that user.
86,400 Z ≈ 18.6 hours. Daemon re-encrypts automatically when crossed.