Operational Workflows

This section outlines OmniSocial’s operational lifecycle: from code changes to deployment, testing, upgrades, and community involvement.

It is designed to serve both as a transparency document for the community and a practical guide for maintainers and contributors.

⚙️ Operational Workflows

This section outlines OmniSocial’s operational lifecycle: from code changes to deployment, testing, upgrades, and community involvement. It provides visibility into how the platform is maintained and evolved.

🔁 CI/CD Pipeline

All OmniSocial components are managed in a monorepo structure using GitHub Actions for CI/CD.

🔧 Repositories

• omnisocial-contracts — Smart contracts (Polygon zkEVM)

• omnisocial-app — Front-end social dApp

• omnisocial-explorer — DAO and governance explorer

• omnisocial-subgraph — Subgraph for data indexing

• omnisocial-docs — Developer & protocol documentation

✅ CI Checks

On each pull request:

• Linting (ESLint + Prettier)

• Type Checking (TypeScript strict mode)

• Smart Contract Compilation (Hardhat)

• Unit Tests (Jest + Hardhat Network)

• Subgraph Build + Codegen (Graph CLI)

• Storybook Snapshot Tests (UI components)

CI is enforced before merge.

🚀 Deployment

Via GitHub Actions (or Vercel for frontend):

• Staging deployments on PR merge to dev

• Production deployments on merge to main

• Contracts deployed with hardhat-deploy

• Subgraph published to The Graph hosted service and self-hosted instance

🧪 Testing Methodology

Smart Contract Testing

• Uses Hardhat + Waffle + Ethers.js

• Full coverage on:

  • OmniWallet

  • PersonaNFT

  • RepModule

  • DAO + Governance Modules

Tests include edge cases like:

• Reentrancy scenarios

• Access control

• Reputation decay over time

• Timelock validation

Front-End Testing

• React Testing Library for UI interaction

• Snapshot testing via Storybook

• Mocked GraphQL data for feed and reputation scenarios

🔁 Upgrade Flow

OmniSocial uses UUPS (Universal Upgradeable Proxy Standard) for contract upgradability, controlled via DAO governance.

🛠 Contract Upgrade Steps

1. Developer submits PR with new logic (e.g. PersonaNFTV2)

2. CI runs tests and type checks

3. Upgrade script is audited by internal maintainers

4. Proposal is submitted via DAO.createProposal() containing:

   • Upgrade calldata (via prepareUpgrade)

   • Execution plan with optional timelock

5. DAO votes on proposal (quorum + delay)

6. If passed, upgrade is executed by DAO multisig or trusted relayer

Example upgrade:

await DAO.createProposal({
  title: "Upgrade PersonaNFT to v2",
  actions: [
    {
      target: personaNFTProxyAddress,
      data: proxyAdminInterface.encodeFunctionData("upgrade", [
        personaNFTProxyAddress,
        newPersonaNFTImplementation,
      ]),
    },
  ],
});

🧩 Deployment Matrix

Environment	Network	Deployed Contracts	Subgraph
Local Dev	Hardhat	All contracts deployed via scripts/dev.ts	Local Graph node
Staging	Polygon zkEVM Testnet	Latest main branch deployed	omnisocial/staging-subgraph
Production	Polygon zkEVM Mainnet	Audited and DAO-approved contracts	omnisocial/mainnet-subgraph

Contracts are tagged with release versions and stored in /deployments.

🧩 Release Versioning

OmniSocial uses semantic versioning:

• X.Y.Z = Major.Minor.Patch

• Smart contract upgrades = major

• Front-end features = minor

• Fixes = patch

Example:

v2.1.0 — Adds token-gated tips, DAO upgrade flow
v2.1.1 — Fixes bug in vote tally display

📌 Contributor Guide

Maintainers and contributors should follow these conventions:

• PRs must include descriptions and related issue links

• Contract changes must include gas benchmarks

• New features require at least 2 reviewers

🛡 Transparency Commitments

• All governance proposals are publicly viewable

• All contract upgrades are on-chain and time-delayed

• Contract addresses and changelogs are published in /docs/deployment.json