decentralized-novel-platform

About the Project

Inspiration

Traditional online novel platforms usually rely on a centralized server to store content, manage access permissions, process payments, and distribute revenue. This means authors and readers must trust the platform’s rules, data availability, and revenue settlement process. We were inspired to explore whether blockchain and decentralized storage could create a more transparent publishing model in which authors retain greater control over their works, readers can verify their purchases, and payments are transferred directly according to smart-contract rules.

How We Built It

We built a decentralized novel reading and publishing platform without a traditional centralized backend. Solidity smart contracts serve as the trusted state layer: BookRegistry manages novels and chapters, ChapterAccess handles chapter purchases and access permissions, and CommentIndex records paragraph-level comment indexes. The contracts were developed and tested using Hardhat, TypeScript, and OpenZeppelin.

Novel chapter content is encrypted locally with AES before being uploaded to IPFS. Only the content identifier and necessary metadata are recorded on-chain, reducing blockchain storage costs while keeping the content decentralized. After purchasing a chapter, the reader obtains the required access information and decrypts the content locally in the browser.

The frontend was developed with React, TypeScript, Vite, TailwindCSS, wagmi, viem, and RainbowKit. It connects directly to the user’s wallet, smart contracts, and IPFS instead of communicating with a centralized application server. The basic author revenue model can be expressed as:

$$ R_{\text{author}} = \sum_{i=1}^{n} P_i \times N_i $$

where (P_i) is the price of chapter (i), (N_i) is the number of successful purchases, and (R_{\text{author}}) is the author’s total chapter revenue before network fees.

Challenges We Faced

One of the greatest challenges was balancing decentralization, privacy, usability, and cost. Storing complete novel chapters directly on-chain would be prohibitively expensive, while storing plaintext content on IPFS would expose paid chapters to anyone who obtained the CID. We therefore designed a hybrid solution that combines local AES encryption, IPFS content storage, and blockchain-based metadata and access control.

Another challenge was coordinating asynchronous operations across multiple systems. Publishing or purchasing a chapter may involve wallet authorization, blockchain transaction confirmation, IPFS communication, contract-event updates, and local encryption or decryption. We needed to provide clear loading, success, and failure states so users could understand what was happening during each step.

We also had to carefully handle blockchain-specific issues such as wallet connection, contract authorization, transaction failures, gas costs, address validation, access-state synchronization, and changes to the active wallet or network. Paragraph-level comments introduced an additional indexing challenge because the comment content is stored on IPFS while its relationship to a specific paragraph must remain verifiable on-chain.

What We Learned

Through this project, we learned that building a decentralized application is not simply a matter of replacing a database with a blockchain. A practical DApp requires each type of data to be placed in the most appropriate layer: smart contracts for ownership, payment, and verifiable state; IPFS for distributed content storage; and the client for encryption, decryption, wallet interaction, and user experience.

We also gained practical experience with Solidity contract design, Hardhat testing and deployment, ERC-20-style payment flows, React-based Web3 development, wallet integration, IPFS content management, cryptographic hashing, and client-side encryption. Most importantly, we learned to evaluate decentralization as an architectural trade-off rather than an end in itself. Blockchain improves transparency and verifiability, but it also introduces transaction latency, network fees, key-management risks, and additional usability challenges.

The current project is an educational and research prototype. Before production use, it would require a formal smart-contract security audit, a stronger and more carefully designed key-distribution mechanism, improved failure recovery, and comprehensive testing under real-world network conditions.

Built With

• bitcoin
• coin