SDK 2.0.0-rc.1 preparation

Historical record for the September 16 rc.1 handoff, not current npm status or current-source acceptance. All eight packages subsequently published rc.2. See tester-beta consolidation for the next source candidate.

Status: SDK-local release checks passed; packed for maintained-provider testing, with downstream release gates below. Not published, committed, or deployed. All eight canonical packages use the fixed Changesets release train. Changesets entered rc prerelease mode, applied the existing browser-binding major change as rc.0, then the documentation/API release-preparation change as rc.1. Changesets 3 archives applied changesets under .changeset/pre/; keep those and .changeset/pre.json until the coordinated stable release.

Changed SDK APIs

• @u-net/server: authenticated per-attempt browser challenge, lifecycle-only status, and atomic requestRef exchange; HTTP adapters require provider identity, account store, and a session exchange callback.
• @u-net/server: PostgreSQL stores require checked-out transactional connections. Custom account stores claim cleanup jobs and fence completion and failure with leaseToken. Retirement and durable cleanup enqueue are atomic; tombstones and operation records remain permanent.
• @u-net/web-login: challenge response is { success, challenge }; exchangeDirectProviderLogin uses the originating browser cookie and requestRef. Polling never returns a session ID or scoped identity.
• @u-net/react: useUnetLogin exchanges approval before reporting consumed.
• All eight packages advance together; browser packages must not import issuer cryptography. API Extractor reports remain the authoritative exported surface.

Read the migration requirements before provider integration. No v1 or session-ID redemption fallback is provided.

Provider artifact handoff

Artifacts are generated into the SDK checkout's artifacts/ directory:

The local artifacts/2.0.0-rc.1-manifest.json handoff lists all eight absolute paths and SHA-256 digests for Lovelace/provider installation tests. Repacking requires refreshing that manifest; pack:dry now does this automatically. The unpublished RC artifacts were refreshed after release-tag cleanup. Use the current manifest hashes, not previously installed copies of the same version.

Package	Tarball
@u-net/client	u-net-client-2.0.0-rc.1.tgz
@u-net/contracts	u-net-contracts-2.0.0-rc.1.tgz
@u-net/issuer	u-net-issuer-2.0.0-rc.1.tgz
@u-net/react	u-net-react-2.0.0-rc.1.tgz
@u-net/server	u-net-server-2.0.0-rc.1.tgz
@u-net/setup	u-net-setup-2.0.0-rc.1.tgz
@u-net/verification	u-net-verification-2.0.0-rc.1.tgz
@u-net/web-login	u-net-web-login-2.0.0-rc.1.tgz

Install each required package and its canonical transitive dependencies from these matching local tarballs in the same package-manager transaction, or use provider-local overrides. Do not resolve this unpublished candidate from npm. Keep issuer/setup tooling server-only; do not install the whole set into a browser application. Legacy @union-networks/* forwarding manifests receive automatic Changesets dependency propagation but are not in this artifact set.

Validation

Validated on 2026-09-16 with pnpm 10.33.0:

• Clean build and typecheck passed, including compatibility forwarding packages and the typed examples.
• All five real PostgreSQL tests passed through the authorized SSH forward to the isolated unet_security_test database on port 55439. Fixtures create and drop only their own random schema; no production database is used.
• Strict api:report passes without warnings for all eight packages. Explicit public release tags and reproducible OpenAPI comment normalization resolved the warnings. CI now checks reports strictly rather than regenerating them.
• Compared all 31 declaration files with the earlier RC tarballs: their non-comment TypeScript syntax trees are identical. No API signatures changed. Generated contract comment normalization is idempotent and checks that types remain unchanged on every generation.
• All eight current-version tarballs were packed. Their embedded versions and internal dependency ranges (^2.0.0-rc.1) were checked.
• Publint passed for all eight packages. Attw passed for all eight tarballs with the repository's esm-only profile; CommonJS require remains unsupported.
• release:check and the offline frozen lockfile consistency check passed.
• Node 20.20.2 and Node 22.23.2 passed frozen install, clean build, typecheck, all 52 tests (zero skipped), strict API reports, release metadata, publint, and attw in disposable, resource-limited containers on u-chain.
• Both containers verified all eight handed-off tarball SHA-256 hashes, then installed those exact tarballs into a separate consumer with local overrides. scripts/packed-release-smoke.mjs passed all eight package imports and the browser-bound login flow, including missing-cookie and replay rejection.
• Node 22 also passed TypeDoc generation and the VitePress docs build. Large documentation bundle warnings remain non-fatal.
• The containers used read-only SDK archive mounts and --rm. Both exact labeled containers were confirmed absent after completion; the temporary remote archive was removed. No production containers were modified.

Node image digests used for the matrix:

• node:20-bookworm-slim: sha256:2cf067cfed83d5ea958367df9f966191a942351a2df77d6f0193e162b5febfc0
• node:22-bookworm-slim: sha256:83f487e0a63425e5b4d146fb5e5be574bcbe1b7b843d3ebafdd95eaf7767a7e5

Messaging runtime evidence

Main integration reported on 2026-09-16 that the production BbJsAccessProofBackend, without an injected test shim, verified both r2 fixture proofs and rejected altered public inputs on u-chain Node 24 with an actual npm ci installation of @aztec/bb.js@4.2.0. Its scripts/checkProofRuntime.mjs ran in an isolated temporary directory, with no production deployment. This closes the production BbJs runtime gap. This SDK task records that reported evidence; it did not rerun the messaging checker.

Release blockers

• Maintained-provider installs and browser-bound login/retirement integration tests must pass against these exact artifacts, including dashboard proxies and the mobile WebView/native approval bridge.
• Security cutover must invalidate legacy challenges/sessions and enforce active-account checks for already-issued provider sessions.
• The phone's full membership/persona/expiry three-proof challenge flow remains a blocker; production fixture verification does not establish that result.
• Messaging policy integration, client reset, and the full deployed integration matrix remain separate gates. SDK preparation does not certify them.
• Publication, tagging, commits, and deployment require separate authorization.