# Deployment & Migration Guide

It also supports contributors or projects wishing to **deploy their own instance** of OmniSocial.

### 🔧 Deployment Process Overview

OmniSocial’s core is composed of smart contracts, a subgraph, and a front-end dApp. Deployment occurs in three coordinated phases:

1. **Smart Contracts (Hardhat)**
2. **Subgraph Indexing (The Graph)**
3. **Front-End Configuration (Next.js)**

> All deployments are managed via `Hardhat` scripts in the `/packages/contracts` folder.

### 🛠 Smart Contract Deployment (Using Hardhat)

#### Pre-requisites

* Node.js ≥ v18
* Hardhat + ethers
* `.env` file with deployer key & RPC endpoint

#### Run Deploy Script

```bash
npx hardhat run scripts/deploy.ts --network polygonZkEvm
```

This deploys core contracts:

* `OmniWalletFactory`
* `PersonaNFT`
* `RepModule`
* `DAOFactory`
* `EditionDropFactory` (optional)

Addresses are auto-logged and stored in `/deployments/[network].json`.

### 🌍 Network Configuration

| Network            | Chain ID | Description        | Status     |
| ------------------ | -------- | ------------------ | ---------- |
| `polygonZkEvm`     | 1101     | Main zkEVM network | ✅ Active   |
| `polygonZkTestnet` | 1442     | Test zkEVM network | 🧪 Testing |

Update `hardhat.config.ts` and `subgraph.yaml` with correct addresses per deployment.

### 🧬 Subgraph Deployment

Update `/packages/subgraph/subgraph.yaml` with deployed contract addresses.

#### Deploy to Hosted Service

```bash
graph deploy \
  --product hosted-service \
  --access-token $GRAPH_ACCESS_TOKEN \
  omnisocial/zk-mainnet
```

> Replace with `zk-testnet` or your own namespace as needed.

### 🌐 Front-End Environment

Update `.env.local` in the `frontend/` package with:

```env
NEXT_PUBLIC_CONTRACTS_JSON=/deployments/polygonZkEvm.json
NEXT_PUBLIC_GRAPHQL_ENDPOINT=https://api.thegraph.com/subgraphs/name/omnisocial/zk-mainnet
```

### 🧱 Upgrade Flow via DAO

OmniSocial contracts use **UUPS (Universal Upgradeable Proxy Standard)** where applicable. Contract upgrades must be:

1. Proposed via `createProposal()` in a DAO.
2. Voted on by token holders or reputation holders.
3. Queued and executed via the `TimelockController`.

#### Example upgrade proposal:

```ts
const proposal = daoContract.createProposal(
  "Upgrade RepModule to v2",
  [repModuleProxy.address],
  [0],
  [repModuleImpl.interface.encodeFunctionData("upgradeTo", [newImplAddress])],
  "Upgrade RepModule contract for new domain logic."
);
```

> DAO votes + timelock are required for execution unless deploying your own fork without governance gating.

### 🪜 Forking & Migrating

To fork OmniSocial:

1. Clone the repo and update the namespaces (`omnisocial` → your project).
2. Deploy fresh contracts using the same steps.
3. Optionally, fork the subgraph and point to your contract addresses.
4. Replace `omnisocial.dev` links and branding in the front-end config.

Migration tools (e.g., to import users or personas from another deployment) will be available soon.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.omnisocial.dev/operations/deployment-and-migration-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.