Transparent Lending Platform
BEEM161: smart contracts class. Transparent on-chain lending and collective decision-making over how capital is used after it is funded.
At a glance
Quick navigation to the key sections on this page.
Contents
Jump to section
Role
I originated the idea, led the roadmap, built the web front end, and shaped the smart-contract mechanics (structure, flows, and governance rules).
Stack: Solidity · Sepolia testnet
Problem & solution
SmartFundX (crowdFundDAO) targets a common trust failure in crowdfunding: once funds are sent, contributors lose transparency and control over how money is spent. We built a Solidity-based escrow + governance mechanism so spending happens only through on-chain proposals that contributors approve.
- Programmatic escrow: funds are locked in-contract, with no direct founder access.
- Spending requests (with proof): withdrawals are initiated as requests describing how funds will be spent; receipts/proof can be attached later as a feature.
- Donor voting: contributors vote on each request before any release; the initial version uses a simple majority threshold (>50%).
- Auditability: Deposit → Propose → Vote → Execute is recorded and verifiable on-chain.
How it works
The system is intentionally simple: contributions are tracked on-chain, spending happens through proposals, and funds are released only after an approval threshold is met.
- Contribute: contributors deposit to the contract; balances are recorded in an internal ledger.
- Propose: the project owner creates a spending request (amount, recipient, description).
- Vote: contributors approve/reject; voting weight reflects contribution size in the initial version.
- Execute: once the threshold is met, the contract releases the funds to the recipient.
Design choices: We used a simple internal ledger (not a tradable token) to keep the first version focused on governance + accounting, and deployed on Sepolia to test real wallet flows without risking real funds.
Demo video
Below is a quick demo walkthrough showing two perspectives: (1) a user creating the contract/request flow, and (2) a user donating and voting. This is a lightweight sample demo, not a full in-depth showcase of every feature.
Results
- Transparent spending flow: every proposal, vote, and execution step is on-chain and reviewable.
- Reduced trust assumptions: contributors don’t need to rely on off-chain promises for fund usage.
- Tested end-to-end: deployed and interacted with on Sepolia to validate the user flow.
Future features & use cases
Future features
- Receipts / proof attachments: allow request creators to attach receipts and evidence for transparency.
- Quorum + designated voters: add quorum rules and “council”/designated voter sets for higher-stakes decisions.
Use cases
- Council tax / fines governance: citizens pay into a council contract; larger budget proposals can only be approved via society voting or quorum-based designated approval.
- University societies: transparent fundraising and spending approvals for events, trips, and equipment.
- Starting a business: raise funds with milestone-based releases tied to approved spending requests.
- Milestone payments: contributors approve each milestone before funds are released, reducing risk for both sides.