presentation about a blockchain
Term Project CIS 5730- Blockchain Application
Project Guideline
Part ii–Presentation Along with the project you will present what you did to the class in a short presentation. If you want, you can demonstrate the project, or just present an overview of what you did. Presentations should be about 15-20 minutes. Part of your project grade will include the effectiveness of the presentation.
Please find your topic for your project and do around 10 slides for it
(1) what products/platform/blockchain languages you will work on
(2) How this products/Dapp works for ? who is your DApp users
(3) Dataset you need to develop DApp
(4) how your hands-on lab design –at least 4 tasks
Purpose Free Solution
Smart contract development & deployment (test) Remix, Hardhat, Truffle
Connecting to blockchain MetaMask, Infura
Frontend hosting Fleek, Replit, 4EVERLAND
Full-stack free prototyping Replit Blockchain Builder
My Thoughts:
Project Brief: Secure-Trade
A Decentralized Multi-Sig Escrow System
1. Executive Summary
Secure-Trade is a full-stack Decentralized Application (DApp) designed to eliminate fraud in high-value transactions, such as luxury fashion resale and real estate. The system replaces traditional, expensive escrow services with a 2-out-of-3 Multi-Signature Smart Contract. Funds are only released when a combination of the Buyer, Seller, or a neutral Arbiter (Legal Node) provides digital signatures.
2. Technology Stack
To ensure the project is industry-standard the following tools will be used:
· Smart Contract Language: Solidity ^0.8.0 (targeting the Ethereum Virtual Machine).
· Blockchain Libraries: Ethers.js (to bridge the frontend and the blockchain).
· Development Environment: Remix IDE for rapid testing and Hardhat for deployment/debugging.
· Wallet Integration: MetaMask (for user authentication and transaction signing).
· Hosting: Fleek or 4EVERLAND (to host the frontend on IPFS).
3. User Personas & Logic
The DApp functions as a “Trustless Vault” with three key roles:
1. The Buyer: Deposits the purchase price into the contract.
2. The Seller: Receives funds only after verification.
3. The Arbiter (The “Third Key”): A verified expert (Lawyer or Authenticator) who confirms the “Real World” condition (e.g., house title signed or luxury bag verified) to trigger the release or refund.
4. Dataset Strategy
The project will be grounded in real-world data to simulate a live environment:
· Asset Data: Kaggle “Real Estate Property Transactions” (Florida/Arizona). This provides realistic property IDs, prices, and locations.
· Transaction Logic: Modeled after Gnosis Safe multi-sig logs and Propy on-chain deed transactions.
—
5. Hands-On Lab Design (The Demo)
The project will be demonstrated through 4 specific technical tasks:
· Task 1: Deployment: Deploying the contract and initializing the three wallet addresses.
· Task 2: The Lock-In: The Buyer account sends Test ETH to the contract.
· Task 3: Legal/Expert Verification: The Arbiter account reviews the asset metadata and “approves” the transaction on-chain.
· Task 4: Automated Settlement: Executing the transfer once the 2-signature threshold is met and verifying the transaction on a block explorer (Etherscan).
Presentation Slides
I WOULD LIKE TO DEMO BOTH THE REAL ESTATE AND LUXURY SIDE.
To position Secure-Trade as a universal solution for “High-Value Trust.”
Presentation Outline: Secure-Trade
Slide 1: Title & Vision
· Project Name: Secure-Trade
· Tagline: A Universal Multi-Signature Protocol for High-Value Trust.
· Presented by: Kayla Beasley
· Core Concept: Bridging the “Trust Gap” in Luxury Resale and Real Estate through 2-out-of-3 Arbiter Logic.
Slide 2: The Problem (Industry Fragmentation)
· Luxury: Counterfeit “Super-Fakes” and lack of provenance.
· Real Estate: High wire-fraud risks and manual, 30-day escrow delays.
· Commonality: Both rely on expensive, fallible human middlemen.
Slide 3: (1) Technology Stack
· Languages: Solidity ^0.8.0 (Smart Contracts) & JavaScript (Frontend).
· Libraries: Ethers.js (Blockchain Bridge).
· Tools: Remix IDE, Hardhat, MetaMask, and Infura.
· Deployment: IPFS hosting via Fleek/4EVERLAND for a decentralized UI.
Slide 4: (2) How Secure-Trade Works
· The “Digital Vault”: Funds are locked in a contract, not a bank.
· The 2-out-of-3 Rule: Release requires 2 signatures.
o Scenario A: Buyer + Seller (Smooth transaction).
o Scenario B: Buyer + Arbiter (Refund on a fake/bad title).
o Scenario C: Seller + Arbiter (Payout when a buyer is unresponsive).
Slide 5: User Personas (Dual Industry)
· The Buyer: Luxury collector or Homebuyer (Florida/Arizona).
· The Seller: Luxury brand/reseller or Property Owner.
· The Arbiter:
o Fashion: Professional Authenticator.
o Legal: Real Estate Attorney / Title Agent.
Slide 6: (3) Dataset Strategy
· Primary Source: Kaggle Real Estate Dataset (Transaction IDs, Locations, Sale Prices).
· Secondary Source: Synthetic Luxury Metadata (Serial numbers, Brand IDs).
· On-Chain Reference: Gnosis Safe and Propy transaction logs to model security patterns.
Slide 7: (4) Hands-on Lab: Task 1 & 2
· Task 1 (Deployment): Deploy the SecureTrade.sol contract and define the Arbiter (Lawyer/Authenticator) address.
· Task 2 (Deposit): The Buyer locks 0.1 Test ETH.
o Visual: Show the “Contract Balance” increasing while the funds are “Pending.”
Slide 8: (4) Hands-on Lab: Task 3 & 4
· Task 3 (Verification): The Arbiter reviews the Kaggle Property ID or Luxury Certificate and signs the “Approved” function.
· Task 4 (Settlement): The payout executes.
o Visual: Screenshot of the successful balance transfer on Etherscan.
Slide 9: Related Work & Scholarly Context
· Ricardian Logic: Linking legal intent to code (Grigg, 2004).
· Industry Standards: Following the Aura Blockchain Consortium (Fashion) and Propy (Real Estate) models.
· Recent Research: Title automation and counterfeit prevention (Yang et al., 2025).
Slide 10: Conclusion & Roadmap
· Summary: Secure-Trade is a portable protocol for any high-value asset.
· Future Scope: Integrating Chainlink Oracles to automatically verify real-world data without a human arbiter.