Small Grant Proposal: Pinet| Decentralized Energy Trading Platform

Grants Proposed
1

Introduction

Project Name:
Pinet: Decentralized Energy Trading Platform

Name of the organization or individual submitting the proposal:
Alireza Hajimohammadi (Founder, Pinet Project)

Describe your project.

Pinet is a decentralized peer-to-peer energy trading platform designed to enable individuals and small-scale renewable energy producers to securely trade surplus energy with consumers. The platform focuses on user ownership, privacy, and verifiability of sensitive energy transaction data.

Energy settlements are handled on-chain using smart contracts deployed on the Polygon network, while sensitive off-chain energy transaction artifacts are stored as encrypted objects using Sia’s decentralized object storage.

The MVP (Minimum Viable Product) will demonstrate:

  • On-chain energy trade settlement using the PNTE token on Polygon
  • Generation of off-chain energy transaction artifacts (e.g. trade receipts, metering summaries, aggregated kWh proofs)
  • Client-side encryption and decentralized storage of these artifacts using Sia (via renterd on the Zen testnet)
  • A basic web dApp allowing users to initiate, track, and verify energy trades

Advanced features such as staking, governance, and scalability optimizations are intentionally out of scope for this grant and planned for later phases.

How does the projected outcome serve the Foundation’s mission of user‑owned data?

This project directly aligns with Sia’s mission of user-owned data by ensuring that sensitive energy transaction artifacts are never stored in plaintext, never stored on centralized infrastructure, and never stored on-chain.

Key principles include:

  • Client-side encryption: All energy transaction artifacts are encrypted before upload.
  • User-centric ownership: Encryption keys are held by users, not by the platform.
  • Decentralized object storage: Sia is used strictly as encrypted object storage; no application data is stored on the Sia chain database itself.
  • Verifiable references: Only hashes and storage references are linked to on-chain settlements, enabling auditability without exposing raw data.

This architecture allows users to retain full control over their energy data while still benefiting from decentralized settlement and verification.

Project Architecture (High-Level)

  • Frontend / dApp:
    PHP-based web interface for initiating and viewing energy trades.
    The web dApp is a non-custodial MVP interface; no user funds, private keys, or decrypted data are ever held by the application.
  • Blockchain Layer:
    Polygon (Amoy testnet for MVP)
    • PNTE token contract
    • Energy trade settlement smart contract
  • Storage Layer:
    Sia decentralized object storage
    • renterd
    • Zen testnet (no paid storage required for MVP)
  • Data Flow:
    1. Energy trade is settled on-chain on Polygon
    2. Off-chain energy transaction artifact is generated
    3. Artifact is encrypted client-side
    4. Encrypted object is uploaded to Sia via renterd
    5. Hash and Sia object reference are associated with the on-chain transaction

No raw energy data, private keys, or user balances are stored on-chain or accessible to the server.

Security & Privacy Best Practices

  • Client-side encryption before upload to Sia
  • User-held encryption keys (server cannot decrypt data)
  • Server acts only as a coordination and relay layer
  • No storage of private keys or sensitive data on backend
  • Clear separation between:
    • Settlement logic (Polygon smart contracts)
    • Data availability and evidence storage (Sia)
  • Minimal trust assumptions for infrastructure components

This design is compatible with future migration toward fully client-side data management as Sia tooling (e.g. indexd) matures.
The MVP does not depend on indexd; future iterations may optionally adopt it once publicly released.

Compliance

Are you a resident of any jurisdiction on that list?
No

Will your payment bank account be located in any jurisdiction on that list?
No

Grant Specifics

Amount Requested:
$2,500 USD

Category Breakdown:

Category Amount (USD) Description
Lead Developer / Architect $1,500 20 hrs/week × 4 weeks @ $25/hr. Development of smart contracts and integration with Sia storage.
Frontend Development & UI Design $1,000 Contracted support for basic web interface and user experience.

Total Requested: $2,500

All Sia storage will use the Zen testnet for MVP development, requiring no paid storage budget.

Goals and Timeline

Goals:

  • Deliver a functional MVP demonstrating decentralized energy trade settlement with encrypted off-chain evidence storage
  • Integrate encrypted off-chain artifact storage using Sia
  • Open-source all code with clear documentation

Timeline (3 months)

Month Milestone Deliverables
1 Setup & architecture Repositories initialized, smart contract scaffolding
2 Core functionality Energy settlement contracts, Sia renterd integration
3 MVP completion Web interface, end-to-end demo, documentation

Potential Risks

  • Integration complexity between on-chain settlement and off-chain storage
    Mitigation: Modular architecture and early testing
  • User adoption risk for early MVP
    Mitigation: Focus on simplicity and clear documentation

Development Information

Will all of your project’s code be open-source?
Yes, all code will be open-sourced under the MIT License.

Link where code will be accessible for review:

GitHub Repository:

Do you agree to submit monthly progress reports?
Yes

Implementation References (MVP)

These references are provided to demonstrate existing implementation and are not production deployments.

Contact Info

Email: [email protected]

Other Contact Methods:

  • Telegram: @pinet_pnte
2

Hi, and welcome to the community

Are you implying you will be building your own blockchain? (also referencing the PNTE tokens tokens)

You can use the Zen testnet for free. There’s no need to cover storage costs. Faucet
I suggest updating this in your proposal.

Lastly. How do you intend to implement the Sia storage?

Data isn’t stored on the Sia blockchain itself, only the contract data is.

1 Like
3

1.Are you implying you will be building your own blockchain? (also referencing the PNTE tokens tokens.
“We are not building our own blockchain. PNTE is an token used for energy transactions and settlement within the Pinet platform.”
2.Sia Storage & Infrastructure Costs $500 Cloud VM for testing, Sia storage costs (~2 TB) for energy transaction data.
“We will use the Sia Zen testnet for MVP development, which is free. There is no need to budget for Sia storage costs at this stage.”
3.stored in a decentralized manner on the Sia blockchain.
“Energy transaction data and proofs are stored in a decentralized manner using Sia contracts. The actual data is not on the Sia blockchain itself; only the contract metadata and references are stored. User data is encrypted and uploaded to Sia hosts, ensuring privacy and decentralization, while smart contracts on handle settlement.”

4

Hello, I just want to make something clear since the style of your responses was bizarre and unclear to me.

Sia uses smart contracts without a VM and they are unlike ETH or any other smart contract chain. You will generally not have an engineering reason to put data on the chain database itself, and the database is intentionally minimalist compared to peer chains.

From a web2 POV, Sia is effectively object/s3 storage. And the upcoming indexd will make data encrypted by each user as the owner of the data effectively.

Given this, I am just trying to make sure you understand how Sia works. Lastly, it would be a good idea for you to give a technical plan on how you want to integrate Sia overall rather then just what you want to integrate it for.

Kudos.

1 Like
5

Integration Clarification

First, I would like to apologize for the oversight in my previous responses regarding the PNTE token network. PNTE is used for energy transactions and settlement on the POL network, not on a separate blockchain.

Regarding Sia integration, we understand that Sia is a decentralized object storage system, and that smart contracts in Sia manage contract metadata rather than storing raw data. For our MVP, we plan to integrate our Energy trade smart contract (0xB3D0a1186d5E560B4886E31F0040fC88B88cf3f0) and PNTE token contract (0x00558E155f34264BF8C39151143e5760CcbCFD94) (both on polygon amoy testnet ) with Sia by:

  1. Encrypting energy transaction proofs and uploading them to the Sia Zen testnet for decentralized storage.
  2. Storing only contract references and hashes on the Sia network, allowing verification and auditing without exposing raw data.
  3. Using our PHP dApp (https://pinetworkinton.free.nf/energy.php) and a demo video (https://youtu.be/Px2K72O8RC4) to demonstrate how energy transactions are recorded, verified, and :
    Will link to the Sia contracts.

This approach ensures data privacy, aligns with Sia’s architecture, and allows us to integrate our token-based settlement system on POL without storing actual energy data on-chain.

6

Storing only contract references and hashes on the Sia network, allowing verification and auditing without exposing raw data.

  • Can you give more info on this please? Are you just planning on storing JSON blobs recording onchain data into Sia?
  • Who do you intend to have ownership of the data uploaded. If it is the user it would mean your server could not see the data. If you are expecting to act as a relay it is more like traditional s3 via an API.
  • Are you expecting to distribute the data at all/be viewable by others or treat as archival storage?

Kudos.

7

We are not planning to store arbitrary onchain JSON blobs in Sia. The intent is not to mirror blockchain state, but to store off-chain energy transaction artifacts that are impractical or undesirable to keeep on-chain.

What is stored in Sia

  • Encrypted energy transaction artifacts (e.g. trade receipts, metering summaries, or aggregated kWh proofs generated off-chain)
  • These artifacts are generated after onchain settlement occurs
  • Each artifact is content-addressed, and we retain only:
    • a hash / identifier
    • a reference pointer (sia path)

What is NOT stored

  • Raw blockchain state
  • Smart contract logic
  • User balancces or private keys

Ownership model

  • Data ownership is user-centric
  • Artifacts are encrypted client-side before upload
  • The encryption key is held by the user
  • Our server may act as a transport/relay during upload, but cannot read or decrypt the data
  • This is closer to user-owned encrypted object storage than traditional S3

Server role

  • The server:
    • coordinates uploads
    • associates Sia object references with onchain transaction IDs
    • never requires plaintext access to user data
  • Long-term, this can move fully client-side once indexd and tooling mature

Visibility & distribution

  • By default, data is treated as private archival storage
  • Selective disclosure is possible:
    • users may share decryption keys with auditors, regulators, or counterparties
    • enabling verification without public exposure
  • We are not building a public CDN or content distribution layer

Why Sia fits

  • Energy transaction data is sensitive and regulated
  • Sia’s object-storage model + encryption aligns well with:
    • private-by-default data
    • verifiable references
    • long-term auditability

In short, Sia is used as a user-owned, encrypted evidence layer that complements onchain settlement, rather than duplicating it.
Sorry for the long answer.

8

Long-term, this can move fully client-side once indexd and tooling mature This is what I was trying to grok, to understand if you knew the implications of indexd.

This is closer to user-owned encrypted object storage than traditional S3 I would argue semantics since you can still encrypt before upload on s3 and get a similar result, but :man_shrugging: .

High level I was trying to figure out if you were expecting to use renterd or indexd or fully understood what the technical requirements are.

You may need to wait until indexd is released to do this grant though, but thanks for clarifying to the community what your trying to store.

Kudos.

1 Like
9

Thanks for the clarification and the thoughtful feedback , much appreciated.

You’re right that our longer-term direction aligns more cleanly with indexd for a fully client-side, user-owned model. For now, this helps us better scope the MVP and roadmap.

Do you happen to have any rough expectations or timelin for when indexd is expected to be publicly usable?

Thanks again.

10

Hello @pinetworkinton - Happy New Year and thank you for your proposal. I see some community members have already provided feedback on the proposal (thanks @CtrlAltDefeat @pcfreak30!).

In addition to incorporating their feedback, please also review our Grants Development Guide and note we require inclusion of your project architecture and information on your security best practices in your proposal. Also considering you’re new to the community, is there previous work on GitHub you can share?

We hope to have more information on indexd’s release soon, but in the meanwhile I will consider this proposal under construction and not ready for the Committee meeting on January 20th. Please tag me when you’re ready to have it reviewed again.

1 Like
11

Thanks for the review and guidance.
I’ve updated the proposal to include a clear project architecture, detailed security and privacy best practices, and links to prior implementation (GitHub, contracts, and MVP dApp).
The proposal is now ready for review.
@mecsbecs

1 Like