nymirad 0.1.5

nymirad 0.1.5, for NEAR testnet with test funds. It goes with web release 0.1.9.

What is new since 0.1.4

• A running nymirad looks for a newer signed attestation policy every 15 minutes, through its own proxy, at the two web hosts. It takes a file only when the pinned policy key signed it and its version is higher than the one in force; a file that fails any check changes nothing. A NEAR AI redeploy no longer needs a new nymirad release or a file copied by hand. Direct transport does not follow.
• The signed attestation policy is version 9 (it was 6 in 0.1.4).

Files

nymirad-0.1.5-x86_64-linux, nymirad-0.1.5-aarch64-macos, attestation-policy.json, TERMS.md, and SHA256SUMS with its signature SHA256SUMS.minisig.

Check it before you run it

V=0.1.5
B=https://github.com/nymiralabs/nymira/releases/download/nymirad-v$V
curl -LO $B/SHA256SUMS -LO $B/SHA256SUMS.minisig -LO $B/nymirad-$V-aarch64-macos   # or ...-x86_64-linux
minisign -V -p web/pins/release-signing.pub -m SHA256SUMS      # from a checkout of the repository
shasum -a 256 -c SHA256SUMS --ignore-missing

The key is web/pins/release-signing.pub (minisign key id 934C176AF34D794D). web/INTEGRITY.md says how to check the key itself.

What this release does not promise

• The Linux binary was built twice in the pinned container from the commit of the tag, and the two builds were equal (3f641859…). No outside party has rebuilt it yet. Other builds of the same commit came out in a second byte form (6a82da01…), as one build of 0.1.4 did; the cause is not found, so an outside rebuild may not match byte for byte.
• The macOS arm64 binary was built on the maintainers' own Mac from a clean checkout of the tag (MACOSX_DEPLOYMENT_TARGET=14.0, --locked), not by the nymirad-macos workflow, whose runner did not start. The signature shows that the project published these bytes. It does not show that the binary matches the source: the macOS toolchain's output is not byte-stable and nobody can rebuild it to the same hash. It needs macOS 14 or later.
• The policy follow has been tested against a fake proxy, in unit tests, and once against the two real hosts without a proxy. A run over Tor from this binary is not recorded yet.
• The binary does not print its own version. The version is in the tag, the file names and the signature.
• Testnet only. The circuits have had no independent review. THREAT_MODEL.md says what each party can see.

nymirad 0.1.4

nymirad 0.1.4, for NEAR testnet with test funds. It goes with web release 0.1.4.

What is new since 0.1.3

• The signed attestation policy is version 6. It lists the compose hash that NEAR AI's model deployment showed on 11 November 2026; chats on that deployment were refused with provenance.verification_failed under version 5. If you downloaded attestation-policy.json from release 0.1.3, replace it with the one in this release.
• Nothing else in the client changed.

Files

nymirad-0.1.4-x86_64-linux, nymirad-0.1.4-aarch64-macos, attestation-policy.json, TERMS.md, and SHA256SUMS with its signature SHA256SUMS.minisig.

Check it before you run it

V=0.1.4
B=https://github.com/nymiralabs/nymira/releases/download/nymirad-v$V
curl -LO $B/SHA256SUMS -LO $B/SHA256SUMS.minisig -LO $B/nymirad-$V-aarch64-macos   # or ...-x86_64-linux
minisign -V -p web/pins/release-signing.pub -m SHA256SUMS      # from a checkout of the repository
shasum -a 256 -c SHA256SUMS --ignore-missing

The key is web/pins/release-signing.pub (minisign key id 934C176AF34D794D). web/INTEGRITY.md says how to check the key itself.

What this release does not promise

• The Linux binary was built twice in the pinned container from the commit of the tag, and the two builds were equal. No outside party has rebuilt it yet. In the first attempt of this release one of two builds differed from the other (a18b82dd… against 99ac000b…); the second attempt gave 99ac000b… twice. The cause is not found.
• The macOS arm64 binary was built by the nymirad-macos workflow on a GitHub runner. The signature shows that the project published these bytes. It does not show that the binary matches the source, because the macOS toolchain's output is not byte-stable and nobody can rebuild it to the same hash. It needs macOS 14 or later.
• The binary does not print its own version. The version is in the tag, the file names and the signature.
• Testnet only. The circuits have had no independent review. THREAT_MODEL.md says what each party can see.

nymirad 0.1.3

nymirad 0.1.3, for NEAR testnet with test funds. It goes with web release 0.1.3.

What is new since 0.1.2

• Budget notes for agents: nymirad agent, a signed spending policy, agent tokens that reach chat and models only, limits, approvals, and an opt-in mode that moves a note to the agent's machine. See BUDGET_NOTES.md.
• --rpc-second asks a second RPC provider for the set size and shows the lower figure.
• Pinned Tor packages for Debian 12 on amd64 and arm64, next to the macOS one.
• Message content sent as a list of text parts is accepted, so IronClaw on Linux works. Anything that is not text is still refused.

Files

nymirad-0.1.3-x86_64-linux, nymirad-0.1.3-aarch64-macos, attestation-policy.json, TERMS.md, and SHA256SUMS with its signature SHA256SUMS.minisig.

Check it before you run it

V=0.1.3
B=https://github.com/nymiralabs/nymira/releases/download/nymirad-v$V
curl -LO $B/SHA256SUMS -LO $B/SHA256SUMS.minisig -LO $B/nymirad-$V-aarch64-macos   # or ...-x86_64-linux
minisign -V -p web/pins/release-signing.pub -m SHA256SUMS      # from a checkout of the repository
shasum -a 256 -c SHA256SUMS --ignore-missing

The key is web/pins/release-signing.pub (minisign key id 934C176AF34D794D). web/INTEGRITY.md says how to check the key itself.

What this release does not promise

• The Linux binary was built twice in the pinned container from the commit of the tag, and the two builds were equal. No outside party has rebuilt it yet. In an earlier attempt of this release one of two builds differed from the other; the cause is not found.
• The macOS arm64 binary was built by the nymirad-macos workflow on a GitHub runner. The signature shows that the project published these bytes. It does not show that the binary matches the source, because the macOS toolchain's output is not byte-stable and nobody can rebuild it to the same hash. It needs macOS 14 or later.
• The binary does not print its own version. The version is in the tag, the file names and the signature.
• Testnet only. The circuits have had no independent review. THREAT_MODEL.md says what each party can see.

nymirad 0.1.2

What changed

• The attestation policy is version 5. For the gateway, it accepts any compose hash (the entry "*"). The gateway's measurements, TCB status and signing key are still checked. The model deployment keeps its exact compose hashes. Version 4 listed one gateway compose hash, which NEAR AI changes between deployments.
• nymirad refuses any policy older than version 5.
• The NVIDIA pins from 0.1.1 are unchanged. Validity checks of the GPU verdict use the time the operator signs, so a wrong clock on your machine does not break them.
• nymirad verify-web accepts the access-control-allow-origin: * header that Cloudflare Pages adds, and prints it as a note.

What is not checked

• The two pinned NVIDIA certificates were not compared with an official NVIDIA source, and the policy marks them so. The NVIDIA root certificate is not pinned.
• A full chat over Tor with this release is not recorded yet.
• The macOS arm64 binary is signed but not reproducible. The Linux x86_64 binary was built twice in the pinned container. The first attempt gave two different hashes and was not published; the second attempt gave the same hash twice. The cause of the first difference is not found.
• No Tor package is pinned for Linux; run your own Tor and pass --socks.

Verify

minisign -V -p release-signing.pub -m SHA256SUMS, then shasum -a 256 -c SHA256SUMS. The release key is web/pins/release-signing.pub. See web/INTEGRITY.md.

nymirad 0.1.1

What changed

• The attestation policy is version 4. It pins the two NVIDIA attestation-service intermediate certificates (GPU Intermediate 005 and 004) that NVIDIA's public key set carried on 5 November 2026. nymirad now checks the GPU verdict against that chain itself: the signature, the nonce, the times, and a certificate path to a pinned certificate.
• A policy without NVIDIA pins is refused, and so is any policy older than version 4.
• NVIDIA's attestation service answers 403 to Tor exit nodes, so the GPU evidence goes through the operator, which forwards it and returns the answer unchanged. nymirad serve --nras-direct sends it straight to NVIDIA instead; NVIDIA then sees your IP address. It is off by default, nymirad status says when it is on, and nymirad never switches to it by itself.
• The operator running at the status URL in the README carries the relay since 5 November 2026.

What is not checked

• The two pinned certificates come from NVIDIA's public key set over TLS. They were not compared with an official NVIDIA source, and the policy marks them so. The NVIDIA root certificate is not pinned.
• The relay was called with recorded GPU evidence and answered with a real NVIDIA token. A full chat over Tor with this release, and a measurement from a Tor exit, are not recorded yet.
• The macOS arm64 binary is signed but not reproducible. The Linux x86_64 binary was built twice in the pinned container and both builds gave the same hash.
• No Tor package is pinned for Linux; run your own Tor and pass --socks.

Verify

minisign -V -p release-signing.pub -m SHA256SUMS, then shasum -a 256 -c SHA256SUMS. The release key is web/pins/release-signing.pub. See web/INTEGRITY.md.

nymirad 0.1.0

First release of nymirad, the local client for the Nymira testnet deployment. Test funds only: the vault is on NEAR testnet. Read the README and THREAT_MODEL.md before you rely on any claim.

Files

• nymirad-0.1.0-x86_64-linux is reproducible. Rebuild it from the tag nymirad-v0.1.0 with scripts/release-nymirad.sh build nymirad-v0.1.0 and you should get the same bytes (sha256 c62ad41f911cd6b1728ed3002f6e5fbe58e5ed43723188a7070c6e397320b282). Two builds in the pinned container matched here. In earlier runs a few builds differed from their twin, and we have not found why. If your rebuild differs, open an issue with both hashes.
• nymirad-0.1.0-aarch64-macos was built on the maintainer's Mac and is not reproducible. The signature shows that the project published these exact bytes, not that they match the source. If that matters to you, build from the tag.
• attestation-policy.json and TERMS.md are the files the binary was built with.
• SHA256SUMS and SHA256SUMS.minisig list every file above. They are signed with the release key in web/pins/release-signing.pub (minisign key id 934C176AF34D794D).

Check the download

minisign -V -p web/pins/release-signing.pub -m SHA256SUMS
shasum -a 256 -c SHA256SUMS

Limits

• nymirad starts its own Tor and runs only a Tor executable whose SHA-256 is built in. The only pinned package is Homebrew's tor 0.4.9.15 for macOS arm64. On Linux, or with another Tor version, run your own Tor and start nymirad with init ... --socks 127.0.0.1:9050. The README has the steps.
• Windows is not supported. Use the web app or WSL2.
• Linux and macOS arm64 only.