MihRazvan · MihRazvan · Mar 30, 2026 · Mar 1, 2026 · Mar 1, 2026 · Mar 1, 2026
diff --git a/.env.example b/.env.example
@@ -15,7 +15,9 @@ SAFE_API_KEY=your-safe-api-key
 SEPOLIA_OWNER_ADDRESS=0x...
 SEPOLIA_OWNER_PK=0x...
 
-# Storacha Configuration (optional, uses CLI by default)
+# Storacha Configuration
+# Current deploy flow uses your local Storacha CLI login + selected space.
+# KEY / PROOF are reserved for a future native Storacha integration.
 # KEY=your-storacha-key
 # PROOF=your-storacha-delegation-proof
 

diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
@@ -1,4 +1,4 @@
-name: Secure Deploy to ENS + IPFS
+name: Autark Deploy to ENS + IPFS
 
 on:
   push:
@@ -29,36 +29,25 @@ jobs:
         run: npm run build
 
       - name: Install Storacha CLI
-        run: npm install -g @storacha/client
+        run: npm install -g @storacha/cli
 
       - name: Setup Storacha credentials
+        if: ${{ secrets.STORACHA_TOKEN != '' }}
         run: |
           mkdir -p ~/.storacha
           echo "${{ secrets.STORACHA_TOKEN }}" > ~/.storacha/token
-        if: env.STORACHA_TOKEN != ''
-
-      - name: Install secure-deploy CLI
-        run: |
-          cd path/to/secure-deploy
-          npm install
-          npm run build
-          npm link
 
       - name: Deploy to ENS + IPFS
         run: |
-          secure-deploy deploy dist \
-            --network sepolia \
-            --ens-domain rome.eth \
-            --rpc-url ${{ secrets.SEPOLIA_RPC_URL }} \
-            --safe-address ${{ secrets.SAFE_ADDRESS }} \
-            --safe-threshold 2 \
-            --owner-address ${{ secrets.SEPOLIA_OWNER_ADDRESS }} \
-            --owner-pk ${{ secrets.SEPOLIA_OWNER_PK }}
+          npm run cli -- deploy dist --network sepolia
         env:
           SEPOLIA_RPC_URL: ${{ secrets.SEPOLIA_RPC_URL }}
+          MAINNET_RPC_URL: ${{ secrets.MAINNET_RPC_URL }}
           SAFE_ADDRESS: ${{ secrets.SAFE_ADDRESS }}
-          SEPOLIA_OWNER_ADDRESS: ${{ secrets.SEPOLIA_OWNER_ADDRESS }}
+          SEPOLIA_ENS_DOMAIN: ${{ secrets.SEPOLIA_ENS_DOMAIN }}
+          ENS_DOMAIN: ${{ secrets.ENS_DOMAIN }}
           SEPOLIA_OWNER_PK: ${{ secrets.SEPOLIA_OWNER_PK }}
+          SAFE_API_KEY: ${{ secrets.SAFE_API_KEY }}
 
       - name: Comment on commit with deployment info
         uses: actions/github-script@v7
@@ -74,5 +63,5 @@ jobs:
               body: `🚀 **Deployment Initiated**\n\n` +
                     `Commit: ${shortSha}\n` +
                     `Safe Transaction created for approval.\n\n` +
-                    `View pending transactions: https://app.safe.global/sepolia.safe/${{ secrets.SAFE_ADDRESS }}/transactions/queue`
+                    `View pending transactions: https://app.safe.global/transactions/queue?safe=sep:${{ secrets.SAFE_ADDRESS }}`
             })
diff --git a/README.md b/README.md
@@ -1,85 +1,141 @@
 # AUTARK
-<img width="1920" height="360" alt="ETHRome25banner" src="https://github.com/user-attachments/assets/f0cc3bed-8418-47c3-b59f-f311ea959580" />
 
-Autark is a crypto-anarchic `DevSecOps` framework for more secure, and self-sovereign frontend deployments; embracing immutable, decentralized, and multi-party-verified frontend governance through Safe + ENS + IPFS.
+Autark is a DevSecOps framework for more secure, self-sovereign frontend deployments, combining Safe multisig governance, ENS versioning, and IPFS storage into a verifiable release flow.
 
-[Demo](https://www.youtube.com/watch?v=-pGsHpUI0J0) | [User Guide](https://github.com/MihRazvan/ETHRome_hackathon/blob/main/docs/USER-GUIDE.md) | [Technical Architecture](https://github.com/MihRazvan/ETHRome_hackathon/blob/main/docs/TECHNICAL-ARCHITECTURE.md) | [Flow Chart](https://github.com/MihRazvan/ETHRome_hackathon/blob/main/docs/FLOW-CHART.md) | [Submission](https://taikai.network/ethrome/hackathons/2025/projects/cmgx4r1we02d112kkxt8y1sxi/idea) | [Safe DAO Proposal](https://forum.safe.global/t/grant-proposal-supporting-autark-a-secure-self-sovereign-frontend-deployment-framework-built-on-safe/6799)
+**Project Summary:** [SUMMARY.md](./SUMMARY.md)
+
+[Demo](https://www.youtube.com/watch?v=-pGsHpUI0J0) | [Quickstart](./docs/QUICKSTART.md) | [User Flow](./docs/USER-FLOW.md) | [Git Hooks](./docs/GIT-HOOKS.md) | [Technical Architecture](./docs/TECHNICAL-ARCHITECTURE.md) | [Architecture (Short)](./docs/ARCHITECTURE-SHORT.md) | [Docs Index](./docs/README.md) | [Safe DAO Proposal](https://forum.safe.global/t/grant-proposal-supporting-autark-a-secure-self-sovereign-frontend-deployment-framework-built-on-safe/6799)
 
 ---
 
-# Problem First!
+## Problem First
 
-Modern `DevOps` pipelines have become too automated, too centralized, and too trusting.
+Modern deployment pipelines are fast, centralized, and often trusted too blindly.
 
-A single compromised developer or **CI/CD** token can silently push malicious frontend code to production — within minutes — across millions of users. Here, the weakest link remains the deployment pipeline.
+A single compromised developer machine, CI token, or deployment credential can push malicious frontend code to production in minutes. For onchain applications, that means the frontend becomes the weakest link, even when the smart contracts are sound.
 
-<img width="1679" height="584" alt="Frame 4 (2)" src="https://github.com/user-attachments/assets/eaa5cbef-2670-4834-9e93-618d539868c0" />
+Autark exists to slow that attack path down and make every release auditable.
 
-**AUTARK** exists to contribute to fixing this.
+It introduces:
 
-It reintroduces multi-party verification, cryptographic immutability, and decentralized governance into the deployment lifecycle. We are turning `DevOps` into `DevSecOps`, and `DevSecOps` into a **meta-governance layer for frontends**.
+- multi-party approval before a deployment goes live
+- immutable, versioned ENS releases instead of mutable overwrite-in-place deploys
+- content-addressed IPFS storage that can be independently verified
 
-> **AUTARK** enforces a new rule where nothing goes live without consensus, and once live, new (as well as previous) version lives forever.
+> Nothing goes live without consensus, and every approved version remains available as an immutable artifact.
 
 ---
 
-# Overview
+## Overview
 
-Autark [/ô′tär″k/] derived from [autarky](https://en.wikipedia.org/wiki/Autarky), meaning self-sufficiency; is a crypto-anarchic  framework for frontend deployments.
+Autark adds a governance layer to frontend deployment.
 
-It transforms how teams ship code by introducing a meta-governance layer for frontends. A trustless, multi-sig process that enforces security at the developer layer while preserving decentralization.
+A release is built, uploaded to IPFS, mapped to a versioned ENS subdomain, and gated by Safe multisig approval before execution. In the recommended mode, subdomain creation and contenthash assignment are bundled into a single Safe transaction so the release is atomic.
 
-## Core Principles
+### Core Principles
 
-1. **ENFORCE BETTER**
-*Every deployment passes through explicit multi-party verification, and immutable cryptographic sealing.*
+1. **Enforce Better**  
+   Every deployment passes through explicit review and cryptographic sealing.
 
-2. **REJECT CENTRALIZED GATEKEEPERS**
-*No single-point of failure, no opaque CI/CD pipelines.*
+2. **Reject Single Points of Failure**  
+   No single developer, machine, or CI token should be able to ship production frontend code alone.
 
-3. **META-GOVERNANCE LAYER FOR FRONTENDS**
-*A decentralized review `dev` board encoded through Safe multisig decides what becomes production.*
+3. **Version, Don’t Overwrite**  
+   Each release becomes a permanent `vN.parent.eth` record instead of mutating one live address invisibly.
 
-4. **CRUCIAL PART OF THE  PIPELINE**
-*Autark integrates directly into **GitHub Actions**, enforcing multi-sig approval checkpoints before any code can go live.*
+4. **Keep Governance Close to the App**  
+   Frontend deployment is part of application security, not a separate convenience layer.
 
 ---
 
-# How it Works?
+## How It Works
+
+Autark replaces implicit trust with a verifiable release flow:
+
+1. Build static frontend output
+2. Upload the build to IPFS via Storacha
+3. Detect the next versioned ENS subdomain
+4. Create a Safe proposal
+5. Review and approve with threshold signers
+6. Execute the transaction and publish the immutable release
 
-Autark replaces “trust” with verifiable processes and cryptographic finality:
-<img width="1522" height="595" alt="Frame 5" src="https://github.com/user-attachments/assets/1a392867-b64e-4e12-a3b5-78fd9ee26788" />
+In the Safe-owned-parent mode, Autark batches:
 
-> Each release becomes an immutable record, and an auditable artifact of a more secure frontend versioning deployment.
+- `setSubnodeRecord` on ENS NameWrapper
+- `setContenthash` on the Public Resolver
 
-Explore: detailed [Technical Architecture](https://github.com/MihRazvan/ETHRome_hackathon/blob/main/docs/TECHNICAL-ARCHITECTURE.md) and extended [Flow Chart](https://github.com/MihRazvan/ETHRome_hackathon/blob/main/docs/FLOW-CHART.md).
+That means the version is created and pointed to the IPFS CID atomically.
+
+Explore the detailed flow in [User Flow](./docs/USER-FLOW.md) and the system design in [Technical Architecture](./docs/TECHNICAL-ARCHITECTURE.md).
 
 ---
 
-# Quickstart
+## Quickstart
 
-``` console
+```bash
 npm install -g autark
 autark init
 autark deploy dist
 ```
 
-Explore: detailed [User Guide](https://github.com/MihRazvan/ETHRome_hackathon/blob/main/docs/USER-GUIDE.md).
+For the full setup path, including Storacha auth, ENS configuration, channels, and auto-deploy hooks, see [Quickstart](./docs/QUICKSTART.md).
+
+---
+
+## Documentation
+
+Autark now ships with an active docs set on `genesis`:
+
+- [Quickstart](./docs/QUICKSTART.md)
+- [User Flow](./docs/USER-FLOW.md)
+- [Git Hooks](./docs/GIT-HOOKS.md)
+- [Technical Architecture](./docs/TECHNICAL-ARCHITECTURE.md)
+- [Architecture (Short)](./docs/ARCHITECTURE-SHORT.md)
+- [Docs Index](./docs/README.md)
+
+Older long-form hackathon docs remain available in [docs/_legacy](./docs/_legacy/).
 
 ---
 
-# Tech Stack
+## Tech Stack
+
+| Component | Technology | Purpose |
+| --- | --- | --- |
+| Governance | **Safe Multisig** | Threshold approval and release governance |
+| Immutability | **ENS NameWrapper** | Fuse-burned, versioned subdomains |
+| Storage | **IPFS + Storacha** | Content-addressed decentralized hosting |
+| Automation | **Git Hooks / CLI** | Deployment workflow automation |
+| Language | **Node.js / TypeScript** | CLI and release tooling |
+
+---
+
+## What We Shipped For PL Genesis
+
+This hackathon pass updated the original project into the current `0.1.2` implementation.
+
+### Product and CLI updates
+
+- added `promote` for moving mutable channels to immutable versions
+- added `rollback` as an explicit alias for channel rollback flows
+- added `channels` to inspect channel state and create missing channel subdomains via Safe proposals
+- improved `setup` so git hooks can run a custom build command before deploy
+
+### Deployment and infra updates
+
+- standardized on `autark` config naming while keeping backward compatibility for legacy config names
+- improved Storacha CLI integration and error handling for login and space-selection failures
+- removed the unused native Storacha provider path to keep one clear upload implementation
+- removed the vulnerable Safe starter kit dependency and moved runtime Safe handling to `protocol-kit` + `api-kit`
+- fixed the published CLI entrypoint so the globally installed `autark` binary works correctly
+
+### Demo and documentation updates
 
-| Component    | Technology                     | Purpose                                |
-| ------------ | ------------------------------ | -------------------------------------- |
-| Governance   | **Safe Multisig**              | Threshold approval and meta-governance |
-| Immutability | **ENS NameWrapper**            | Fuse-burned version locking            |
-| Storage      | **IPFS + Storacha**            | Verifiable decentralized hosting       |
-| Automation   | **Git Hooks + GitHub Actions** | DevSecOps enforcement layer            |
-| Language     | **Node.js / TypeScript**       | CLI and automation scripting           |
+- updated the example site for the PL Genesis demo flow
+- restored active docs for user flow, git hooks, and technical architecture on the `genesis` branch
+- removed old hackathon submission references from the main project entry points
 
-> [Autarky](https://en.wikipedia.org/wiki/Autarky) in code: build sovereign software, enforce your `devops` security.
+Autark is now published at version `0.1.2`.
 
 ---
 
-Built at [ETHRome](https://www.ethrome.org/) 2025.
+Built for the PL Genesis hackathon and continued here as an actively iterated solo project.
diff --git a/SUMMARY.md b/SUMMARY.md
@@ -0,0 +1,23 @@
+# Project Summary
+
+Autark is a DevSecOps framework for frontend deployments that replaces blind trust with multisig approval, immutable ENS versioning, and content-addressed IPFS releases. Instead of letting one developer, one CI token, or one deployment credential push code straight to production, Autark forces a governed release flow before anything goes live.
+
+## The problem
+
+Frontend deployment pipelines are still one of the weakest links in Web3 security. Even when smart contracts are secure, a compromised developer machine or CI/CD credential can push malicious frontend code to users in minutes. Traditional pipelines optimize for speed, but not for adversarial release governance.
+
+## The solution
+
+Autark introduces a security checkpoint before publication. A frontend build is uploaded to IPFS, mapped to a versioned ENS subdomain, and submitted as a Safe proposal before execution. Signers can review the intended release, verify the CID and commit context, and only then approve publication. The result is a deployment flow where every production version is explicit, auditable, and immutable.
+
+## The Storacha integration
+
+Storacha is the storage layer that makes each Autark release content-addressed and independently verifiable. Autark uploads the static build output to IPFS through the local Storacha CLI and receives a CID that becomes the release artifact. That CID is then written into ENS as the contenthash for the approved versioned subdomain. Because the deployment points to immutable IPFS content instead of a mutable web host, approved frontend versions remain permanent and inspectable after release.
+
+## Architecture
+
+Autark is built in Node.js and TypeScript as a CLI-first workflow. Safe handles governance, ENS NameWrapper handles immutable versioned subdomains and fuse policy, and Storacha provides IPFS-backed artifact storage. In the recommended mode, Autark creates one Safe proposal that atomically creates the next versioned subdomain and sets its resolver contenthash. Mutable channels like `live.parent.eth` can then be promoted or rolled back to immutable `vN.parent.eth` releases through additional Safe proposals.
+
+## Track
+
+Submitted for the PL Genesis hackathon. Continued as a solo project in the current `0.1.2` implementation.
diff --git a/autark.config.yaml b/autark.config.yaml
@@ -0,0 +1,28 @@
+# AUTARK Configuration
+# You can also use environment variables or CLI flags
+
+# Network Configuration
+network: sepolia
+rpcUrl: https://ethereum-sepolia-rpc.publicnode.com
+
+# ENS Configuration
+ensDomain: your-domain.eth
+
+# Safe Multisig Configuration
+safeAddress: 0x...
+safeApiKey: your-safe-api-key
+
+# Owner/Signer Configuration (for Safe operations)
+ownerPrivateKey: 0x...
+
+# Storacha Configuration (optional, uses CLI by default)
+# storachaKey: ...
+# storachaProof: ...
+
+# GitHub Configuration (optional)
+# githubToken: ghp_...
+# githubRepo: owner/repo
+
+# CLI Options
+quiet: false
+debug: false
diff --git a/docs/ARCHITECTURE-SHORT.md b/docs/ARCHITECTURE-SHORT.md
@@ -0,0 +1,39 @@
+# Architecture (Short)
+
+Autark adds a governance gate to frontend deployments.
+
+## Goal
+
+Prevent single-actor frontend takeover by requiring Safe multisig approval before ENS content is updated.
+
+## Deployment Pipeline
+
+1. Build frontend output (`dist/`)
+2. Upload output to IPFS via Storacha
+3. Resolve next versioned ENS subdomain (`vN.parent.eth`)
+4. Create Safe proposal:
+- Safe-owns-parent: batch `setSubnodeRecord + setContenthash`
+- Personal-owns-parent: create subdomain first, then Safe proposal for `setContenthash`
+5. Multisig signers review and execute
+6. Subdomain is immutable through NameWrapper fuses
+
+## Security Properties
+
+- Multi-party approval checkpoint (Safe threshold)
+- Content-addressed artifacts (IPFS CID)
+- Versioned immutable releases (`v0`, `v1`, ...)
+- On-chain audit trail for release operations
+
+## Key Modules
+
+- CLI entry: `src/cli/index.ts`
+- Main deploy flow: `src/cli/commands/deploy.ts`
+- Config merge/validation: `src/lib/config.ts`
+- IPFS upload: `src/lib/ipfs/upload.ts`
+- ENS version and planning: `src/lib/ens/version.ts`, `src/lib/ens/deploy.ts`
+- Safe integration: `src/lib/safe/client.ts`, `src/lib/ens/safe-batch-deploy.ts`
+
+## Notes
+
+- The current repo also contains legacy experimental scripts under `src/test` and `src/core`.
+- Long-form architecture and hackathon docs are archived in `docs/_legacy/`.