Skip to content

Repository files navigation

Stability Nexus      Chainvoice

Stability Nexus · Chainvoice

OpenSSF Scorecard

Telegram   X (Twitter)   Discord   Stable Viewpoints   LinkedIn   YouTube


Chainvoice

Chainvoice is a decentralized invoicing platform that enables secure, transparent, and tamper‑proof invoice creation, management, and payments on blockchain. Powered by Ethereum-compatible smart contracts, Chainvoice automates payment flows and reduces reliance on intermediaries.

Table of Contents

Overview

Chainvoice transforms traditional invoicing by leveraging blockchain technology to create a trustless, automated payment system. Users can create invoices, manage payments, and track transaction history with complete transparency and security.

Features

  • Decentralized Invoice Creation - Create and manage invoices on-chain
  • Multi-Token Support - Pay using native currency or ERC-20 tokens
  • Immutable Records - Verifiable transaction history and status tracking
  • Treasury Management - Built-in fee management for platform sustainability
  • Privacy Protection - Encrypted invoice data with access control
  • User-Friendly Interface - Intuitive web application with wallet integration

Project Structure

Chainvoice/
├── frontend/ # Web application (UI/UX, wallet integration)
├── contracts/ # Solidity smart contracts (core invoicing logic)
├── docs/ # Documentation and guides
└── README.md # This file

Getting Started

  1. Fork the repository
  2. Clone your fork

git clone https://github.com/YOUR_USERNAME/Chainvoice.git
cd Chainvoice

Frontend Setup

  1. Navigate to frontend directory
    cd frontend

  2. Install dependencies
    npm install

  3. Start development server
    npm run dev

  4. Open application Navigate to http://localhost:5173 in your browser

Smart Contract Testing

Prerequisites: Foundry must be installed

  1. Navigate to contracts directory
    cd contracts

  2. Run test suite
    forge test

  3. Run tests with verbosity (optional)
    forge test -vvv

Deploy to Ethereum Classic

Prerequisites

  • Foundry installed
  • Wallet funded with ETC
  • ETC RPC URL (e.g., Rivet, Ankr, Chainstack)

Deployment Steps

  1. Configure environment variables
    cp contracts/.env.example contracts/.env
    Edit contracts/.env with your actual values

  2. Compile contracts
    cd contracts
    forge build

  3. Load environment variables
    source .env

  4. Deploy to Ethereum Classic
    forge create contracts/src/Chainvoice.sol:Chainvoice --rpc-url $ETC_RPC_URL --private-key $PRIVATE_KEY --broadcast

  5. Configure frontend
    cp frontend/.env.example frontend/.env
    Edit frontend/.env and set:
    VITE_CONTRACT_ADDRESS=your_deployed_contract_address_here

  6. Restart frontend development server
    cd frontend
    npm run dev

Environment Variables

Frontend Configuration (frontend/.env)

#Ethereum Sepolia (11155111)
VITE_CONTRACT_ADDRESS_11155111=0x7bC4C5abb5b1B8355Aa65307C1cFDbe6254505d2
#Ethereum Classic (61) — blank until redeployed, see note below
VITE_CONTRACT_ADDRESS_61=
#Polygon Mainnet (137) — blank until redeployed, see note below
VITE_CONTRACT_ADDRESS_137=
#Project ID
VITE_WALLETCONNECT_PROJECT_ID=Your Project ID can be obtained from https://dashboard.reown.com/ 

⚠️ Ethereum Classic and Polygon are left blank on purpose. Both still run the v1 contract, which stores invoice payloads on-chain as strings and has no public key registry, so it does not match the current ABI. The app treats any non-empty address as supported, so filling these in would send calls those contracts cannot decode. Populate them only after redeploying. ⚠️ Security Note: Never commit .env files to version control. Keep your private keys secure.

Relay configuration

Invoice payloads travel encrypted over a ThruBox relay, configured with:

VITE_RELAY_URL=http://localhost:3000
VITE_RELAY_API_KEY=
VITE_RELAY_TIMEOUT_MS=
  • VITE_RELAY_URL — in development this is the target the Vite dev server proxies /relay to, so the browser stays same-origin. In production, either an absolute https:// URL (which requires CORS on the relay) or a path such as /relay that your host rewrites to it (Vercel rewrites, Netlify redirects, nginx proxy_pass), which avoids CORS entirely.
  • VITE_RELAY_API_KEY — only needed if the relay sets security.api_key. This is not a secret: Vite inlines every VITE_-prefixed variable into the built JavaScript, so any visitor can read it. Treat it as a spam speed-bump, not access control. To keep a relay key private, proxy relay calls server-side and inject it there.
  • VITE_RELAY_TIMEOUT_MS — request timeout, default 15000. Raise it (around 60000) on hosts that suspend idle instances: a cold start can take most of a minute, and sends are deliberately not retried, so a timeout means an undelivered invoice.

Deployed Contracts

Current (hash-based invoice storage)

Stores only keccak256 of the invoice data on-chain and exposes the public key registry. This is the deployment the frontend is configured against.

  • Ethereum Sepolia (11155111) 0x7bC4C5abb5b1B8355Aa65307C1cFDbe6254505d2

v1 (Mainnet Deployment — Jan 1)

Stores the invoice payload on-chain as strings. Superseded, kept for reference.

  • Ethereum Sepolia (11155111) 0x54a542dCDC306eE281b5De4613EcEfe6e6ABc562
  • Ethereum Classic (61) 0xD044A85a5daC307217B9bF313A90E8a60AF7DdCe
  • Polygon Mainnet (137) 0xD044A85a5daC307217B9bF313A90E8a60AF7DdCe

Release: release v1

Community and Support

Join our community for support, updates, and discussions:

Contributing

We welcome contributions! Please read our contributing guidelines and submit pull requests for any improvements.

Before making or updating any smart contract changes, please review the Smart Contract Contribution Guidelines to ensure compliance with testing, design, and review requirements.

Built with ❤️ by Stability Nexus.

(back to top)

Sponsor this project

Contributors

Languages