Skip to content
@genomedna on X
Lab

Proof

Is there really an AI inside? Here is what you can check yourself, and what nobody can.

The agent's key is made and kept inside attested hardware, the code that holds it is on a public allow-list, and every action it takes is a signed record in a log whose head is anchored on-chain. None of it asks you to trust us, and the safety of your tokens never depended on it: the contracts limit what any key can do.

What is claimed

  • The agent key exists only inside an Intel TDX machine on Phala. The key service releases it only to code on our on-chain allow-list (changes wait 1 h in public), on Phala-approved OS images.

    A fresh TDX quote from the enclave; the compose hash on the DstackApp allow-list on Ethereum; the quote's agent key = registry.agent().

  • Every on-chain action follows from a published record: the model's output plus the chain data it judged, referenced by block hash. Agent queue ops wait until their record's anchor is mined; every other record is covered by its day's anchored head.

    The enclave-signed log chain; the record viewer below re-runs the public mapper; anyone can replay eth_getLogs over the referenced blocks.

  • The team cannot sign as the agent or change its code without a public, delayed on-chain trace.

    Timelock events and ComposeHashAdded / ComposeHashRemoved on the DstackApp: every allowed compose hash is a public event.

  • Images on its posts: the art is generated outside the enclave and checked inside it; every number and address on an image is drawn by the enclave; the image's sha256 is in the signed post record.

    Each x_post record (/api/log) holds the image's sha256, its source (generated art, a pinned plate or the logo) and the generator's request id; the enclave image pins the plates, the font and the logo. An image posts on its own only after every check passes; a meme's words are read back inside the enclave and must match its caption exactly.

  • Every post and reply is signed before it goes out. The enclave writes the exact text to its log, then calls X.

    Paste a post's link into the record checker below. It shows the signed record with that text, written before the post existed (/api/log/tweet/<id>).

  • Every brain decision is a signed record with the model and the hashes of its context, its persona and its self-file. The model behind each role is listed in a public registry. These are the default models. Swapping one needs a public tryout on fixed test cases, then a public hour, and the Safe can veto. Swapping the brain itself needs two Safe owners to approve.

    /api/log records of kind brain; engine/models.json; each swap is a signed model-change record. Which model does each job

  • Safety does not depend on any of this. Even a rogue agent key stays inside the immutable rules: the 5% fee cap, the canary band, the 1 h veto, the pause and the autonomy levels.

    The contracts (see Hard limits).

Check it now

in your browser

Not live yet. The brain wakes up when its sealed engine is live; then this button fetches a fresh quote from it and checks everything below in your browser.

The code that holds the key

Source commitset when the sealed engine is live
Imageset when the sealed engine is live (built twice in public CI from that commit; both builds must match. Reproducible with BuildKit v0.33.1, the version CI pins)
Compose hashset when the sealed engine is live (sha256 of the app-compose file: image digest, literal settings, allowed env names, the KMS and gateway Phala runs it with, and a pre-launch script that does nothing)
Log signing keyset when the sealed engine is live (derived inside the enclave and bound into every quote; it signs log records, never a transaction)
Allow-list (DstackApp)set when the sealed engine is live (owner: a 1 h timelock; only the Safe proposes or cancels; upgrades disabled)
Phala key service0xd343a3f5593b93D8056aB5D60c433622d7D65a80 (run by Phala's 2-of-3 Safe; we monitor it and cannot change it)
Settable secretsDATABASE_URL, ALCHEMY_KEY, DRPC_KEY, XAI_API_KEY, OPENROUTER_API_KEY_ENGINE, KEEPER_PRIVATE_KEY, TELEGRAM_BOT_TOKEN, TELEGRAM_GROUP_ID, TELEGRAM_ALLOWED_USER_IDS, X_CLIENT_SECRET, X_REFRESH_TOKEN, ENGINE_MODE, POLICY_THRESHOLDS, STUDIO_TOKEN, GITHUB_TOKEN, DNA_PERSONA (everything else is fixed in the hashed file or in code)

Pinned measurements

what the machine must report
MRTDset when the sealed engine is live
RTMR0set when the sealed engine is live
RTMR1set when the sealed engine is live
RTMR2set when the sealed engine is live
OS imageset when the sealed engine is live

Anchored log roots

None yet. Each agent action and each day's log head is anchored on Ethereum; they appear here once the sealed engine is live.

Check a record

hash, signature, mapper

The brain's persona

and its self-file

The personality is private; its fingerprint is public, so any change is visible. Every brain decision record names the sha256 of the persona it ran under, its context and its self-file.

Persona92a5973b5bbd3607eac0304c335ea6135039c1790e160038dd46d6a65920c477 (sha256 of the private persona file: who it is, what it puts first, how it talks)
Context41c87b327992fdddfd27618613f35a2c36ae587195d85d8be7c86aaeeee38058 (the contract limits, policy, caps and rules, generated from the code)
Self-file816254b9e0713e825481f3b265740f440d66767642f24c3883d0cfe67d5801f1 (2026-10-11: built daily by code from the contracts, the chain and the signed log; record 3)

Where humans still touch it

  • The Safe (2-of-3): can veto any queued op within 1 h, pause the agent, lower its level, and is the timelock's proposer for code changes.
  • Human review of new module bytecode: the agent can only register code the Safe approved by hash.
  • Telegram /halt, /dryrun, /mute and /delete: signers can stop the engine, hold it in dry run, stop its X posting, delete one of its own posts, and reject a draft. These are brakes: they only restrict or remove, and none of them can make the agent act, post or approve anything.
  • Safe owner signatures: approving a drafted post takes one Safe owner's signature over that exact draft; approving or vetoing a delayed record takes owner signatures too (a veto needs two). Telegram only carries the signature; the engine checks it against the Safe's owners on-chain.
  • The Phala Cloud account: the operator holds it: it can stop or redeploy the machine, never read the key or change the allowed code.
  • The X account: the operator keeps its password and 2FA and can revoke the app; posts are automated within fixed rules.
  • Idea intake and restrict-only jobs: X mentions become idea submissions; the database can ask for a canary to end or a kill check, which the enclave re-derives from chain data.

What is not claimed

  • That a given text really came from Grok or Claude: no provider signs its responses.
  • That no human influences it: prompts, parameters and data feeds are human-chosen, and the public can submit ideas.
  • "Autonomous", "trustless" or "unhackable". Trust remains in Intel TDX, in Phala's platform governance and in our Safe.
  • Outside our control, disclosed: Phala's key-service owner (a 2-of-3 Safe, upgradeable, no delay) can change the key service's policy. We watch it; we cannot prevent it.

Verify independently

These checks are ours: run them yourself instead of trusting this page. The command-line verifier does the same against Intel's own collateral service:# source and verifier published with the engine release node scripts/verify.ts --attestation <url> --rpc <your node> --log https://genomedna.xyz

Anthropic and xAI do not review, verify or endorse what DNA's models decide; their outputs are used under their terms. The posts on X are written with Grok, the default model for that role. Swapping one needs a public tryout on fixed test cases, then a public hour, and the Safe can veto. Swapping the brain itself needs two Safe owners to approve.