> **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.

# Upgrade to 0.5

Version 0.5.0 moves Sepolia ENSv2 to deployment snapshot `71a3b733` and changes HCA session
authorization. Mainnet behavior is unchanged. If your target is 0.6, apply the API changes below,
then use the [0.6 deployment](/migrations/0-6) rather than creating intermediate fixtures.

## Changed `enableHcaSession` to return a signed proof

HCA session enablement now returns an **owner-signed, reusable authorization proof**. It does not
send an enablement transaction. Remove UI or backend logic that waits for that transaction's
receipt, and retain the complete returned proof for later execution.

The Rhinestone session setup uses the same SDK instance and adapter as execution:

```ts [session.ts]
// [!include ~/snippets/hca/guides/session.ts]
```

Pass the exported `authorization` when preparing or executing session calls. For the full client,
account, and resolver setup, see [Sessions](/hca/rhinestone/sessions).

The stateless validator checks the owner signature, expiry, and account session nonce.
`isHcaSessionEnabled` returns `false` on this validator; remove it as a precondition for using a
valid proof. Revoking sessions still requires an owner transaction and invalidates all proofs for
that HCA by incrementing the nonce. Keep proofs and signing keys in protected storage.

## Required scope consent for `setRecordPermissions`

Permissioned Resolver record-key roles apply across names using that resolver. When granting them
through `setRecordPermissions`, explicitly set `allowScopeWidening: true` only after accepting that
scope. Do not add the flag blindly to every permission request.

```ts
await sdk.permissions.setRecordPermissions({
  name,
  account: hca,
  records: [{ type: "text", key: "description" }],
  approved: true,
  allowScopeWidening: true, // [!code ++]
});
```

See [setRecordPermissions](/sdk/api/permissions/set-record-permissions) for the complete input.

## Changed resolver initialization and record support

`createResolver` accepts initial administrator `grants`. Session-based HCA registration requires
grants for the HCA and its owner, in that order. Follow the current provider registration example
when constructing that resolver.

Check your record UI for these deployment differences:

* Public-key writes, record versions, and bulk record clearing are unavailable on the Permissioned Resolver.
* `setAlias` creates a same-resolver record link. The legacy `getAlias` query cannot reconstruct a name from it.
* Registry transfers use the safe path by default. Use `unsafe: true` only when you intend to bypass
  its registry-state constraints.

Use capability reads to decide which operations to offer rather than assuming every resolver
implements every record action.

## Replace deployment-specific state

Create new Sepolia names, resolver instances, HCA accounts, and permissions for the target factory.
Old workflow records and session proofs are not compatible with the replacement deployment.
Before replacing state, reconcile submitted operations using the old configuration.

Registration funds, relayer refunds, and cross-chain source funds serve different purposes.
Read the registrar's current payment token and price before approving or funding registration;
an existing balance of a previous deployment's token is insufficient.

## Review indexer consumers

The V2 GraphQL schema and generated operations changed with the deployment. Update any application
queries copied from older schemas. Record updates use record IDs, and associating them with names
requires resolver link events; do not treat missing indexed history as proof that a write failed.
Use a receipt and an on-chain read to confirm writes.

After upgrading, verify a session-backed record update, session revocation, and any registration
flow your app exposes. See [storage and recovery](/hca/guides/storage) for handling saved operations.