From 568308c47c55b932b03e7e8320e37452e7109de8 Mon Sep 17 00:00:00 2001
From: "google-labs-jules[bot]"
 <161369871+google-labs-jules[bot]@users.noreply.github.com>
Date: Mon, 20 Oct 2025 17:33:18 +0000
Subject: [PATCH 1/2] feat: Create implementation roadmap for LiveChain Mesh

Adds a comprehensive implementation roadmap for the LiveChain Mesh architecture, a decentralized video multistreaming platform.

The document outlines a three-month plan, including a Proof-of-Concept, a Pilot Program, and a Production Hardening phase. It details the proposed technology stack, resource plan, and a thorough risk assessment.

This roadmap provides a clear, actionable strategy for developing and deploying the platform.
---
 foundry_installer.sh                    | 64 ++++++++++++++++++
 livechain_roadmap.md                    | 87 +++++++++++++++++++++++++
 ~/.docker/buildx/buildkitd.default.toml |  2 +
 3 files changed, 153 insertions(+)
 create mode 100755 foundry_installer.sh
 create mode 100644 livechain_roadmap.md
 create mode 100644 ~/.docker/buildx/buildkitd.default.toml

diff --git a/foundry_installer.sh b/foundry_installer.sh
new file mode 100755
index 0000000..2a01e27
--- /dev/null
+++ b/foundry_installer.sh
@@ -0,0 +1,64 @@
+#!/usr/bin/env bash
+set -eo pipefail
+
+echo "Installing foundryup..."
+
+BASE_DIR="${XDG_CONFIG_HOME:-$HOME}"
+FOUNDRY_DIR="${FOUNDRY_DIR:-"$BASE_DIR/.foundry"}"
+FOUNDRY_BIN_DIR="$FOUNDRY_DIR/bin"
+FOUNDRY_MAN_DIR="$FOUNDRY_DIR/share/man/man1"
+
+BIN_URL="https://raw.githubusercontent.com/foundry-rs/foundry/master/foundryup/foundryup"
+BIN_PATH="$FOUNDRY_BIN_DIR/foundryup"
+
+# Create the .foundry bin directory and foundryup binary if it doesn't exist.
+mkdir -p "$FOUNDRY_BIN_DIR"
+curl -sSf -L "$BIN_URL" -o "$BIN_PATH"
+chmod +x "$BIN_PATH"
+
+# Create the man directory for future man files if it doesn't exist.
+mkdir -p "$FOUNDRY_MAN_DIR"
+
+# Store the correct profile file (i.e. .profile for bash or .zshenv for ZSH).
+case $SHELL in
+*/zsh)
+    PROFILE="${ZDOTDIR-"$HOME"}/.zshenv"
+    PREF_SHELL=zsh
+    ;;
+*/bash)
+    PROFILE=$HOME/.bashrc
+    PREF_SHELL=bash
+    ;;
+*/fish)
+    PROFILE=$HOME/.config/fish/config.fish
+    PREF_SHELL=fish
+    ;;
+*/ash)
+    PROFILE=$HOME/.profile
+    PREF_SHELL=ash
+    ;;
+*)
+    echo "foundryup: could not detect shell, manually add ${FOUNDRY_BIN_DIR} to your PATH."
+    exit 1
+esac
+
+# Only add foundryup if it isn't already in PATH.
+if [[ ":$PATH:" != *":${FOUNDRY_BIN_DIR}:"* ]]; then
+    # Add the foundryup directory to the path and ensure the old PATH variables remain.
+    # If the shell is fish, echo fish_add_path instead of export.
+    if [[ "$PREF_SHELL" == "fish" ]]; then
+        echo >> "$PROFILE" && echo "fish_add_path -a \"$FOUNDRY_BIN_DIR\"" >> "$PROFILE"
+    else
+        echo >> "$PROFILE" && echo "export PATH=\"\$PATH:$FOUNDRY_BIN_DIR\"" >> "$PROFILE"
+    fi
+fi
+
+# Warn MacOS users that they may need to manually install libusb via Homebrew:
+if [[ "$OSTYPE" =~ ^darwin ]] && [[ ! -f /usr/local/opt/libusb/lib/libusb-1.0.0.dylib ]] && [[ ! -f /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib ]]; then
+    echo && echo "warning: libusb not found. You may need to install it manually on MacOS via Homebrew (brew install libusb)."
+fi
+
+echo
+echo "Detected your preferred shell is $PREF_SHELL and added foundryup to PATH."
+echo "Run 'source $PROFILE' or start a new terminal session to use foundryup."
+echo "Then, simply run 'foundryup' to install Foundry."
diff --git a/livechain_roadmap.md b/livechain_roadmap.md
new file mode 100644
index 0000000..abbae4e
--- /dev/null
+++ b/livechain_roadmap.md
@@ -0,0 +1,87 @@
+# LiveChain Mesh: Implementation Roadmap and PoC Plan
+
+## 1. Introduction
+
+This document outlines a phased implementation roadmap for developing and deploying a decentralized multistreaming solution based on the **LiveChain Mesh** architecture. The goal is to build a resilient, scalable, and cost-effective platform that overcomes the limitations of traditional, centralized multistreaming setups.
+
+This roadmap is designed for a Proof-of-Concept (PoC) and subsequent pilot program, with a focus on validating the core technical assumptions and demonstrating the viability of the architecture before a full-scale production rollout.
+
+## 2. Proof-of-Concept (PoC) Goals & Success Criteria
+
+The primary objective of the PoC is to validate the foundational components of the LiveChain Mesh architecture.
+
+**Success Criteria:**
+
+*   **SC1: Successful End-to-End Stream:** A single broadcaster can successfully stream a 1080p/30fps feed through one transcoding edge node to at least two simultaneous destinations (e.g., YouTube and Twitch).
+*   **SC2: Latency Target:** The average end-to-end latency from broadcaster to final destination must be below **200ms**.
+*   **SC3: P2P Network Stability:** The Lattica P2P overlay network, consisting of at least 4 nodes (1 broadcaster, 1 edge node, 2 viewers), maintains stable connectivity for a continuous 1-hour stream with no more than 1% packet loss.
+*   **SC4: Smart Contract Interaction:** The `StreamRegistry.sol` smart contract, deployed on a public testnet (Polygon Amoy), correctly registers and updates the status of the live stream.
+*   **SC5: Transcoding Validation:** The GPU-enabled edge node must successfully transcode the incoming RTMP stream into the required format for the final destinations without introducing significant artifacts (maintaining a VMAF score of ≥ 90).
+
+## 3. Phased Rollout
+
+### Phase 1: Proof-of-Concept (Month 1)
+
+This phase focuses on building and validating the core components of the LiveChain Mesh.
+
+| Week | Key Tasks                                                                                                                              | Owner            | Outcome                                                                                                 |
+| ---- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------- |
+| **1**  | **Smart Contract & P2P Setup**<br>- Develop & test `StreamRegistry.sol` using Foundry.<br>- Deploy contract to Polygon Amoy testnet.<br>- Set up a minimal 4-node Lattica P2P network on AWS EC2. | Blockchain Dev   | A functional smart contract and a stable P2P overlay network.                                           |
+| **2**  | **Broadcaster Client Development**<br>- Build a Go client that captures an RTMP stream.<br>- Integrate FFmpeg for initial encoding.<br>- Implement logic to connect to the Lattica network and publish the stream. | Media Dev        | A command-line broadcaster application that can push a live stream to the P2P network.                   |
+| **3**  | **Edge Node Development**<br>- Build a Go application for the edge node.<br>- Implement logic to pull a stream from the Lattica network.<br>- Integrate FFmpeg with GPU acceleration (NVENC) for transcoding.<br>- Implement logic to push the transcoded stream to RTMP endpoints. | Media Dev        | A functional edge node capable of transcoding and relaying one stream.                                    |
+| **4**  | **Integration & Testing**<br>- Integrate all components.<br>- Conduct end-to-end stream tests to validate PoC Success Criteria.<br>- Set up basic Prometheus monitoring for nodes.<br>- Document results and identify bottlenecks. | All              | A successful end-to-end stream that meets the defined latency, stability, and quality targets.          |
+
+### Phase 2: Pilot Program (Month 2)
+
+The goal of this phase is to test the network's scalability, incentive model, and monitoring under more realistic conditions.
+
+| Week | Key Tasks                                                                                                                              | Owner            | Outcome                                                                                                 |
+| ---- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------- |
+| **5**  | **Network Expansion & Incentive Model**<br>- Scale the P2P network to 15 geographically distributed nodes (e.g., US-East, EU-West, Asia-East).<br>- Develop and deploy the `EdgeReward.sol` contract and the `STREAM` ERC-20 token.<br>- Integrate token reward logic into the edge node application. | Blockchain Dev   | A scaled-up network and a functional economic model for incentivizing participation.                      |
+| **6**  | **Advanced Monitoring & Dashboard**<br>- Set up a centralized Grafana dashboard.<br>- Implement Prometheus exporters in the broadcaster and edge nodes to track critical metrics (latency, bitrate, GPU usage, VMAF score).<br>- Develop a simple web dashboard for viewing stream status and node rewards. | DevOps/Media Dev | Real-time visibility into the health and performance of the entire network.                             |
+| **7**  | **Multi-Stream & ABR Testing**<br>- Enhance the edge node to handle at least 3 concurrent streams.<br>- Implement Adaptive Bitrate (ABR) logic to handle varying network conditions.<br>- Conduct scalability tests with multiple broadcasters and viewers. | Media Dev        | A more robust edge node capable of handling a moderate load and adapting to network fluctuations.        |
+| **8**  | **Pilot Review & Feedback**<br>- Invite a small group of friendly testers to use the platform.<br>- Gather feedback on stream quality and stability.<br>- Analyze performance data and identify key areas for optimization. | All              | Actionable insights and performance data to guide the production hardening phase.                      |
+
+### Phase 3: Production Hardening (Month 3)
+
+This phase focuses on ensuring the platform is secure, scalable, and reliable enough for a production environment.
+
+| Week | Key Tasks                                                                                                                              | Owner            | Outcome                                                                                                 |
+| ---- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------- |
+| **9**  | **Security Audits**<br>- Conduct a full security audit of all smart contracts (`StreamRegistry`, `EdgeReward`).<br>- Perform penetration testing on the P2P network and public-facing APIs.<br>- Remediate any identified vulnerabilities. | Security/BC Dev  | Audited and secured smart contracts and network infrastructure.                                         |
+| **10** | **Scalability & Stress Testing**<br>- Use a load testing framework (e.g., k6) to simulate 100+ concurrent broadcasters and 1000+ viewers.<br>- Identify and resolve performance bottlenecks in the edge nodes and P2P layer.<br>- Optimize database queries and smart contract gas usage. | DevOps/Media Dev | A clear understanding of the platform's performance limits and a plan for future scaling.               |
+| **11** | **SLA Oracle & Automated Monitoring**<br>- Develop and deploy the `SLAOracle.sol` contract.<br>- Integrate Chainlink or a custom off-chain oracle to feed real-time QoE metrics (latency, VMAF) into the SLA contract.<br>- Automate penalty/reward adjustments based on SLA compliance. | Blockchain Dev   | A trustless, automated system for enforcing quality of service standards.                                 |
+| **12** | **Documentation & Launch Preparation**<br>- Finalize technical documentation for node operators and broadcasters.<br>- Prepare a public launch plan and marketing materials.<br>- Final review of all components and sign-off for production deployment. | All              | A production-ready platform with comprehensive documentation, ready for public launch.                    |
+
+## 4. Proposed Technology Stack
+
+| Component             | Technology Choice                                       | Justification                                                                                             |
+| --------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+| **P2P Network Layer**   | **Lattica (Rust Implementation)**                       | Aligns with the report. Rust provides memory safety and performance, critical for a network overlay.       |
+| **Smart Contracts**    | **Solidity**                                            | The de-facto standard for EVM-compatible chains.                                                          |
+| **Blockchain Testnet**  | **Polygon Amoy**                                        | Low transaction costs, high throughput, and strong developer tooling (Foundry). Ideal for a PoC.          |
+| **Broadcaster Client**  | **Custom Go Application + FFmpeg**                       | Go offers excellent concurrency for handling media streams. FFmpeg is the industry standard for transcoding. |
+| **Edge Node**           | **Go Application + FFmpeg (with NVENC/Quick Sync)**     | Go for network logic, FFmpeg for hardware-accelerated transcoding.                                         |
+| **Cloud Provider**      | **AWS / GCP**                                           | For initial node deployment, offering GPU instances (e.g., EC2 G4/G5) required for the edge node.         |
+| **Monitoring**          | **Prometheus + Grafana**                                | Industry-standard stack for monitoring network and application metrics.                                   |
+
+## 5. Resource Plan
+
+This plan outlines the personnel required for the successful execution of the 3-month roadmap.
+
+| Role               | Allocation | Responsibilities                                                                        |
+| ------------------ | ---------- | --------------------------------------------------------------------------------------- |
+| **Project Lead**     | 50%        | Oversee project milestones, manage resources, and coordinate between teams.             |
+| **Blockchain Dev**   | 100%       | Develop, test, and deploy all Solidity smart contracts; manage blockchain infrastructure. |
+| **Media Dev (Go)**   | 100%       | Build and maintain the broadcaster and edge node applications; integrate with Lattica.    |
+| **DevOps Engineer**  | 75%        | Manage cloud infrastructure (AWS/GCP), CI/CD pipelines, and monitoring (Prometheus/Grafana). |
+| **Security Auditor** | External   | Contracted for the Phase 3 security audit of smart contracts and network components.     |
+
+## 6. Risk Assessment & Mitigation
+
+| Risk Category         | Description                                                                                             | Likelihood | Impact | Mitigation Strategy                                                                                             |
+| --------------------- | ------------------------------------------------------------------------------------------------------- | ---------- | ------ | --------------------------------------------------------------------------------------------------------------- |
+| **Technical Risk**    | The Lattica P2P library, being a relatively new technology, may have undiscovered bugs or performance limitations. | Medium     | High   | **Mitigation:** Allocate extra time in Phase 1 for thorough testing and benchmarking. Engage with the Lattica developer community for support. Develop a contingency plan to use a more established P2P library (e.g., libp2p) if major issues arise. |
+| **Economic Risk**     | The `STREAM` token's value may be volatile, making the incentive model unpredictable and potentially unattractive for node operators. | High       | Medium | **Mitigation:** Initially, peg the `STREAM` reward value to a stablecoin (e.g., USDC) to guarantee predictable earnings for node operators. Introduce a governance model in a later phase to allow the community to vote on reward parameters. |
+| **Execution Risk**    | The 3-month timeline is ambitious and could be delayed by unforeseen technical challenges or resource constraints. | Medium     | Medium | **Mitigation:** Adopt an agile development approach with weekly sprints and regular reviews. Prioritize core features and be prepared to de-scope non-essential items to meet deadlines. Maintain a buffer in the project budget for unexpected costs. |
+| **Adoption Risk**     | Broadcasters and viewers may be hesitant to adopt a new, decentralized platform due to a lack of awareness or trust. | Medium     | High   | **Mitigation:** During the pilot program, actively engage with a small group of influential creators to gather feedback and build case studies. Develop clear documentation and tutorials. Offer initial incentives (e.g., bonus `STREAM` tokens) to early adopters. |
diff --git a/~/.docker/buildx/buildkitd.default.toml b/~/.docker/buildx/buildkitd.default.toml
new file mode 100644
index 0000000..3946ff7
--- /dev/null
+++ b/~/.docker/buildx/buildkitd.default.toml
@@ -0,0 +1,2 @@
+[registry."docker.io"]
+  mirrors = ["mirror.gcr.io"]

From c0f8a3232c5d2a5e761b5e7035e536a6be5a67b5 Mon Sep 17 00:00:00 2001
From: "google-labs-jules[bot]"
 <161369871+google-labs-jules[bot]@users.noreply.github.com>
Date: Mon, 20 Oct 2025 17:53:38 +0000
Subject: [PATCH 2/2] feat: Propose Ethos OS features inspired by Wavelink

This document proposes a set of new, OS-level features for the Ethos (Ethereum Operating System) project, inspired by the "wavelink" topic on GitHub.

The proposals include:
1. A "Generalized Service Offloading Protocol" for delegating resource-intensive tasks.
2. A "Decentralized Real-Time Communication (D-RTC) Service" for native audio/video.
3. A "Programmable Media Mixing Layer" for on-the-fly composition of media streams.

These features aim to provide a powerful, cohesive foundation for building sophisticated, real-time, decentralized applications on Ethos.
---
 ethos_wavelink_features.md | 58 +++++++++++++++++++++++++
 foundry_installer.sh       | 64 ----------------------------
 livechain_roadmap.md       | 87 --------------------------------------
 3 files changed, 58 insertions(+), 151 deletions(-)
 create mode 100644 ethos_wavelink_features.md
 delete mode 100755 foundry_installer.sh
 delete mode 100644 livechain_roadmap.md

diff --git a/ethos_wavelink_features.md b/ethos_wavelink_features.md
new file mode 100644
index 0000000..62791e9
--- /dev/null
+++ b/ethos_wavelink_features.md
@@ -0,0 +1,58 @@
+# Ethos Feature Proposals: Inspired by Wavelink
+
+## Introduction
+
+This document proposes a set of new, OS-level features for the Ethos (Ethereum Operating System) project. The inspiration for these features comes from a thorough analysis of the technologies and concepts associated with the "wavelink" topic on GitHub, which primarily encompasses two areas: the Lavalink/Wavelink client-server architecture for offloading audio processing, and the Elgato Wave Link software for real-time audio mixing.
+
+By generalizing these concepts, we can create powerful, native services within Ethos that will enable a new generation of decentralized applications.
+
+## 1. Core Feature: Generalized Service Offloading Protocol
+
+**Concept:** Derived from the Lavalink/Wavelink model, this is a native, OS-level protocol that allows any dApp to delegate resource-intensive, specialized tasks to a decentralized network of incentivized service nodes. This is analogous to how a traditional OS offloads tasks to a GPU, but generalized for any task.
+
+**Proposed Implementation:**
+
+*   **Service Registry:** A smart contract where service nodes can register their capabilities (e.g., "video transcoding," "AI inference," "ZKP generation") and their pricing.
+*   **Task Delegation:** An OS-level API that allows dApps to submit a "task request" to the registry. The OS, via the protocol, would then select a suitable and available service node.
+*   **Incentive Mechanism:** The protocol would handle the financial aspects, escrowing payment from the dApp and releasing it to the service node upon successful completion of the task, verified either by the dApp or a decentralized oracle.
+*   **Data Transport:** The protocol would leverage a robust P2P communication layer (like Lattica, as researched in the multistreaming project) to handle the transfer of data between the dApp and the service node.
+
+**Benefits:**
+
+*   **Scalability:** dApps can remain lightweight and efficient, offloading heavy computation.
+*   **Flexibility:** Any specialized task can be made available as a service on the network.
+*   **Economic Incentive:** Creates a new economic layer for users to provide computational resources to the network.
+
+## 2. D-RTC: Decentralized Real-Time Communication Service
+
+**Concept:** A specific, high-value implementation of the Service Offloading Protocol, designed to provide robust, low-latency audio and video communication services directly within the OS. This would function as a decentralized alternative to WebRTC, but with native integration and incentives.
+
+**Proposed Implementation:**
+
+*   **Service Nodes:** A specialized subset of service nodes would register as "D-RTC nodes," running optimized software for audio/video processing and routing (inspired by Lavalink).
+*   **OS-Level API:** Ethos would provide a simple API for dApps to initiate and manage audio/video sessions (e.g., `initiateCall(participants)`, `createStream(source)`).
+*   **Media Routing:** The D-RTC nodes would handle the complex tasks of media routing, transcoding, and mixing, ensuring low latency and high quality, even with many participants.
+*   **Use Cases:** This would be a foundational service for decentralized social media, gaming (in-game voice chat), and streaming applications.
+
+---
+## 3. Programmable Media Mixing Layer
+
+**Concept:** Inspired by the fine-grained control of Elgato's Wave Link software, this is a higher-level OS service, built on top of the D-RTC service, that allows for the sophisticated, on-the-fly composition and manipulation of media streams.
+
+**Proposed Implementation:**
+
+*   **Media Graph API:** Ethos would provide an API for dApps to define a "media graph," specifying sources (e.g., a user's microphone, a game's audio, a D-RTC stream from another user), processing nodes (e.g., "volume control," "equalizer," "noise suppression"), and output sinks (e.g., "main speakers," "stream output," "recording file").
+*   **Decentralized Mixing:** The actual mixing and processing of the media graph would be handled by D-RTC service nodes, ensuring that the user's local device is not burdened with the task.
+*   **Composable Streams:** This would allow for powerful, dynamic audio/video experiences. For example, a decentralized streaming application could allow the audience to choose which gamer's voice they want to listen to, or a social VR application could apply spatial audio effects to participants' voices based on their location in the virtual world.
+
+**Benefits:**
+
+*   **Rich Media Experiences:** Enables complex, interactive audio/video applications that are not possible with traditional, rigid streaming models.
+*   **User Empowerment:** Gives users and developers fine-grained control over their media streams.
+*   **Efficiency:** Offloads the complex task of media mixing to the decentralized network of service nodes.
+
+---
+
+## Conclusion
+
+The features proposed in this document—a generalized offloading protocol, a native decentralized RTC service, and a programmable media mixing layer—represent a powerful, cohesive vision for the future of Ethos. By abstracting the core principles of the "wavelink" ecosystem, we can provide developers with the tools to build a new class of sophisticated, real-time, decentralized applications that are both highly scalable and richly interactive.
diff --git a/foundry_installer.sh b/foundry_installer.sh
deleted file mode 100755
index 2a01e27..0000000
--- a/foundry_installer.sh
+++ /dev/null
@@ -1,64 +0,0 @@
-#!/usr/bin/env bash
-set -eo pipefail
-
-echo "Installing foundryup..."
-
-BASE_DIR="${XDG_CONFIG_HOME:-$HOME}"
-FOUNDRY_DIR="${FOUNDRY_DIR:-"$BASE_DIR/.foundry"}"
-FOUNDRY_BIN_DIR="$FOUNDRY_DIR/bin"
-FOUNDRY_MAN_DIR="$FOUNDRY_DIR/share/man/man1"
-
-BIN_URL="https://raw.githubusercontent.com/foundry-rs/foundry/master/foundryup/foundryup"
-BIN_PATH="$FOUNDRY_BIN_DIR/foundryup"
-
-# Create the .foundry bin directory and foundryup binary if it doesn't exist.
-mkdir -p "$FOUNDRY_BIN_DIR"
-curl -sSf -L "$BIN_URL" -o "$BIN_PATH"
-chmod +x "$BIN_PATH"
-
-# Create the man directory for future man files if it doesn't exist.
-mkdir -p "$FOUNDRY_MAN_DIR"
-
-# Store the correct profile file (i.e. .profile for bash or .zshenv for ZSH).
-case $SHELL in
-*/zsh)
-    PROFILE="${ZDOTDIR-"$HOME"}/.zshenv"
-    PREF_SHELL=zsh
-    ;;
-*/bash)
-    PROFILE=$HOME/.bashrc
-    PREF_SHELL=bash
-    ;;
-*/fish)
-    PROFILE=$HOME/.config/fish/config.fish
-    PREF_SHELL=fish
-    ;;
-*/ash)
-    PROFILE=$HOME/.profile
-    PREF_SHELL=ash
-    ;;
-*)
-    echo "foundryup: could not detect shell, manually add ${FOUNDRY_BIN_DIR} to your PATH."
-    exit 1
-esac
-
-# Only add foundryup if it isn't already in PATH.
-if [[ ":$PATH:" != *":${FOUNDRY_BIN_DIR}:"* ]]; then
-    # Add the foundryup directory to the path and ensure the old PATH variables remain.
-    # If the shell is fish, echo fish_add_path instead of export.
-    if [[ "$PREF_SHELL" == "fish" ]]; then
-        echo >> "$PROFILE" && echo "fish_add_path -a \"$FOUNDRY_BIN_DIR\"" >> "$PROFILE"
-    else
-        echo >> "$PROFILE" && echo "export PATH=\"\$PATH:$FOUNDRY_BIN_DIR\"" >> "$PROFILE"
-    fi
-fi
-
-# Warn MacOS users that they may need to manually install libusb via Homebrew:
-if [[ "$OSTYPE" =~ ^darwin ]] && [[ ! -f /usr/local/opt/libusb/lib/libusb-1.0.0.dylib ]] && [[ ! -f /opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib ]]; then
-    echo && echo "warning: libusb not found. You may need to install it manually on MacOS via Homebrew (brew install libusb)."
-fi
-
-echo
-echo "Detected your preferred shell is $PREF_SHELL and added foundryup to PATH."
-echo "Run 'source $PROFILE' or start a new terminal session to use foundryup."
-echo "Then, simply run 'foundryup' to install Foundry."
diff --git a/livechain_roadmap.md b/livechain_roadmap.md
deleted file mode 100644
index abbae4e..0000000
--- a/livechain_roadmap.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# LiveChain Mesh: Implementation Roadmap and PoC Plan
-
-## 1. Introduction
-
-This document outlines a phased implementation roadmap for developing and deploying a decentralized multistreaming solution based on the **LiveChain Mesh** architecture. The goal is to build a resilient, scalable, and cost-effective platform that overcomes the limitations of traditional, centralized multistreaming setups.
-
-This roadmap is designed for a Proof-of-Concept (PoC) and subsequent pilot program, with a focus on validating the core technical assumptions and demonstrating the viability of the architecture before a full-scale production rollout.
-
-## 2. Proof-of-Concept (PoC) Goals & Success Criteria
-
-The primary objective of the PoC is to validate the foundational components of the LiveChain Mesh architecture.
-
-**Success Criteria:**
-
-*   **SC1: Successful End-to-End Stream:** A single broadcaster can successfully stream a 1080p/30fps feed through one transcoding edge node to at least two simultaneous destinations (e.g., YouTube and Twitch).
-*   **SC2: Latency Target:** The average end-to-end latency from broadcaster to final destination must be below **200ms**.
-*   **SC3: P2P Network Stability:** The Lattica P2P overlay network, consisting of at least 4 nodes (1 broadcaster, 1 edge node, 2 viewers), maintains stable connectivity for a continuous 1-hour stream with no more than 1% packet loss.
-*   **SC4: Smart Contract Interaction:** The `StreamRegistry.sol` smart contract, deployed on a public testnet (Polygon Amoy), correctly registers and updates the status of the live stream.
-*   **SC5: Transcoding Validation:** The GPU-enabled edge node must successfully transcode the incoming RTMP stream into the required format for the final destinations without introducing significant artifacts (maintaining a VMAF score of ≥ 90).
-
-## 3. Phased Rollout
-
-### Phase 1: Proof-of-Concept (Month 1)
-
-This phase focuses on building and validating the core components of the LiveChain Mesh.
-
-| Week | Key Tasks                                                                                                                              | Owner            | Outcome                                                                                                 |
-| ---- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------- |
-| **1**  | **Smart Contract & P2P Setup**<br>- Develop & test `StreamRegistry.sol` using Foundry.<br>- Deploy contract to Polygon Amoy testnet.<br>- Set up a minimal 4-node Lattica P2P network on AWS EC2. | Blockchain Dev   | A functional smart contract and a stable P2P overlay network.                                           |
-| **2**  | **Broadcaster Client Development**<br>- Build a Go client that captures an RTMP stream.<br>- Integrate FFmpeg for initial encoding.<br>- Implement logic to connect to the Lattica network and publish the stream. | Media Dev        | A command-line broadcaster application that can push a live stream to the P2P network.                   |
-| **3**  | **Edge Node Development**<br>- Build a Go application for the edge node.<br>- Implement logic to pull a stream from the Lattica network.<br>- Integrate FFmpeg with GPU acceleration (NVENC) for transcoding.<br>- Implement logic to push the transcoded stream to RTMP endpoints. | Media Dev        | A functional edge node capable of transcoding and relaying one stream.                                    |
-| **4**  | **Integration & Testing**<br>- Integrate all components.<br>- Conduct end-to-end stream tests to validate PoC Success Criteria.<br>- Set up basic Prometheus monitoring for nodes.<br>- Document results and identify bottlenecks. | All              | A successful end-to-end stream that meets the defined latency, stability, and quality targets.          |
-
-### Phase 2: Pilot Program (Month 2)
-
-The goal of this phase is to test the network's scalability, incentive model, and monitoring under more realistic conditions.
-
-| Week | Key Tasks                                                                                                                              | Owner            | Outcome                                                                                                 |
-| ---- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------- |
-| **5**  | **Network Expansion & Incentive Model**<br>- Scale the P2P network to 15 geographically distributed nodes (e.g., US-East, EU-West, Asia-East).<br>- Develop and deploy the `EdgeReward.sol` contract and the `STREAM` ERC-20 token.<br>- Integrate token reward logic into the edge node application. | Blockchain Dev   | A scaled-up network and a functional economic model for incentivizing participation.                      |
-| **6**  | **Advanced Monitoring & Dashboard**<br>- Set up a centralized Grafana dashboard.<br>- Implement Prometheus exporters in the broadcaster and edge nodes to track critical metrics (latency, bitrate, GPU usage, VMAF score).<br>- Develop a simple web dashboard for viewing stream status and node rewards. | DevOps/Media Dev | Real-time visibility into the health and performance of the entire network.                             |
-| **7**  | **Multi-Stream & ABR Testing**<br>- Enhance the edge node to handle at least 3 concurrent streams.<br>- Implement Adaptive Bitrate (ABR) logic to handle varying network conditions.<br>- Conduct scalability tests with multiple broadcasters and viewers. | Media Dev        | A more robust edge node capable of handling a moderate load and adapting to network fluctuations.        |
-| **8**  | **Pilot Review & Feedback**<br>- Invite a small group of friendly testers to use the platform.<br>- Gather feedback on stream quality and stability.<br>- Analyze performance data and identify key areas for optimization. | All              | Actionable insights and performance data to guide the production hardening phase.                      |
-
-### Phase 3: Production Hardening (Month 3)
-
-This phase focuses on ensuring the platform is secure, scalable, and reliable enough for a production environment.
-
-| Week | Key Tasks                                                                                                                              | Owner            | Outcome                                                                                                 |
-| ---- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------- |
-| **9**  | **Security Audits**<br>- Conduct a full security audit of all smart contracts (`StreamRegistry`, `EdgeReward`).<br>- Perform penetration testing on the P2P network and public-facing APIs.<br>- Remediate any identified vulnerabilities. | Security/BC Dev  | Audited and secured smart contracts and network infrastructure.                                         |
-| **10** | **Scalability & Stress Testing**<br>- Use a load testing framework (e.g., k6) to simulate 100+ concurrent broadcasters and 1000+ viewers.<br>- Identify and resolve performance bottlenecks in the edge nodes and P2P layer.<br>- Optimize database queries and smart contract gas usage. | DevOps/Media Dev | A clear understanding of the platform's performance limits and a plan for future scaling.               |
-| **11** | **SLA Oracle & Automated Monitoring**<br>- Develop and deploy the `SLAOracle.sol` contract.<br>- Integrate Chainlink or a custom off-chain oracle to feed real-time QoE metrics (latency, VMAF) into the SLA contract.<br>- Automate penalty/reward adjustments based on SLA compliance. | Blockchain Dev   | A trustless, automated system for enforcing quality of service standards.                                 |
-| **12** | **Documentation & Launch Preparation**<br>- Finalize technical documentation for node operators and broadcasters.<br>- Prepare a public launch plan and marketing materials.<br>- Final review of all components and sign-off for production deployment. | All              | A production-ready platform with comprehensive documentation, ready for public launch.                    |
-
-## 4. Proposed Technology Stack
-
-| Component             | Technology Choice                                       | Justification                                                                                             |
-| --------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
-| **P2P Network Layer**   | **Lattica (Rust Implementation)**                       | Aligns with the report. Rust provides memory safety and performance, critical for a network overlay.       |
-| **Smart Contracts**    | **Solidity**                                            | The de-facto standard for EVM-compatible chains.                                                          |
-| **Blockchain Testnet**  | **Polygon Amoy**                                        | Low transaction costs, high throughput, and strong developer tooling (Foundry). Ideal for a PoC.          |
-| **Broadcaster Client**  | **Custom Go Application + FFmpeg**                       | Go offers excellent concurrency for handling media streams. FFmpeg is the industry standard for transcoding. |
-| **Edge Node**           | **Go Application + FFmpeg (with NVENC/Quick Sync)**     | Go for network logic, FFmpeg for hardware-accelerated transcoding.                                         |
-| **Cloud Provider**      | **AWS / GCP**                                           | For initial node deployment, offering GPU instances (e.g., EC2 G4/G5) required for the edge node.         |
-| **Monitoring**          | **Prometheus + Grafana**                                | Industry-standard stack for monitoring network and application metrics.                                   |
-
-## 5. Resource Plan
-
-This plan outlines the personnel required for the successful execution of the 3-month roadmap.
-
-| Role               | Allocation | Responsibilities                                                                        |
-| ------------------ | ---------- | --------------------------------------------------------------------------------------- |
-| **Project Lead**     | 50%        | Oversee project milestones, manage resources, and coordinate between teams.             |
-| **Blockchain Dev**   | 100%       | Develop, test, and deploy all Solidity smart contracts; manage blockchain infrastructure. |
-| **Media Dev (Go)**   | 100%       | Build and maintain the broadcaster and edge node applications; integrate with Lattica.    |
-| **DevOps Engineer**  | 75%        | Manage cloud infrastructure (AWS/GCP), CI/CD pipelines, and monitoring (Prometheus/Grafana). |
-| **Security Auditor** | External   | Contracted for the Phase 3 security audit of smart contracts and network components.     |
-
-## 6. Risk Assessment & Mitigation
-
-| Risk Category         | Description                                                                                             | Likelihood | Impact | Mitigation Strategy                                                                                             |
-| --------------------- | ------------------------------------------------------------------------------------------------------- | ---------- | ------ | --------------------------------------------------------------------------------------------------------------- |
-| **Technical Risk**    | The Lattica P2P library, being a relatively new technology, may have undiscovered bugs or performance limitations. | Medium     | High   | **Mitigation:** Allocate extra time in Phase 1 for thorough testing and benchmarking. Engage with the Lattica developer community for support. Develop a contingency plan to use a more established P2P library (e.g., libp2p) if major issues arise. |
-| **Economic Risk**     | The `STREAM` token's value may be volatile, making the incentive model unpredictable and potentially unattractive for node operators. | High       | Medium | **Mitigation:** Initially, peg the `STREAM` reward value to a stablecoin (e.g., USDC) to guarantee predictable earnings for node operators. Introduce a governance model in a later phase to allow the community to vote on reward parameters. |
-| **Execution Risk**    | The 3-month timeline is ambitious and could be delayed by unforeseen technical challenges or resource constraints. | Medium     | Medium | **Mitigation:** Adopt an agile development approach with weekly sprints and regular reviews. Prioritize core features and be prepared to de-scope non-essential items to meet deadlines. Maintain a buffer in the project budget for unexpected costs. |
-| **Adoption Risk**     | Broadcasters and viewers may be hesitant to adopt a new, decentralized platform due to a lack of awareness or trust. | Medium     | High   | **Mitigation:** During the pilot program, actively engage with a small group of influential creators to gather feedback and build case studies. Develop clear documentation and tutorials. Offer initial incentives (e.g., bonus `STREAM` tokens) to early adopters. |