> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://ensforge.com/api/mcp` to find what you need. # Sepolia Deployment Upgrading an existing application? Start with [Upgrade to 0.6](/migrations/0-6) for dependency, account, and saved-workflow changes. The Sepolia profile uses the deployment artifacts at [`07e55a05`](https://github.com/ensdomains/contracts-v2/tree/07e55a056f5b6a9c90119f501bdd05714e67dddd/contracts/deployments/sepolia), linked from the [ENS deployment documentation](https://docs.ens.domains/learn/deployments/#sepolia-ensv2). Use the addresses and ABIs together. A custom configuration with newer addresses does not make older contract interfaces compatible. ## October 1 deployment The October 1, 2026 deployment replaces the registries, registrar, resolvers, HCA factory, implementations, and mock payment tokens. The Universal Resolver proxy addresses remain the same, but resolve through the new deployment. Existing balances in an old mock token do not pay for registrations in the new registrar. Registry metadata now uses the ENS URI renderers. User and wrapper registry implementations expose `URI_RENDERER()` and initialize their renderer automatically. Inherited resolver lookups enforce ENSIP-10 support; a resolver on a parent name must support extended resolution to resolve a child. The HCA account and session-validator interfaces are unchanged from the September deployment. The new factory reuses certified accounts without reinitializing them, including when their initial implementation is no longer approved for new deployments. Ensforge still verifies the current implementation belongs to the supported account generation before allowing execution. ## Update an application Update the Ensforge packages together and recreate your Sepolia config. Mainnet configuration is unchanged. Names, resolver instances, HCA addresses and registration progress from the previous Sepolia deployment must not be reused as fixtures for this deployment. The important API differences are: * Permissioned Resolver permissions for a record key apply across names using that resolver. `setRecordPermissions` requires `allowScopeWidening: true` when granting this access. * `createResolver` accepts `grants` for multiple initial administrators. HCA session registration requires grants for the HCA and its owner, in that order; see the provider registration guides. * Public keys, record versions and bulk record clearing are unavailable on the current Permissioned Resolver. Check action capability results before offering these operations. * `setAlias` links records in the same resolver. `getAlias` only reads the legacy alias interface; it cannot reconstruct an alias name from the new link representation. * Registry transfers use the safe transfer path by default. Set `unsafe: true` only when intentionally transferring a name or subname whose registry state fails the safe-transfer constraints. ## HCA sessions Create a new HCA using the current factory. `enableHcaSession` now returns an owner-signed, reusable authorization proof; it does not submit an enablement transaction. Pass the complete proof as `{ kind: "session", session }` when preparing execution. Keep it private and persist it if the session must survive a restart. The validator checks the signature, expiry and the HCA's session nonce. `isHcaSessionEnabled` returns `false` on this stateless validator; use execution validation rather than that legacy storage query to determine whether a proof is usable. Revocation increments the nonce and invalidates all existing proofs. The contract requires positive refund bounds even for sponsored authorizations. The default session proof uses minimal bounds; the Rhinestone adapter requests sponsored execution and rejects unexpected charges. Use the explicit refund authorization and unsponsored adapter configuration only when paying fees from the HCA. Factory ownership and upgrade-set role administration are separate: the upgrade set uses roles, not an Ownable owner. ## Verify a repository checkout From the repository root, with Docker running: ```sh pnpm install pnpm build:devnet pnpm check pnpm test:integration pnpm verify:sepolia-v2 pnpm verify:hca:sepolia ``` `build:devnet` builds the pinned source locally. The two verification commands are read-only; set `ENSFORGE_SEPOLIA_RPC_URL` in the root `.env` to use your RPC. The first compares configured addresses and exported deployed ABIs with the pinned artifacts and checks deployed code. The second checks HCA runtime code and contract wiring. Neither verifies provider execution or indexer synchronization. ## Refresh playground fixtures Set `ENSFORGE_SEPOLIA_RPC_URL` and `ENSFORGE_SEPOLIA_PRIVATE_KEY` in the root `.env`. Review `fixtureConfig` at the top of `scripts/setup-sepolia-v2.mjs`, including the root name and secondary accounts. Choose an available test name and fund the owner with Sepolia ETH. Preview the fixture plan before applying it: ```sh pnpm setup:sepolia-v2 pnpm setup:docs-sepolia ``` The second command sends transactions. It creates the name and resolver fixtures, writes the manifest to `.ensforge/sepolia-v2-fixtures.json`. Use the resulting fixture names in the playground; if you change the default root, update the playground inputs accordingly. Progress is stored separately from the previous deployment in `.ensforge/sepolia-v2-07e55a0-state.json`; preserve this file when resuming. For HCA playground reads, deploy an HCA with the current factory and set `VITE_SEPOLIA_HCA_ADDRESS` in `apps/docs/.env.local` to its address. Restart the docs server after changing environment values. HCA playgrounds do not silently reuse an older factory's account. Run the local HCA example independently: ```sh pnpm --filter @ensforge/docs example:hca:local ``` Run live Sepolia read checks after refreshing the fixtures: ```sh pnpm test:live:sepolia ``` Provider execution requires separate verification with your Pimlico and Rhinestone credentials. Follow the [Pimlico guides](/hca/pimlico/getting-started) and [Rhinestone guides](/hca/rhinestone/getting-started), including registration, session revocation and recovery. Cross-chain funding is a separate operation from registration. ## Indexer schema The Sepolia V2 source is `https://staging-graphql.ens.dev/graphql`. The checked-in schema is introspected from that endpoint; generating query types validates every V2 operation against it. To refresh only V2 without requesting the V1 subgraphs: ```sh pnpm --filter @ensforge/core schema:indexer:refresh v2 pnpm --filter @ensforge/core codegen:indexer ``` ## Staging indexer limitations The staging indexer currently exposes the new resolver record inventories, but its resolved-address filter and name-based record-history queries can omit record-ID updates. An empty indexer result therefore does not prove that a name has no address or record history. Use on-chain record reads for current values. ENSv2 record events must be joined to names through the resolver’s `Linked` events; see [ENS indexing documentation](https://docs.ens.domains/ensv2/indexing/). The two affected live tests are temporarily skipped until those indexer relationships are fixed. Their assertions remain in the suite to re-enable after the upstream correction.