dApp Release
Table of Contents
Introduction • Features • Examples • Contributing • Disclaimer • License • Contact
Developed By: Ryan Hatch
© 2026 Ryan Hatch
All Rights Reserved.
This software is proprietary and owned by Ryan Hatch. Unauthorized use, modification, or distribution is prohibited.
Zencrypt is currently undergoing a repo and branch organization pass, including documentation cleanup, branch pruning, and version tag/release standardization.
Expect some temporary inconsistencies in branch names, folder layout, and docs while this work is in progress.
Stable entry points
- Code:
main - Versions:
Releases / Tags
Project Purpose and Evolution •
Architecture & Technology Stack •
Features and Functionalities
Documentation, Flowcharts, and Future Enhancements •
Deployment and Operational Considerations •
Summary
I started this project with a CLI script that used core encryption functions and was designed with the purpose of parsing sensitive information offline to be encrypted or decrypted.
This project was intended to merge the final CLI program into a full fledged dApp/webapp that has all of the same functions, with a complete cipher handling everything from hashing, AES, RSA, and fully implemented PGP functionality.
With Zencrypt dApp, I took the next step I had been planning for a while: moving Zencrypt from web2 to web3. This version replaces the traditional email and password login system with Solana wallet-based authentication, meaning users prove their identity by signing a cryptographic challenge with their own wallet instead of storing a password anywhere on the server. No email, no password, no shared secret — just a public key and a signature.
I restructured the backend from a monolithic webapp.py into a clean set of Flask Blueprints — auth, gate, crypto, and billing — so that each concern is fully separated and independently testable. The wallet authentication flow uses Ed25519 signature verification via PyNaCl, with nonce-based anti-replay protection baked in from the start. On top of that, I integrated Solana Pay so that users can purchase access plans directly with SOL, keeping the entire user journey on-chain.
I learned that moving to web3 is not just a technology swap — it forces you to rethink what identity even means in your system. When a wallet address becomes the primary key for a user record, every assumption about password resets, email lookups, and session expiry has to be revisited. Keeping the encryption core unchanged while swapping out the entire auth layer was a good test of how well the modular design from the previous version had actually held up.
This dApp represents the transition point I had been writing about since
Version 6-Alpha. Zencrypt went from a hash generator, to a full cipher suite, to a web platform, and now to a decentralized application. Each step was a deliberate build on the one before it, and this step in particular reinforced whykeeping it modularmatters — the encryption engine did not have to change at all, only the door in front of it did.
-
Core Functionality:
I started Zencrypt as a simple command-line tool focused primarily on SHA-256 hash generation and verification, then steadily expanded its capabilities to include file encryption, RSA-based PGP features, and a full web interface. Version 6-Alpha marked the completion of the web2 platform — a modular, scalable Flask app with JWT authentication, SQLAlchemy ORM, and a React front end. Zencrypt dApp is my first step into web3: the encryption and hashing features remain unchanged, but the entire authentication layer has been replaced with Solana wallet-based login. -
Evolutionary Path:
The progression from CLI to webapp to dApp followed a consistent philosophy: add capability without breaking what already works. In alpha2, email and password fields on the User model were made nullable and awallet_addresscolumn was added to support wallet-only accounts, all while keeping backward compatibility for any existing email-based users. I made sure the cryptographic core — Fernet, AES, PGP — stayed exactly as it was, because the goal was not to rebuild Zencrypt but to give it a new front door.
-
Backend Architecture: I refactored the backend from a single
webapp.pyfile into a set of Flask Blueprints, each with a single responsibility:authhandles wallet challenge and verification,gateprotects the encryption routes,cryptoexposes the hashing and cipher API, andbillingmanages Solana Pay subscriptions. This restructuring made each module independently testable and kept the application factory pattern clean. SQLAlchemy ORM and Flask-Migrate are still used for modeling users, hashes, and encryption keys, and the database remains SQLite in development with a straightforward path to swap it for another backend if needed. -
Security Implementation: The authentication model in alpha2 is fundamentally different from the previous version, 'v6-Alpha'. Instead of storing a password hash and issuing a JWT on credential match, the server now issues a one-time cryptographic nonce, waits for the client to return that nonce signed by their Solana wallet, and verifies the Ed25519 signature server-side using
PyNaCl'sVerifyKey. No private key ever leaves the user's wallet. On successful verification, the user record is upserted by wallet address and a short-lived JWT is issued for the session. Nonces are stored in-memory with a ten-minute expiry and destroyed on use, preventing replay attacks. -
Cryptographic Foundation: The existing encryption stack — Fernet for text, AES in CFB mode for files, RSA PGP for asymmetric operations — is carried forward unchanged from version 6-Alpha. On the web3 side, Ed25519 is used exclusively for wallet identity verification via
PyNaCl==1.5.0, and Solana base58 address encoding is handled bybase58==2.1.1. Keeping these two cryptographic layers cleanly separated — one for identity, one for data — helped me understand how a system can adopt blockchain primitives without having to rewrite its core security logic. -
Frontend Integration: The wallet connection UI uses the Phantom browser extension's
window.solanaAPI. When a user clicks Connect, the frontend callswindow.solana.connect()to get the public key, fetches a nonce fromGET /auth/nonce, asks the wallet to sign it withsignMessage, and posts the result toPOST /auth/verify. Solflare and Ledger Live are also supported through the same flow. The Navbar component was updated to display a truncated wallet address in place of a username once the user is authenticated via wallet. -
Solana Pay Integration: The
billingBlueprint exposes endpoints for creating and confirming Solana Pay invoices. Subscription plans are priced in lamports — personal, pro, and team tiers — and the payment flow uses a reference key system that is designed to be verified against on-chain transaction data in a production setting. AWalletManagerclass instatic/wallet.jswraps the Phantom adapter and handles both the connection and the payment creation flows.
-
Wallet Authentication:
- Supports Phantom, Solflare, and Ledger Live wallets.
- Nonce-based Ed25519 challenge/response — no password stored anywhere.
- Wallet address is the primary user identifier; email and password are optional fallbacks.
- JWT issued on successful verification; session stores wallet address.
-
Solana Pay Subscriptions:
- Personal, Pro, and Team plans denominated in lamports.
- Invoice creation and confirmation endpoints in the
billingBlueprint. WalletManagerJS class handles wallet connection and payment creation client-side.
-
Hash Generation:
- Uses SHA256 with an optional salt.
- Hashes can be stored in the database for parsing or later verification.
-
Text Encryption/Decryption:
- Implements encryption of text using Fernet.
- Both encryption and decryption are supported.
-
File Encryption/Decryption:
- Encrypts files using AES with a random salt and initialization vector, and decrypts them using the same key.
- Supports file
uploads,processing, anddownloadoperations, depending on the user's input.
-
PGP Encryption:
- Generates RSA keys for the user and encrypts messages using the recipient's public key.
- Allows users to encrypt messages using a recipient's public key and decrypt messages using their own private key.
- Features for exporting and importing public keys are optional but provided to enhance the security of key management.
-
User Authentication & Session Management:
- Primary: wallet address + Ed25519 signature via Solana wallet (Phantom / Solflare / Ledger).
- Fallback: email and password for backward compatibility with existing accounts.
- JWT-based session management with short-lived tokens.
- User-specific encryption keys are generated and stored securely to ensure data privacy.
-
Database Operations:
- Models are defined for users (with optional wallet address), encryption keys, hashing or encryption event logs, and PGP keys.
- SQLAlchemy ORM is used for database interactions, making it easy to manage and query data.
- Database migrations are handled using Flask-Migrate and Alembic, ensuring that the database schema can be updated seamlessly.
- The modular code structure allows for easy switching to other database systems like MongoDB or MySQL.
Extensive Documentation: The dApp ships with a full set of wallet authentication documents covering quick reference and a migration guide for existing email-based users. I made sure these documents explain both the how and the why behind the design choices, just like the whitepapers in the earlier versions, so that anyone reading the codebase can understand the reasoning without having to reverse-engineer the implementation.
Whitepapers: The existing whitepapers from version 6-Alpha are carried forward intact because the underlying encryption design has not changed. The new wallet auth documents — WALLET_AUTH_SETUP.md, WALLET_AUTH_QUICK_REFERENCE.md, WALLET_AUTH_IMPLEMENTATION_SUMMARY.md, MIGRATION_GUIDE.md, and DELIVERY_SUMMARY.md — complement those whitepapers by documenting the web3 layer specifically.
Enhancement Plans: The immediate next steps are to replace the in-memory nonce store with a proper database-backed or Redis-backed store for multi-instance deployments, add real on-chain RPC verification to the Solana Pay confirmation endpoint, and expand wallet support beyond Phantom and Solflare. Longer term, the plan is to explore moving encryption key ownership fully on-chain so that users hold their keys in their wallet rather than in the server database.
Professional Skills and ePortfolio: Building the web3 layer on top of the existing web2 foundation taught me that a well-structured modular codebase is one of the most valuable things you can invest in early. The fact that the encryption engine required zero changes when the authentication layer was completely replaced is a direct result of the design choices made in version 6 Alpha.
Deployment Configuration: Zencrypt alpha2 is configured for cloud deployment using Gunicorn as the web server, with the same render.yaml setup from version 6-Alpha. The two new runtime dependencies — PyNaCl==1.5.0 and base58==2.1.1 — are added to requirements.txt and require no special build steps. Environment variables for JWT_SECRET, MERCHANT_WALLET, and RPC_URL must be set before deployment; these are documented in the .env template included in the repository.
Testing and Quality Assurance: Alpha2 includes a dedicated test suite in test_wallet_auth.py that covers nonce generation, Ed25519 key pair creation, server-side signature verification, and session persistence. These tests run without a browser or a real wallet, making them suitable for CI. The existing test_webapp.py unit tests for database operations and encryption routes continue to pass unchanged. Security scanning with Snyk and OWASP ZAP from version 6-Alpha is carried forward as part of the QA process.
Looking back at Zencrypt's path from a command-line hash tool to a decentralized application, the most important thing I have taken away is that each version had to be built well enough to be a foundation for the next one. Version 6 gave me a solid modular Flask platform with clean separation between the encryption logic, the database models, and the web routes. Alpha2 proved that foundation by swapping the entire authentication layer — from email and password to cryptographic wallet signatures — without touching the encryption engine at all.
The move to web3 is more than a technology choice. It changes what a user account means, what login means, and what trust means. In Zencrypt alpha2, a user is a Solana public key, login is a signature, and trust is cryptographic proof rather than a shared secret. I made sure every part of this version reflected a genuine understanding of those differences, from the nonce-based anti-replay design in the auth flow to the lamport-denominated subscription model in the billing layer. In the end, Zencrypt is still doing the same thing it always did — keeping data secure — but now the door to the system is secured by the same kind of cryptography that secures the data inside it.
wallet_address field to User model; made email and password nullable./auth/nonce and /auth/verify endpoints. Zencrypt is a decentralized application (dApp) that allows users to hash, encrypt, and decrypt text and files — authenticated entirely through a Solana wallet, with no password required. The dApp runs on the Flask framework and is hosted at Here.
The dApp is built for simplicity and security, combining the encryption suite from version 6-Alpha with Solana wallet-based authentication. Users connect their Phantom, Solflare, or Ledger wallet, sign a one-time cryptographic nonce, and are issued a session token — no email, no password, no shared secret stored on the server. Subscription access is handled through Solana Pay, keeping the entire user journey on-chain.
Zencrypt is a Flask-based decentralized application focused on encryption, hashing, and secure file operations with Solana wallet authentication. The project completes the planned migration from the web2 platform in version 6-Alpha to a web3 dApp, while maintaining the same strong cryptographic foundations.
- Solana wallet authentication — Phantom, Solflare, and Ledger Live
- Ed25519 nonce-based challenge/response login (no password stored)
- Solana Pay subscription billing (personal, pro, and team plans)
- SHA256 hashing with optional salt values
- Fernet symmetric encryption for text
- AES-based file encryption with password protection
- PGP asymmetric encryption with key management
- JWT session management after wallet verification
- Secure key storage in dedicated directory
- SQLite database with encrypted storage
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
This script is provided for educational and demonstration purposes only.
Use it responsibly and please adhere to all applicable laws and regulations.
I am absolutely immune from any responsibility in regards to any damages or loss of data caused by the
use, abuse, or misuse of this software.
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
<=>
This software is the property of the copyright holder and is protected by copyright laws. All rights are reserved. The copyright holder grants no implied or express license for the use, copying, modification, distribution, or reproduction of this software, in whole or in part, without the prior written permission of the copyright holder.
Any unauthorized use, copying, modification, distribution, or reproduction of this software, in whole or in part, is strictly prohibited and constitutes a violation of copyright law. Such unauthorized use may result in civil and/or criminal penalties, including but not limited to legal action and monetary damages.
To obtain permission for any use, copying, modification, distribution, or reproduction of this software, please contact the copyright holder at the following address: ryanshatch@gmail.com
By using this software, you acknowledge that you have read and understood the terms of this license and agree to comply with all applicable copyright laws.
Failure to abide by the terms of this license may subject you to legal consequences.
For any inquiries or suggestions, please contact me at ryanshatch@gmail.com.