Bouachain ( Large Grant Proposal)

Grants Rejected
1

Introduction

Project Name: BouaChain
Name of the organization submitting the proposal: [removed by admin]

Describe your project:
BouaChain is a next-generation BouaChain SDK-based blockchain designed to prioritize interoperability, scalability, security, and developer inclusivity. This grant supports a suite of real-world applications and infrastructure fully integrated with the Sia decentralized storage layer — including validator bootstrap systems, encrypted document vaults, decentralized blog publishing, and an AI assistant for developers.

Who benefits from your project?
Developers, validators, content creators, identity holders, and the broader Web3 community. Each phase of the project promotes active usage of decentralized storage via Sia in a real, functional capacity.

How does the project serve the Foundation’s mission of user-owned data?
Each deliverable places storage ownership and control directly in the hands of users. From document encryption and vault storage to self-hosted blogs and developer-owned model weights, BouaChain dApps showcase the potential for user-owned, censorship-resistant data backed by verifiable file contracts on Sia.

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: $90,000
Funding Structure: 4 milestone-based phases at $22,500 per phase

Phase Budget Breakdown (per milestone):

  • $11,250 – Development & Engineering
  • $4,000 – Frontend/UI/UX
  • $3,500 – DevOps & Sia Infrastructure
  • $2,000 – QA, Community Testing, Hosting
  • $1,750 – Compliance, Reporting, Misc.

Timeline with Objectives and Milestones

Duration: 6 Months

Phase 1 (Month 1–1.5): Infrastructure & Explorer

  • Deploy BouaChain’s validator bootstrap infrastructure
  • Store binaries, snapshots, genesis files on Sia using renterd
  • Deploy explorer frontend traditionally (not on Sia)
  • Store frontend assets and static content redundantly via renterd

Phase 2 (Month 2–3): BEVA Vault

  • Encrypted document storage vault using client-side encryption
  • Upload encrypted data to Sia using renterd
  • Store access logic and metadata on BouaChain
  • Smart contract-based access control

Phase 3 (Month 3.5–4.5): SiaContent

  • Web3 blog publishing platform
  • Posts stored on Sia via renterd, metadata on BouaChain
  • Wallet login, tipping, subscriptions via token or Stripe
  • DAO-based moderation options

Phase 4 (Month 5–6): Developer AI Assistant

  • Lightweight AI assistant for developers
  • Weights, prompts, config files stored on Sia
  • Deployed via Akash or GPU VPS
  • Exposes API/CLI for interaction

Development Details

Is code open-source? Yes
GitHub: https://github.com/Bouachain/
Progress reports submitted monthly? Yes
Designated contact:
Name: Pureheart Moluno
Email: [email protected]

Past work:
https://github.com/pmoluno
https://github.com/Moluno-xiii
[removed by admin]
[removed by admin]

Proof of concept already developed? Yes
Agree to present demo during community calls? Yes
Primary Contact Email: [email protected]

Project Breakdown by Phases

:white_check_mark: Phase 1 – Validator Infrastructure + Explorer

What It Is:
Setup BouaChain’s validator infrastructure using decentralized file distribution for bootstrap files (binaries, genesis files, etc.) and deploy a full-featured blockchain explorer.

How It Works:

  • Use renterd to upload and reference all validator setup assets
  • Explorer frontend hosted traditionally; explorer data stored/referenced on Sia
  • Validators required to pull files from Sia before spinning up nodes

Why This Matters for Sia Tech:

  • Positions Sia as an infrastructure layer for blockchain setup
  • Avoids GitHub/IPFS reliance for bootstrapping
  • Encourages ecosystem-wide validator usage of Sia

Long-Term Vision:

  • Default validator bootstrap hub for IBC chains
  • Explorer stack reusable across Cosmos-based chains

:white_check_mark: Phase 2 – BEVA Vault

What It Is:
Encrypted document vault where files are securely stored on Sia and access rights are controlled via BouaChain smart contracts.

How It Works:

  • Files are encrypted client-side (AES/ECIES)
  • Uploaded to Sia via renterd
  • File metadata + permissions managed on-chain
  • Access requests verified via chain-based auth logic

Why This Matters for Sia Tech:

  • Real-world encrypted use case
  • IPFS cannot support privacy-preserving file uploads
  • Leverages Sia’s secure file contracts for sensitive data

Long-Term Vision:

  • Used in legal, government, identity, or medical apps
  • Modular encryption tool for third-party apps

:white_check_mark: Phase 3 – SiaContent (Web3 Publishing)

What It Is:
Decentralized publishing engine where writers store blog posts on Sia and readers access through a rich interface with token incentives.

How It Works:

  • Post created in Markdown or rich text
  • Post saved to Sia via renterd
  • BouaChain manages metadata and tipping logic
  • Readers access post through frontend viewer

Why This Matters for Sia Tech:

  • Showcases Sia for public content publishing
  • IPFS often used — this shows better persistence + redundancy
  • Daily usage potential via writers + subscribers

Long-Term Vision:

  • Full creator economy
  • DAO-based moderation and tokenized subscriptions

:white_check_mark: Phase 4 – AI Developer Assistant

What It Is:
An AI-powered tool to help onboard developers using BouaChain SDK and Sia Tech APIs. All model assets are hosted on Sia.

How It Works:

  • Fine-tuned LLM stored on Sia (weights, config, prompts)
  • Deployed via Akash or other decentralized compute
  • Devs query via terminal or REST API
  • Logs + inference metadata backed up to Sia

Why This Matters for Sia Tech:

  • Sia becomes a storage registry for AI assets
  • Developer-focused onboarding tool
  • Proof-of-concept for decentralized Hugging Face

Long-Term Vision:

  • Expand into full developer co-pilot
  • Serve as reusable inference blueprint for Web3 teams

Future Grant Proposals

:crystal_ball: BEvoNFT – Dynamic NFTs

  • NFTs that evolve based on off-chain actions
  • Media + metadata stored on Sia
  • Use cases: badges, game items, academic credentials

:crystal_ball: ChainBackup-as-a-Service

  • Validator backup + snapshot service
  • Stores zipped .data, config, genesis files on Sia
  • Helps chains enforce slashing or compliance

:crystal_ball: DID + Verifiable Credentials Vault

  • Self-sovereign identity manager
  • Encrypts and stores credentials on Sia
  • Verifiable on-chain proofs + renterd references

:white_check_mark: Why We Deserve Sia Tech Support

  • We’ve been working on BouaChain since last year
  • Consistently published our journey on X (Twitter)
  • [removed by admin]
  • Grant delivers tools that prove real usage of Sia — across validators, identity, content, and developers

:mega: Social Links

2

Hello, welcome.

I am not sure where to begin on this, however I can see you have done some research on Sia.

  • The grant committee (which is not me) tends to be skeptical of things around tokens or cross-chain stuff, without a good explanation.
  • They would want community rapport before getting a request for 90k… As you are brand new to the community, the response here will be a MVP experiment at a max of 10k USD if you want to be funded.
  • Some of your ideas are mis-guided/mis-informed like IPFS cannot support privacy-preserving file uploads and Leverages Sia’s secure file contracts for sensitive data.

I personally have these criticisms:

  • https://bouachain.com/ does not load (DNS when going to the website linked on the GitHub), and that is just amateur hour to me… (ping: bouachain.com: Name or service not known)
  • I have yet to see a good argument/use-case for onchain-based access control or gating, especially when EVM calldata is recorded transparently and you can effectively see all OOP class state data, so there is zero privacy on anything stored, in most EVM networks, or even other contract VM’s.
  • The only thing that seems reasonable here is storing your blockchains history in Sia by treating it like S3. However that does not need or deserve a grant… you can just… do it? :upside_down_face:
  • Out of all these ideas, the BEVA Vault seems the most reasonable, but it is also going to be another storage drive attempt as its the most obvious thing to build, and I expect Sia to eventually get saturated with these grant ideas. The other things I am not sure make sense right now, as Sia just needs more adoption for them to have value IMO (blog system, ai stuff?).
  • Infrastructure & Explorer does not make any sense to fund b/c, again, you can just do that yourself, you should not need to be subsidized for doing that… and Sia should not be paying for the IT of another blockchain network without a VERY good reason IMO.
  • Why We Deserve Sia Tech Support → Being active on twitter/CT (“crypto”), and building another blockchain project does not entitle you to Sia community funding…

In short, IMO, boil down your ideas to 1 grant request at a max of $10k USD, for a max of 3 months, and try again.

Kudos.

3

Hello @pcfreak30,

First of all, we sincerely appreciate you taking the time to review our grant proposal in such detail and for pointing out the strengths and weaknesses you see in our approach.
We also want to thank you for recognizing that BEVA Vault stands out as a solid use case — that validation is important to us, because it shows we are aligned on certain impactful directions.

We’d like to address the key points you raised, and in doing so, clarify some technical aspects that may not have been fully evident from the initial proposal.

1. Website & Domain Resolution

You are correct that bouachain.com currently does not resolve. This was due to an unfinished DNS update following a server migration.
This is being fixed immediately — our public landing page, developer documentation hub, and project resources will be live before any further funding decisions are made.

2. On-chain Access Control & Privacy

We agree that public blockchains are transparent by default, and raw access keys or sensitive information should never be stored directly on-chain.

Our BEVA Vault design addresses this by:

  • Performing client-side encryption before upload.
  • Storing only hashed or tokenized permission references on-chain — never raw keys.
  • Using public-key-based envelope encryption so only authorized recipients can decrypt the content.
  • Leveraging Sia (via renterd/hostd) purely for immutable storage of encrypted payloads .
  • Keeping the blockchain as an authorization ledger only.

This ensures privacy is preserved, even though the access rules are blockchain-managed.

3. Infrastructure & Explorer Funding Justification

We understand your point that setting up a blockchain explorer or validator bootstrap system can be done without funding.
However, in our model, these components are integral to driving Sia adoption :

  • Validator bootstrap : All BouaChain validators must fetch binaries, genesis files, and snapshots from Sia — eliminating reliance on centralized GitHub, Dropbox, or IPFS.
  • Explorer integration : The explorer will archive historical blockchain data directly into Sia, turning Sia into a queryable long-term ledger of blockchain activity, rather than passive file storage.

This isn’t just “funding another blockchain’s IT” — it’s making Sia a core infrastructure dependency for BouaChain and its users.

4. Interdependency of BEVA Vault, Blockchain, and Explorer

Even though BEVA Vault is a strong standalone idea, it requires :

  • A BouaChain SDK-powered blockchain to manage permissions and audit trails.
  • An explorer to give users visibility into permission grants, file ownership, and vault transactions.

For this reason, developing BEVA Vault in isolation would still mean building substantial blockchain and explorer components — and without those, BEVA Vault’s utility is significantly reduced.

5. On Blog & AI Features

We agree these are long-term roadmap items. They were included to illustrate future potential for driving recurring Sia usage, not as immediate deliverables for this grant cycle.
We can postpone these until after proving adoption through core infrastructure + BEVA Vault.

6. Why Sia Should Care

Our proposal ensures:

  • Continuous Sia interaction by all BouaChain validators.
  • A high-visibility storage use case (BEVA Vault) that is Sia-first and blockchain-agnostic for broader adoption.
  • A real-world demonstration of renterd + hostd for encrypted file storage, not theoretical.

We’re not proposing that Sia subsidize another blockchain’s IT — we’re making Sia an unavoidable part of BouaChain’s operational backbone .

4

Ok, from what I can see your proposing to create an entire blockchain network just for this? I looked and it seems you might be using tendermint as a basis?

Sorry but requesting Sia fund an entire other blockchain that just acts as an onchain account system… that makes zero sense. That MAY make some viable sense if it was just 1 smart contract on ETH as thats realistically all you need, not its own chain, in any form.

Additionally, renterd itself is a centralizing point and there is no way with it right now that you can access any Sia data in a decentralized way (distribution)… so you are wrapping an entire fancy blockchain as a user database around effectively a storage server at a single IP address…

Lastly → Leveraging Sia (via renterd/hostd) purely for immutable storage of encrypted payloads .. Sia is NOT arweave, and it is NOT btc ordinals…

Sia is a marketplace where data stays up for as long as you pay for it. I would read the grant request Small Grant: Chi as they fell into the same fallacy.

Finally, this entire idea regardless of my opinion, almost certainly needs to be shrunk down into a MVP at a max of 10k, Global Grants Program | Sia.

Kudos.

5

Hi @Bouachain, thanks for your proposal to the Sia Foundation.

Unfortunately one type of project that we explicitly don’t fund is one where Sia is integrated in some way into or on top of another blockchain. That presents a whole host of potential issues regarding future development and compatibility that we’d rather not invite.

You can see the list of projects that we don’t fund here. Thanks and best of luck.

6

Also a note for future grantee’s. At least from my perspective, writing your entire grant proposal with AI… just feels bad. I can’t trust someone’s code if they won’t even write a grant proposal themselves.

Note: I’m not on the board, just wanted to let people know my perspective.

7

I appreciate your perspective
I don’t see AI as a “forbidden tool” in getting tasks done, except the Foundation is against the use of the technology and has explicitly stated this.
Technology advances rapidly mostly because we keep finding fast and easier ways to get things done (which is what really matters).
Devs use AI to fix bugs and loads of amazing products/tools have been built with it

8

True, do we want it or not, AI has become part of our life. The point brought up by Covalent is that there needs to be a line between using and abusing the AI.

Ultimately, this can be described by the anecdotic situation where Alice needs to write a 50-page report and asks the AI to do it based on 5 bullet points. Then Bob who needs to read that report asks the AI to convert it to 5 bullet points, because he doesn’t have enough time to read a 50-page report.

You are welcome to use the AI but please, don’t abuse it.

9

(the following is my opinion, the only responder here so far on the grant committee is mike76)

… as an AI-enhanced user (I don’t hide that I leverage it…), AI is a very powerful tool, but not magic. The pro-AI arguments are right, and no one I think is against that (the core team themselves have a copilot AI review bot on the SiaFoundation GitHub org)…

What I can say is excessive checkmarks/bulletpoints, emojis, and regurgitation’s of questions (this has happened in other grant requests), are huge giveaways and there is a line between helping you in a governance post for communication, and doing it for you to the point you don’t read its output.

If any grant request is not edited/curated as a governance post before publishing after throwing it in AI and leaving in the emoji’s etc, I would call that an un-neededly flashy (and possibly lazy/spammy) post that hasn’t had any sort of content review, and I can generally spot AI content in seconds b/c there is only a handful of personalities and their training data leads them to these patterns. Both cloud and FOSS models do this.

So @Covalent criticism is warranted I think, but it should not be overblown and turned into a strawman argument.

Every grant request needs the grantee to spent their time on it and take it seriously, so that everyone else will as well.