Skip to content

Releases: libid-org/chain-configurations

v0.16.0 — libid-contracts 0.17.0, one deployer per environment

Choose a tag to compare

@xgreenx xgreenx released this 04 Oct 01:08
81023e1

Takes libid-contracts 0.17.0: the factory's genesis admin is a parameter, so each network file names its deployer ([accounts].deployer) and every canonical address follows from that key.

  • Testnet deployer alias/libid-testnet-deployer (libid-testnet AWS account), address 0xdaeb247f5a90c53f2d7a80a81f6cb6acb0d8b907; eden-testnet and Sepolia carry its table (factory 0x9dbf2b5f96cb31a48cca4e25d2c8348be414ebc8, IdentityRegistry 0x25f29c8c765db2f27d1e2b23987a7b0655c7d640) and the libid-testnet notary 0x569ae51d9c356f838c2811389a932b681cb6491c.
  • Apply refuses a signer that is not the deployer, on every chain; --dev and the factory-owner impersonation are gone.
  • plan --print-addresses reads the file before validation, so a new network's table can be filled in from it.

v0.15.0 — libid-contracts 0.16.0, circuit verifiers 0.6.0

Choose a tag to compare

@xgreenx xgreenx released this 03 Oct 15:03
5c4b0bc

Deploys libid-contracts 0.16.0: the Honk verifiers of libid-circuits v0.6.0, built by nargo 1.0.0-rc.3 and bb 6.0.0-rc.2.

  • Circuit verifiers: libid.circuits.bearer-link.0.6.0 at 0x7be247fc8040fac413f8c7451618d9589c3b689e and libid.circuits.oidc-google.0.6.0 at 0x4d4fcbf08d075992e40feb5a4124e4d573a85238 on every network. Apply deploys them and sends setTrustRoots to the X, GitHub and Google Platform Verifiers; proxies and registrations stay.
  • Endpoints: a network file names no RPC endpoint; the RPC_URL secret of its GitHub environment supplies it (#20, #21). validate requires one only under --check-rpc.

From the apply's block, only proofs made with the v0.6.0 circuits verify: the CCDP carrying them moves at the same time.

What's Changed

  • feat: a network file names no endpoint; the environment supplies it by @xgreenx in #20
  • fix(validate): require an endpoint only under --check-rpc by @xgreenx in #21
  • build!: take libid-contracts 0.16.0 by @xgreenx in #22

Full Changelog: v0.14.0...v0.15.0

v0.14.0 — libid-contracts 0.15.0, IdentityRegistry and HandleEscrow.2

Choose a tag to compare

@xgreenx xgreenx released this 01 Oct 08:37
f69494b

Deploys libid-contracts 0.15.0.

  • Platform Verifiers: each profile's validity window is compiled in, so initialize takes none; the three verifiers upgrade in place.
  • IdentityRegistry: IdentityNames is renamed and its storage root moved, so the registry deploys fresh as libid.IdentityRegistry; libid.IdentityNames.3 is left in place, not migrated.
  • HandleEscrow: libid.HandleEscrow.2, bound to the new registry for life; libid.HandleEscrow stays with .3.

eden-testnet addresses after the apply: IdentityRegistry 0x0531b83b010a6b0c24c2c2c1a6beecc90cc71366, HandleEscrow.2 0xf7e3ad279f913ffe2ef74614e3046c15cbdabb9a.

What's Changed

  • build!: take libid-contracts 0.15.0 by @xgreenx in #17

Full Changelog: v0.13.0...v0.14.0

v0.13.0 — libid-contracts 0.14.0, IdentityNames.3 and a HandleEscrow

Choose a tag to compare

@xgreenx xgreenx released this 30 Sep 12:21
fa29eaa

Deploys libid-contracts 0.14.0.

  • Honk verifiers: bb's optimized zero-knowledge verifiers from libid-circuits v0.5.0, one contract each, deployed without libraries; the Platform Verifiers' trust roots move to them.
  • IdentityNames: a fresh libid.IdentityNames.3 (account lists start empty); .2 is left in place, not migrated.
  • HandleEscrow: libid.HandleEscrow on every network, bound to that network's IdentityNames for life, owned by the deployer.

eden-testnet addresses after the apply: IdentityNames 0x5b86114eccd8259347294a2bdbf3da2c93857796, HandleEscrow 0xbbfe9b5301d44cd67b725c600fac4a53dc090de1, bearer-link verifier 0x8373cb5ce354ea975c11c406ee5fc639efe0a3cc, oidc-google verifier 0x6e55aa9a42d4902b834aeb84db860eed0e4ae209.

What's Changed

  • ci(deps): monitor all supported dependency sources by @Wondertan in #13
  • refactor!: deploy the Honk verifiers without libraries by @xgreenx in #14
  • feat!: IdentityNames under libid.IdentityNames.3, and a HandleEscrow beside it by @xgreenx in #16

New Contributors

Full Changelog: v0.12.0...v0.13.0

v0.12.0 — libid-contracts 0.13.0, and IdentityNames under a fresh name

Choose a tag to compare

@xgreenx xgreenx released this 20 Sep 17:39
f15832a

The deploy tool takes libid-contracts 0.13.0, IdentityNames gets a fresh canonical name, and an apply --upgrade converges a proxy whose running implementation predates a getter the wiring reads.

Changes

  • Pins libid-contracts / libid-identity / libid-profiles 0.12.0 → 0.13.0: GitHub's token request is revealed whole and every token body is held to its profile's field list on chain. Nothing libid-deploy calls changed shape.

  • apply runs each requested upgrade inside that component's own step, before it reads or wires through the proxy. Previously every upgrade ran last, so a network whose IdentityNames predates proofVerifier() aborted at that read; now apply --upgrade identity-names finishes in one run. A guard fails the run if a requested component has no section. plan names the flag in its warning.

  • IdentityNames deploys under a new canonical name, libid.IdentityNames.2: eden-testnet's libid.IdentityNames came from the pre-ceremony contract set and keeps that storage, and an in-place upgrade over a layout this repository no longer builds is not a thing to do. The old contract stays where it is, orphaned.

Addresses

One row moves; everything else is byte-identical to v0.11.0 and the circuit verifiers still carry circuits 0.4.0.

contract was now
contracts.identity_names 0xd467d48769c26faee36ba6b6fc9228f14aef6dd2 0xe78b53a183dd51763df44beb2500ddab9bb0329e

Consumers that record the address (libID harness and demo, usernames-indexer, the deployment's indexer manifest, keeper's e2e file) follow.

v0.11.0 — the verifiers come from libid-contracts

Choose a tag to compare

@xgreenx xgreenx released this 14 Sep 22:13
65eb28b

The ceremony verifiers now come from libid-contracts. bb no longer runs in this repo, and nothing
is generated here at all.

Changes

  • Pins libid-contracts / libid-identity / libid-profiles 0.10.0 → 0.12.0.
  • Deletes scripts/vendor-artifacts.sh, the vendor-artifacts CI action and circuits-manifest.json.
    Building this repo needs neither forge nor bb.
  • ceremony.rs is replaced by circuits.rs: bindings, artifacts, Circuit and Initializer come
    from the crate, and this repo only decides where things land.
  • Libraries deploy through Libraries::deploy — CREATE2, address derived from the bytecode, so a
    re-run and any later circuit find the same pair instead of deploying their own.
  • Platform Verifiers initialize through Initializer::call, which checks the contract's own rules
    before a transaction is built.
  • plan, --print-addresses and the apply summary list the libraries.

Addresses

The canonical table is unchanged — the factory and proxy artifacts are byte-identical in 0.12.0. Only
the circuit verifiers move, because their names now carry the circuits version:

contract was now
bearer-link verifier 0x21c26fde…1879 0xab8c8aabbcd921a8bd944ca693cd2426369d702f
oidc-google verifier 0xfe6de589…2ba6 0xc1150bc7e095aa56654b5c9f6b4561c1751b8352
RelationsLib nonce-dependent 0x306319f854a5596e1e9e2ec59f99f82ea48abeef
ZKTranscriptLib nonce-dependent 0x7bb464aa25203cc5b199e0fd7a4258580d71d2a1

libid-circuits 0.3.0 and 0.4.0 carry the same verification keys, so every artifact is byte-identical
to what was vendored here. Only the verifiers' code hashes change, through the library addresses they
now carry.

Known

An existing deployment is not migrated. A later apply deploys the new pair and rotates the affected
trust roots; the previously deployed verifiers stay on chain, unreferenced.

v0.10.0 — the Platform Verifiers, and an RPC you can point somewhere else

Choose a tag to compare

@xgreenx xgreenx released this 14 Sep 17:37
883f01c

Migrates to libid-contracts 0.10.0 and deploys the three Platform Verifiers alongside the core stack.

Changes

  • Deploys XPlatformVerifier, GitHubPlatformVerifier and GooglePlatformVerifier, wired to the
    circuits' UltraHonk verifiers and registered with CeremonyProofVerifier.
  • --rpc-url on validate, plan and apply overrides the endpoint a network file names, so a file
    written for a compose network can be applied from outside it. The flag wins outright; nothing ever
    falls back to the file.
  • Network files carry the contract addresses under [contracts].

Assets

Four per release: Linux x86_64/aarch64, macOS aarch64/x86_64.

Known

Verifier artifacts are still generated here with bb at the version the circuits manifest pins.
That moves to libid-contracts once it consumes the Verifier.sol that libid-circuits v0.4.0 now
publishes; the deployed code hash is worth re-checking at that point, since the compiling project
changes.

v0.6.0

Choose a tag to compare

@xgreenx xgreenx released this 12 Aug 23:47
62b5035

Deploys against libid-contracts 0.5.0: GitHubIdentityVerifier.initialize no longer takes a backend key, and apply_identity no longer threads the address at all.

accounts.backend stays required — the wallet product's Registry and Bank still take it.

v0.5.0

Choose a tag to compare

@SupremaLex SupremaLex released this 12 Aug 16:40
bdec02f

Deploys against libid-contracts 0.4.0: platform wiring is two calls now — setPlatform carries a platform's keyspace, setVerifier installs the verifier for one proof format — and plan reads verifierOf(platformId, version). Every platform lands on the first version and becomes its own default, so a deployment behaves exactly as it did before: one verifier per platform. The anvil test asserts against a live chain that this repository and the contract agree on that version number, that the platform is wired under it rather than merely deployed, and that the first version installed became the default. Managing several verifier versions from config is deliberately absent — 0.4.0 ships one verifier artifact per platform, so there is nothing to select between yet.

v0.4.0

Choose a tag to compare

@xgreenx xgreenx released this 12 Aug 13:05

Declarative configs: network files carry the full canonical address table up front and are never rewritten — deployed-vs-not is read from chain state, the fresh-deploy guard keys on factory presence, and [accounts].owner declares the operational owner. The write-back PR machinery is retired.