refactor: rename dyaka-noir-token to x-token - #2
Merged
Merged
Conversation
Directory circuits/dyaka-noir-token -> circuits/x-token, package dyaka_noir_token -> x_token, authors Dyaka -> libid, and the dyaka references in scripts, workflows and docs go with them. The README historical note keeps one deliberate mention of the old name: v0.1.0 shipped the circuit as dyaka_noir_token, and auditors need that thread. The rename never touches the ACIR bytecode, so the deployed on-chain verifier is unaffected. Verified locally with the pinned toolchain (nargo 1.0.0-beta.20, bb 5.0.0-nightly.20260324): vk and vk_hash are byte-identical before and after the rename via the exact scripts/build.sh release path (vk sha256 fe6a945bf161fac154633f3dac1b86bd077de2a9e13c33eb 56559bc7e128ce8c, vk_hash 0x0ef6521315935086e2161c8343e6e402c97e16770e1d b9d53955fe1ca8f86e67). nargo fmt --check clean, x_token 9/9 tests pass, jwt_email untouched, shellcheck clean. Assisted-by: Claude Fable 5 Signed-off-by: xgreenx <xgreenx9999@gmail.com>
Assisted-by: Claude Fable 5 Signed-off-by: xgreenx <xgreenx9999@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scrubs the dyaka branding from this repo by renaming the X login circuit:
circuits/dyaka-noir-token→circuits/x-token; Nargo packagedyaka_noir_token→x_token; authors["Dyaka"]→["libid"]scripts/gen-verifier.sh(usage text),.github/workflows/ci.yml(comments, the 9-tests note),README.md(circuits table, gen-verifier example, extraction paragraph), and themain.nrheader commentdyaka_noir_tokenmention is deliberate — v0.1.0 shipped the circuit under that name and auditors need the thread from the release assets to today'sx_tokennargo fmt-clean; commit 1638b0b formatted them and CI enforcesnargo fmt --check) — it now states the actual policyvk byte-identity (the critical constraint)
XHonkVerifier.solin libid-contracts derives from this circuit's vk and is deployed on chain, so the rename must not move the vk. Proven locally with the pinned toolchain fromtoolchain.env(nargo1.0.0-beta.20, bb5.0.0-nightly.20260324, exact versions verified):origin/main(pre-rename) and on this branch (post-rename, via the exactscripts/build.shrelease path);bb write_vk --oracle_hash keccakboth timescmponvkandvk_hash: byte-identical — vk sha256fe6a945bf161fac154633f3dac1b86bd077de2a9e13c33eb56559bc7e128ce8c, vk_hash0x0ef6521315935086e2161c8343e6e402c97e16770e1db9d53955fe1ca8f86e67bytecodeandabifields are identical pre/post; only source-derived metadata moves (file_mappaths, thehashfield, debug spans — the header comment and package name live there, and bb derives the vk from the bytecode alone)The next release build plus the libid-contracts
verifiersCI job will re-prove this independently before any downstream pin moves.Validation (CI parity, run locally)
nargo fmt --check: clean for both circuitsnargo test:x_token9/9 pass;jwt_emailuntouched (0 tests, vacuous as in CI)shellcheck scripts/*.sh: cleanscripts/build.shsucceeds with the renamed directory (tarball naming derives from the circuit dir, so the next release shipslibid-circuits-<version>-x-token.tar.gz)Follow-up (not in this PR)
Deliberately no release, no tag, no downstream bumps here. After merge: cut the next release (assets become
…-x-token.tar.gz/ packagex_token.json), then bump the libid-contracts circuits pin and let itsverifiersjob byte-compare the committedXHonkVerifier.solagainst the new release, then roll any claim-full asset references.🤖 Generated with Claude Code