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

Version 0.4.0 introduces HCA support, custom deployments, and shared workflow storage. Existing
built-in network configurations and ordinary ENS actions do not require an HCA adapter.
Update the ensforge packages together before adopting these features.

## Review stored network identifiers

Custom V1 and V2 deployment profiles can use arbitrary network and chain IDs. If your application
narrows resolved network IDs to only Mainnet or Sepolia, update that assumption. Deployment
provenance is optional for custom profiles; do not assume a source commit is always present.

Supply the complete required contract address groups for your chosen protocol and chain. Custom
profiles do not inherit preset indexer endpoints: configure an indexer explicitly if you use
discovery actions. See [configuration](/core/api/create-config).

## Choose workflow persistence

Configuration can now own shared storage for resumable workflows. The SDK defaults to memory;
React defaults to IndexedDB when its provider constructs the config. An existing config or explicit
storage choice is preserved.

If operations must survive a process restart, provide durable storage. Keep the config and storage
instance stable across requests where appropriate. Explicit resume parameters remain supported;
you do not need to discard an existing resume implementation to upgrade.

:::code-group
```ts [Memory]
import { createMemoryWorkflowStorage } from "@ensforge/core/storage";

export const storage = createMemoryWorkflowStorage();
```

```ts [Browser]
import { createIndexedDbWorkflowStorage } from "@ensforge/core/storage/browser";

export const storage = createIndexedDbWorkflowStorage();
```
:::

Pass the chosen `storage` to your configuration. The browser subpath keeps IndexedDB imports out
of server code. See [workflow storage](/core/guides/workflow-storage) for database adapters and
recovery behavior.

## Add HCA only when needed

HCA actions live in the existing Core, SDK, and React packages. The optional `@ensforge/hca` package
supplies provider adapters; there is no separate ENS client to migrate to. The package's first
aligned release is 0.4.0, alongside the other ensforge packages.

Owner execution and provider execution are distinct choices. Configure Pimlico or Rhinestone
when you need their execution infrastructure. Cross-chain funding is a separate operation from
name registration.

The original 0.4 session flow used on-chain enablement. Do not copy that flow into a current
application: read [Upgrade to 0.5](/migrations/0-5) for the signed-proof model, then follow the
[current HCA guides](/hca/getting-started).