1. What Is a Decentralised Application (DApp)?

A DApp is a composite system where the core business logic is executed by smart contracts on a decentralised network, while off-chain infrastructure provides complementary features such as storage, indexing, analytics, and UI delivery.

A typical DApp contains:

• On-chain components: smart contracts, state, events
• Off-chain components: UI, serverless functions, oracles, indexing services
• Wallet integration: signature flows, gas estimation, account abstraction
• Front-end logic: ABI encoding, provider interactions

A distinguishing feature of DApps is that users sign state transitions directly instead of interacting with a backend authority.

2. Designing Contract Architecture

Good smart contract architecture reduces gas, improves security, and minimises attack surfaces. A typical contract system is decomposed into:

• Core logic – essential state transitions
• Access control – Ownable, Role-based, or DAO-based governance
• Utility modules – libraries or helper functions
• External interfaces – ERC interfaces, oracle adapters, router contracts
• Proxy/upgrade layers (if applicable)

Example: Modular token architecture

A token contract may divide responsibilities into:

• ERC20 logic
• Mint/burn module
• Access control module
• Fee accounting module
• Upgradeable storage contract

Separation ensures that each module has a small, auditable surface area.

3. Contract-to-Contract Interaction

DApps frequently rely on interconnected smart contracts. Interactions occur through:

• Direct function calls
• Interface-based static calls
• Low-level call with ABI encoding
• delegatecall (proxy pattern)
• Events for off-chain triggers

3.1 Message Calls

A contract calls another contract using:

OtherContract(addr).method(arg1, arg2);

3.2 Delegatecall

Executes code in the context of the caller’s storage—critical for proxy patterns but dangerous if misconfigured.

3.3 Interfaces

Interfaces enable safe static typing:

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
}
    

4. Contract State Machines and Data Flow

Most production-grade smart contracts operate as explicit or implicit state machines. For example:

• Escrow: Created → Funded → Released or Refunded
• DAO voting: Active → Passed/Rejected → Executed
• AMM: Pool initialised → Swaps → Liquidity adjustments

State machines ensure that illegal transitions cannot occur.

4.1 Updating State

Typical update sequence:

• Verify input
• Check invariants
• Adjust storage
• Emit events
• Interact with external contracts

4.2 Event-driven architecture

DApps rely heavily on events for:

• Front-end updates
• Indexing
• Notification systems

5. Deployment Pipeline: From Source to On-chain Contract

Deploying a smart contract involves multiple steps:

1. Write Solidity code
2. Compile to bytecode
3. Prepare constructor arguments
4. Create deployment transaction
5. Broadcast and wait for mining
6. Verify the contract (Etherscan/verifier)

Deployment frameworks like Hardhat, Foundry, or Truffle automate large parts of this workflow.

5.1 Deployment Considerations

• Gas cost estimation
• Constructor logic
• Initial parameters and admin keys
• Proxy vs non-proxy deployment

6. Testing Frameworks, Simulation & Invariant Checking

Professional smart contract engineering requires rigorous testing. Test categories include:

• Unit tests: direct function-level behaviour
• Integration tests: multi-contract interactions
• Fork tests: simulate mainnet environment using live state
• Invariant tests: ensure mathematical and logical invariants never break
• Property-based tests: fuzzing with randomized inputs

Hardhat, Foundry, and Brownie offer comprehensive ecosystems for testing with mainnet forking, gas analysis, and automated scripting.

7. Off-chain Components, Oracles & Data Feeds

Smart contracts cannot access off-chain data directly. Oracles bridge this gap through:

• Push-based oracles: external agents write data to contracts
• Pull-based oracles: contracts request data when needed
• Hybrid oracles: multi-layer verification with consensus

7.1 Examples of Oracle Use Cases

• Price feeds for lending protocols
• Randomness for gaming/lotteries
• Weather or event data for insurance

7.2 Oracle Risks

• Price manipulation
• Front-running
• Dependency risk

Many DeFi failures stem directly from oracle misconfiguration or insufficient redundancy.

8. Front-end Integration, Web3 Providers & ABI Interaction

DApps use wallet providers (MetaMask, WalletConnect, Phantom, etc.) to interact with contracts. The front-end typically performs:

• ABI loading
• Contract instantiation
• Read calls (no gas)
• Write transactions (signed by users)
• Error decoding

8.1 Provider and Signer Concepts

Providers read blockchain data; signers send transactions.

8.2 User Flow

1. UI constructs transaction request
2. User signs with private key
3. Transaction submitted to network
4. DApp listens for events
5. UI updates reflect new on-chain state

9. Indexing Engines & Data Subgraphs

Most blockchain data is not query-friendly. Indexing engines transform contract events and state changes into queryable APIs.

9.1 The Graph Protocol

Developers define:

• Subgraph schema
• Mapping logic
• Event handlers

Resulting indexed data is accessible via GraphQL queries.

9.2 Custom Indexers

Some applications require custom processing pipelines using:

• Node.js backends
• Serverless functions
• Off-chain databases

10. DApp Architecture Patterns

Real-world DApps commonly follow certain architectural templates:

10.1 Monolithic Smart Contract

Single contract holding all logic. Simple but inflexible.

10.2 Modular Contract System

Logic separated into multiple contracts; easier to audit.

10.3 Proxy + Implementation Pattern

Enables upgradeability without changing user-facing address.

10.4 Hybrid On-chain / Off-chain Pattern

Heavy computation done off-chain; results verified on-chain.

10.5 Event-driven UI Pattern

Front-end relies entirely on contract events instead of polling state.

11. Upgradeability, Proxy Patterns & Storage Slots

The immutability of contracts introduces limitations. Proxy patterns overcome them by decoupling the storage location from the implementation logic.

11.1 Transparent Proxy Pattern

Admin-only upgrades; users cannot call admin functions.

11.2 UUPS Pattern

Upgrade logic lives in the implementation contract.

11.3 Storage Layout Consistency

Upgradeable contracts must maintain exact storage ordering to prevent corruption.

12. Gas Optimisation & Efficiency Techniques

• Minimise storage writes
• Use immutable variables when possible
• Pack storage variables
• Avoid unbounded loops
• Emit events for off-chain data instead of storing everything

Efficient contracts are cheaper, faster, and significantly more resistant to DoS attacks.

13. Common Attack Surfaces in DApps

Key vulnerabilities include:

• Re-entrancy
• Oracle manipulation
• Flash-loan attacks
• Access control misconfiguration
• Unchecked delegatecall
• Race conditions in event handling
• Front-end phishing or malicious signature requests

14. Putting It All Together: A Mini DApp Blueprint

Consider a decentralised crowdfunding application. Its architecture might include:

Smart Contracts

• Funding logic
• Campaign struct management
• Refund mechanisms
• Event emission for indexing

Off-chain Components

• Front-end UI
• Wallet integration
• Indexing service
• Notification system

This blueprint can be adapted for tokens, DAOs, marketplaces, lending protocols, and other smart contract systems.

15. Module Summary

This module developed an applied and architectural view of DApps. It covered system design, contract interaction patterns, storage models, deployment, testing, oracles, front-end integration, indexing engines, upgradeability, and common attack vectors.

In Module 4, we move to advanced DeFi smart contract engineering — AMMs, lending protocols, governance systems, and economic design patterns.