libid-contracts
Typed alloy bindings, embedded forge
artifacts, and deploy/upgrade helpers for the libid identity stack: the
ceremony verification path (NotaryService, CeremonyProofVerifier, the
three launch Platform Verifiers it routes to, the two UltraHonk verifiers
they pin, and GoogleJwtRoots, the signing keys the google/v1 verifier
trusts), the naming system (IdentityNames), and the deterministic
deployment factory (LibidFactory).
The compiled artifacts are vendored into the crate, so a consumer can deploy
or upgrade the whole stack against a live network with zero filesystem
dependencies at runtime. They are generated, not committed:
scripts/vendor-artifacts.sh produces artifacts/ from solidity/ and CI
runs it before every build, test and publish. Working in this repo, run
scripts/vendor-circuit-verifiers.sh and then it once after cloning — the
Honk verifiers are vendored too, and the crate embeds the directory with
include_dir!, so until it exists cargo build fails at macro expansion. Signing stays on the
consumer's side: every helper is generic over an alloy Provider you have
already wired with a wallet.
Example: deploy the Notary Service and the Google JWT root list
use ;
use ;
async
Example: deploy a Platform Verifier on its circuit's Honk verifier
A Platform Verifier pins the bb-generated UltraHonk verifier for its circuit
by address and by code hash, holds a Notary Service only if its profile
notarizes anything, and caps its parameters. platform_verifier::Initializer
knows those rules: it reads the code hash off the chain, refuses what the
contract would refuse, and builds the exact initialize call.
The Honk verifier is vendored here too, from the pinned libid-circuits
release. circuits::deploy_honk_verifiers deploys the libraries a set of
circuits link (RelationsLib, ZKTranscriptLib) once per distinct
bytecode, links each verifier against them and deploys it — four
transactions for both launch circuits, not six — and returns the addresses
the initializers pin. A library lands at an address derived from its
bytecode, so circuits::deploy_honk_verifier for one circuit finds a
library another deploy already put there and links it instead of deploying
a copy.
use ;
use ;
async
For a factory (CREATE3) deploy, Initializer::call returns the typed
initialize call; abi_encode it into the proxy's init data.
Other entry points:
deploy::upgrade_uups— deploy a fresh implementation andupgradeToAndCalla UUPS proxy onto it.factory::ensure_factory/factory::factory_deploy— install the canonical cross-network factory where missing and deploy protocol proxies through it at name-derived CREATE3 addresses.deploy::Libraries— deploys the external libraries a set of contracts link, once per distinct bytecode (Libraries::deploy), and substitutes their addresses into a contract's creation bytecode (Libraries::link) without deploying it — for a verifier that goes through the factory.deploy::load_linked_bytecode(orArtifacts::linked_bytecode) is the same over one contract.circuits::version— thelibid-circuitsrelease the vendored verifiers came from, for a consumer that names a deployment after its artifact.platform_verifier::codehash_at— the code hashsetTrustRootswants when a Platform Verifier is rotated onto a new circuit release.Artifacts::method_identifiers— selector extraction from the vendoredmethodIdentifiers.
Testing
Unit tests run everywhere; the integration tests in tests/anvil.rs spawn
anvil (foundry) and deploy the stack for real. From rust/: