DEV Community: Darlington Gospel

How I Would Design an Autonomous REIT that Pays Monthly Dividends

Darlington Gospel — Thu, 26 Mar 2026 05:45:34 +0000

Most real estate investment trusts still run leasing and dividends through spreadsheets and human teams. They think the problem is slow paperwork or high fees.
It is not.

The real gap is blockchain underuse. REIT operators use less than 5% of what blockchain can do for trust and instant settlement. That is not a property management problem. It is a trust and latency problem — and no traditional process upgrade fixes an on-chain settlement problem.

Here is the system I would build to close that gap completely: a closed-loop, 7-layer autonomous AI + blockchain + automation operating system on Polygon PoS that executes the entire REIT lifecycle without intermediaries and pays monthly dividends in under 15 seconds.

The Infrastructure Problem

Traditional REITs have three compounding failures. Manual underwriting takes weeks. Leases need lawyers and paper signatures. Rent collection sits in spreadsheets, and dividends arrive quarterly after wire fees and delays. That costs time, errors, and lost yield — and none of it is a technology limitation. It is a stack design failure.

The deeper issue is coordination trust. When a lease gets executed today, the proof lives in a filing cabinet or a PDF on a shared drive. When rent is collected, the confirmation travels through a bank, a property manager, an accountant, and a wire transfer that takes days to clear. Each handoff is a point where data can be disputed, delayed, or manipulated. The entire system is held together by human intermediaries because no one built the infrastructure that makes intermediaries unnecessary.

Blockchain is the obvious fix — except most REIT operators have never built it in properly. They bolt on a token here, a smart contract there, and call it "tokenized real estate." What they actually have is a traditional REIT with a digital wrapper. The operational logic — the leasing, the rent cycles, the dividend calculations — still runs on the same human-dependent stack underneath.

The fix is not a token. The fix is redesigning the operating system from the ground up so that trust, settlement, and decision-making are all encoded in the infrastructure itself.

The System Architecture: 7-Layer Autonomous REIT Operating System

The architecture organises 24 nodes across 7 horizontal layers. Data flows upward from ingestion to intelligence. Decisions flow downward to blockchain settlement. The Automation Fabric connects everything. No layer has a dependency that skips a layer below it.

You can watch the full step-by-step breakdown of the architecture and user journey in the video below, or explore the full playlist covering different system architectures.

Here is what each layer does and why it exists.

L01 — Data & Ingestion

This is the sensory layer. Four nodes handle everything that enters the system: IoT telemetry from property sensors (pushed via MQTT at 1 Hz, normalised into typed events on Kafka), the PGVector RAG Store (a PostgreSQL 16 + PGVector instance holding SEC regulations, lease templates, MLS comparables, and REIT tax rules as searchable vector embeddings), The Graph Subgraph (which indexes all smart contract events on Polygon PoS and exposes a GraphQL API returning portfolio balances in under 200ms), and IPFS + Pinata (decentralised document storage where every lease PDF, property deed, and inspection report is pinned, with a content identifier written on-chain as an immutable reference).

L01 solves the data silo problem that breaks traditional REITs. Every agent in L02 operates from a single, queryable source of truth — not from a spreadsheet someone last updated on Tuesday.

L02 — AI & Intelligence

Seven LangGraph agents run here. Each agent has a defined persona, a constrained toolset, a versioned prompt library, and a deterministic output schema validated by Pydantic. They share no state at runtime. All context is injected via a structured Context Envelope assembled in under 250ms.

The roster:

Investor Advisor generates personalised allocation recommendations.
Acquisition Scout runs on Grok-4 via Groq (under 900ms) and scores deals autonomously against cap rate, cash-on-cash return, and vacancy risk — submitting letters of intent on properties under $2M without human approval.
Tenant Matcher sets rent within DAO-approved bands, screens tenants for Fair Housing Act compliance, and approves leases in under 12 seconds.
Operations Overseer dispatches maintenance contractors using GPT-4o Vision to verify work completion before releasing payment.
Financial Steward pulls all expense records, reconciles against collected rent, and calculates net distributable income.
Compliance Warden monitors five REIT qualification tests daily and issues on-chain attestations.
Supervisor Agent coordinates all other agents, arbitrates conflicts, and routes anomalies to the human escalation queue.

The business logic here: no human approval delay in the critical path. Decisions drop straight to the blockchain.

L03 — Blockchain & Trust

This layer is the legal spine. Four smart contracts on Polygon PoS encode everything that would otherwise live in a law firm's filing cabinet.

ReitaPropertyNFT.sol (ERC-721) is the on-chain property title deed — soulbound to the Reita operations multisig, minted at acquisition close, with the IPFS deed CID embedded in token metadata.
FractionalShareContract.sol (ERC-1155) represents divisible investor shares. balanceOf() is used for real-time dividend calculation. Every secondary transfer is tracked on-chain at 0.3% fee. RentEscrowContract.sol is the neutral vault that receives USDC rent, holds security deposits, and enforces a 48-hour dispute window before releasing funds.
DividendDistributor.sol is the gas-optimised batch payout contract that distributes pro-rata rental income to all fractional shareholders on Polygon PoS — 5-second finality means investors see USDC in their wallets within 15 seconds of the distribution call.

This is where the blockchain underuse problem ends. No spreadsheets. No intermediaries. The contract is the law.

L04 — Automation Fabric

This layer is what prevents the system from collapsing under its own complexity. The runtime is Temporal.io — durable, exactly-once workflow execution with automatic replay on failure. For a system managing financial assets, this is non-negotiable. No workflow ever silently fails.

The Kafka Event Bus carries every platform domain event, partitioned by property_id for ordered processing. KEDA autoscales AI agent pods based on Kafka consumer lag — during a major rent collection event, agent pods scale up automatically.
The Acquisition Workflow manages the full lifecycle from deal identification to token issuance, with saga compensation logic: if registerProperty() fails, all prior steps reverse — no property is ever left in a half-registered state.
The Rental Lifecycle Workflow manages 10,000+ concurrent tenancy instances, each tracking its own schedule, state, and exception handling via Temporal's persistence engine.

L04 connects AI decisions to blockchain actions. No dropped steps, no race conditions, no missing state.

L05 — Interface & UX

This layer serves the humans. Four surfaces, all built on Next.js 15 with real-time data via The Graph and Socket.io.

Listing Syndication automatically publishes vacant units to Zillow, Trulia, Redfin, and MLS the moment a property becomes available — and deactivates the listing the moment a lease is signed.
Tenant Portal handles the full application flow: browse listings, submit an encrypted application with Plaid-verified income, receive an AI decision in seconds, and e-sign a jurisdiction-specific lease directly in the browser.
Investor Dashboard renders real-time yield curves, dividend history, and property NAV with on-chain portfolio balances via The Graph's GraphQL API.
Operator Dashboard gives platform operators a unified view of every active lease, pending maintenance job, agent decision log, and compliance alert — updating via SSE at 500ms frequency.

L06 — Infra & Observability

AWS EKS runs all pods. Prometheus and Grafana handle metrics and alerting. LangSmith traces every LangGraph agent call — every prompt, response, token count, model version, and latency — giving a full audit trail for every autonomous decision. KEDA autoscales AI agent replicas 1–20 based on Kafka consumer lag per topic. AlertManager pages on-call engineers for SLA breaches: agent inference over 900ms, lease approval over 12 seconds, dividend distribution over 15 seconds.

Without LangSmith tracing, a prompt regression causing discriminatory lease decisions would be invisible until a Fair Housing Act violation occurred. L06 is not optional infrastructure. It is a first-class architectural requirement.

L07 — Payments & Finance

Stripe ACH initiates monthly rent pulls from tenant bank accounts. Once USD clears, Circle converts to USDC at 1:1 parity and routes to the RentEscrowContract on Polygon PoS. Investors deposit USDC directly — gasless, via Circle's programmable wallets API. Dividend payouts flow through the DividendDistributor contract. All payment webhook endpoints are idempotent — Stripe and Circle event IDs are stored in PostgreSQL with ON CONFLICT DO NOTHING, so duplicate deliveries are silently discarded.

L07 is intentionally isolated as its own layer because it sits at the intersection of traditional financial regulation and blockchain infrastructure. Swapping Stripe or Circle for a different provider never touches agent or workflow logic.

End-to-End System Flow Simplified

1. Investment Entry

Investor deposits USDC
Corresponding shares are minted on-chain

2. Property Acquisition

Acquisition Scout identifies a property
Property is registered as an ERC-721 NFT

3. Tenant Onboarding

Tenant submits application
Tenant Matcher reviews and approves (< 12 seconds)

4. Rental Lifecycle Activation

Temporal Rental Lifecycle Workflow is triggered
Lease becomes active and managed automatically

5. Rent Collection & Conversion

Stripe ACH pulls monthly rent (fiat)
Circle converts fiat → USDC
Funds are deposited into RentEscrow

6. Financial Reconciliation

Financial Steward validates and reconciles all inflows

7. Investor Payout

DividendDistributor executes batch payouts (< 15 seconds)

8. Transparency & Reporting

Investor Dashboard updates
On-chain receipt is recorded and visible

User Experience — How Each Stakeholder Interacts

Three user types interact with this system. Each one used to operate at the mercy of delays they couldn't see or control. Here is what changes.

Investors previously waited months for quarterly dividends to arrive via wire transfer, with no real-time visibility into portfolio performance. In this system, an investor connects a wallet, deposits USDC, and immediately sees projected yield on the dashboard. Shares mint on-chain as ERC-1155 tokens pro-rata to their contribution. Every month, the Financial Steward reconciles income, the DividendDistributor executes the payout, and the investor sees USDC land in their wallet — with a cryptographically verifiable on-chain receipt — within 15 seconds of distribution.

Tenants used to fill out paper applications, wait for a human to review them, negotiate leases through a property manager, and sign documents through a multi-day back-and-forth. In this system, a tenant browses AI-curated listings on the portal or through a Zillow click-through, submits an encrypted application, receives an AI screening decision in seconds, and e-signs a fully customised jurisdiction-specific lease in the same browser session. The security deposit and first month's rent are collected once, automatically, at activation.

Operators used to be the connective tissue holding the whole process together — coordinating between lawyers, accountants, property managers, and banks. In this system, the Operator Dashboard surfaces everything the Supervisor Agent has already handled: every active lease, every maintenance job, every compliance alert, every yield distribution. Human operators are present for escalations — not for routine execution. The system handles the critical path. The operator sets the policy parameters.

The second phase of the journey map shows what happens after the tenant is approved: lease generation, e-signature, escrow initiation, automated rent collection, Financial Steward reconciliation, dividend distribution, platform fee auto-deduction on-chain, and instant USDC payout to the Investor Dashboard. The entire sequence — phases 4 through 7 — runs without a single human step in the critical path.

Key Stats & System Summary

Data points to include:
- REITs today use less than 5% of what blockchain can actually do
- Transactions on Polygon are:
- Finalized in under 5 seconds
- Cost less than $0.001
- Lease approvals happen in under 12 seconds
- Dividend payouts complete in 15 seconds
- System runs on:
- 24 nodes
- Across 7 infrastructure layers
- MVP can be built in 12 weeks
- Platform fees are fully automated on-chain:
- 1.5% of assets (AUM)
- 8% of rental income
- Powered by 7 AI agents
- No human approvals in the main execution flow

Before vs After comparison:
1. Dividends
- Before: Quarterly payouts via wire transfers
- After: Monthly payouts in USDC delivered in under 15 seconds
2. Lease Approval
- Before: Takes weeks with manual review
- After: Fully automated approval in under 12 seconds end-to-end
3. Rent Collection
- Before: Manual tracking and reconciliation
- After: Automated ACH collection with instant USDC conversion
4. Accounting
- Before: Spreadsheet-based and error-prone
- After: Fully on-chain, immutable settlement
5. Property Ownership Records
- Before: Opaque and paper-based title systems

- After: Transparent ownership via ERC-721 NFTs on Polygon PoS

The Business Case

The revenue model is straightforward: 1.5% AUM fee plus 8% rental income fee, both deducted automatically on-chain before pro-rata USDC distribution to investors. There is no billing cycle, no invoice, no collections process. The contracts enforce the fee structure atomically at the moment of payout. Acquisition generates an additional 2% fee on property tokenization proceeds, and secondary market transfers carry a 0.3% on-chain fee. The SaaS licensing model — $2,500/month for Starter, $8,000/month for Portfolio — adds recurring infrastructure revenue on top of the transactional fees, and enterprise API access creates a third revenue line for institutional processors who want to build on top of the stack.

The defensible position is not the token. It is the data. Every property acquisition, tenant screening decision, rent payment, maintenance job, and yield distribution generates structured, queryable, on-chain data that compounds over time. A REIT operating on this infrastructure after three years has a deal-scoring model, a tenant screening model, and a yield prediction model that no new entrant can replicate quickly. The switching cost for an institutional operator running 500 properties through this stack is not just technical — it is the operational history embedded in the system.

The investor signal: the infrastructure creates a lower cost structure than any traditional REIT operator. No underwriting staff. No leasing agents for routine approvals. No accountants for monthly yield reconciliation. The fixed cost base is the infrastructure, and the infrastructure scales horizontally. A portfolio of 10 properties and a portfolio of 500 properties run on the same stack with KEDA autoscaling handling the load difference automatically.

Strategic Considerations & Real Challenges

The adoption barrier is not technical. It is institutional. Most REIT operators do not have engineers who can build this stack, and most engineers who can build this stack have not run a real estate portfolio. The gap between the architecture described here and a production deployment is not just code — it is regulatory counsel, smart contract audits (Certik or Trail of Bits before any mainnet deployment), KYC/AML infrastructure via Persona and Chainalysis, and the operational change management required to hand routine decisions to an AI agent. Founders who underestimate this timeline end up with a half-finished stack that is worse than the spreadsheet they started with. The realistic closed-loop MVP is 12 weeks for a team that already has the technical depth.

The regulatory landscape is the second friction point. The ERC-1155 fractional shares are security tokens. SEC Regulation A+ caps public issuance at $75M per 12-month rolling period. Regulation D 506(c) limits access to accredited investors only. The Compliance Warden runs five REIT qualification tests daily — 75% asset test, 75% gross income test, 90% distribution requirement, 100-shareholder minimum, 5/50 concentration rule — but a DAO vote and a legal opinion are still required before launch. The architecture handles the technical compliance layer; the legal work cannot be automated away.

The smart contract risk is real. A bug in DividendDistributor.sol that miscalculates a pro-rata split or allows re-entrancy on a USDC-moving function is not a UI bug — it is a financial loss event. The mitigation: OpenZeppelin battle-tested base contracts, re-entrancy guards on every fund-moving function, a multi-firm audit before mainnet, an emergency pause via DAO multi-sig, and DeFi insurance via a protocol like Nexus Mutual. The risk is manageable. It is not dismissible.

The Stack Proves Something the Industry Has Avoided Admitting

The reason traditional REITs still run on spreadsheets is not that blockchain is too complex for real estate. It is that no one has built the operating system layer that makes blockchain the obvious choice at every decision point. This 7-layer stack is that operating system.

In three to five years, the operators who have built this infrastructure will have a data advantage, an operational cost advantage, and a settlement speed advantage that cannot be replicated by a traditional REIT adding a tokenization feature to its existing stack. The question for founders and institutions in this space is not whether autonomous REITs are possible. The question is whether they build this infrastructure now or buy access to it later.

If you are a founder or investor building in tokenized real estate, connect with me for a consulting discussion on designing your own autonomous REIT system — book a session at dappmentors.org/consult (limited to business propositions).

Watch the full architecture walkthrough on the Beyond Blockchain YouTube channel — the full Reita architecture video covers every layer and the live journey map animation.

About the Author

Darlington Gospel is an AI + Blockchain + Automation Infrastructure Architect and Strategic Technology Analyst. Founder of Dapp Mentors, Host of Beyond Blockchain, operating through Dapp Mentors. He designs autonomous AI, blockchain, and automation infrastructure for tokenized real estate systems that run without human intermediaries — writing for global enterprise founders, infrastructure startups, investors, technical leaders, business strategists, and AI/Blockchain/Automation architects.

How I Would Build an Autonomous Pharmaceutical Retail Chain Operating System

Darlington Gospel — Sat, 14 Mar 2026 20:58:26 +0000

The pharmaceutical retail chain does not have a technology problem. It has a coordination problem that technology has never properly addressed.

Walk into any mid-size pharmacy chain's back office and you find the same pattern: remittance submitted on a spreadsheet at the end of the day, procurement triggered by a manager's judgment when shelves look thin, supplier payments sitting in a queue waiting for someone to review the invoice. Branch A is out of Amoxicillin. Branch B is about to expire its surplus. Nobody knows. Nobody acts.

The infrastructure failure here is not just inefficiency — it is the complete absence of a trusted coordination layer between procurement, inventory, inter-branch operations, and financial settlement. The global pharmaceutical retail market exceeds $1.4 trillion annually. Chains are losing billions not because they lack inventory software, but because the software they run does not talk to anything and enforces nothing.

Buduka is the system I would build to fix this. A seven-layer Autonomous Business Operating System that replaces every manual bottleneck from low-stock detection to supplier payment with AI reasoning, durable automation, and on-chain settlement. Here is the architecture.

The Infrastructure Problem

The specific failure point in pharmaceutical retail is not stockouts. Stockouts are a symptom. The root cause is that no system currently coordinates the chain as a single operational unit.

Every branch runs as an island. POS data stays in the branch system. Procurement decisions get made by individual managers working from memory and gut feel. When a branch finally submits its daily remittance, it goes into a spreadsheet — and if the numbers are disputed two weeks later, there is no immutable record to resolve the disagreement. No audit trail. No chain-wide visibility into what was ordered, what was delivered, and what was paid. The data exists in fragments. The trust infrastructure does not exist at all.

The supplier side is equally broken. Suppliers deliver goods and wait weeks for payment because the settlement workflow depends on a human reviewing an invoice, matching it to a delivery, and approving a bank transfer. That process fails on volume. It fails on speed. It generates disputes that get resolved by email, documented nowhere, and forgotten before the next cycle. Meanwhile, the supplier's performance — on-time rate, GRN accuracy, pricing compliance — is never tracked in any structured way. Poor suppliers stay on the list. Good ones get no advantage.

The financial reconciliation problem is the one most chains refuse to confront directly. When a pharmacy manager submits remittance, the amount is taken on trust. There is no automated cross-check against POS totals. Discrepancies surface slowly if at all. And because nothing is blockchain-attested, there is no tamper-proof record to anchor a compliance audit. Regulators asking for a three-year procurement history get a spreadsheet archive that nobody can fully trust.

This is not a problem of lacking the right ERP system. It is a problem of lacking the right infrastructure design — one that treats AI coordination, workflow durability, and on-chain trust as first-class requirements rather than optional add-ons.

The Autonomous Pharmaceutical Retail Operating System

Buduka is structured as seven distinct layers. Each layer has a specific function. Each layer connects to the next with defined data contracts. Nothing is coupled by coincidence.

You can watch the full step-by-step breakdown of the architecture and user journey in the video below, or explore the full playlist covering different system architectures.

L01 — Data & Ingestion

This layer feeds the entire system. Three nodes operate here: the POS Data Feed, the Inventory DB, and Apache Kafka.

POS transactions stream in real time. Inventory state is maintained in a structured database with per-branch, per-SKU visibility. Kafka carries every event — stock movements, sales records, reorder signals — through the system with no batch delay and no nightly sync. When stock drops below reorder point at any branch, the event fires instantly. The AI layer receives it within milliseconds.

The significance of this layer is not the technology. It is the design decision to treat the entire chain as a single event stream rather than a collection of disconnected branch databases. That is the foundational shift that makes everything downstream possible.

L02 — AI & Intelligence

Seven LangGraph-based agents operate in this layer. Each has a defined persona, a constrained toolset, and a validated output schema. No agent outputs freeform text into the system — every decision is structured and machine-readable.

The Inventory Agent monitors every branch continuously. When stock at any branch crosses the reorder threshold, it generates a Branch Order Request with SKU IDs and quantities. The Demand Aggregator Agent collects all branch requests within a six-hour aggregation window and produces a chain-wide demand profile. The Trade Match Agent scans simultaneously for surplus and shortage patterns across branches and proposes net-zero inter-branch transfers. The Compliance Agent verifies every supplier's regulatory attestation before any order is allocated. The Settlement Agent handles GRN verification and constructs payment instructions. The Performance Agent scores suppliers live on delivery rate, accuracy, and compliance. The Orchestrator Agent arbitrates inter-agent conflicts and routes escalations to the correct human actor.

No manager approves a routine reorder. No supervisor manually matches a supplier invoice. The agents handle this. Human judgment enters the system only at escalation gates — high-value purchase orders that exceed autonomous spend thresholds, trade proposals waiting for manager confirmation, remittance discrepancies that require an explanation.

L03 — Blockchain & Trust

This is where the system earns its credibility. Four Solana smart contracts anchor every consequential operational and financial event.

The Solana Settlement Contract locks and releases USDC from the central procurement fund wallet — every fund reservation on PO creation and every release on GRN confirmation is on-chain. The Remittance Attestation Contract records the hash of every daily reconciliation result — branch ID, date, POS total, submitted amount, and status — immutably on Solana. The Procurement Fund Wallet is a program-derived address controlled exclusively by the Settlement Contract, holding central procurement capital with a real-time burn rate visible to Administration.

The Inter-Pharmacy Trade Contract anchors every net-zero inter-branch stock transfer with multi-sig confirmation from both branch managers.

The business argument for this layer is precise: when a supplier disputes a payment, when a regulator requests a compliance audit, when a branch manager contests a remittance shortfall, the answer is not a spreadsheet. It is a blockchain transaction hash with a timestamp that nobody altered.

L04 — Automation Fabric

Temporal-powered durable workflows operate here. Three primary workflows run on exactly-once execution semantics: Purchase Order Workflow, Daily Remittance Workflow, and Supplier Settlement Workflow.

The Purchase Order Workflow generates and reserves procurement funds the moment a supplier confirms their allocation. The Daily Remittance Workflow fires at 18:00 UTC for every active branch simultaneously — fetching POS totals, notifying the Pharmacy Manager, waiting for remittance submission, reconciling the result, and anchoring the outcome on-chain. The Supplier Settlement Workflow triggers on GRN (Goods Received Note) confirmation and orchestrates the end-to-end payment process through the Payment Gateway.

The design requirement for this layer is durability. Temporal workflows survive infrastructure restarts, retry failures automatically, and never lose state. An AI decision that triggers a workflow does not depend on the application server staying healthy. The workflow runs to completion regardless.

L05 — Interface & UX

Three Next.js portals serve the three actor classes. The Supplier Portal surfaces aggregated chain-wide demand by SKU — without exposing individual branch data — and handles GRN submission and payment history. The Pharmacy Manager Portal shows branch stock, incoming purchase orders, remittance status, and inter-pharmacy trade options. The Administration Dashboard controls procurement fund status, daily remittance scoreboards, supplier KPI tables, escalation queues, and chain-wide policy parameters.

A Socket.io WebSocket Chat Service sits alongside the three portals in this layer — correctly classified as an interface component, not a financial one.

Five room types operate on the hub:

TRADE (manager-to-manager stock negotiations)
PROCUREMENT (admin-to-supplier PO clarification)
ESCALATION (admin-to-manager dispute resolution)
SUPPORT (supplier-to-manager GRN discrepancies)
BROADCAST (admin to all actors). All conversations are archived for 90 days and auditable by Administration.

Room lifecycle is event-driven — rooms auto-open on operational triggers and auto-close when the linked entity reaches terminal state.

L06 — Infra & Observability

LangSmith runs the observability layer. Every agent inference, every workflow execution, and every on-chain transaction emits structured telemetry here.

The system traces complete LangGraph run trees per agent — prompt, structured output, tool call latency, schema validation pass/fail. Alert callbacks trigger the Orchestrator Agent when schema violation rates exceed defined thresholds. The Administration Dashboard receives a live agent health feed pushed by LangSmith webhooks. Without this layer, diagnosing why an allocation decision deviated from expected behavior requires guesswork. With it, the exact reasoning chain is traceable from the triggering event to the final output.

L07 — Payments & Finance

A dedicated Payment Gateway node sits here alongside the Solana contracts. This is an intentional architectural boundary — payment execution logic is separated from the smart contract layer. The Gateway listens for USDC disbursement events from the Settlement Contract, executes on-chain transfers for suppliers with Solana wallets (sub-500ms finality), and initiates Circle bank wires for fiat-payment suppliers. Every payment is signed through a CloudHSM-backed enterprise wallet. The Gateway broadcasts payment confirmation to the Supplier Portal and the Administration Dashboard simultaneously, and sends a completion signal to the Settlement Workflow to close the GRN lifecycle.

Complete System Flow

1. Demand Detection
Branch POS Event
→ Kafka Ingestion
→ InventoryAgent detects stock movement
→ DemandAggregatorAgent consolidates demand across branches

2. Supplier Allocation
Demand signal
→ Supplier allocation engine selects supplier
→ Supplier Portal confirmation

3. Purchase Order Execution
Supplier confirmation
→ PurchaseOrderWorkflow triggered
→ Funds reserved on-chain

4. Delivery & Inventory Verification
Supplier delivery
→ Goods Received Note (GRN) confirmation

5. Financial Settlement
GRN confirmation
→ SettlementAgent verification
→ Payment Gateway execution
→ USDC settlement

6. Compliance & Audit
Settlement completion
→ Remittance attestation recorded
→ LangSmith audit trail logged

Nothing in that chain waits for a human signature unless a policy threshold demands one.

User Experience — How Each Stakeholder Operates

The Pharmacy Manager previously ran on a combination of shelf observation, manual reorder emails, and daily spreadsheet remittance. They had no visibility into whether the supplier had received their order, no knowledge of which neighboring branch was sitting on surplus of what they needed, and no confirmation that the payment they submitted matched what the system recorded. With Buduka, their dashboard shows real-time branch stock, incoming order status, and active trade options. The Inventory Agent handles routine reorders autonomously. When an order requires approval, the Manager gets a time-gated escalation — approve or reject within a defined window, after which inaction routes to Administration. Daily remittance is submitted through the platform, cross-checked against POS totals automatically, and anchored on-chain. The manager's operational cognitive load drops to exception handling.

The Supplier previously received orders by email or EDI, delivered goods, raised an invoice, and waited. Payment timelines were unpredictable. Disputes about delivery quantities went back and forth with no formal resolution mechanism. With Buduka, the Supplier Portal shows their allocated demand before an order is formally issued — enabling logistics planning. Once goods are delivered and GRN is confirmed, the Payment Gateway executes within milliseconds for USDC-enabled suppliers, or initiates a Circle wire within standard banking windows. Every settlement has a blockchain transaction hash. Every dispute has a SUPPORT chat room with a linked GRN record. Performance scores update in real time, and a supplier's allocation weight in future orders reflects their actual track record.

Administration previously operated on reports — end-of-week summaries, month-end reconciliation reviews, quarterly supplier assessments. The data was backward-looking and could not be trusted entirely because it was assembled manually. With Buduka, Administration operates on live infrastructure. Procurement fund balance updates in real time with burn rate and runway projections. Daily remittance scoreboards show every branch's status by 22:00. Supplier KPI tables are scored continuously. Policy parameters — autonomous spend caps, allocation weights, reorder thresholds — are configured through the dashboard and enforced by the agents without manual follow-up.

The Business Case

The revenue model has five legs and a clear moat. SaaS licensing per pharmacy branch provides predictable recurring revenue that scales with the size of the chain — not with transaction volume. Per-transaction infrastructure fees on USDC settlements through the Payment Gateway attach revenue directly to the operational utility the system provides. Enterprise licensing for chains with 20 or more branches captures the segment with the highest willingness to pay, since larger chains carry the largest operational risk from the status quo. Compliance and operational data products sold to regulators and auditors convert the immutable on-chain records into a standalone revenue stream — audit-grade supply chain attestation is a regulated product category in most jurisdictions. Implementation consulting for chains adopting the system covers onboarding complexity and creates a high-value professional services layer.

The defensibility argument is not speculative. Every month a chain runs on Buduka, it accumulates on-chain attestation records, supplier performance histories, branch remittance patterns, and procurement baselines. That data set becomes the chain's operational intelligence layer. Switching to a competitor means abandoning that history. The network effect applies to the supplier side as well — suppliers onboarded into the Buduka ecosystem are scored, attested, and integrated. Re-onboarding them into a competing system carries real cost and compliance friction.

For investors evaluating autonomous business systems infrastructure, the signal here is architectural. This is not workflow automation layered on top of an existing ERP. This is a purpose-built operating system that replaces the coordination layer entirely. The switching cost is the point. The data moat is the compounding asset.

Strategic Considerations & Real Challenges

The hardest adoption challenge is not technical. It is organizational. Pharmacy chain managers who built their careers on judgment-based procurement and relationship-based supplier management do not readily hand decision authority to an AI agent. The mitigation is not to argue that the AI is better than they are — it is to position Buduka as the system that handles the volume they cannot, while preserving their role for escalations, exceptions, and strategic decisions. Autonomous for routine. Human for consequential. That framing changes the adoption conversation.

Regulatory complexity across different markets is real. Blockchain pharmaceutical logistics intersects with data residency requirements, controlled substance handling rules, and financial settlement regulations that vary by jurisdiction. The Compliance Agent's on-chain attestation model needs to be configured per regulatory environment, and the controlled substance eligibility gate for inter-pharmacy trades is a hard architectural requirement, not a soft rule. Chains operating across multiple regulatory environments need this baked into the system from day one — not bolted on later.

Infrastructure cost is the honest friction point for smaller chains. The Temporal workflow infrastructure, LangSmith observability, CloudHSM wallet security, and Solana settlement layer together represent a meaningful operational baseline cost. The per-branch SaaS model makes this work financially at scale. For chains under ten branches, the ROI calculation requires a clear analysis of current losses from stockouts, reconciliation disputes, and delayed supplier payments — because that is the number the infrastructure cost is measured against, not some abstract efficiency percentage.

The Infrastructure Always Determines the Outcome

Most pharmaceutical chains will spend the next decade optimizing processes built on fundamentally broken infrastructure. Better spreadsheet templates. Faster email approvals. More responsive supplier portals that still don't talk to the settlement layer. The operational ceiling of that approach is low, and every year spent under it is a year of compounding losses.

Buduka proves a different thesis: that pharmaceutical retail operations are not inherently complex — they are complex because no one designed the coordination layer correctly. When AI agents reason over live chain-wide data, when automation workflows execute without human bottlenecks, and when every financial transaction is blockchain-attested before it closes, the operational picture changes entirely. Stockouts become detectable and preventable in advance. Supplier payments become instant and irrefutable. Remittance disputes become resolved by on-chain evidence rather than negotiated in email.

In three to five years, the chains that built this infrastructure will have compounding data advantages that no late adopter can quickly replicate. The ones still running on spreadsheets will be paying for that gap.

If you want me to design a system like Buduka for your business — an autonomous operating stack that removes manual decisions from your chain operations — the consulting booking link is here: dappmentors.org/consult. Let's build the infrastructure.

About the Author

Darlington Gospel is an AI, Blockchain & Automation Infrastructure Architect and Strategic Technology Analyst. Host of Beyond Blockchain series, and Founder of Dapp Mentors. Writing for enterprise founders, infrastructure startups, technical architects, supply chain operators, investors evaluating infrastructure innovation, and global business strategists.

What You Need to Build an Automated AI Crypto Trading Bot

Darlington Gospel — Tue, 12 Aug 2025 01:57:07 +0000

Introduction: From a Clueless Beginner to Automated Profits

Six months ago, I knew absolutely nothing about cryptocurrency trading. The crypto markets felt like a chaotic casino where fortunes were made and lost in minutes, and I was completely overwhelmed by the endless charts, technical indicators, and market psychology that seasoned traders seemed to navigate effortlessly.

But here's what changed everything: I realized I didn't need to become a trading expert overnight. I needed to become a problem-solving programmer who could teach machines to trade better than humans.

Today, I'm running an autonomous AI crypto trading platform that operates like clockwork—analyzing market sentiment from thousands of news sources, processing real-time price data, making calculated trading decisions, and executing trades automatically.

The transformation wasn't magic. It was systematic learning, failed experiments, breakthrough moments, and ultimately combining my programming skills with cutting-edge AI technology. The bot you'll see in the demo has generated consistent profits across multiple cryptocurrencies, with sophisticated risk management that keeps losses minimal while capturing market opportunities.
I'm going to show you the exact path I took—not just the successes, but the failures that taught me why most trading bots fail spectacularly and how AI-powered systems represent a fundamental shift in automated trading.

The Reality Check: Why Most Trading Bots Fail

Before diving into solutions, let's address the uncomfortable truth: most trading bots are expensive disappointments.

Traditional trading bots rely on static algorithms—rigid rules like "buy when the price crosses above the 50-day moving average" or "sell when RSI exceeds 70." These approaches worked reasonably well in traditional markets where patterns were more predictable, but cryptocurrency markets are different beasts entirely.

The Volatility Problem:
Crypto markets can swing 10-20% in minutes based on a single tweet, regulatory news, or whale movement. Static algorithms can't adapt to these sudden shifts in market psychology.

The Sentiment Gap:
Traditional technical analysis ignores the human element—the fear, greed, and hype that drive crypto prices. While your bot is calculating moving averages, the market might be reacting to breaking news about regulatory changes or celebrity endorsements.

The Scalability Issue:
Even if you create rules that work for Bitcoin, they might fail completely for smaller altcoins with different trading patterns and liquidity profiles.

This is where AI-powered systems create a paradigm shift. Instead of following rigid rules, they continuously learn from market data, news sentiment, and trading patterns. They adapt their strategies in real-time, weigh multiple factors simultaneously, and most importantly—they understand context in ways that traditional algorithms simply cannot.

The Essential Components: Breaking Down the AI Trading Stack

Building an effective AI crypto trading bot requires four interconnected layers, each serving a critical purpose in the decision-making process.

A. Data Collection Layer
Your AI is only as smart as the data it processes. This layer continuously gathers three types of critical information:

Historical Market Data serves as the training ground for your AI models. Just like a human trader studies past price movements to identify patterns, your AI needs months or years of historical data to understand how different cryptocurrencies behave under various market conditions.

Real-time Price Feeds provide the live market data necessary for execution decisions. This isn't just current prices—it includes trading volume, order book depth, and market momentum indicators that help the AI understand the immediate trading environment.

News Sentiment Analysis bridges the gap between technical analysis and market psychology. The system continuously monitors cryptocurrency news sources, social media sentiment, and major market announcements, using natural language processing to gauge whether the overall market mood is bullish, bearish, or uncertain.

B. AI Processing Engine
This is where the magic happens—where raw data transforms into trading intelligence.

Large Language Models (LLMs) process news articles and market commentary, extracting meaningful insights about how current events might impact cryptocurrency prices. Unlike humans who might miss subtle connections, LLMs can simultaneously analyze hundreds of news sources and identify sentiment patterns across different cryptocurrencies.

Machine Learning Models handle the predictive analytics, identifying patterns in price movements, volume changes, and technical indicators that suggest profitable trading opportunities.

Risk Management Algorithms ensure that potential profits never come at the cost of catastrophic losses. These systems calculate position sizes, set stop-loss levels, and diversify trades to protect capital during market downturns.

Portfolio Optimization Logic balances the entire portfolio, deciding how much capital to allocate to each trading opportunity based on expected returns, risk levels, and correlation with other holdings.

C. Trading Execution System
Having great insights means nothing without flawless execution.

Exchange API Integration connects your bot to cryptocurrency exchanges, enabling seamless buying and selling across multiple platforms.

Order Management handles the technical details of trade execution—optimizing order types, timing entries and exits, and managing partial fills.

Capital Allocation distributes available funds across different trading opportunities according to the risk-return profiles calculated by the AI.

Performance Tracking monitors every trade, calculating profits and losses, and feeding performance data back into the system for continuous improvement.

D. User Interface & Control
Even autonomous systems need human oversight.

The Real-time Dashboard provides instant visibility into bot performance, current holdings, and market conditions. Performance Visualization tools help you understand how your bot is performing over different time periods and market conditions. Manual Override Capabilities ensure you maintain ultimate control, allowing you to pause trading, adjust parameters, or intervene during unusual market conditions. Reporting and Analytics features provide detailed insights into trading patterns, helping you optimize the system over time.

Want to see these components working together? Check out the full system demo

Technical Deep Dive: The Technologies That Make It Possible

Choosing the right technology stack can make the difference between a hobby project and a production-grade trading system. Here's why each technology was selected and how they work together.

Backend Technologies
Python forms the backbone of the system because it's the lingua franca of AI and machine learning. With libraries like scikit-learn, pandas, and numpy, Python provides unmatched support for data analysis and model development. More importantly, most AI research and tools are Python-first, ensuring compatibility with cutting-edge developments.

FastAPI powers the backend API because speed matters in trading systems. FastAPI provides automatic API documentation, built-in data validation, and exceptional performance—crucial when your bot needs to process market data and execute trades in milliseconds.

MongoDB handles data storage because cryptocurrency trading generates massive amounts of unstructured data. Historical prices, news articles, sentiment scores, and trading logs don't fit neatly into traditional relational database schemas. MongoDB's document-based structure and horizontal scaling capabilities make it ideal for high-frequency trading data.

Ollama manages interactions with large language models, providing a standardized interface for processing news sentiment and generating trading insights. This abstraction layer allows you to experiment with different LLMs without rewriting core logic.

Docker ensures consistent deployment across different environments. Trading systems often run on cloud servers, local machines, or dedicated hardware, and Docker containers eliminate the "it works on my machine" problem.

Frontend Technologies
Next.js + TypeScript creates the responsive trading dashboard because real-time data visualization demands performance and type safety. Next.js provides server-side rendering for fast initial loads, while TypeScript catches errors before they reach production.

React Components handle real-time data visualization, updating charts and metrics as new market data arrives. The component-based architecture makes it easy to add new visualization features without disrupting existing functionality.

Tailwind CSS provides professional UI design with minimal custom CSS. In trading applications where users need to quickly process large amounts of information, consistent, clean design isn't just aesthetic—it's functional.

AI & Data Technologies
LLM Integration processes news and social media content, converting unstructured text into structured sentiment scores that the trading algorithm can incorporate into decision-making.

Scikit-learn handles the machine learning predictive modeling, providing battle-tested algorithms for pattern recognition in price data and feature engineering.

Playwright enables automated data harvesting from websites that don't provide APIs, ensuring your bot has access to comprehensive market information even from non-traditional sources.

Real-time APIs connect to cryptocurrency exchanges and market data providers, ensuring your bot always operates with the most current information available.

The Trading Strategy: Where AI Meets Market Psychology

The secret to successful automated trading isn't just having good technology—it's implementing a strategy that acknowledges both market mechanics and human psychology.

Multi-factor Analysis Approach
Rather than relying on a single indicator, the AI system evaluates multiple factors simultaneously. Technical indicators like moving averages and RSI provide insights into price momentum, while volume analysis reveals whether price movements have strong support. Market sentiment from news analysis adds context about why prices are moving, and correlation analysis with other cryptocurrencies helps identify market-wide trends versus asset-specific movements.

Sentiment Weighting in Decision-Making
Here's where AI systems excel beyond human traders: they can simultaneously process sentiment from thousands of sources without emotional bias. The system assigns sentiment scores to news articles, social media trends, and regulatory announcements, then weighs these scores against technical indicators. For example, strong technical buy signals might be downgraded if news sentiment suggests regulatory crackdowns, while weak technical signals might be amplified during periods of positive market sentiment.

Risk-Adjusted Position Sizing
The AI doesn't just decide what to buy—it calculates exactly how much to risk on each trade based on historical volatility, current market conditions, and portfolio correlation. High-confidence trades with strong risk-reward ratios get larger position sizes, while experimental trades or highly volatile assets get smaller allocations.

Market Condition Adaptation
Perhaps most importantly, the system recognizes that market conditions change. Strategies that work in bull markets may fail during bear markets or sideways trading periods. The AI continuously evaluates current market regimes and adjusts its approach accordingly—becoming more conservative during high volatility periods and more aggressive when opportunities present clear risk-reward profiles.

Backtesting and Validation
Before risking real capital on any strategy modification, the system validates changes against historical data. This isn't simple backtesting that assumes perfect execution—the validation process includes realistic transaction costs, slippage, and market impact to ensure strategies remain profitable in real-world conditions.

Ready to implement these strategies yourself? My complete course walks you through every line of code

Real-World Challenges and Solutions

Building a production trading system means solving problems that theoretical discussions often ignore.

Technical Challenges
API Rate Limiting and Data Reliability: Cryptocurrency exchanges impose strict rate limits and occasionally experience downtime during high volatility periods. The solution involves implementing intelligent request throttling, failover systems that switch between multiple data providers, and local caching to reduce API dependencies during critical trading periods.

Latency Optimization: In crypto markets where prices can move significantly in seconds, every millisecond matters. This requires optimizing network connections, using geographically distributed servers close to exchange data centers, and implementing efficient data processing pipelines that minimize computational delays.

Error Handling and System Resilience: Trading systems must continue operating even when individual components fail. This means implementing comprehensive logging, automatic restart procedures, graceful degradation when non-critical services are unavailable, and fail-safe mechanisms that protect capital during system errors.

Trading Fee Considerations: Transaction costs can quickly erode profits from automated trading. The system must calculate all fees—trading commissions, network fees, spread costs—and incorporate them into profitability calculations before executing any trade.

Market Challenges
Handling Extreme Volatility: Crypto markets can experience 50%+ price swings during black swan events. The system includes volatility circuit breakers that reduce position sizes or halt trading entirely when market conditions exceed historical norms, protecting capital during unpredictable periods.

Avoiding Overfitting to Historical Data: Machine learning models can become too specialized to past market conditions, failing when markets behave differently. Regular model retraining, out-of-sample validation, and ensemble methods help ensure the system remains robust across different market environments.

Adapting to Changing Market Conditions: Market structure evolves as institutional adoption increases, new regulations emerge, and trading patterns shift. The system includes mechanisms to detect when historical relationships break down and requires human intervention to update strategies.

Managing Drawdown Periods: Even the best trading systems experience losing streaks. Proper capital management, position sizing, and psychological preparation for drawdown periods prevent emotional decision-making during temporary setbacks.

Regulatory and Risk Considerations
Exchange Compliance Requirements: Different jurisdictions have varying regulations about automated trading, data storage, and financial reporting. The system includes audit trails, compliance reporting features, and jurisdiction-specific configurations.

Capital Preservation Strategies: The primary goal isn't maximizing profits—it's preserving capital while generating consistent returns. This means conservative position sizing, diversification across multiple assets, and strict stop-loss disciplines.

Monitoring and Alerting Systems: Automated systems require human oversight. The platform includes real-time monitoring, automated alerts for unusual conditions, and comprehensive reporting to ensure you maintain awareness of system performance and market conditions.

Beyond Personal Trading: The Business Opportunity

The technology stack we've discussed isn't just for personal trading—it represents a significant business opportunity for developers and entrepreneurs.

Building Trading Bots for Clients
High-net-worth individuals and small hedge funds often lack the technical expertise to build sophisticated trading systems. With the complete codebase and commercial license, you can customize the platform for specific client needs, charge setup fees, ongoing management fees, or performance-based compensation.

SaaS Trading Platform Development
The modular architecture makes it straightforward to build a multi-tenant SaaS platform where users can configure their own trading strategies, deposit funds, and monitor performance through personalized dashboards. This creates recurring revenue opportunities with minimal ongoing development costs.

Hedge Fund Technology Solutions
Institutional clients require enterprise-grade features like advanced risk management, regulatory reporting, and multi-asset support. The foundational platform can be extended with these features, targeting hedge funds and asset managers who want proven AI trading technology without building from scratch.

Educational and Consulting Services
As AI trading becomes mainstream, demand for expertise in building and optimizing these systems will grow exponentially. The deep technical knowledge gained from building the platform positions one to offer consulting services, educational workshops, or even develop additional courses targeting different market segments.

The complete source code with commercial-use license is included in the course

Getting Started: Your Roadmap to Building

Success in building an AI trading bot depends on systematic progression through four distinct phases.

Prerequisites and Preparation
You'll need basic proficiency in JavaScript and Python—not expert level, but comfortable with variables, functions, and basic data structures. The development environment requires Node.js for the frontend, Python 3.8+ for the backend, Docker for containerization, and accounts with cryptocurrency exchanges for testing and live trading.

Understanding basic trading concepts helps but isn't required. The course covers necessary trading knowledge within the context of building the bot, so programming background is more important than market expertise.

Hardware requirements are modest—any modern laptop can handle development, though you'll eventually want cloud hosting for production deployment to ensure 24/7 operation and low-latency connections to exchanges.

Learning Path Recommendations
Phase 1: Understanding the Architecture involves studying the system design, data flow, and component interactions. This foundation prevents confusion later when building individual pieces.

Phase 2: Building Core Components focuses on implementing the data collection layer, database design, and basic API structures. Getting these fundamentals right ensures the advanced AI features have a solid foundation.

Phase 3: AI Integration and Testing introduces machine learning models, sentiment analysis, and trading logic. This phase includes extensive backtesting to validate strategies before risking real capital.

Phase 4: Deployment and Optimization covers containerization with Docker, cloud deployment, monitoring systems, and performance optimization for production environments.

Resources and Tools
Development tools include Visual Studio Code with Python and JavaScript extensions, Git for version control, and database management tools for MongoDB. Data sources encompass cryptocurrency exchange APIs, financial news feeds, and market data providers—both free and premium options depending on requirements.

Testing frameworks include pytest for Python backend testing, Jest for JavaScript frontend testing, and specialized financial backtesting libraries for strategy validation. Monitoring and analytics platforms help track system performance, trading results, and technical metrics in production environments.

Conclusion: The Future of Automated Trading

The convergence of artificial intelligence and cryptocurrency trading represents more than just a technological advancement—it's the foundation of how financial markets will operate in the coming decade.

AI is transforming trading forever by eliminating human emotional biases, processing information at superhuman scales, and identifying patterns that would be impossible for manual analysis. Early adopters who master these technologies today will have significant competitive advantages as the financial industry increasingly adopts AI-driven approaches.

These skills are becoming increasingly valuable across the fintech sector. Major banks, hedge funds, and fintech startups are desperately seeking developers who understand both AI technology and financial markets. The combination is rare enough that expertise in this area commands premium compensation and opens doors to fascinating career opportunities.

The time to start building is now. The cryptocurrency market is still young enough that individual developers can compete with institutional players, and the AI tools necessary to build sophisticated trading systems have never been more accessible.

But theoretical knowledge isn't enough. The only way to truly understand automated trading is to build, test, and deploy a real system that trades real money in real markets. That's exactly what we'll do together in this comprehensive course.

The future of trading isn't about humans versus machines—it's about humans who understand machines having massive advantages over those who don't.

Don't just read about the future of trading—build it. Get started with the complete AI Trading Bot Mastery course and watch the live demo.

Technical Spotlight: How AI Processes Market Sentiment
Traditional trading bots ignore the human element of markets, but AI systems excel at understanding the emotional context behind price movements. When the AI encounters news like "SEC announces new crypto regulations," it doesn't just categorize this as "regulatory news"—it understands the historical impact of regulatory announcements on different cryptocurrencies, weighs the severity of the language used, and factors in current market sentiment to predict whether prices will rise or fall.

Pro Tip: Start with Paper Trading
Before deploying real capital, run your AI trading bot with simulated money for at least 30 days. This allows you to validate your strategies, identify edge cases, and build confidence in the system's decision-making process without financial risk.

Common Pitfall: Over-Optimization
The biggest mistake in automated trading is creating systems that work perfectly on historical data but fail in live markets. Always reserve a portion of your historical data for final validation testing, and never optimize strategies based on short-term results—cryptocurrency markets can remain irrational far longer than your account can remain solvent.

About Author

I am a web3 developer and the founder of Dapp Mentors, a company that helps businesses and individuals build and launch decentralized applications. I have over 7 years of experience in the software industry, and I am passionate about using blockchain technology to create new and innovative applications. I run a YouTube channel called Dapp Mentors where I share tutorials and tips on web3 development, and I regularly post articles online about the latest trends in the blockchain space.

Stay connected with us, join communities on
Discord: Join
X-Twitter: Follow
LinkedIn: Connect
GitHub: Explore
Website: Visit

Build a Web3 Movie Streaming dApp using NextJs, Tailwind, and Sia Renterd: Part Three

Darlington Gospel — Fri, 23 Aug 2024 11:04:25 +0000

Let's dive into the final part of this tutorial series, where we'll integrate the backend with the Frontend, connecting the pieces to complete the file upload application. We will begin by ensuring that authentications in the Frontend are up and running.

Web3 Modal Authentication

Create a new folder named 'config' in the Frontend directory and add an index file, resulting in the path /frontend/config/index.tsx. Now let’s add the following codes to it.

This code sets up a Wagmi configuration for our Web3 application, defining metadata, supported chains, and authentication settings, including wallet and social login options, and stores it in the config export. We also need to create a context API to keep track of the authentication state.

The Context API
Next, create a new folder named 'context' still in the Frontend directory and add an index file, resulting in the path /frontend/context/index.tsx. Add the following codes to it.

This code sets up a Web3Modal provider using Wagmi and React Query, configuring the Web3 modal with the project ID and theme variables, and wrapping the application in a WagmiProvider and QueryClientProvider.

Updating Layout
Let’s have our application layout updated to include the above configurations. Head to /frontend/app/layout.tsx and replace its codes with the one below.

The above code sets up the root layout for a Next.js application, including metadata, fonts, styles, and providers for Web3 modal, toast notifications, and layout components like header and footer.

The Login Button
Now, we need to enable the login buttons in the /frontend/app/components/layout/Header.tsx and /frontend/app/components/shared/Menu.tsx components, and update their codes using the information below.

This code defines a React component for a navigation bar that includes a logo, navigation links, a custom menu, and a login button that launches a Web3 Modal, with a responsive design for different screen sizes.

The following images should pop up as proof that what we have done works when you click on the login button and proceed with your preferred provider, X, Facebook, Google, Discord, or Ethereum.

Superb, let’s go deeper and set up our database and NextJs API-based system. For any confusion on the process, please watch the video section below, just make sure you stop at the 02:57:59 mark.

Database Scripts

First, let’s update the NextJs configuration script to properly address our pages, and endpoints, and free our remote images from warnings and scrutiny.

This code defines a Next.js configuration object that sets up API route rewrites and image optimization, allowing remote images from any HTTPS hostname and local images from the localhost domain.

Database Config Script
We will be using SQLite for this application, but you are free to use a more robust solution such as MYSQL or NOSQL providers. For the sake of simplicity, let's work with a SQLite flat file.

Create /frontend/app/api/database.ts file path and add the codes below in it.

This code sets up an SQLite database connection and defines two API functions, apiGet and apiPost, to perform GET and POST requests on the database, with error handling and promise-based asynchronous execution. We will be using these codes whenever we wish to send or retrieve data from the database.

Database Migration Script
We need to create both a database flat file and a table to hold all our contents. Create /frontend/app/api/migrations.ts file path and add the codes below in it.

This code defines a database migration function that creates a 'movies' table with specified columns if it doesn't exist, using SQLite, and logs the result of the operation. Now run the command below in a terminal pointed at the /frontend directory.

$ cd frontend
$ npx esrun app/api/migrations.ts

It should be noted that this process will also create a database flat file called movies.db at the root of the frontend directory. We have also added this command to the package.json script, so running $ yarn migrate on the frontend directory should work the same.

For visual assistance, watch the video below, just stop it at the 03:10:54 mark.

Application Endpoints

Now, let’s define some endpoints for creating, reading, updating, and deleting movies, we will be using the NextJs API provision to make these endpoints.

Create Movie Endpoint
To create a movie, the required information includes the user ID, movie name, image, video URL, release date, genre, rating, language, duration, and background description. Create /frontend/app/api/movies/create/route.ts file path and add the codes below in it.

This code defines an endpoint to handle POST requests, validate and process movie data, generate a unique slug, and insert the data into a database using an apiPost function while handling errors and returning JSON responses.

Update Movie Endpoint
To update a movie, the required information includes the user ID, slug, and other information provided when creating a movie. Create /frontend/app/api/movies/update/route.ts file path and add the codes below in it.

This code defines an endpoint to handle POST requests for updating a movie, validating required properties, and executing an SQL query to update the movie data in the database using the apiPost function.

Delete Movie Endpoint
To delete a movie, the required information includes the user ID and slug of a movie. Create /frontend/app/api/movies/delete/route.ts file path and add the codes below in it.

This code defines an endpoint to handle POST requests for deleting a movie, validating required properties (userId and slug), and executing an SQL query to delete the movie from the database using the apiPost function.

All Movies Endpoint
The optional data required to get movies are pageSize and userId, which can be passed as query parameters to filter and paginate the results. Create /frontend/app/api/movies/all/route.ts file path and add the codes below in it.

The above code defines an endpoint to handle GET requests for retrieving movies, allowing optional filtering by userId and pagination by pageSize, and returns the results in JSON format.

Single Movie Endpoint
To retrieve a single movie, the required data is the slug of a movie. Create /frontend/app/api/movies/[slug]/route.ts file path and add the codes below in it.

This code defines an endpoint to handle GET requests for retrieving a movie by its slug, validating the slug parameter, and executing an SQL query to retrieve the movie data from the database using the apiGet function.

That marks all the endpoints we will need for this application. If you need a visual aid to help you understand these endpoints better, please watch the video below, just ensure you stop at the 03:48:22 timestamp.

Endpoint Integration

Our task is to review and update pre-coded components and pages, explaining each one's purpose and functionality, and documenting the changes we make to the existing code. We will start by creating a service for interacting with the endpoints we previously created in the api directory.

Create /frontend/app/services/api.service.ts file path and add the codes below in it.

This service provides a set of functions to interact with a movie database, allowing the application to fetch movies, fetch a single movie by slug, create a new movie, update an existing movie, delete a movie, and upload files, using API requests and handling errors.

Application Pages

Let’s review and update the various pages associated with our application. You wouldn’t need to change many things, just the ones highlighted here.

Create Movie Page

This page is a movie publishing form that allows users to upload video and image files, input movie details, and submit the form to publish the movie, with validation and error handling, using React and Wagmi libraries.

Now, update the file found in /frontend/app/pages/create/page.tsx with the codes below.

The changes made in this code compared to the original one are:

Imported the createMovie function from api.service and used it in the handleSubmit function to create a new movie.
Added the userId parameter to the createMovie function call, passing the user's address from the useAccount hook.
Updated the handleSubmit function to use toast.promise to handle the promise returned by createMovie.
Added error handling to the createMovie function call in the handleSubmit function.

These changes enable the form to submit movie data to the API and create a new movie entry, while also handling errors and displaying a success message.

Edit Movie Page

This movie editing page allows authorized users to update movie details, upload posters and videos, and save changes, with validation and error handling, utilizing React, Wagmi, and Next.js, specifically designed for users to edit their movies.

Now, update the file found in /frontend/app/pages/movies/edit/[slug]/page.tsx with the codes below.

The upgrades made to the code that is different from the original are:

Imported fetchMovie and updateMovie functions from @/app/services/api.service and used them in the useEffect hook and handleSubmit function, respectively.
Replaced the posters.find() method with the fetchMovie function to retrieve movie data.
Updated the handleSubmit function to call the updateMovie function with the updated movie details.
Added error handling to the updateMovie function call in the handleSubmit function.

These changes enable our application to interact with our API endpoints to retrieve and update movie data, whereas the original code relied on our local posters array.

Home Page

This home page renders the banners component, a list of movies (either from an API source or a loading UI), and subscription options, utilizing React and Next.js, to provide an engaging and informative landing page for users.

Update the file found in /frontend/app/pages/page.tsx with the following codes.

The changes we made to the home page are:

Imported fetchMovies function from ./services/api.service and used it in the useEffect hook to retrieve movie data from our API.
Replaced the local posters data with the fetchMovies function call, which fetches data from our API.
Added await keyword to wait for the promise returned by fetchMovies to resolve before setting the movies state.

These changes help our application to retrieve movie data from our API instead of relying on local data, making the application more dynamic and data-driven.

User Account Page

This page displays a list of movies posted by the currently connected user, with a loading skeleton placeholder while the data is being fetched, and a message prompting the user to connect their account if they haven't done so, utilizing Wagmi, and react-loading-skeleton.

Update the file found in /frontend/app/pages/account/page.tsx with the following codes.

The changes made to the page are:

Imported fetchMovies function from @/app/services/api.service and used it in the useEffect hook to retrieve movie data from our API.
Replaced the local posters data with the fetchMovies function call, which fetches data from our API.
Passed address as an argument to the fetchMovies function to retrieve user-specific movie data.
Removed the conditional check for address before rendering the movie list, as the fetchMovies function now handles this logic.
Simplified the conditional statement for displaying the loading skeleton, as it now only depends on the loaded state.

These changes retrieve movie data from our API, specific to the connected user, and display a loading skeleton while the data is being fetched.

Movies Details Page

This page displays a single movie's details, including its name, release year, rating, duration, genre, and background information, along with a video player and related movies, and provides options to edit or delete the movie if the user is the owner, utilizing Next.js, and Wagmi.

Update the file found in /frontend/app/pages/movies/[slug]/page.tsx with the following codes.

We made some huge changes here! Here's a summary of what we did:

Imported deleteMovie, fetchMovie, and fetchMovies functions from @/app/services/api.service and used them to interact with our API endpoints.
Replaced local data with API calls to retrieve movie data.
Implemented movie deletion functionality using the deleteMovie function.
Used toast.promise to display a notification while deleting a movie.
Removed the posters local data and replaced it with API calls.
Updated the handleSubmit function to call the deleteMovie function and handle the response.
Updated the useEffect hook to call the fetchMovie and fetchMovies functions.

These changes cause our application to interact with our API to retrieve and delete movie data and display notifications to the user during the deletion process.

This part of the video below will show you hands-on how we integrated these pages with the endpoint, please feel free to watch that part if you run into any problem. Just make sure you stop at the 04:57:41 timestamp.

Application Components

Let’s discuss the purpose of each component in our application. We will update any component that needs to be modified.

Banner Component

This component displays a rotating background image of movie banners, cycling through an array of movie images every 5 seconds, creating a simple and automatic slideshow effect. This component code can be assessed at /frontend/app/components/home/Banner.tsx.

Posters Component

This component displays a responsive and interactive carousel of movie posters, using the Swiper library, with features like autoplay, pagination, and navigation, showcasing a list of movies passed as a prop, with a dynamic layout adapting to different screen sizes. This component code can be assessed at /frontend/app/components/home/Posters.tsx.

Poster UI Component

This component displays a placeholder skeleton layout for a movie posters section, using the react-loading-skeleton library, showing a dynamic number of skeleton posters based on the "posters" prop, with a responsive design adapting to different screen sizes, indicating a loading state until the actual posters data is fetched and displayed. This component code can be assessed at /frontend/app/components/home/PosterUI.tsx.

Subscriptions Component

This component displays a subscription plans section, showcasing various dummy plans with their details, prices, and benefits. It allows users to choose a plan that suits their needs, utilizing a responsive grid layout and interactive hover effects to enhance the user experience. This component code can be assessed at /frontend/app/components/home/Subscription.tsx.

Header Component

This component renders a fixed navigation bar at the top of the page, featuring a logo, a navigation menu with links to various sections, a menu toggle button for responsive design, and a login button, providing a consistent and accessible header section across the application. This component code can be assessed at /frontend/app/components/layout/Header.tsx.

Footer Component

This component renders a footer section at the bottom of the page, featuring the application's logo, a brief description, navigation links, contact information, and a credit mentioning the decentralized storage solution powered by Sia Foundation, providing a clear and organized footer section with relevant information and links. This component code can be assessed at /frontend/app/components/layout/Footer.tsx.

Menu Component

This component renders a responsive menu toggle button, which when clicked, opens or closes a dropdown menu containing navigation links, allowing users to access various sections of the application on smaller screens while hiding the menu on larger screens where the navigation links are already visible. This component code can be assessed at /frontend/app/components/shared/Menu.tsx.

Movie Card Component

This component displays a single movie's poster with a hover effect, showing additional information such as the movie's name, release year, and background summary, while also serving as a link to the movie's details page, utilizing a responsive design and animated transitions to enhance the user experience. This component code can be assessed at /frontend/app/components/shared/MovieCard.tsx.

Uploaded Component

This component displays a preview of an uploaded file, either an image or a video, with a progress bar and a removal button, allowing users to review and delete the uploaded file, while also providing a visually appealing and interactive interface with animations and hover effects. This component code can be assessed at /frontend/app/components/shared/Uploaded.tsx.

Uploader Component

This component provides a user interface for uploading files, specifically videos or posters, with features like drag-and-drop, file type validation, size limits, upload progress tracking, and success/error notifications, utilizing a combination of React state management, event handling, and API integration to handle the upload process.

Update the file found in /frontend/app/components/shared/uploader.tsx with the following codes.

The changes made to this component are:

Upload File Functionality: The original code didn't have the actual upload file functionality implemented. It only showed a success toast notification without uploading the file. This updated code includes the uploadFile function from api.service which handles the file upload.
Progress Tracking: The updated code tracks the upload progress and displays it on the UI.
Error Handling: The updated code includes error handling for the file upload process.
File Type Validation: The updated code uses a more robust file type validation using a regular expression.
Code Organization: The updated code is better organized, with separate functions for handling different tasks, making it easier to read and maintain.
UI Updates: The updated code includes some UI updates, such as showing the upload progress and a cancel button during upload.

This updated code is more complete and robust, with actual file upload functionality, progress tracking, error handling, and better code organization.

The video below explains what each component does in more detail, kindly check it out for your betterment.

And that is it guys, we have completed this project, and the last step we need to take is to launch this project on the browser. Run $ yarn build && yarn start to see the project live on the browser.

If you encounter any issues, refer to the following resources for troubleshooting, till next time, all the best!

About Author

I am a web3 developer and the founder of Dapp Mentors, a company that helps businesses and individuals build and launch decentralized applications. I have over 8 years of experience in the software industry, and I am passionate about using blockchain technology to create new and innovative applications. I run a YouTube channel called Dapp Mentors where I share tutorials and tips on web3 development, and I regularly post articles online about the latest trends in the blockchain space.

Build a Web3 Movie Streaming dApp using NextJs, Tailwind, and Sia Renterd: Part Two

Darlington Gospel — Fri, 23 Aug 2024 10:55:33 +0000

The Backend Service

Welcome Back! Please read through Part 1 if you haven't already. Now, let's dive into Part 2: Building the backend service for our web3 movie streaming platform.

We've provided a starter code for the backend, which currently displays a "Welcome" message when you start the server and visit http://localhost:9000 in your browser. Let's build on this foundation.

We currently have these codes in the source directory of the backend, and let me briefly explain them to you.

Utility Files
This folder which can be fully addressed to backend/src/utils contains two essential files, an HTTP exception handler function and an interface for handling file upload information.

This code defines a custom HttpException class that extends the built-in JavaScript Error class, allowing for the creation of error instances with specific HTTP status codes and messages.

This code defines an interface FileUpload that represents an uploaded file, specifying its properties such as name, data, size, encoding, and more, providing a structured way to handle file uploads in this backend application.

And then at backend/src root folder, we have this index.ts file which sets up an Express.js server with CORS and file upload support, defines a single GET route that returns a "Welcome" message, and handles errors by catching and re-throwing them as custom HttpExceptions, then starts the server on the port 9000 as specified in the environment variables.

Now that we've covered the key files, let's create two new files in a services folder, each serving a distinct purpose in our application.

Service Files

In the backend/src folder, make a new folder called services in this location, this is where we'll create two services:

Sia Service: Handles file uploads, downloads, streaming, and caching, communicating with the Renterd service.
Background Service: Manages cached files, automatically removing them after 7 days at midnight daily.

The Sia Service

Let’s create a file named sia.service.ts at the backend/src/services folder and follow the steps below to formulate this service.

This code defines a SiaService class that initializes with environment variables for Sia API settings and an origin URL, providing a foundation for managing interactions with the Sia service. Now, let's supply the rest of the codes for this service.

Uploading Files to Sia Renterd
To upload files to the Sia Network, we will need to add these three methods into the class, two will be private whereas one will be public.

This code defines a private method generateRandomString that generates a random string of a specified length, composed of uppercase and lowercase letters and numbers, using a loop to select characters randomly from a predefined string. We will use it to rename each file uniquely before shipping a file to Renterd.

The above code defines a private method uploadToSiaService that uploads a file to Sia Renterd using Axios, handling upload progress and errors, and returning the Axios response or throwing an error if the upload fails.

The Renterd endpoints are written in the API documentation which you can check out or watch the video below where I explained how the Sia Renterd API documentation.

Now let’s include the public method which we will later expose as an endpoint in our application.

This code defines a public method uploadFile that uploads a file by generating a unique identifier, saving the file to a local cache, and then uploading it to the Sia Renterd, returning the file's URL and a success message or throwing an error if the upload fails.

Downloading Files to Sia Renterd
To download files to the Sia Network, we will need to add these two methods into the class, one will be private and the other will be public.

This code defines a private method downloadFromSiaService that retrieves a file from the Sia service, caches it locally, and returns a readable stream of the file, handling errors and returning a 404 image if the file is not found.

Let’s have those response_files available in the backend directory, else we will experience an error calling the 404.png file. At the backend directory create another folder called response_files and copy the following images into it.

Perfect, now let’s complete this file download service, also add the method below in the SiaService class.

This code defines a public method downloadFile that calls the private method downloadFromSiaService to retrieve a file from the Sia Renterd and returns the readable stream of the retrieved file.

Service Endpoints

It's time we couple these various methods to their respective endpoints, currently, we have just one, but we will need an additional two for uploading and downloading files. File streaming will also utilize the download endpoint.

Head to the backend/src/index.ts file and update its content with these codes.

This code sets up an Express.js server with CORS and file upload support, defining three endpoints: a welcome message, file upload to the Sia Network, and file download from the Sia Network, using the SiaService class to handle file operations and HttpException for error handling.

Watch this section of the video below if you require some visual aid, ensure you stop at the 01:50:44 timestamp.

We need to create a cache management service to ensure our server doesn't fill up with unused files by controlling how long files stay in the cache. Its important to know that the only reason we needed this service is to reduce data latency.

The Background Service

Head to the backend/src/services folder and create a file called background.service.ts and add these sequences of code to it.

This code defines a BackgroundService class that sets up a cache directory and schedules daily jobs using the node-cron library, initializing the background jobs and logging a confirmation message. Let’s create a method that will be responsible for deleting files older than 7 days in the cache.

Deleting Old File
Add this method to the BackgroundService class.

This code defines a method called deleteOldFiles that removes files from a cache directory that are older than 7 days, by reading the directory, checking each file's creation time, removing files that exceed the target time, logging the start and end of the job, and any errors or successful deletions.

Now, let’s write a function that will utilize the node-cron package to schedule when to execute the file deletion.

This code sets up a daily cron job to run the deleteOldFiles method every day at midnight (00:00) to perform automatic file cleanup.

We also need to update the constructor function to schedule the daily Jobs at the instantiation of the background service class.

Perfect, lastly, let’s add this background operation as part of the server process at initialization. Head to the backend/src/index.ts file and update the app listener method and also importing the background service file.

You should rerun the backend service command using $ yarn build && yarn start and see a terminal printout like the one in the image below.

If you would rather watch how I coded the entire background service, the video below is for you, just ensure you stop at the 02:16:07 timestamp.

Next Step
Congratulations, you are now ready for the final part of this tutorial which is Part 3. If you encounter any issues, refer to the following resources for troubleshooting.

About Author

Build a Web3 Movie Streaming dApp using NextJs, Tailwind, and Sia Renterd: Part One

Darlington Gospel — Fri, 23 Aug 2024 10:47:23 +0000

Introduction

The web is evolving, and Web3 technologies are revolutionizing traditional industries, including video streaming. Platforms like Odysee are leading the charge, offering decentralized alternatives to YouTube and Rumble. Similarly, unlike legacy providers like Google Drive and Dropbox, Sia is transforming data storage, providing a privacy-focused and user-centric approach.

Join us on a journey to build a cutting-edge Web3 movie streaming dApp using NextJs, TypeScript, Tailwind CSS, and Sia Renterd. This tutorial series will guide you in creating a decentralized application that leverages Sia's blockchain technology to ensure user data ownership and privacy.

By the end of this tutorial, you'll gain the expertise to:

Build a fully functional movie streaming platform to share with friends or use as a school project
Launch your own SaaS (Software as a Service) application
Unlock the potential of Web3 technologies in the video streaming industry

Watch the demo video below to see the project in action and subscribe to our channel for more innovative content like this!

Prerequisites

To follow along, ensure you have the following tools installed, and familiarity with the stacks will also enhance your understanding:

NodeJs
NextJs
Tailwind CSS
TypeScript
Docker (required)

This three-part series will cover:

Part 1: Project Setup - Renterd Zen testnet, Package Installations, and environment variables.
Part 2: Backend Development - Building the Backend Service
Part 3: Frontend Development - Integrating the Frontend with the Backend service.

If you prefer watching the entire development process, I recommend watching this playlist, in the playlist, everything that is written here and more are captured in the videos.

With that said, let’s jump into setting up this project.

Project Setup

We'll start by cloning a prepared repository which includes the Sia Renterd docker compose script, the backend, and frontend services. Run the following commands:

$ git clone https://github.com/Daltonic/sia_vid_tv
$ cd sia_vid_tv

Now, it's crucial that we switch to our starter branch on this newly cloned GitHub project, and run the below command to have that done.

$ git checkout 01_starter_branch

Next, let’s set up the associated environment variable for this Renterd service. Create a .env file at the root of this project and apply the keys below:

RENTERD_SEED=<RENTERD_SEED_PHRASE>
RENTERD_API_PASSWORD=<YOUR_PREFERED_PASSWORD>
RENTERD_LOG_LEVEL=debug
RENTERD_LOG_DATABASE_LEVEL=error

To get these API keys you will need to have Sia Renterd installed on your machine, please watch this short video below, it pretty much summarizes it all.

Generate a seed phrase with the Renterd application as seen in the above video and include it inside your environment variable as instructed in the above video. Replace the password with something you can easily remember.

Next, we need to install Docker by downloading it from the official website if you haven't already. Alternatively, use a free online platform like Gitpod or a VPS to run a Docker instance, if possible. Otherwise, install it on your local computer.

Finally, we can spin up a docker container by running the following docker command at the root of this project, ensure that the terminal is at the same directory location as this docker-compose.yml file.

$ docker compose -f "docker-compose.yml" up -d --build

Note the command to pull down the container: $ docker compose -f "docker-compose.yml" down. Run this when you want to shut down your Docker instance (but not now).

If you performed the above instructions correctly, you should see the interface below when you visit your browser at http://localhost:9880.

Enter your password (from your environment variable) to log in. Then, follow the configuration procedure in the video below to set up your Sia Renterd instance for file uploads, downloads, and streaming.

The above video starts at the 6:41 minute mark, please stop at the 20:01 mark, this part will visually guide you through the Renterd configuration process.

Take note that the blockchain synchronization process along with host matching takes up to 25 min to be ready, so you will have to be patient with the whole process.

Please create a new bucket on Renterd called vidtv, where all our files for this project will be stored. if you have executed the above instructions successfully, your Renterd node should be ready for upload and download, see the image below.

Amazing, at this point, our Renterd service is now ready to start receiving files, but we need to communicate with it programmatically.

Let's round this part one of this tutorial by having the packages and environment variables set up as well for the Backend and Frontend.

Backend Project Setup
Perform the following instructions to have the backend service packages installed and ready for further development.

Navigate to the backend directory from a new terminal instance using the following commands:

$ cd backend
$ yarn install #you can also use npm install
$ touch .env #or mannually create it at the root of the backend directory

Next, supply the following information into the environment variables.

SIA_API_BUCKET=vidtv
SIA_API_PASSWORD=<YOUR_PREFERED_PASSWORD>
SIA_API_BASE_URL=http://localhost:9880
ORIGIN=http://localhost:9000
PORT=9000

And now, run $ yarn build && yarn start to spin up the backend and to also confirm that it's free from any bug.

Frontend Project Setup
Lastly, run the following commands to install the packages associated with the frontend, afterwards, we will run it.

Navigate to the backend directory from a new terminal instance using the following commands:

$ cd frontend
$ yarn install #you can also use npm install
$ touch .env #or mannually create it at the root of the backend directory

Next, supply the following information into the environment variables.

NEXT_PUBLIC_PROJECT_ID=<YOUR_WALLET_CONNECT_ID>
NEXT_PUBLIC_FILE_SERVICE_URL=http://localhost:9000

Sign up and create a project with Walletconnect to get your project ID. After you have supplied the project ID to the environment variable, run $ yarn build && yarn start to spin up the backend and to also confirm that it's free from any bug.

At this point, you will see the interface below when you visit the browser at http://localhost:3000.

Next Step
Congratulations on reaching this milestone! Proceed to Part 2 to complete the backend service development. If you encounter any issues, refer to the following resources for troubleshooting:

About Author

How to Learn Blockchain Development: A Step-by-Step Guide

Darlington Gospel — Wed, 10 Jul 2024 18:11:05 +0000

Hello there, and welcome to Dapp Mentors! I'm Darlington Gospel, and today, I want to share some insights on how to effectively learn blockchain development. Over the years, I've worked on numerous blockchain and smart contract projects, including a recent series on Solana. Now, let's dive into the essential steps for mastering blockchain development.

You can watch this entire breakdown on this YouTube video below, or else you can keep reading on.

Introduction

Blockchain development is not for the faint-hearted. It requires time, dedication, and a strategic approach. In this guide, I'll outline six critical steps to help you shorten your learning curve and achieve success in this field.

Step 1: Be Project-Oriented
From the outset, have a clear vision of what you want to build. Whether it's an NFT minting project, a decentralized application, or another blockchain project, your learning should be tied to achieving that specific goal. This focused approach will save you time and effort, preventing you from getting lost in irrelevant details.

Key Points

Define Your Goal: Determine what you want to build. It could be an NFT marketplace, a decentralized voting dApp, or any other blockchain-based solution.
Stay Focused: Concentrate on learning the skills and tools necessary to complete your specific project.
Avoid Distractions: Don't get sidetracked by unrelated blockchain technologies or programming languages that are not relevant to your project.

Example
If your goal is to create a crowdfunding platform on the blockchain, focus on learning Solidity for crowd-funding smart contract development, don’t go and learn Solidity programming language A to Z, if you do so, it will ensure you spend too much time in the wilderness.

Step 2: Break Your Project into Smaller Components
Breaking your project into smaller, manageable components reduces complexity and makes the learning process less overwhelming. Just like in React development, where you have distinct components like headers and cards, in blockchain development, you need to break down your project into clear, actionable parts.

Key Points

Identify Components: Determine the major parts of your project, such as the front-end interface, back-end logic, smart contracts, and integrations.
Divide and Conquer: Work on each component individually before integrating them into the final project.
Simplify: Simplifying complex tasks into smaller chunks makes the learning process more manageable and less daunting.

Example
For the crowdfunding platform, break down the project into:

Smart contract development for handling fund collection and distribution.
Front-end development for user interaction.
Back-end services for data management and user authentication.
Integration of front-end with smart contracts.

Step 3: Gather Information Strategically
Gathering information is crucial. Focus on learning what's necessary to achieve each component of your project. Avoid getting stuck in "tutorial hell," where you endlessly watch videos or read articles without applying the knowledge. Research specific solutions and apply them directly to your project.

Key Points

Focus on Relevance: Search for information specific to the components of your project.
Use Multiple Sources: Combine videos, articles, and tutorials to get a well-rounded understanding.
Stay Updated: Blockchain technology evolves rapidly, so ensure you’re learning from up-to-date sources.

Example
When learning Solidity, look for resources specifically on writing smart contracts for your current project, such as our crowdfunding project. Platforms like Udemy, Coursera, and developer communities like GitHub and Stack Overflow can be invaluable.

Step 4: Be Research-Driven
You'll encounter problems as you progress, and solving them requires extensive research. Be thorough and resourceful in your investigations. Relying solely on others for help can hinder your growth. Embrace the challenge and become adept at finding solutions independently.

Key Points

Investigate Issues: When faced with a problem, dive deep into research to find a solution.
Explore Widely: Look at different sources and perspectives to get a comprehensive understanding.
Learn Independently: Develop the ability to solve problems without always relying on others.

Example
If you encounter an issue with a smart contract function, research similar problems on forums, and ask an A. I assistant, read documentation, and experiment with different solutions in a test environment.

Step 5: Repeat the Process for All Components
Once you solve one component, move on to the next, repeating the process of gathering information, researching, and applying your knowledge. This iterative approach ensures that you comprehensively understand each part of your project.

Key Points

Iterate: Work through each component using the same methodical approach.
Refine: Continuously improve and refine each part as you progress.
Integrate: Once all components are developed, integrate them and test the full system.

Example
After developing and testing the smart contract for the crowdfunding platform, move on to the front-end, then the back-end, ensuring each component works perfectly before integrating them.

Step 6: Teach the Project
Teaching what you've learned solidifies your knowledge and enhances your mastery. Create tutorials, write articles, or produce videos explaining your project. Teaching reinforces your understanding and builds your visibility and credibility in the field.

Key Points

Reinforce Knowledge: Teaching helps solidify what you’ve learned.
Gain Visibility: Sharing your knowledge increases your visibility in the blockchain space.
Build Credibility: Demonstrating your expertise through teaching can quickly lead to new opportunities such as landing a new job.

Example
Create a technical YouTube video or write a technical blog tutorial demonstrating how to build a project, such as our example crowdfunding platform. Explain the challenges you faced and how you overcame them.

Check out our new Solana-based course on YouTube to learn how to Build a Token Sales Dapp with Solana, NextJs, Typescript, Tailwind CSS, Redux, and Phantom.

Conclusion

Learning blockchain development requires a strategic, project-oriented approach. By breaking your project into manageable components, gathering targeted information, and embracing research, you can master the necessary skills efficiently. Teaching your knowledge further reinforces your expertise and opens up new opportunities.
Stay tuned for more tutorials and insights on blockchain development. Until next time, keep learning and building!

About the Author
Darlington Gospel is a seasoned blockchain developer and educator with over 8 years of experience. He specializes in blockchain development, fullstack software development, technical instruction, and content creation.
We run a YouTube channel called Dapp Mentors where we share tutorials and tips on web3 development, and we regularly post articles online about the latest trends in the blockchain space.

About Dapp Mentors
Dapp Mentors is a community dedicated to helping developers transition into web3 development. Our team includes experienced blockchain developers and educators passionate about sharing their knowledge.

For more information, contact us at:
LinkedIn
Discord
X-twitter
YouTube
Website

Data-Driven Dapps Storage: Filecoin, Sia, & Arweave Compared

Darlington Gospel — Fri, 14 Jun 2024 12:12:46 +0000

Introduction

Welcome to Dapp Mentors! In this article, we'll explore decentralized blockchain storage networks, a crucial aspect of building decentralized applications (dApps). Unlike regular blockchain networks, which focus on financial transactions, decentralized storage networks store data files across a network of node providers, ensuring no single point of failure.

You can watch this entire breakdown on this YouTube video, or else you can keep reading on.

The Need for Decentralized Storage

Regular blockchain networks like Ethereum and Layer Two are expensive for storing large files, making decentralized storage networks a cost-effective solution. Decentralized storage networks like Filecoin, Sia, and Arweave offer cheap data storage, encryption, and permanency, making them ideal for dApp development.

Filecoin

Filecoin uses IPFS as a protocol for storing and sharing files and has been a pioneer in decentralized storage. I appreciate its storage capacity, which allows developers to store files on the network. The concept of miners, storage providers, and clients ensures that data is stored decentralized, making Filecoin a reliable option. However, data encryption is not built-in, and permanency is not guaranteed. Additionally, market volatility can impact storage costs.

Sia

Sia's renter-host model impresses me, as it ensures data encryption, compression, and chunking across multiple computers. This network's blockchain regulates data storage, making it a secure option. I appreciate Sia's object-like storage format, similar to AWS's S3 bucket, which makes it easy to understand and work with.

Arweave

Arweave boasts permanency, which sets it apart from other networks. The ability to store data forever without worrying about removal or inaccessibility is a game-changer. I appreciate Arweave's decentralized platform for building applications, which ensures data permanency. While Arweave does offer encryption tools, data encryption is not a built-in feature of the network. This network has the potential to revolutionize the way we build and store data in dApps.

Check out our new Solidity-based course on YouTube to learn about NFT development, breeding, and more.

Conclusion

In conclusion, decentralized blockchain storage networks like Filecoin, Sia, and Arweave offer a reliable and cost-effective solution for storing data in dApps. By understanding how these networks work, you can incorporate them into your decentralized applications and take advantage of their benefits. Remember to check out their documentation and explore how they can enhance your dApp development journey.

We run a YouTube channel called Dapp Mentors where we share tutorials and tips on web3 development, and we regularly post articles online about the latest trends in the blockchain space.

For more information, contact us at:
LinkedIn
Discord
X-twitter
YouTube
Website

Top Smart Contract Languages in 2024: Solidity, Rust, Motoko

Darlington Gospel — Wed, 05 Jun 2024 18:10:28 +0000

Welcome to Dapp Mentors! In this article, we'll delve into the top three programming languages for blockchain development: Solidity, Rust, and Motoko. As a seasoned blockchain developer and educator, I'll share my expertise to help you transition into web3 development.

You can watch this article as a video below or continue reading through it.

Solidity: The Favorite
Solidity is our top choice due to its simplicity, ease of use, and wide community support. It's the most widely used language for blockchain development, and its simplicity makes it an excellent choice for beginners. However, it has limitations:

Scalability: Solidity is not very scalable, especially on layer one. This limitation has led to the development of layer two solutions built on top of Ethereum.
Security: Solidity is not as secure as Rust. While it's widely adopted, its security vulnerabilities can be a concern.

In my opinion, Solidity is a great language for beginners, but its limitations make it less suitable for large-scale applications.

Top Companies Using Solidity

Ethereum
Binance Smart Chain
Polygon Network

Watch our video on "Building a Simple Smart Contract with Solidity" to learn more about how to implement Solidity in your blockchain projects!

Rust: The Secure and Scalable
Rust is a more mature language than Solidity, offering security and scalability. Its advantages include:

Security: Rust is a more secure language than Solidity, making it an excellent choice for high-stakes applications.
Scalability: Rust is highly scalable, making it suitable for large-scale blockchain applications.

In my opinion, Rust is a powerful language that offers a great balance between security and scalability, making it an excellent choice for large-scale blockchain applications.

Top Companies Using Rust

Solana
Polkadot
Stellar (uses Rust under the hood for their smart contract framework Soroban)

Motoko: The Newcomer
Motoko is exclusive to the Internet Computer Protocol (ICP) ecosystem. While it's highly scalable and performant, its adoption is limited, and it's relatively new. Its advantages include:

Scalability: Motoko is highly scalable, making it suitable for large-scale blockchain applications.
Ease of use: Motoko is easy to learn and use, even for developers new to blockchain development.

In my opinion, Motoko is a promising language that offers a unique set of features and advantages. Still, its limited adoption and exclusive nature make it less versatile than Solidity and Rust.

Conclusion
In conclusion, each language has its strengths and weaknesses. Solidity is simple and widely adopted, Rust offers security and scalability, and Motoko is unique to ICP. Consider learning Rust for its versatility across blockchain networks. Join the conversation and share your thoughts on your favorite programming language and why you prefer it.

Watch our video on "Getting Started with Blockchain Development" to learn more about our community and resources!

For more information, contact us at:
LinkedIn
Discord
X-twitter
YouTube
Website

How to Build a Web3 Events Marketplace with Next.js, Typescript, and Solidity

Darlington Gospel — Sun, 04 Feb 2024 14:52:41 +0000

What you will be building, see our git repo for the finished work and our live demo.

Introduction

Welcome to our comprehensive guide on "Building a Web3 Events Marketplace with Next.js, TypeScript, and Solidity". In this tutorial, we'll construct a decentralized Events Marketplace that harnesses the power of blockchain technology. You'll gain a clear understanding of the following:

Building dynamic interfaces with Next.js
Crafting Ethereum smart contracts with Solidity
Incorporating static type checking using TypeScript
Deploying and interacting with your smart contracts
Understanding the fundamentals of blockchain-based Events Marketplaces

By the end of this guide, you'll have a functioning decentralized platform where users can list and participate in events, with all transactions managed and secured by Ethereum smart contracts.

As an added incentive for participating in this tutorial, we're giving away a copy of our prestigious book on becoming an in-demand Solidity developer. This offer is free for the first 300 participants. For instructions on how to claim your copy, please watch the short video below.

Prerequisites

You will need the following tools installed to build along with me:

Node.js
Yarn
Git Bash
MetaMask
Next.js
Solidity
Redux Toolkit
Tailwind CSS

To set up MetaMask for this tutorial, please watch the instructional video below:

Once you have successfully completed the setup, you are eligible to receive a free copy of our book. To claim your book, please fill out the form to submit your proof-of-work.

Watch the following instructional videos to receive up to 3-months of free premium courses on Dapp Mentors Academy, including:

Join the Bitfinity ecosystem and be a part of the next generation of dApps. Apply your Bitfinity knowledge to create a Blockchain-based House Rental dApp in the final module. Deploy your smart contracts to the Bitfinity network and revolutionize the rental industry

With that said, let’s jump into the tutorial and set up our project.

Setup

We'll start by cloning a prepared frontend repository and setting up the environment variables. Run the following commands:

git clone https://github.com/Daltonic/dappEventX
cd dappEventX
yarn install
git checkout 01_no_redux

Next, create a .env file at the root of the project and include the following keys:

NEXT_PUBLIC_RPC_URL=http://127.0.0.1:8545
NEXT_PUBLIC_ALCHEMY_ID=<YOUR_ALCHEMY_PROJECT_ID>
NEXT_PUBLIC_PROJECT_ID=<WALLET_CONNECT_PROJECT_ID>
NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_SECRET=somereallysecretsecret

Replace <YOUR_ALCHEMY_PROJECT_ID> and <WALLET_CONNECT_PROJECT_ID> with your respective project IDs.

YOUR_ALCHEMY_PROJECT_ID: Get Key Here
WALLET_CONNECT_PROJECT_ID: Get Key Here

Finally, run yarn dev to start the project.

Our user interface is prepared to incorporate smart contracts, however, we still need to integrate Redux in order to facilitate the sharing of data.

Building the Redux Store

The above image represents the structure of our Redux store, it will be simple since we are not creating some overly complex project.

We'll set up Redux to manage our application's global state. Follow these steps:

Create a store folder at the project root.
Inside store, create two folders: actions and states.
Inside states, create a globalStates.ts file.

Inside actions, create a globalActions.ts file.

Create a globalSlices.ts file inside the store folder.

Create an index.ts file inside the store folder.

Update the pages/_app.tsx file with the Redux provider.

We have implemented Redux toolkit in our application and plan to revisit its usage when integrating the backend with the frontend.

Smart Contract Development

Next, we'll develop the smart contract for our platform:

Create a contracts folder at the project root.
Inside contracts, create a DappEventX.sol file and add the contract code below.

The above smart contract is designed to manage an Events Marketplace on the blockchain. It allows users to create, update, and delete events, buy tickets for events, and handle payouts. Here's a detailed breakdown of its functions:

Constructor (**constructor(uint256 _pct) ERC721('Event X', 'EVX')**): This function initializes the contract, sets the service fee percentage, and assigns initial token parameters.
createEvent Function: This function allows a user to create a new event. It requires the title, description, image URL, capacity, ticket cost, and start and end times. It validates all input data and creates a new event structure, which is stored in the events mapping.
updateEvent Function: This function allows a user to update an existing event. It requires the same parameters as the createEvent function. It checks that the event exists and that the caller is the owner of the event before updating the event data.
deleteEvent Function: This function allows the owner of an event to delete it. It checks that the event exists, that the caller is the owner of the event or the contract owner, and that the event has not been paid out or refunded. It then refunds all tickets for the event and marks the event as deleted.
getEvents Function: This function returns all existing events. It creates an array of the right size, then fills it with all events that have not been deleted.
getMyEvents Function: This function returns all events owned by the caller. It creates an array of the right size, then fills it with all events owned by the caller that have not been deleted.
getSingleEvent Function: This function returns a specific event. It simply returns the event structure from the events mapping.
buyTickets Function: This function allows a user to buy tickets for an event. It checks that the event exists, that the sent value is at least the total cost of the tickets, and that there are enough seats available. It then creates new ticket structures for each ticket and adds them to the tickets mapping.
getTickets Function: This function returns all tickets for a specific event. It simply returns the array of ticket structures from the tickets mapping.
refundTickets Function: This internal function refunds all tickets for a specific event. It marks each ticket as refunded, sends the ticket cost back to the ticket owner, and decreases the contract balance.
payout Function: This function handles payout distribution at the end of an event. It checks that the event exists, has not already been paid out, and is no longer ongoing. It then mints tickets for the event, calculates the revenue and fee, and sends the revenue minus the fee to the event owner and the fee to the contract owner. It marks the event as paid out and decreases the contract balance.
mintTickets Function: This internal function mints tickets for a specific event. It marks each ticket and the event as minted, and mints a new ERC721 token for each ticket.
payTo Function: This internal function sends funds to a specified address. It uses the low-level call function to send the funds and checks that the call was successful.
currentTime Function: This internal function returns the current timestamp. It uses the block.timestamp global variable, multiplies it by 1000, and adds 1000.

Contract Deployment and Seeding

Now, let's deploy our smart contract and populate it with some dummy data:

Create a scripts folder at the project root.
Inside scripts, create a deploy.js and a seed.js file and add the following codes.

Deploy Script

Seed

Run the following commands to deploy the contract and seed it with data:

yarn hardhat node # Run in terminal 1
yarn hardhat run scripts/deploy.js # Run in terminal 2
yarn hardhat run scripts/seed.js # Run in terminal 2

If you did that correctly, you should see a similar output like the one below:

At this point we can start the integration of our smart contract to our frontend.

Frontend Integration

First, create a services folder at the project root, and inside it, create a blockchain.tsx file. This file will contain functions to interact with our smart contract.

The above code is a service that interacts with a Events Marketplace contract. The service interacts with a smart contract deployed on the Ethereum blockchain using the ethers.js library.

Here's a detailed breakdown of its functions:

getEthereumContracts Function: This function sets up a connection to the Ethereum blockchain and the smart contract. It uses the ethers library to create a provider (to interact with the Ethereum blockchain) and a signer (to sign transactions). Then, it creates a contract instance that can be used to interact with the smart contract.
createEvent Function: This function creates a new event by calling the createEvent function of the contract.
updateEvent Function: This function updates an existing event by calling the updateEvent function of the contract.
deleteEvent Function: This function deletes an event by calling the deleteEvent function of the contract.
payout Function: This function handles payout distribution at the end of an event.
buyTicket Function: This function allows a user to buy tickets for an event.
getEvents and getMyEvents Functions: These functions retrieve information about all events or the events owned by the caller. They call the corresponding functions in the contract and structure the returned data.
getEvent Function: This function retrieves information about a specific event. It calls the corresponding function in the contract and structures the returned data.
getTickets Function: This function retrieves information about the tickets for a specific event. It calls the corresponding function in the contract and structures the returned data.
structuredEvent and structuredTicket Functions: These functions structure the data returned from the contract into a more manageable format. They convert the data types from the contract's format to JavaScript's format and sort the data.

Next, update the provider.tsx file inside services to include the bitfinity network using the following codes.

Page Interacting with Smart Contract

Next, we'll link the functions in the blockchain service to their respective interfaces in the frontend:

No 1: Displaying Available Events
Update pages/index.tsx to get data from the getEvents() function.

Take a moment and observe how we implemented the load more button, I bet you’ll find it useful.

No 2: Displaying User’s Events
Update pages/events/personal.tsx to get data from the getMyEvents() function.

No 3: Creating New Event
Update pages/events/create.tsx to use the createEvent() function for form submission..

No 4: Displaying Single Event
Update pages/events/[id].tsx to get data from the getEvent() and getTickets() functions.

No 5: Editing a Single Event
Change pages/events/edit/[id].tsx to retrieve data from the getEvent() and update by calling updateEvent().

No 6: Displaying Event Tickets
Update pages/events/tickets/[id].tsx to retrieve data from the getTickets() function.

Components with Smart Contract

Let's apply the same approach we used for the previous pages and update the following components to interact with the smart contract.

No 1: Purchasing Ticket
Update components/BuyTicket.tsx file to use the handleSubmit() function to call the buyTicket() function.

No 2: Deleting and Paying out Events
Lastly, update components/EventAction.tsx file to use the deleteEvent() and payout() functions.

It should be noted that this component is a dropdown and contains the relevant actions for managing a specific event.

All the components and pages of the project have been successfully connected to the smart contract, indicating the completion of the project after implementing these updates.

If your Next.js server was offline, you can bring it back up by executing the command yarn dev.

For further learning, we recommends subscribing to our YouTube channel and visiting our website for additional resources.

Conclusion

In this tutorial, we have successfully built a Web3 Events Marketplace using Next.js, TypeScript, and Solidity. We've established the development environment, constructed the Redux store, and deployed our smart contract to our local chain.

We've created dynamic interfaces, crafted Ethereum smart contracts, and managed shared data with Redux. By integrating the smart contract with the frontend, we've enabled users to list and participate in events, with transactions managed and secured by Ethereum smart contracts.

Now, you're equipped with the skills to build your own Web3 Events Marketplace. We've also provided you with a live demo and the finished work in our git repo for reference. Happy coding!

About Author

Stay connected with us, join communities on
Discord: Join
X-Twitter: Follow
LinkedIn: Connect
GitHub: Explore
Website: Visit

How to Build a Web3 Play-To-Earn Platform with Next.js, Typescript, and Solidity

Darlington Gospel — Sun, 28 Jan 2024 13:42:52 +0000

What you will be building, see our git repo for the finished work and our live demo.

Introduction

Welcome to our comprehensive guide on "Building a Web3 Play-To-Earn Platform with Next.js, Typescript, and Solidity". In this tutorial, we'll build a decentralized Play-To-Earn platform that leverages the power of blockchain technology. You'll gain a clear understanding of the following:

Building dynamic interfaces with Next.js
Crafting Ethereum smart contracts with Solidity
Incorporating static type checking using TypeScript
Deploying and interacting with your smart contracts
Understanding the fundamentals of blockchain-based Play-To-Earn platforms

By the end of this guide, you'll have a functioning decentralized platform where users can participate in Play-To-Earn games, with all activities managed and secured by Ethereum smart contracts.

Prerequisites

You will need the following tools installed to build along with me:

Node.js
Yarn
Git Bash
MetaMask
Next.js
Solidity
Redux Toolkit
Tailwind CSS

To set up MetaMask for this tutorial, please watch the instructional video below:

Once you have successfully completed the setup, you are eligible to receive a free copy of our book. To claim your book, please fill out the form to submit your proof-of-work.

Watch the following instructional videos to receive up to 3-months of free premium courses on Dapp Mentors Academy, including:

Ready to take your Bitfinity skills to the next level? Dive into the intricacies of smart contract development on ICP as you build a Ticketing Management System in the upcoming module. Create, deploy, and manage your smart contracts on the Bitfinity network.

With that said, let’s jump into the tutorial and set up our project.

Setup

We'll start by cloning a prepared frontend repository and setting up the environment variables. Run the following commands:

git clone https://github.com/Daltonic/play2earnX
cd play2earnX
yarn install
git checkout 01_no_redux

Next, create a .env file at the root of the project and include the following keys:

NEXT_PUBLIC_RPC_URL=http://127.0.0.1:8545
NEXT_PUBLIC_ALCHEMY_ID=<YOUR_ALCHEMY_PROJECT_ID>
NEXT_PUBLIC_PROJECT_ID=<WALLET_CONNECT_PROJECT_ID>
NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_SECRET=somereallysecretsecret

Replace <YOUR_ALCHEMY_PROJECT_ID> and <WALLET_CONNECT_PROJECT_ID> with your respective project IDs.

YOUR_ALCHEMY_PROJECT_ID: Get Key Here
WALLET_CONNECT_PROJECT_ID: Get Key Here

Finally, run yarn dev to start the project.

Our user interface is prepared to incorporate smart contracts, however, we still need to integrate Redux in order to facilitate the sharing of data.

Building the Redux Store

The above image represents the structure of our Redux store, it will be simple since we are not creating some overly complex project.

We'll set up Redux to manage our application's global state. Follow these steps:

Create a store folder at the project root.
Inside store, create two folders: actions and states.
Inside states, create a globalStates.ts file.

Inside actions, create a globalActions.ts file.

Create a globalSlices.ts file inside the store folder.

Create an index.ts file inside the store folder.

Update the pages/_app.tsx file with the Redux provider.

We have implemented Redux toolkit in our application and plan to revisit its usage when integrating the backend with the frontend.

Smart Contract Development

Next, we'll develop the smart contract for our platform:

Create a contracts folder at the project root.
Inside contracts, create a PlayToEarnX.sol file and add the contract code below.

The above smart contract is a Play-To-Earn (P2E) gaming platform, which is created with Solidity. The contract integrates features such as game creation, player invitations, score recording, and payout distribution.

Here's a breakdown of its logic, function by function:

Constructor (**constructor(uint256 _pct) ERC20('Play To Earn', 'P2E')**): This function initializes the contract. It sets the service fee percentage and assigns initial token parameters.
createGame Function: This function allows a user to create a new game, specifying the title, description, number of participants, number of winners, start date, and end date. It requires a stake greater than zero and validates all input data. A new game and score structure are created and stored in their respective mappings.
deleteGame Function: This function allows the owner of a game to delete it, provided no participants have joined. It refunds the stake to the game owner and marks the game as deleted.
playedSaved Function: This function is an internal function that creates a new player for a game. It increments the total players count, adds the new player to the players mapping, and increases the game's acceptees count.
invitePlayer Function: This function allows a user to invite another player to a game. It checks if the game exists and if there is room for more players. An invitation is then created and added to the invitationsOf mapping.
acceptInvitation Function: This function allows a user to accept an invitation to a game, provided they send enough funds to cover the game's stake. It creates a new player for the game and updates the invitation status.
rejectInvitation Function: This function allows a user to reject an invitation.
payout Function: This function handles the payout distribution at the end of a game. It checks if the game has ended and if it has not already been paid out. It calculates the total stakes, platform fee, creator fee, and game revenue. It pays out the platform fee to the contract owner, the creator fee to the game owner, and distributes the game revenue among the winners. It also mints new tokens for the winners.
sortScores Function: This function sorts players based on their scores. It uses a simple bubble sort algorithm with a twist: it also takes into account whether a player has played the game or not. Players who have not played are sorted to the bottom.
saveScore Function: This function allows a player to save their score for a game. It validates the game and player, then updates the player's score.
setFeePercent Function: This function allows the contract owner to change the service fee percentage.
getGames, getPaidOutGames, getMyGames Functions: These functions return lists of games based on different criteria (all games, games that have been paid out, and games owned by the caller).
getGame Function: This function returns the details of a specific game.
getInvitations Function: This function returns all invitations for a specific game.
getMyInvitations Function: This function returns all invitations received by the caller.
getScores Function: This function returns all scores for a specific game.
payTo Function: This internal function sends funds to a specified address.
currentTime Function: This internal function returns the current timestamp.

Contract Deployment and Seeding

Now, let's deploy our smart contract and populate it with some dummy data:

Create a scripts folder at the project root.
Inside scripts, create a deploy.js and a seed.js file and add the following codes.

Deploy Script

Seed

Run the following commands to deploy the contract and seed it with data:

yarn hardhat node # Run in terminal 1
yarn hardhat run scripts/deploy.js # Run in terminal 2
yarn hardhat run scripts/seed.js # Run in terminal 2

If you did that correctly, you should see a similar output like the one below:

At this point we can start the integration of our smart contract to our frontend.

Frontend Integration

First, create a services folder at the project root, and inside it, create a blockchain.tsx file. This file will contain functions to interact with our smart contract.

The above code is a service that interacts with our Play-To-Earn gaming smart contract on the chain. It uses the Ethers.js library to interact with the Ethereum blockchain for contract interaction.

Here's a detailed breakdown of its functions:

getEthereumContracts Function: This function sets up a connection to the Ethereum blockchain and the smart contract. It uses the ethers library to create a provider (to interact with the Ethereum blockchain) and a signer (to sign transactions). Then, it creates a contract instance that can be used to interact with the smart contract.
getOwner Function: This function retrieves the owner of the contract. It calls the owner function of the contract, which is defined in the OpenZeppelin's Ownable contract.
getGames, getMyGames, getGame Functions: These functions retrieve information about the games. They call the corresponding functions in the contract and structure the returned data.
getInvitations, getMyInvitations Functions: These functions retrieve information about the game invitations. They call the corresponding functions in the contract and structure the returned data.
getScores Function: This function retrieves scores of a game. It calls the corresponding function in the contract and structures the returned data.
createGame Function: This function creates a new game by calling the createGame function of the contract. It checks if the browser provider is installed and handles any errors that might occur.
deleteGame Function: This function deletes a game by calling the deleteGame function of the contract. It checks if the browser provider is installed and handles any errors that might occur.
invitePlayer Function: This function invites a player to a game by calling the invitePlayer function of the contract. It checks if the browser provider is installed and handles any errors that might occur.
saveScore Function: This function saves a player's score by calling the saveScore function of the contract. It checks if the browser provider is installed and handles any errors that might occur.
payout Function: This function handles payout distribution by calling the payout function of the contract. It checks if the browser provider is installed and handles any errors that might occur.
respondToInvite Function: This function allows a user to respond to an invitation by calling either the acceptInvitation or rejectInvitation function of the contract, based on the user's response. It checks if the browser provider is installed and handles any errors that might occur.
structuredGames, structuredInvitations, structuredScores Functions: These functions structure the data returned from the contract into a more manageable format. They convert the data types from the contract's format to JavaScript's format and sort the data.

Next, update the provider.tsx file inside services to include the bitfinity network using the following codes.

Page Interacting with Smart Contract

Next, we'll link the functions in the blockchain service to their respective interfaces in the frontend:

No 1: Displaying Available Games
Update pages/index.tsx to get data from the getGames() function.

No 2: Displaying User’s Games
Update pages/games.tsx to get data from the getMyGames() function.

Notice how we combined useEffect() to dispatch the games into the store before rendering on screen.

No 3: Displaying User’s Invitations
Update pages/invitations.tsx to get data from the getMyInvitations() function.

We also combined useEffect() to dispatch the invitations into the store before rendering on screen.

No 4: Displaying Game Invitations
Update pages/invitations/[id].tsx to use the getServerSideProps(), getGame(), and getInvitations() to retrieve a game invitations by specifying the game Id.

No 5: Showcasing a Gameplay
Update pages/gameplay/[id].tsx to use the getServerSideProps(), getGame(), and getScores() to retrieve a game players by specifying the game Id.

The script mentioned above is the core of the frontend code for this page. It contains the necessary functions and behaviors to create a memory game where users can compete against each other.

No 6: Displaying Game Result
Update pages/results/[id].tsx to use the getServerSideProps(), getGame(), and getScores() to retrieve a game score by specifying the game Id.

It's worth mentioning that users can make a payout from this page after the game duration has ended.

Components with Smart Contract

Let's apply the same approach we used for the previous pages and update the following components to interact with the smart contract.

No 1: Creating New Games
Update components/CreateGame.tsx file to use the handleGameCreation() function to call the createGame() function for form submission.

No 2: Handling Game Deletion
Update components/GameActions.tsx file to use the handleDelete() function to call the deleteGame() function.

No 3: Displaying Game Details Modal
Update components/GameDetails.tsx file to use the closeModal() function to call the setResultModal() function.

No 4: Inviting Players
Update components/GameInvitation.tsx file to use the handleResponse() function to call the respondToInvite() function.

No 5: Launching Game Details Modal
Update components/GameList.tsx file to use the openModal() function to call the setResultModal() function.

Please note that this setResultModal() function actually launches the game details modal, that’s a little oversight in function name.

No 6: Launching the Create Game Modal
Update components/Hero.tsx file to dispatch the setCreateModal() function, this will help us launch the create game form modal.

No 7: Launching the Invite Modal
Lastly, update components/InviteModal.tsx file to use the sendInvitation() function to call the invitePlayer() function.

The project is now complete as all components and pages are connected to the smart contract through the implementation of these updates.

If your Next.js server was offline, you can bring it back up by executing the command **yarn dev**.

For further learning, we recommends watch the full video of this build on our YouTube channel and visiting our website for additional resources.

Conclusion

In this tutorial, we've successfully built a decentralized Play-To-Earn platform using Next.js, TypeScript, and Solidity. We've established the development environment, constructed the Redux store, and deployed our smart contract to our local chain.

By merging the smart contract with the frontend, we've ensured a seamless gaming experience. This guide has equipped you with the skills to create dynamic interfaces, craft Ethereum smart contracts, manage shared data with Redux, and interact with smart contracts from the frontend. Now, you're ready to create your own Web3 Play-To-Earn platform. Happy coding!

About Author

Stay connected with us, join communities on
Discord: Join
X-Twitter: Follow
LinkedIn: Connect
GitHub: Explore
Website: Visit

How to Build a Decentralized House Rental Platform with Next.js, Redux, and Solidity

Darlington Gospel — Sun, 21 Jan 2024 08:57:15 +0000

What you will be building, see the live demo at Bitfinity test network and the git repo.

Introduction

Welcome to our second comprehensive guide on “Building a Decentralized House Rental Platform with Next.js, Redux, and Solidity”. We'll be developing a Decentralized House Rental Platform using Next.js, Solidity, and TypeScript. Throughout this tutorial, you'll gain a clear understanding of the following:

- Building dynamic interfaces with Next.js
- Crafting Ethereum smart contracts with Solidity
- Incorporating static type checking using TypeScript
- Deploying and interacting with your smart contracts
- Understanding the fundamentals of blockchain-based rental platforms

By the end of this guide, you will have a functioning decentralized platform where users can list and rent houses, all managed and secured by Ethereum smart contracts.

Prerequisites

You will need the following tools installed to build along with me:

Node.js
Yarn
Git Bash
MetaMask
Next.js
Solidity
Redux Toolkit
Tailwind CSS

To set up MetaMask for this tutorial, please watch the instructional video below:

Once you have successfully completed the setup, you are eligible to receive a free copy of our book. To claim your book, please fill out the form to submit your proof-of-work.

Watch the following instructional videos to receive up to 3-months of free premium courses on Dapp Mentors Academy, including:

Continue your Bitfinity journey by learning how to build easy Play-to-Earn dApps. Discover the potential of blockchain gaming in the next module. Dive deeper into Bitfinity and deploy your smart contracts to the network.

With that said, let’s jump into the tutorial and set up our project.

Setup

We'll start by cloning a prepared frontend repository and setting up the environment variables. Run the following commands:

git clone https://github.com/Daltonic/dappBnbX
cd dappBnbX
yarn install
git checkout no_redux

Next, create a .env file at the root of the project and include the following keys:

NEXT_PUBLIC_RPC_URL=http://127.0.0.1:8545
NEXT_PUBLIC_ALCHEMY_ID=<YOUR_ALCHEMY_PROJECT_ID>
NEXT_PUBLIC_PROJECT_ID=<WALLET_CONNECT_PROJECT_ID>
NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_SECRET=somereallysecretsecret

Replace <YOUR_ALCHEMY_PROJECT_ID> and <WALLET_CONNECT_PROJECT_ID> with your respective project IDs.

YOUR_ALCHEMY_PROJECT_ID: Get Key Here
WALLET_CONNECT_PROJECT_ID: Get Key Here

Finally, run yarn dev to start the project.

Our frontend is ready for smart contract integration, but we need to implement Redux to enable shared data space.

Building the Redux Store

The above image represents the structure of our Redux store, it will be simple since we are not creating some overly complex project.

We'll set up Redux to manage our application's global state. Follow these steps:

Create a store folder at the project root.
Inside store, create two folders: actions and states.
Inside states, create a globalStates.js file.

Inside actions, create a globalActions.js file.

Create a globalSlices.js file inside the store folder.

Create an index.js file inside the store folder.

Update the pages/_app.jsx file with the Redux provider.

We have implemented Redux toolkit in our application and plan to revisit its usage when integrating the backend with the frontend.

Smart Contract Development

Next, we'll develop the smart contract for our platform:

Create a contracts folder at the project root.
Inside contracts, create a DappBnb.sol file and add the contract code below.

The DappBnb contract represents a decentralized house rental platform where users can list apartments for rent, book available apartments, and leave reviews.

Let's go through each part of the contract:

Contract Setup and Libraries: The contract imports Ownable, Counters, and ReentrancyGuard from the OpenZeppelin library. Ownable provides basic authorization control functions, Counters is used for counting variables, and ReentrancyGuard helps prevent re-entrancy attacks.
Struct Definitions: The contract defines three structs: ApartmentStruct, BookingStruct, and ReviewStruct. These define the data structures for apartments, bookings, and reviews respectively.
State Variables: The contract declares several state variables, including security fees, tax percentages, and mappings to keep track of apartments, bookings, reviews, and other related data.
Constructor: The constructor function initializes the taxPercent and securityFee state variables.
Apartment Functions: Functions like createApartment, updateApartment, deleteApartment, getApartments, and getApartment are used to manage apartment listings on the platform.
Booking Functions: Functions like bookApartment, checkInApartment, claimFunds, refundBooking, getUnavailableDates, getBookings, getQualifiedReviewers, and getBooking are used to manage the booking process and interactions between tenants and apartment owners.
Review Functions: The addReview and getReviews functions manage the review process, allowing tenants to leave reviews for apartments they've booked.
Utility Functions: The payTo and currentTime functions are utility functions used in multiple other functions. payTo is used to transfer funds between addresses, and currentTime returns the current block timestamp.

Contract Deployment and Seeding

Now, let's deploy our smart contract and populate it with some dummy data:

Create a scripts folder at the project root.
Inside scripts, create a deploy.js and a seed.js file and add the following codes.

Deploy Script

Seed Script

Run the following commands to deploy the contract and seed it with data:

yarn hardhat node # Run in terminal 1
yarn hardhat run scripts/deploy.js # Run in terminal 2
yarn hardhat run scripts/seed.js # Run in terminal 2

If you did that correctly, you should see a similar output like the one below:

At this point we can start the integration of our smart contract to our frontend.

Frontend Integration

First, create a services folder at the project root, and inside it, create a blockchain.jsx file. This file will contain functions to interact with our smart contract.

The above script is a service that interacts with a smart contract deployed on the chain. In a joint effort with EthersJs, it provides functions to read and write data on the blockchain via the contract's methods.

Here's a breakdown of the functions:

getEthereumContracts: This function establishes a connection to the Ethereum network either through a browser provider (if available) or via a JSON-RPC endpoint. It then creates an instance of the smart contract using its ABI and address. If a user is connected via their wallet, the contract instance is linked to the user's account. Otherwise, a random account is generated and linked to the contract.
getApartments, getApartment: These functions fetch all apartments and a specific apartment respectively from the smart contract.
getBookings: Fetches all bookings for a specific apartment from the smart contract.
getQualifiedReviewers: Fetches all addresses that are qualified to leave reviews for a specific apartment.
getReviews: Fetches all reviews for a specific apartment from the smart contract.
getBookedDates: Fetches all dates that are booked for a specific apartment from the smart contract.
getSecurityFee: Fetches the security fee from the smart contract.
createApartment, updateApartment, deleteApartment: These functions allow a user to create, update, and delete apartments respectively.
bookApartment: This function allows a user to book an apartment for specific dates.
checkInApartment: This function allows a user to check into an apartment.
refundBooking: This function allows a user to get a refund for a booking.
addReview: This function allows a user to add a review for an apartment.

Update the provider.jsx file inside services to include the bitfinity network using the following codes.

Page Interacting with Smart Contract

Next, we'll link the functions in the blockchain service to their respective interfaces in the frontend:

No 1: Displaying Available Apartments
Update pages/index.jsx to get data from the getApartments() function.

No 2: Displaying Single Apartment
Update pages/room/[roomId].jsx to use the getServerSideProps(), getApartment(), getBookedDates() and the other functions to retrieve apartment and booking details by the room’s Id.

No 3: Creating New Apartments
Update pages/room/add.jsx to use the createApartment() function for form submission.

No 4: Editing Existing Apartments
Update pages/room/edit/[roomId].jsx to use the getApartment() function to retrieve apartment by Id and populate the form fields.

No 5: Displaying All Bookings
Update pages/bookings/roomId.jsx to get data from the getApartment() and getBookings() functions.

Components with Smart Contract

Like we did with the pages above, let’s Update the following components to interact with the smart contract:

No 1: Handling Apartment Deletion
Update components/Actions.jsx file to use the handleDelete() function to call the deleteApartment() functions.

No 2: Adding Reviews to Apartment
Update components/AddReview.jsx modal to use the handleSubmit() function to call the addReview() function.

Observe how Redux was used to open and close the review modal.

No 3: Adding Reviews to Apartment
Update components/Booking.jsx file to use the handleCheckIn() and handleRefund() functions.

No 4: Adding Reviews to Apartment
Lastly, update components/Calendar.jsx file to use the handleSubmit() function to call the bookApartment() function.

Also notice that we are using Redux to retrieve the security fee which is necessary to calculate the cost of booking an apartment.

The project is now complete as all components and pages are connected to the smart contract through the implementation of these updates.

If your Next.js server was offline, you can bring it back up by executing the command yarn dev.

For further learning, we recommends watch the full video of this build on our YouTube channel and visiting our website for additional resources.

Conclusion

In this tutorial, we've built a Decentralized House Rental Platform using Next.js, Redux, and Solidity. We set up the development environment, built the Redux store, and deployed the smart contract to the blockchain. By integrating the smart contract with the frontend, we created a seamless user experience.

Throughout the tutorial, you gained valuable skills in building Web3 applications, crafting smart contracts, and incorporating static type checking. You also learned how to use Redux for shared data space and interact with smart contracts from the frontend.

Now, you're ready to create your own Decentralized House Rental Platform. Happy coding and unleash your innovation in the world of Web3!

About Author

Stay connected with us, join communities on
Discord: Join
X-Twitter: Follow
LinkedIn: Connect
GitHub: Explore
Website: Visit