Three.js Example

Features	ReactJS	NextJS
Rendering	CSR (Client-Side)	SSR, SSG, ISR, CSR
SEO Optimization	No SEO (CSR)	SEO Friendly (SSR, SSG)
Routing	Manual (React Router)	File-based routing
Performance	Slower (CSR)	Faster with pre-rendering
API Handling	External APIs	Built-in API routes

`, etc.). * Allows embedding images, videos, and other media. * Forms the basis for web development. ### **2. CSS (Cascading Style Sheets)** **CSS** is used to style HTML elements and create visually appealing layouts. It controls **colors, fonts, spacing, animations, and responsiveness**. Example of basic CSS styles: ```css body { font-family: Arial, sans-serif; background-color: #f5f5f5; color: #333; text-align: center; } h1 { color: #007bff; } button { background-color: #28a745; color: white; padding: 10px 20px; border: none; cursor: pointer; } ``` **Key Features of CSS:** * Provides **selectors** (`class`, `id`, `element`). * Uses **flexbox** and **grid** for layouts. * Allows **animations and transitions**. * Supports **responsive design** using media queries. Example of a **responsive design** using media queries: ```css @media (max-width: 768px) { body { background-color: lightgray; } } ``` ### **3. JavaScript (JS)** JavaScript makes web pages **interactive and dynamic**. It is used for **handling events, making API calls, manipulating the DOM, and building complex applications**. Example of JavaScript in action: {% code fullWidth="false" %} ```javascript document.getElementById("btn").addEventListener("click", function() { alert("Button Clicked!"); }); ``` {% endcode %} **Key Features of JavaScript:** * **Manipulates the DOM** (`document.querySelector`, `getElementById`). * Supports **event handling** (`click`, `hover`, `keydown`). * Enables **AJAX and Fetch API** for server communication. * Can be used for **building full-stack applications** with Node.js. Example of **fetching API data**: {% code overflow="wrap" %} ```javascript fetch("https://jsonplaceholder.typicode.com/posts/1") .then(response => response.json()) .then(data => console.log(data)); ``` {% endcode %} ### **4. Tailwind CSS – Utility-First Framework** Tailwind CSS is a **utility-first CSS framework** that provides predefined classes for rapid development. It allows developers to **style directly in the HTML** instead of writing custom CSS. Example of a Tailwind CSS button: ```html ``` **Key Features of Tailwind CSS:** * Uses **utility classes** instead of writing custom CSS. * Provides **responsive design utilities** (`sm:`, `md:`, `lg:`, etc.). * Supports **dark mode** and **custom themes**. * Reduces **CSS file size** with built-in PurgeCSS. Example of a **responsive Tailwind grid layout**: ```html

Box 1

Box 2

Box 3

``` **Best for:** Rapid UI development, modern design systems, and lightweight projects. ### **5. Bootstrap – Responsive UI Framework** Bootstrap is a **popular CSS framework** that provides **pre-built components** and a **responsive grid system**. It simplifies the process of designing mobile-friendly websites. Example of a **Bootstrap button**: ```html ``` **Key Features of Bootstrap:** * Comes with a **12-column grid system** for responsive layouts. * Provides **ready-to-use components** (buttons, modals, cards, etc.). * Includes built-in **JavaScript plugins** (`carousel`, `tooltip`, `modal`). * Offers **themes and customization** via SCSS variables. Example of a **Bootstrap responsive navbar**: ```html ``` **Best for:** Quick prototyping, enterprise applications, and cross-browser compatibility. ### Comparison: Tailwind CSS vs. Bootstrap

Features	Tailwind CSS	Bootstrap
Styling Approach	Utility-first	Pre-styled components
Customization	Highly customizable	Limited customization
File Size	Smaller (PurgeCSS)	Larger with built-in components
Responsiveness	Uses flexbox/grid utilities	Uses grid system and predefined classes
Ease of Use	Requires learning classes	Easier with prebuilt components

* **Use Tailwind CSS** for custom designs with better performance. * **Use Bootstrap** for quick prototyping and enterprise projects. # Material UI – The Ultimate React UI Framework ### **Introduction** **Material UI (MUI)** is a popular **React UI library** that provides ready-to-use, customizable components based on **Google’s Material Design** principles. It helps developers build **beautiful, responsive, and accessible** web applications quickly. ### **Why Use Material UI?** * **Pre-designed Components** – Buttons, Modals, Tables, Forms, etc. * **Customizable with Theme Support** – Easily change colors, typography, and styles. * **Fully Responsive** – Works on all screen sizes. * **Performance Optimized** – Uses JSS (CSS-in-JS) for efficient styling. * **Built-in Dark Mode** – Easy theming for dark/light mode. * **Accessibility (a11y) Ready** – Compliant with WCAG standards. ### **Installation** Install Material UI core library & icons: ```bash npm install @mui/material @emotion/react @emotion/styled npm install @mui/icons-material ``` ### **Basic Usage in a React Project** **Using a Material UI Button** ```javascript import React from "react"; import { Button } from "@mui/material"; function App() { return ( ); } export default App; ``` ### Core Components in Material UI | **Button** | Styled buttons with different variants | `` | | ---------- | -------------------------------------- | -------------------------------------------- | | **Typography** | Pre-styled text elements | `Heading` | | -------------- | ------------------------ | ----------------------------------------------- | | **Grid** | Responsive layout system | `...` | | -------- | ------------------------ | ---------------------------------------- | | **Card** | Material Design card component | `Content` | | -------- | ------------------------------ | ------------------------------------------------- | | **AppBar** | Navigation bar/header | `...` | | ---------- | --------------------- | ---------------------------------------- | | **Drawer** | Sidebar navigation menu | `...` | | ---------- | ----------------------- | ---------------------------------- | | **Table** | Display tabular data | `Data

` | | --------- | -------------------- | ----------------------------------------------------------------- | | **Dialog** | Pop-up modal for interactions | `` | | ---------- | ----------------------------- | ---------------------------------- | ### **Theming & Customization** **Applying a Custom Theme** ```javascript import { createTheme, ThemeProvider } from "@mui/material/styles"; const theme = createTheme({ palette: { primary: { main: "#1976d2", }, secondary: { main: "#ff4081", }, }, }); function App() { return ( ); } ``` ### **Responsive Design with Grid System** Material UI uses a **flexbox-based grid system**. ```javascript import { Grid, Paper } from "@mui/material"; function GridExample() { return ( Item 1 Item 2 ); } ``` **Breakpoints:** * `xs` → Extra small (mobile) * `sm` → Small (tablet) * `md` → Medium (laptops) * `lg` → Large (desktops) * `xl` → Extra-large screens ### **Icons in Material UI** **Import and Use Icons** ```javascript import { Home, Delete } from "@mui/icons-material"; function IconExample() { return ; } ``` **Common Icons:** * Home → `` * Delete → `` * Mail → `` * Search → `` * Folder → `` ### **Advanced Features in Material UI** #### **1. Dark Mode** ```javascript const darkTheme = createTheme({ palette: { mode: "dark", }, }); ``` 2. **Data Tables** ```javascript import { Table, TableRow, TableCell } from "@mui/material"; function DataTable() { return ( Name Age Alice 25

); } ``` 3. **Snackbar Notifications** ```javascript import { Snackbar } from "@mui/material"; function Notification() { return ( ); } ``` # ShadCN/UI – The Modern UI Library for React ### **Introduction** **ShadCN/UI** is a minimal yet highly customizable UI component library designed for **React** applications. Unlike traditional component libraries, it focuses on **local components**, meaning you **own** the components and can modify them as needed. It leverages **Tailwind CSS** and **Radix UI** primitives, making it perfect for modern web apps. ### **Why Choose ShadCN/UI?** * **No Vendor Lock-in** – The components are copied to your project, so you have **full control**. * **Fully Customizable** – Modify every part of the UI using **Tailwind CSS**. * **Minimal & Lightweight** – No unnecessary dependencies or bloat. * **Based on Radix UI** – Ensures **accessibility**, **performance**, and **UX best practices**. * **Supports Dark Mode** – Works with Tailwind’s `dark:` mode classes. * **TypeScript Support** – Provides full TypeScript support for safer development. ### **Installation** **Prerequisites:** Make sure you have **Next.js** and **Tailwind CSS** installed. **Step 1: Install ShadCN/UI CLI** ```bash npx shadcn-ui@latest init ``` **Step 2: Add a Component** ```bash npx shadcn-ui@latest add button ``` This command copies the **Button** component to your project inside `components/ui`. ### **Basic Usage** Once installed, you can use components **just like regular React components**. **Example: Using a Button** ```tsx import { Button } from "@/components/ui/button"; export default function Example() { return ; } ``` **Example: Customizing a Button** ```tsx ``` Since the components are in your project, you can modify them freely! ### Available Components | Component | Description | | --------------- | ------------------------------ | | Button | Customizable buttons | | Card | Flexible card layout | | Dialog | Pop-up modal for inter | | Dropdown | Custom dropdown menus | | Input | Styled input fields | | Checkbox | Custom checkboxes | | Tooltip | Small UI hints on hover | | Tab | Tabbed navigation | | Alert Dialog | Confirmation & warning dialogs | | Navigation Menu | Responsive navigation system | ### **Theming & Customization** **Modify Tailwind Theme** in `tailwind.config.js`: ```javascript module.exports = { theme: { extend: { colors: { primary: "#4F46E5", // Custom primary color }, }, }, }; ``` **Apply Custom Theme to Components**\ Since you own the components, just edit them directly! Example: ```tsx export function Button({ className, ...props }) { return ( ``` To add a new **variant**, edit the button component: ```tsx export function Button({ variant = "default", ...props }) { const variants = { default: "bg-primary text-white", outline: "border border-gray-300 text-black", destructive: "bg-red-500 text-white", }; return ; }; export default Button; ``` ### **3️⃣ Using TypeScript with Node.js (Backend)** **Install Required Packages** ```bash npm install express cors body-parser npm install --save-dev @types/node @types/express ``` Create a TypeScript Express Server ```typescript import express, { Request, Response } from "express"; const app = express(); const PORT = 3000; app.get("/", (req: Request, res: Response) => { res.send("Hello from TypeScript Express Server!"); }); app.listen(PORT, () => console.log(`Server running on port ${PORT}`)); ``` Run ```bash tsc && node dist/index.js ``` # Database {% hint style="info" %} **Good to know:** Storybook canvas embeds don't just work great for live components, you can also embed things like icons, or your color palette or typography tokens just as easily! {% endhint %} {% embed url="" %} *These examples are taken from the excellent* [Storybook Example Design System](https://5ccbc373887ca40020446347-geedzbiswp.chromatic.com/?path=/story/icon--labels)*.* # PostgreSQL **What is PostgreSQL?** PostgreSQL is a powerful, open-source, object-relational database management system (ORDBMS) known for its reliability, feature richness, and extensibility. It is widely used in both small and large-scale applications, providing ACID (Atomicity, Consistency, Isolation, Durability) compliance, advanced indexing, and support for structured and unstructured data. ### **Key Features of PostgreSQL** **1. ACID Compliance** Ensures reliable transactions, maintaining data integrity even during failures. **2. Extensibility** * Supports custom data types, operators, and functions. * Extensions like PostGIS for geospatial data. **3. Advanced Indexing** * B-Trees, Hash, GIN (Generalized Inverted Index), GiST (Generalized Search Tree). * Improves performance for searching and filtering. **4. JSON & NoSQL Support** * Supports **JSONB** format for efficient NoSQL-like storage. * Hybrid approach for relational and document-based data. **5. Full-Text Search** * Enables advanced searching capabilities with ranking and filtering. **6. High Availability & Scalability** * **Replication**: Streaming and logical replication. * **Partitioning**: Efficient data sharding for handling large datasets. **7. Stored Procedures & Functions** * Supports procedural languages like PL/pgSQL, PL/Python, and PL/Perl. * Automates complex logic directly in the database. **8. Security Features** * Role-based access control (RBAC). * Data encryption (SSL/TLS) and row-level security. ### **PostgreSQL Architecture Overview** A **typical PostgreSQL system architecture** consists of: 1. **Client Layer**: Applications (web, mobile, or desktop) that interact with the database via APIs or SQL queries. 2. **Query Processing Engine**: Parses, optimizes, and executes SQL queries. 3. **Storage Manager**: Manages data storage, indexing, and transactions. 4. **Write-Ahead Logging (WAL)**: Ensures durability by logging changes before applying them. 5. **Background Processes**: Handles vacuuming, checkpoints, and replication

### **Use Cases of PostgreSQL** * **Web Applications** – Used by companies like Instagram, Reddit, and Spotify. * **Data Warehousing** – Handles large-scale analytics and reporting. * **Geospatial Applications** – GIS systems with PostGIS extension. * **Finance & Banking** – Ensures transactional integrity and security. ### **Creating a User Table in PostgreSQL** To define a **user table**, you can use the following SQL statement: ```sql CREATE TABLE users ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), username VARCHAR(50) UNIQUE NOT NULL, email VARCHAR(100) UNIQUE NOT NULL, password TEXT NOT NULL, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW() ); ``` #### **Inserting Data** To insert a user into the table: ```sql INSERT INTO users (username, email, password) VALUES ('john_doe', 'john@example.com', crypt('securepassword', gen_salt('bf'))); ``` #### **Retrieving Users** To fetch all users: ```sql SELECT * FROM users; ``` #### **Updating a User** To update a user's email: ```sql UPDATE users SET email = 'newemail@example.com', updated_at = NOW() WHERE username = 'john_doe'; ``` #### **Deleting a User** To delete a user: ```sql DELETE FROM users WHERE username = 'john_doe'; ``` ### **Conclusion** PostgreSQL is a **versatile and robust** database that balances SQL and NoSQL features, making it ideal for **enterprise applications, data analytics, and large-scale distributed systems**. With its **advanced indexing, extensibility, and high availability**, PostgreSQL remains a top choice for developers and organizations worldwide. # MongoDB - NOSQL Database MongoDB is a **document-oriented NoSQL database** used for high-volume data storage. Instead of using tables and rows as in relational databases, MongoDB uses **collections and documents**. ### **Key Features of MongoDB** 1. **Schema-less** – No fixed structure, allowing flexibility. 2. **Scalability** – Horizontally scalable using **sharding**. 3. **High Performance** – Fast read and write operations. 4. **Replication** – Provides **high availability** using replica sets. 5. **Indexing** – Supports different types of indexes to improve query performance. 6. **Aggregation Framework** – Enables complex data transformations. ### **MongoDB Architecture** MongoDB follows a **distributed architecture** with multiple components: 1. **Client** – Applications interact with MongoDB using drivers. 2. **MongoDB Server** – Stores and manages the data. 3. **Replica Set** – Ensures **fault tolerance** and high availability. 4. **Sharded Cluster** – Enables horizontal scaling for large datasets. 5. **Config Servers** – Store metadata for sharded clusters. 6. **Mongos Router** – Distributes queries across shards.

### **Basic MongoDB Operations** **1. Creating a Database** ```javascript use myDatabase; ``` 2. Creating a Collection ```javascript db.createCollection("users"); ``` 3. Inserting a Document ```javascript db.users.insertOne({ name: "John Doe", email: "john@example.com", age: 28, created_at: new Date() }); ``` 4. Finding Documents ```javascript db.users.find({ age: { $gt: 25 } }); ``` 5. Updating a Document ```javascript db.users.updateOne( { email: "john@example.com" }, { $set: { age: 30 } } ); ``` 6. Deleting a Document ```javascript db.users.deleteOne({ email: "john@example.com" }); ``` ### **MongoDB Use Cases** * **Big Data Applications** * **Real-time Analytics** * **Internet of Things (IoT)** * **Content Management Systems** * **Mobile and Web Apps** # MySQL ### **Introduction** MySQL is an **open-source relational database management system (RDBMS)** that uses **Structured Query Language (SQL)** for managing and manipulating data. It is widely used for web applications, enterprise applications, and data-driven services. ### **Key Features of MySQL** 1. **Relational Database** – Stores data in tables with structured relationships. 2. **ACID Compliance** – Ensures reliability through transactions. 3. **High Performance** – Supports indexing, caching, and optimized queries. 4. **Scalability** – Works well with small and large-scale applications. 5. **Security** – Provides **user authentication, role-based access control (RBAC), and encryption**. 6. **Replication & High Availability** – Master-slave and master-master replication for failover support. 7. **Stored Procedures & Triggers** – Supports procedural programming within the database. ### **MySQL Architecture** The MySQL architecture consists of multiple components: 1. **Client Layer** – Applications communicate using MySQL drivers. 2. **SQL Parser & Optimizer** – Parses and optimizes queries for efficiency. 3. **Storage Engine Layer** – Manages how data is stored and retrieved. * **InnoDB** (default) – ACID-compliant, supports transactions. * **MyISAM** – Fast for read-heavy operations but lacks transactions. 4. **Buffer Pool & Query Cache** – Speeds up query execution. 5. **Replication & Clustering** – Provides **failover and load balancing**.

### **Basic MySQL Operations** #### **1. Creating a Database** ```sql CREATE DATABASE my_database; USE my_database; ``` 2. Creating a Table ```sql CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, email VARCHAR(100) UNIQUE NOT NULL, password VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); ``` 3. Inserting Data ```sql INSERT INTO users (username, email, password) VALUES ('john_doe', 'john@example.com', 'hashed_password'); ``` 4. Retrieving Data ```sql SELECT * FROM users WHERE email = 'john@example.com'; ``` 5. Updating Data ```sql UPDATE users SET password = 'new_hashed_password' WHERE username = 'john_doe'; ``` 6. Deleting Data ```sql DELETE FROM users WHERE username = 'john_doe'; ``` ### **MySQL Use Cases** * **Web Applications** – Used by Facebook, Twitter, and WordPress. * **E-Commerce Platforms** – Manages transactions, orders, and users. * **Enterprise Applications** – Suitable for CRM, ERP, and HR systems. * **Data Warehousing** – Stores structured data for reporting and analytics. # API # REST API * **Multiple Endpoints**: A REST API usually has different endpoints for different resources (e.g., `/users`, `/orders`). * **Fixed Data Structure**: The server determines the structure and amount of data returned, which can sometimes result in over-fetching or under-fetching. * **Predefined Responses**: Each endpoint returns a fixed set of data, and customizing the response requires modifying the endpoint or adding new one * **Less Flexible**: Clients typically receive a full resource representation, and changes to the data format may require updates to the server or API versioning. * **Multiple Requests**: Nested or related data often requires multiple API calls, potentially leading to performance inefficiencies. * **Versioning Required**: REST often uses versioning (e.g., `/api/v1/`) to manage changes and avoid breaking existing clients. This can lead to version sprawl over time. * **Separate Error Responses**: Errors are usually returned in different HTTP status codes (e.g., `404`, `500`), making it simpler but also less flexible in terms of combining partial data with errors. * **No Type System**: REST APIs do not inherently include a type system. JSON Schema or similar tools can be used, but they are not part of the REST standard. #### **REST API Example** * **Endpoint 1**: `/users/1` (to get user details) * **Endpoint 2**: `/users/1/posts` (to get the user's posts) 1. **Request 1 (Get user details)**: ```http GET /users/1 ``` **Response**: ```json { "id": 1, "name": "John Doe", "email": "john.doe@example.com" } ``` 2. **Request 2 (Get user's posts)**: ```http GET /users/1/posts ``` **Response**: ```json [ { "postId": 101, "title": "My first post", "content": "This is the content of my first post." }, { "postId": 102, "title": "Another day, another post", "content": "Here's some more content." } ] ``` # GraphQL API * **Single Endpoint**: A GraphQL API typically has a single endpoint through which all data is fetched. * **Client-Driven Queries**: The client specifies exactly what data it needs, which minimizes over-fetching (getting more data than needed) and under-fetching (not getting enough data). * **Structured Responses**: The response matches the request, allowing clients to shape the structure of the response to their needs. * **Nested Queries**: It supports complex nested data structures in a single request, which is useful for related data (e.g., querying a user and their posts). * **No Versioning**: GraphQL doesn’t require versioning because clients can request only the fields they need. As a result, new features can be added to an existing schema without breaking existing clients. * **Error Reporting**: GraphQL returns data and errors in the same response structure, so clients can still receive partial data when a non-fatal error occurs. * **Strongly Typed Schema**: GraphQL uses a type system to define the schema, so clients know what data and types are available. This can improve the development experience by enabling better tooling and validation. **Single Endpoint**: `/graphql` ```graphql query { user(id: 1) { id name email posts { postId title content } } } ``` Response: ```graphql { "data": { "user": { "id": 1, "name": "John Doe", "email": "john.doe@example.com", "posts": [ { "postId": 101, "title": "My first post", "content": "This is the content of my first post." }, { "postId": 102, "title": "Another day, another post", "content": "Here's some more content." } ] } } } ``` # RPC (Remote Procedure Call) ### **What is RPC?** RPC (Remote Procedure Call) is a protocol that allows a program to execute a procedure (function) on a remote server as if it were a local function. This enables distributed computing where different services interact seamlessly over a network. Unlike REST APIs, which are resource-based, RPC focuses on calling functions or procedures directly. ### **RPC Architecture and Workflow** #### **Architecture Components** 1. **Client** – Initiates the RPC request. 2. **Stub (Client-Side Proxy)** – Encodes the request and sends it over the network. 3. **Transport Layer (Network)** – Transfers the request to the remote system. 4. **Stub (Server-Side Proxy)** – Decodes the request. 5. **Server** – Executes the requested procedure and returns the response. ### **RPC Workflow** 1. **Client calls a function**: A client calls a remote function just like a local one. 2. **Marshalling (Serialization)**: The client stub serializes parameters. 3. **Network Communication**: The request is sent over the network. 4. **Server Processing**: * Server stub receives the request. * It deserializes (unmarshalls) the parameters. * The actual function is executed. 5. **Response Transmission**: * The server stub serializes the response and sends it back. * The client stub receives and deserializes the response. * The client receives the result as if it were a local function call. ### **Example: RPC API in gRPC (Google RPC with Protocol Buffers)** Let's build an RPC API using **gRPC** (a modern high-performance RPC framework developed by Google). #### **1. Define the RPC Service (Protocol Buffers)** We use **Protocol Buffers (protobuf)** to define the RPC methods and data structures. ```protobuf // calculator.proto syntax = "proto3"; service Calculator { rpc Add (AddRequest) returns (AddResponse); } message AddRequest { int32 a = 1; int32 b = 2; } message AddResponse { int32 result = 1; } ``` #### **2. Generate gRPC Code** After defining the `.proto` file, use the gRPC compiler (`protoc`) to generate client and server code in the desired programming language. ```sh protoc --go_out=. --go-grpc_out=. calculator.proto ``` #### **3. Implement the Server (Go)** The server implements the defined RPC methods. ```go package main import ( "context" "log" "net" "google.golang.org/grpc" pb "path/to/generated/calculatorpb" ) type server struct { pb.UnimplementedCalculatorServer } func (s *server) Add(ctx context.Context, req *pb.AddRequest) (*pb.AddResponse, error) { result := req.A + req.B return &pb.AddResponse{Result: result}, nil } func main() { lis, err := net.Listen("tcp", ":50051") if err != nil { log.Fatalf("Failed to listen: %v", err) } grpcServer := grpc.NewServer() pb.RegisterCalculatorServer(grpcServer, &server{}) log.Println("gRPC server running on port 50051") if err := grpcServer.Serve(lis); err != nil { log.Fatalf("Failed to serve: %v", err) } } ``` #### **4. Implement the Client (Go)** The client makes an RPC call to the server. ```go package main import ( "context" "log" "time" "google.golang.org/grpc" pb "path/to/generated/calculatorpb" ) func main() { conn, err := grpc.Dial("localhost:50051", grpc.WithInsecure()) if err != nil { log.Fatalf("Failed to connect: %v", err) } defer conn.Close() client := pb.NewCalculatorClient(conn) ctx, cancel := context.WithTimeout(context.Background(), time.Second) defer cancel() req := &pb.AddRequest{A: 10, B: 20} res, err := client.Add(ctx, req) if err != nil { log.Fatalf("Error calling Add: %v", err) } log.Printf("Addition Result: %d", res.Result) } ``` ### **Types of RPC** 1. **Synchronous RPC** – The client waits for a response before proceeding. 2. **Asynchronous RPC** – The client does not wait and continues execution, fetching the result later. 3. **Streaming RPC** – The client and server exchange multiple messages in a single RPC call (e.g., bidirectional streaming in gRPC). ### **Advantages of RPC** * **Simplicity** – Calls appear as local function calls. * **Performance** – More efficient than REST over HTTP (especially with gRPC). * **Streaming Support** – Enables real-time communication. * **Strongly Typed** – Enforces structured communication with Protocol Buffers. ### **Disadvantages of RPC** * **Tightly Coupled** – Client and server need shared interfaces. * **Complex Debugging** – More challenging than REST APIs. * **Language Constraints** – Requires language-specific bindings. ### **When to Use RPC?** * **Microservices Communication**: Efficient for service-to-service calls. * **Real-Time Applications**: Streaming capabilities make it ideal for real-time systems. * **High-Performance Systems**: Faster and lightweight compared to REST. ### **Conclusion** RPC APIs provide a powerful way to enable distributed computing with minimal overhead. Modern implementations like **gRPC** improve efficiency, making it a great choice for microservices and high-performance applications. 🚀 # WebSocket ### **What is WebSocket?** WebSocket is a communication protocol that provides **full-duplex**, **real-time** communication between a client and a server over a **single TCP connection**. Unlike traditional HTTP, which follows a **request-response** model, WebSockets enable continuous **bidirectional** communication, making them ideal for **chat applications, live notifications, gaming, and stock market updates**. ### **How WebSockets Work** 1. **Handshake** – The client sends an **HTTP request** to upgrade the connection to WebSocket. 2. **Connection Establishment** – The server accepts the request, and both establish a persistent WebSocket connection. 3. **Bidirectional Communication** – The client and server can now send messages anytime without waiting for a response. 4. **Connection Closure** – Either side can close the connection when needed. ### **WebSocket Architecture** * **Client** – A web browser or app initiating a WebSocket connection. * **WebSocket Server** – Manages connections and routes messages. * **Message Transport** – The WebSocket protocol sends messages over a single connection. ### **WebSocket Example (Node.js & JavaScript)** Let's create a **WebSocket server** and a **WebSocket client**. #### **1. Install WebSocket Library** Run the following command to install WebSocket support:. ```sh npm install ws ``` 2. Create a WebSocket Server (Node.js) ```javascript const WebSocket = require('ws'); const server = new WebSocket.Server({ port: 8080 }); server.on('connection', (socket) => { console.log('New client connected'); socket.on('message', (message) => { console.log(`Received: ${message}`); socket.send(`Server received: ${message}`); }); socket.on('close', () => { console.log('Client disconnected'); }); }); console.log('WebSocket server is running on ws://localhost:8080'); ``` 3. Create a WebSocket Client (Browser JavaScript) ```javascript const socket = new WebSocket('ws://localhost:8080'); socket.onopen = () => { console.log('Connected to WebSocket server'); socket.send('Hello, Server!'); }; socket.onmessage = (event) => { console.log(`Message from server: ${event.data}`); }; socket.onclose = () => { console.log('Disconnected from WebSocket server'); }; ``` ### WebSocket Events:

Event	Description
onopen	Triggered when the WebSocket connection is established.
onmessage	Triggered when a message is received from the server.
onerror	Triggered when an error occurs.
onclose	Triggered when the connection is closed.

### **WebSocket Use Cases** * **Live Chat Applications** – Instant messaging with real-time updates. * **Stock Market Feeds** – Live updates of stock prices. * **Online Gaming** – Multiplayer games with real-time interactions. * **Live Sports Scores** – Streaming real-time game updates. * **Collaboration Tools** – Google Docs-style real-time editing. ### **Disadvantages of WebSockets** * **Firewall Issues** – Some corporate networks block WebSocket connections. * **Scalability** – Managing multiple open WebSocket connections can be resource-intensive. * **Complexity** – More difficult to implement than traditional HTTP requests. ### **When to Use WebSockets?** * **Need real-time updates** (Chat apps, stock tickers, notifications). * **Frequent two-way communication** (Gaming, live streaming). * **Reduce latency** (Instant response without polling the server). ### **Conclusion** WebSockets provide an efficient, low-latency communication channel for real-time applications. They outperform HTTP when **continuous, bidirectional** data flow is required. # Solidity ### **What is Solidity?** Solidity is a high-level **programming language** specifically designed for writing **smart contracts** that run on **Ethereum and other EVM-compatible blockchains**. It is **statically typed**, meaning variables must have a fixed type, and it is influenced by languages like JavaScript, Python, and C++. Solidity enables developers to build **decentralized applications (dApps)** such as **DeFi protocols, NFTs, DAOs, and token contracts**. ## **Solidity Architecture & Workflow** Solidity follows a well-structured **Ethereum-based architecture** that ensures security, transparency, and decentralization. #### **Architecture Diagram** Here’s how a Solidity smart contract interacts with the blockchain: ``` +------------------+ +------------------+ +--------------------+ | Solidity Code | -----> | EVM Bytecode | -----> | Ethereum Virtual | | (Smart Contract)| | (Compiled Code) | | Machine (EVM) | +------------------+ +------------------+ +--------------------+ | | | v v v +------------------+ +------------------+ +--------------------+ | Web3.js/Ethers.js| -----> | Ethereum Node | -----> | Blockchain Storage | +------------------+ +------------------+ +--------------------+ ``` ### **Solidity Workflow** 1. **Write a Smart Contract** in Solidity. 2. **Compile the contract** into EVM Bytecode using tools like **Solidity Compiler (solc)**. 3. **Deploy the contract** to the Ethereum blockchain using Web3.js, Ethers.js, or Hardhat. 4. **Interact with the contract** using a front-end dApp, a wallet like MetaMask, or scripts. ## **Example Solidity Smart Contract** Let's write a simple **"Hello World"** smart contract that allows users to set and get a message. #### **1. Create a Solidity Smart Contract** ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract HelloWorld { string private message; // Constructor sets the initial message constructor(string memory _message) { message = _message; } // Function to update the message function setMessage(string memory _newMessage) public { message = _newMessage; } // Function to retrieve the current message function getMessage() public view returns (string memory) { return message; } } ``` #### **2. Compile and Deploy the Contract** To deploy the contract, you can use **Hardhat, Remix, or Truffle**. **Using Remix (Easiest)** 1. Open Remix IDE. 2. Create a new Solidity file (`HelloWorld.sol`). 3. Paste the code and **Compile** it. 4. Deploy using **Injected Web3** (MetaMask). **Using Hardhat (More Advanced)** 1. **Install Hardhat** ```sh npm install --save-dev hardhat ``` 2. Create Hardhat Project: ```sh npx hardhat ``` 3. Compile and deploy the contract ```sh npx hardhat compile npx hardhat run scripts/deploy.js --network localhost ``` ## **Why Use Solidity Over Other Languages?** #### **1. Optimized for Smart Contracts** * Solidity is **purpose-built** for writing **Ethereum smart contracts**, unlike other languages like Python or JavaScript. #### 2. **EVM Compatibility** * Solidity is **designed to run on Ethereum Virtual Machine (EVM)**, making it the **best** choice for Ethereum-based dApps. #### 3. **Security-Oriented** * Solidity offers **features like modifiers, access control, and reentrancy guards** to prevent common vulnerabilities. #### 4. **Large Developer Community** * Solidity has **strong community support**, making it easier to find resources, audits, and libraries. #### 5. **Interoperability** * Solidity contracts can be **integrated with Web3.js, Ethers.js, and other blockchain tools**. ## **Where Solidity is Used?** * **DeFi (Decentralized Finance)** – Uniswap, Aave, Compound * **NFTs (Non-Fungible Tokens)** – OpenSea, CryptoPunks * **DAOs (Decentralized Autonomous Organizations)** – MakerDAO, Aragon * **Token Contracts** – ERC-20, ERC-721, ERC-1155 * **Gaming & Metaverse** – Axie Infinity, Decentraland # Layer 1 Blockchain # Ethereum # Solana # Bitcoin # Hyperledger # Binance # Avalanche # Cardano # Polkadot # Near Protocol # Algorand # TON (Telegram Open Network) # Optimistic Rollups (L2 on Ethereum) # Arbitrum # Base # Mantle # ZK-Rollups (L2 on Ethereum) # zkSync Era # Polygon zkEVM # Wallet Integration # Reown Appkit # Rainbow Walletkit # Web3 Modal # WalletConnect # Wagmi # Metamask & Safewallet SDKs # Web3 SDKs & API Providers # Alchemy # Moralis # QuickNode # BitQuery API & Stream # ThirdWeb # Infura # Li.Fi # 1Inch API # Uniswap API # OpenZeppelin # Web3 Middleware/ UX Infrastructure Platform # Biconomy # Pimlico # Alchemy AA # Safe (formerly Gnosis Safe) # ZeroDev # On Chain Trading Platform & Telegram Bot # Bullx # Wave Bot # GMGN # Shuriken # Magnum Trade # Trojan # Gemini # OpenAI # Llama 3 70B # Groq # MCP (Model Context Protocol) # A2A (Agent-to-Agent Protocol) # n8n # Pipedream # Zapier # Langchain # Livekit # Pipecat # ERCs & EIPs # ERC-20: The Standard for Fungible Tokens ### **Introduction** ERC-20 is the most widely used Ethereum token standard for **fungible tokens**, meaning each token is **identical** and **interchangeable** (e.g., USDT, DAI, LINK). It defines a set of rules that all Ethereum-based tokens must follow. ### **Architecture** An ERC-20 token smart contract includes: * **Balance Mapping:** Stores token balances for each address * **Total Supply:** Defines the total number of tokens created * **Transfer Mechanism:** Allows tokens to be sent between addresses * **Allowance Mechanism:** Enables third-party contracts to spend tokens on behalf of users ### Key Functions of ERC-20 | Function | Description | | --------------------------------------- | ---------------------------------------- | | totalSupply() | Returns total token supply | | balanceOf(address) | Returns the balance of an address | | transfer(address, uint256) | Transfers tokens to another address | | approve(address, uint256) | Allows a spender to use a set amount | | transferFrom(address, address, uint256) | Transfers tokens using the allowance | | allowance(address, address) | Checks how many tokens a spender can use | ### **Workflow of ERC-20 Transactions** 1. **Token Deployment:** The ERC-20 smart contract is deployed on Ethereum. 2. **Minting:** The contract owner mints tokens. 3. **Transfer:** Users can send tokens to other addresses using `transfer()`. 4. **Approval & Spending:** * User A calls `approve(spender, amount)`, allowing Spender to use a specific amount. * Spender calls `transferFrom(userA, userB, amount)` to transfer the tokens. ### Example: ERC-20 Smart Contract ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract MyERC20Token { string public name = "MyToken"; string public symbol = "MTK"; uint8 public decimals = 18; uint256 public totalSupply = 1000000 * 10**18; mapping(address => uint256) public balanceOf; mapping(address => mapping(address => uint256)) public allowance; event Transfer(address indexed from, address indexed to, uint256 value); event Approval(address indexed owner, address indexed spender, uint256 value); constructor() { balanceOf[msg.sender] = totalSupply; } function transfer(address _to, uint256 _value) public returns (bool success) { require(balanceOf[msg.sender] >= _value, "Insufficient balance"); balanceOf[msg.sender] -= _value; balanceOf[_to] += _value; emit Transfer(msg.sender, _to, _value); return true; } function approve(address _spender, uint256 _value) public returns (bool success) { allowance[msg.sender][_spender] = _value; emit Approval(msg.sender, _spender, _value); return true; } function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) { require(balanceOf[_from] >= _value, "Insufficient balance"); require(allowance[_from][msg.sender] >= _value, "Allowance exceeded"); balanceOf[_from] -= _value; balanceOf[_to] += _value; allowance[_from][msg.sender] -= _value; emit Transfer(_from, _to, _value); return true; } } ``` ### ERC-20 Token Flow ```scss [ User A ] ---> (transfer 100 tokens) ---> [ User B ] [ DApp ] ---> (approve & transferFrom) ---> [ Marketplace ] ``` # ERC-721: The Standard for Non-Fungible Tokens (NFTs) ### **Introduction** ERC-721 is the standard for **non-fungible tokens (NFTs)**, meaning **each token is unique** and cannot be replaced (e.g., CryptoKitties, Bored Apes). ### **Architecture** An ERC-721 token smart contract includes: * **Token Ownership Mapping:** Each token has a unique `tokenId` linked to an address. * **Metadata Storage:** Stores information like name, image, and description. * **Transfer Functions:** Allows ownership to be transferred. ### **Key Functions of ERC-721** | Function | Description | | ------------------------------------------- | ---------------------------------------------- | | balanceOf(address) | Returns the number of NFTs owned by an address | | ownerOf(uint256 tokenId) | Returns the owner of a specific NFT | | transferFrom(address, address, uint256) | Transfers ownership of an NFT | | approve(address, uint256) | Approves another address to manage an NFT | | safeTransferFrom(address, address, uint256) | Ensures safe NFT transfer | ### **Workflow of ERC-721 Transactions** 1. **Minting:** A unique `tokenId` is created and assigned to an owner. 2. **Transfer:** The NFT can be transferred using `transferFrom()`. 3. **Approval & Marketplace Integration:** * The owner approves a marketplace contract to manage their NFT using `approve()`. * The marketplace can then transfer the NFT on behalf of the owner. ### Example: ERC-721 Smart Contract ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; contract MyNFT is ERC721URIStorage, Ownable { uint256 private _nextTokenId; constructor() ERC721("MyNFT", "MNFT") {} function mintNFT(address recipient, string memory tokenURI) public onlyOwner { uint256 tokenId = _nextTokenId; _nextTokenId++; _mint(recipient, tokenId); _setTokenURI(tokenId, tokenURI); } } ``` ### ERC-721 NFT Flow ```scss [ User A ] ---> (mint tokenId #1) ---> [ NFT Contract ] [ User A ] ---> (transfer tokenId #1) ---> [ User B ] [ Marketplace ] ---> (approve & transfer NFT) ---> [ Buyer ] ``` # ERC 4337 ### What is ERC-4337? ERC-4337 is an Ethereum standard that implements **account abstraction** without requiring changes to the core Ethereum protocol. Instead of relying on traditional **Externally Owned Accounts (EOAs)** controlled by private keys, users can operate through **smart contract wallets** with enhanced flexibility, security, and usability. ### **Why is ERC-4337 Important?** Traditionally, Ethereum has two types of accounts: 1. **Externally Owned Accounts (EOAs):** * Controlled by private keys (e.g., MetaMask, Ledger). * Only EOAs can sign transactions. * If the private key is lost, funds are permanently inaccessible. 2. **Smart Contract Accounts:** * Can include **custom logic** (multi-signature, social recovery, spending limits). * Require an EOA to initiate transactions, limiting usability. **ERC-4337 removes the dependency on EOAs, allowing transactions to be validated directly by smart contracts, enabling features like:**\ \- Multi-Factor Authentication\ \- Gas fee payment in **any** ERC-20 token\ \- Social recovery and key rotation\ \- Transaction batching ### **ERC-4337 Architecture Overview** #### ***Key Components of ERC-4337*** ERC-4337 introduces a **new mempool** and several key actors: 1. **User Operation (`UserOp`)** – A new transaction format sent to the network. 2. **Smart Contract Wallet** – A contract that verifies and executes transactions instead of a private key signing it. 3. **Bundler** – A specialized node that collects multiple UserOps and submits them as a single Ethereum transaction. 4. **EntryPoint Contract** – A singleton contract that ensures security and execution of transactions. 5. **Paymaster** – Allows gas fee abstraction (users can pay gas in stablecoins or get sponsorships). ### ERC-4337 Architecture Diagram ``` +-------------------------------------------------------+ | Ethereum Network | | (Settlement Layer) | +-------------------------------------------------------+ | | | | +------------+ +----------------+ | EntryPoint |<---[Executes]--| Bundler | | (Singleton SC)| | (Relayer) | +------------+ +----------------+ ^ | | [Validation & Execution] | +----------------+ +-----------------+ | Smart Contract | | Paymaster | | Wallet | | (Optional Gas | | (User Account) | | Sponsor) | +----------------+ +-----------------+ ^ | +---------------+ | UserOp | <---- Transaction sent by User +---------------+ ``` ### ERC-4337 Code Structure #### **1. Smart Contract Wallet (Minimal Implementation)** The smart contract wallet must be able to validate transactions **without relying on EOAs**. Below is a basic implementation of an **ERC-4337-compatible wallet**: ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; import "@openzeppelin/contracts/access/Ownable.sol"; import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol"; interface IEntryPoint { function handleOps(address user, bytes calldata txData) external; } contract ERC4337Wallet is Ownable { using ECDSA for bytes32; address public entryPoint; constructor(address _entryPoint) { entryPoint = _entryPoint; } function validateUserOp( bytes32 hash, bytes memory signature ) external view returns (bool) { address signer = hash.toEthSignedMessageHash().recover(signature); return signer == owner(); } function executeTransaction( address to, uint256 value, bytes calldata data ) external onlyOwner { (bool success, ) = to.call{value: value}(data); require(success, "Tx failed"); } } ``` **Key Features:**\ \- The wallet can validate **User Operations (UserOps)** via `validateUserOp()`.\ \- Allows execution of transactions without an EOA using `executeTransaction()`.\ \- Owner-based control using OpenZeppelin’s `Ownable`. 2. #### **EntryPoint Contract (Simplified Implementation)** The **EntryPoint** contract acts as a **security layer** that verifies UserOps before they are executed by the smart contract wallet. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract EntryPoint { mapping(address => bool) public authorizedWallets; function handleOps( address user, bytes calldata txData ) external { require(authorizedWallets[user], "Unauthorized wallet"); (bool success, ) = user.call(txData); require(success, "Tx failed"); } function registerWallet(address wallet) external { authorizedWallets[wallet] = true; } } ``` **Key Features:**\ \- Ensures only authorized wallets can send UserOps.\ \- Acts as a **universal validation layer**.\ \- Bundlers interact with this contract to process transactions. 3. #### **Bundler (Node that Collects Transactions)** Bundlers act like miners but **batch multiple UserOps into a single Ethereum transaction**. ```typescript import { ethers } from "ethers"; async function bundleTransactions(userOps) { const provider = new ethers.JsonRpcProvider("https://mainnet.infura.io/v3/YOUR_API_KEY"); const signer = new ethers.Wallet("YOUR_PRIVATE_KEY", provider); const entryPoint = new ethers.Contract( "ENTRYPOINT_CONTRACT_ADDRESS", ["function handleOps(address user, bytes txData)"], signer ); for (let op of userOps) { await entryPoint.handleOps(op.user, op.txData); } } bundleTransactions(userOps); ``` **Key Features:**\ \- Aggregates multiple UserOps into one transaction to **reduce fees**.\ \- Sends transactions via the `EntryPoint` contract. 4. #### **Paymaster (Gas Abstraction via ERC-20 Tokens)** Users can pay gas fees in **any ERC-20 token** via a **Paymaster contract**. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.20; interface IERC20 { function transferFrom(address from, address to, uint256 amount) external returns (bool); } contract Paymaster { address public token; address public relayer; constructor(address _token, address _relayer) { token = _token; relayer = _relayer; } function payForUserOp(address user, uint256 amount) external { IERC20(token).transferFrom(user, relayer, amount); } } ``` **Key Features:**\ \- Allows **gas sponsorship** (dApps can cover user gas fees).\ \- Users can pay fees in **USDT, DAI, or any ERC-20 token**. ### **Advantages** * **Improved UX:** No need to manage private keys directly. * **Gas Fee Flexibility:** Pay gas in any ERC-20 token. * **Multi-Factor Authentication (MFA):** Enhanced security. * **Social Recovery:** No risk of losing funds due to lost private keys. * **Transaction Batching:** Execute multiple transactions at once. ### **Disadvantages** * **Higher Gas Costs:** Smart contract wallets consume more gas than EOAs. * **Increased Complexity:** Requires new infrastructure (bundlers, paymasters). * **Adoption Hurdles:** dApps and wallets must integrate ERC-4337 support. # ERC 6551: Token Bound Accounts (TBA) ### **Basic Understanding** ERC-6551 allows NFTs to have associated smart contract accounts. These accounts can hold tokens, interact with decentralized applications (dApps), and execute transactions—just like a regular Ethereum account. Before ERC-6551, NFTs were static assets. With TBAs, an NFT can own ERC-20 tokens, other NFTs, or interact with DeFi protocols. **How it works:** 1. Each NFT gets an associated **Token Bound Account (TBA)**, which is a smart contract wallet. 2. The TBA is **linked to the NFT** and managed by the NFT's owner. 3. The NFT can **store tokens** or **execute on-chain actions**. ### **Use Cases** 1. **GameFi & Metaverse** * A game character NFT can hold in-game assets (weapons, potions, tokens). * When the character is sold, the new owner also gets the stored items. 2. **On-Chain Identity** * Users can own an NFT-based identity with on-chain history, achievements, and credentials. 3. **DAO & Governance** * An NFT membership card can hold voting power and interact with DAO governance contracts. 4. **DeFi & Financial Instruments** * NFT-backed loans: An NFT with a TBA can hold staked assets or act as collateral. 5. **Composable NFTs** * A fashion NFT (e.g., a digital avatar) can own wearable NFTs (clothing, accessories). ### **Advantages** * **NFTs Become Wallets** – NFTs can own assets, removing the need for separate wallets. * **Better Composability** – Enables richer interactions between NFTs and DeFi, DAOs, gaming. * **Improved Security** – Smart contract-controlled accounts reduce risks of external wallets. * **Gas Efficiency** – Reduces the need for multiple transactions to move assets. ### **Disadvantages** * **Smart Contract Complexity** – More complex than standard NFTs, requiring secure contract audits. * **Adoption Curve** – Wallets, marketplaces, and dApps need to support ERC-6551. * **Higher Gas Costs** – Deploying smart contract accounts for NFTs adds gas costs. ### **Architecture & Code Structure** #### **1. Key Components** * **ERC-721 NFT**: The main NFT that will have an associated wallet. * **Token Bound Account (TBA) Smart Contract**: A contract that acts as the NFT’s wallet. * **Registry Contract**: Deploys and manages TBAs for NFTs. 2. Diagram ``` +----------------------+ | ERC-721 NFT | | (e.g., Game Avatar) | +----------------------+ | | Links to TBA v +----------------------+ | Token Bound Account | | (Smart Contract) | +----------------------+ | | Can store tokens, interact with dApps v +----------------------+ | ERC-20, NFTs, dApps | | (Assets & Contracts)| +----------------------+ ``` #### **3. Code Structure** Here’s a basic implementation of an **ERC-6551 Token Bound Account**: **A. ERC-6551 Registry (Factory to deploy TBAs)** ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; interface IERC6551Registry { function createAccount( address implementation, uint256 chainId, address tokenContract, uint256 tokenId ) external returns (address); } contract ERC6551Registry { mapping(bytes32 => address) public accounts; function createAccount( address implementation, uint256 chainId, address tokenContract, uint256 tokenId ) external returns (address) { bytes32 salt = keccak256(abi.encodePacked(chainId, tokenContract, tokenId)); require(accounts[salt] == address(0), "Account already exists"); ERC6551Account account = new ERC6551Account(); accounts[salt] = address(account); return address(account); } } ``` **B. Token Bound Account (Smart Contract Wallet for NFT)** ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "@openzeppelin/contracts/access/Ownable.sol"; import "@openzeppelin/contracts/token/ERC721/IERC721.sol"; contract ERC6551Account is Ownable { event Executed(address target, uint256 value, bytes data); constructor() { transferOwnership(msg.sender); } function execute(address target, uint256 value, bytes calldata data) external onlyOwner { (bool success, ) = target.call{value: value}(data); require(success, "Execution failed"); emit Executed(target, value, data); } receive() external payable {} // Accept Ether } ``` **C. NFT Contract (Uses ERC-6551)** ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; import "@openzeppelin/contracts/access/Ownable.sol"; contract MyNFT is ERC721URIStorage, Ownable { IERC6551Registry public registry; address public implementation; constructor(address _registry, address _implementation) ERC721("MyNFT", "MNFT") { registry = IERC6551Registry(_registry); implementation = _implementation; } function mint(address to, uint256 tokenId, string memory tokenURI) public onlyOwner { _mint(to, tokenId); _setTokenURI(tokenId, tokenURI); // Create Token Bound Account for NFT registry.createAccount(implementation, block.chainid, address(this), tokenId); } } ``` # ERC 7702 EIP-7702 is a proposal aimed at enhancing Ethereum's account abstraction by allowing Externally Owned Accounts (EOAs) to temporarily function as smart contract accounts. This capability enables EOAs to have both code and storage, unlocking features such as transaction batching, gas sponsorship, and delegated actions. ### **How It Works** EIP-7702 introduces a new transaction type called the "set code transaction," which allows an EOA to temporarily adopt the code of an existing smart contract. The EOA owner signs an authorization that specifies the desired contract code, and this authorization can be submitted by anyone as part of the new transaction type. The code remains valid until replaced by another authorization, and the authorization can be chain-specific or applicable across multiple chains. A sample transaction payload in EIP-7702 is structured as follows: ``` rlp([ chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [ [contract_code, y_parity, r, s], ... ], signature_y_parity, signature_r, signature_s ]) ``` In this structure, the `contract_code` is added to the signing address before the transaction begins and removed after it ends. This allows the EOA to temporarily adopt the functionality of the specified contract code during the transaction's execution. ### **Use Cases** * **Transaction Batching**: EOAs can bundle multiple operations into a single transaction, reducing costs and improving efficiency. * **Gas Sponsorship**: Third parties can sponsor gas fees for EOAs, enabling users to interact with the blockchain without holding Ether. * **Delegated Actions**: EOAs can grant limited permissions to other addresses to act on their behalf, facilitating more flexible account management. ### **Architecture Diagram** While a specific architecture diagram is not provided in the sources, the following conceptual diagram illustrates the process: ``` +------------------+ +------------------+ | | | | | EOA Owner | | Smart Contract | | | | | +--------+---------+ +---------+--------+ | | | 1. Sign Authorization | | (Specifies Contract | | Code) | | | v | +--------+---------+ | | | | | Authorization | | | | | +--------+---------+ | | | | 2. Submit Authorization | | as Part of Set Code | | Transaction | | | v | +--------+---------+ | | | | | Ethereum | | | Network | | | | | +--------+---------+ | | | | 3. Temporarily Assign | | Contract Code to EOA | | | v | +--------+---------+ | | | | | EOA (Now | | | Functions as | | | Smart Contract)| | | | | +------------------+ | | | 4. Execute Transaction Utilizing | Smart Contract Functionality | | v +------------------+ | | | Transaction | | Execution | | | +------------------+ ``` ### **Coding Example** Below is a simplified example demonstrating how an EOA can temporarily adopt smart contract functionality using EIP-7702. In this scenario, the EOA sets its code to a simple contract that allows it to execute a specific function during the transaction. 1. **Define the Smart Contract Code** ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract TemporaryContract { address public owner; constructor() { owner = msg.sender; } function executeAction() external { require(msg.sender == owner, "Not authorized"); // Perform desired action } } ``` 2. **Sign the Authorization** The EOA owner signs an authorization that specifies the contract code (`TemporaryContract`) to be adopted during the transaction. 3. **Submit the Set Code Transaction** The signed authorization is submitted as part of the set code transaction, temporarily assigning the `TemporaryContract` code to the EOA. 4. **Execute the Desired Action** With the `TemporaryContract` code assigned, the EOA can now call the `executeAction` function within the same transaction. This process allows the EOA to temporarily function as a smart contract, enabling more complex interactions within a single transaction. ### **Security Considerations** Implementing EIP-7702 requires careful attention to security, particularly in the following areas: * **Secure Delegation**: Delegated contracts should implement replay protection mechanisms, such as nonces, to prevent unauthorized reuse of signatures. * **Transaction Propagation**: Allowing EOAs to behave as smart contracts introduces challenges in transaction propagation. Clients should be designed to handle scenarios where multiple transactions from the same EOA may become invalidated due to changes in delegation. * **Storage Management**: Changing an account's delegation is a security-critical operation. Developers must ensure that storage layouts are managed carefully to avoid accidental collisions during migrations from one delegate contract to another. For a comprehensive overview of security considerations, refer to the EIP-7702 proposal. EIP-7702 represents a significant advancement in Ethereum's account abstraction efforts, providing EOAs with enhanced capabilities to interact with the blockchain more flexibly and efficiently. # EIP 4844 (Proto-Danksharding) **EIP-4844**, also known as **Proto-Danksharding**, is a pivotal Ethereum upgrade that introduces a new transaction type called a **blob-carrying transaction**. It is designed specifically to improve **scalability for Layer 2 (L2) rollups** by drastically reducing the cost of **data availability** on Ethereum. Rollups already scale Ethereum by executing transactions off-chain and posting compressed data back to Ethereum Layer 1 for security. However, until now, this data has been posted as **calldata** — a permanent, costly form of storage that competes directly with regular transactions for block space. EIP-4844 changes this by introducing a new concept: **blobs**. ### What Are Blobs? **Blobs** (Binary Large Objects) are large chunks of data that are: * **Attached to special transactions** (blob-carrying txs) * **Much cheaper to store than calldata** * **Ephemeral**, meaning they are deleted from the network after \~2 weeks * **Not accessible to the EVM**, so they cannot be read or interacted with by smart contracts directly These characteristics make blobs ideal for rollups, which only need to publish data for a short time to maintain security and allow fraud or validity proofs to be verified. ### How Does It Work? #### 1. **Blob-Carrying Transactions** * A new transaction format includes up to 6 blobs. * These blobs are posted alongside the transaction, but not included in Ethereum’s permanent state. #### 2. **Data Availability & Verification** * To ensure the data is available (even if pruned later), Ethereum uses **KZG polynomial commitments**. * Validators do not need to download full blob data; they only verify **KZG commitments** and **proofs** to confirm the data was indeed posted. #### 3. **Fee Market for Blobs** * EIP-4844 introduces a **separate fee market** for blobs, using a mechanism similar to EIP-1559’s base fee adjustment. * This ensures blob pricing is decoupled from regular gas fees and can scale independently. ### Why It Matters: #### 1. Lower Costs for Rollups * Posting blob data is significantly cheaper than calldata — early benchmarks show **5–10x+ cost reduction**. * This leads to cheaper transactions on rollups like **Arbitrum, Optimism, zkSync, Scroll**, and others. 2. Higher Throughput * With cheaper data availability, rollups can batch more transactions more frequently, boosting TPS (transactions per second) dramatically. #### 3. Better UX at Scale * Lower fees and faster confirmations directly improve end-user experience, especially in high-traffic dApps and gaming, social, and DeFi protocols. ### What Comes Next: Toward Full Danksharding EIP-4844 is a **proto** implementation — it lays the groundwork for **full Danksharding**, Ethereum’s long-term sharding roadmap. Future upgrades will: * Introduce **more blob space per block** * Rely more heavily on **data availability sampling** and **stateless clients** * Decentralize the load by allowing validators to process only parts of the full data Proto-Danksharding is Ethereum’s way of getting real-world scalability gains **today**, without waiting years for full sharding to be completed. ### Conclusion EIP-4844 represents a significant evolution in Ethereum’s architecture — not just a patch, but a foundational shift toward **modular scalability**. By separating execution (L2s) from data availability (blobs), Ethereum strengthens its role as a **secure, decentralized base layer**, while enabling thousands of transactions per second via rollups. This upgrade moves Ethereum closer to its vision: a globally accessible, low-cost, high-throughput infrastructure for the next generation of decentralized applications. # Ethereum Pectra The Ethereum Pectra upgrade, a combination of the "Prague" (execution layer) and "Electra" (consensus layer) updates, is a significant advancement for the network, focusing on enhanced scalability, improved security, and a revolutionary user experience. It integrates a total of 11 Ethereum Improvement Proposals (EIPs), with several key ones driving its impact. Here's a breakdown of the technical details of some prominent EIPs included in Pectra: ### Key EIPs and Their Technical Implications: 1. **EIP-7702: Set EOA Account Code** * **Problem it Solves:** Traditionally, Ethereum has two account types: Externally Owned Accounts (EOAs), controlled by a private key, and Smart Contract Accounts (SCAs), controlled by their code logic. EOAs are simple but lack programmability (e.g., batching transactions, sponsored gas), while SCAs offer features but require users to migrate their identity to a new address. EIP-7702 bridges this gap. * **Mechanism:** This EIP introduces a new transaction type (0x04) that allows an EOA to *temporarily* attach executable code to a single transaction. This means an EOA can behave like a smart contract account *during that specific transaction's execution*. The EOA owner signs a special authorization message, which includes details like `chain_id`, `nonce`, `delegation_address`, and signature components. The protocol records this delegation at the network level. * **Technical Impact:** * **Transaction Batching:** Enables combining multiple operations (e.g., approve token and then swap) into a single atomic transaction, reducing gas costs and improving user experience. * **Gas Sponsorship/Abstraction:** Allows third parties (like dApps or "paymasters") to cover gas fees for users, or for users to pay fees in ERC-20 tokens instead of native ETH. * **Permission Management:** Users can create sub-keys with limited permissions (e.g., a key only able to interact with a specific dApp, or a key with daily spending limits). * **Protocol-Level Integration:** Unlike application-level solutions, EIP-7702's integration at the protocol layer is more gas-efficient, as it avoids the need for per-user contract deployments. * **Limitations:** The EOA's private key remains paramount and can always override any delegation. Delegations are temporary and can be overwritten. Chain-specific authorizations can pose challenges for multi-chain applications. 2. **EIP-7251: Increase the `MAX_EFFECTIVE_BALANCE`** * **Problem it Solves:** The previous maximum effective balance for an Ethereum validator was capped at 32 ETH. This led to large stakers running numerous 32 ETH validators, increasing the overall validator count and network overhead (e.g., P2P messages, BLS signature aggregation, BeaconState memory footprint). * **Mechanism:** This EIP raises the maximum effective balance per validator from 32 ETH to 2,048 ETH. The minimum staking requirement remains 32 ETH. It also introduces a "consolidation request" mechanism, defined as an EIP-7685 request with type `0x02`. This allows validators to merge multiple smaller validators into a larger one without going through the exit and activation queues. * **Technical Impact:** * **Reduced Validator Set Size:** Allows large stakers to consolidate their funds under fewer validators, significantly reducing the total number of active validators. * **Improved Network Efficiency:** Decreases the computational and communication load on the network due to fewer validators. * **Flexible Staking:** Enables solo stakers to compound their rewards more effectively and manage their stake in more flexible increments. * **Execution Layer Partial Withdrawals:** Integrates functionality from EIP-7002, allowing validators to trigger partial withdrawals from the execution layer, enabling more programmable staking workflows. 3. **EIP-7691: Blob Throughput Increase** * **Problem it Solves:** Building on the Dencun upgrade's EIP-4844 (Proto-Danksharding) which introduced "blobs" for Layer 2 rollup data, there was a need to further increase the data availability for these rollups to scale and reduce transaction costs. * **Mechanism:** This EIP increases Ethereum's *target* blob count per block from 3 to 6, and raises the *maximum* from 6 to 9. This effectively doubles the expected blob throughput. * **Technical Impact:** * **Lower Layer 2 Transaction Costs:** More available blob space directly translates to lower data costs for rollups, which in turn reduces transaction fees for users on Layer 2 networks. * **Enhanced Scalability:** Improves the overall data availability layer of Ethereum, making it more capable of supporting the scaling needs of Layer 2 solutions. 4. **EIP-6110: Supply Validator Deposits On-Chain** * **Problem it Solves:** Previously, validator deposits had to be relayed through the consensus layer, adding complexity and potential delays to the onboarding process. * **Mechanism:** This EIP moves validator deposits directly to the execution layer. * **Technical Impact:** * **Simpler Validator Onboarding:** Streamlines the process for new validators to join the network, making it more transparent and predictable. * **Cleaner EL-CL Separation:** Further improves the separation of concerns between the execution and consensus layers. 5. **EIP-7002: Execution Layer Triggerable Exits** * **Problem it Solves:** Validators previously relied solely on consensus-side mechanisms to exit the network, limiting programmatic control over their staking operations. * **Mechanism:** This EIP allows validators to trigger their own exits from the network via the execution layer. * **Technical Impact:** * **Increased Staking Flexibility:** Enables more advanced use cases for staking, such as smart contract-based staking managers or automated exit strategies. * **Improved Composability:** Lays the groundwork for more sophisticated validator services and integrations with other DeFi protocols. 6. **EIP-7547: Inclusion Lists** (Though the status is "Stagnant" as per some sources, it was under consideration for Pectra to enhance censorship resistance.) * **Potential Goal:** To allow proposers to specify a set of transactions that *must* be included in subsequent blocks, improving censorship resistance. * **Mechanism (Proposed):** A proposer for slot N could specify a list of transactions that *must* be included in the block produced for slot N+1. This would be broadcast as an "inclusion list" sidecar. * **Potential Technical Impact:** Empowering proposers to exert some control over transaction inclusion, mitigating potential censorship by block builders. Pectra represents a holistic approach to enhancing Ethereum, addressing both the core infrastructure of the consensus layer and the user-facing experience on the execution layer. The technical changes are designed to make Ethereum more robust, efficient, and accessible for a wider range of users and applications. # Blockchain Context Protocol Giving AI Agents a Native Interface to Blockchains **Version:** v1.0 Protocol Specification\ **Status:** Draft Standard\ **Author:** Anandi Sheladiya\ **Date:** July 2026 *** ## Abstract Blockchains expose state and execution through transaction-centric interfaces such as JSON-RPC. These interfaces are optimized for deterministic execution but are poorly suited for autonomous AI agents that operate using goals, constraints, and reasoning workflows. The **Blockchain Context Protocol (BCP)** proposes a standardized interface layer that allows AI agents to interact with blockchain systems using structured context, declarative intents, verifiable execution plans, and policy-based constraints. BCP introduces an agent-native interaction model that sits above existing blockchain execution standards such as ERC-4337, ERC-6900, and emerging agent authorization proposals. Rather than replacing transaction infrastructure, BCP introduces a reasoning and coordination layer enabling safe, explainable, and programmable agent behavior. *** ## 1. Introduction ### 1.1 Motivation Autonomous agents are increasingly performing tasks involving blockchain systems, including: * DeFi portfolio management * Automated trading and arbitrage * DAO governance participation * Treasury operations * Cross-chain asset routing * On-chain service orchestration Current blockchain interfaces require agents to: * Construct raw transactions * Query fragmented state across RPC endpoints * Rely on centralized indexers * Implement proprietary safety and simulation logic This results in: * Poor interoperability * Increased security risk * Limited explainability * High implementation complexity #### Problem Statement Blockchains lack a standardized **machine-readable context layer** suitable for AI-driven decision systems. *** ### 1.2 Design Goals BCP aims to: 1. Provide structured blockchain state for agent reasoning 2. Enable declarative intent-based execution 3. Introduce verifiable policy enforcement 4. Support multi-step execution planning 5. Provide execution proofs and explainability 6. Remain compatible with existing blockchain standards *** ## 2. Background ### 2.1 JSON-RPC Limitations JSON-RPC provides low-level transaction and state access. It assumes: * Caller already knows execution steps * Caller performs off-chain reasoning * Execution success is binary RPC lacks: * Semantic context * Policy frameworks * Intent abstraction * Execution planning primitives *** ### 2.2 Emerging Agent Infrastructure Several standards address agent execution primitives: | Standard | Role | | ------------------- | ----------------------------- | | ERC-4337 | Account abstraction | | ERC-6900 | Modular smart accounts | | ERC-8004 (proposed) | Trustless agent authorization | | Intent Protocols | Goal-based execution routing | BCP complements these standards by providing a **coordination interface**. *** ## 3. System Overview BCP introduces four primary components: #### 1. Context Layer Provides normalized blockchain state. #### 2. Intent Layer Defines goal-oriented agent requests. #### 3. Policy Layer Defines constraints and safety boundaries. #### 4. Execution Layer Plans and executes verifiable actions. *** ## 4. Architecture ``` +------------------------------------------------------+ | AI AGENT | | Planning • Reasoning • Learning | +-----------------------▲------------------------------+ | | +------------------------------------------------------+ | Blockchain Context Protocol (BCP) | | | | Context Engine → State Normalization | | Intent Engine → Goal Translation | | Policy Engine → Constraint Verification | | Execution Planner → Action Strategy | +-----------------------▲------------------------------+ | | +------------------------------------------------------+ | Smart Account / Agent Authorization | | ERC-4337 • ERC-6900 • ERC-8004 | +-----------------------▲------------------------------+ | | +------------------------------------------------------+ | BLOCKCHAIN | +------------------------------------------------------+ ``` *** ## 5. BCP Core Concepts *** ### 5.1 Context Object BCP defines standardized state objects. #### Example ```json { "account": { "address": "0xAgent", "balances": [ {"asset": "USDC", "amount": "5000"}, {"asset": "ETH", "amount": "2"} ], "positions": [ {"protocol": "Aave", "collateral": "ETH", "health": 1.8} ] }, "network": { "chain": "ethereum", "gas": 45 } } ``` *** ### 5.2 Intent Object Intents describe desired outcomes instead of transactions. ```json { "goal": "Optimize yield", "constraints": { "max_risk": "medium", "max_slippage": "0.5%" } } ``` *** ### 5.3 Policy Object Policies define enforceable execution rules. ```json { "rules": [ {"max_trade_size": "20%"}, {"allowed_protocols": ["Aave", "Uniswap"]} ] } ``` *** ### 5.4 Execution Plan Execution plans define multi-step strategies. ```json { "steps": [ {"action": "withdraw", "protocol": "Aave"}, {"action": "swap", "protocol": "Uniswap"} ] } ``` *** ## 6. Protocol Specification *** ## 6.1 BCP V0 — Minimal Interface V0 introduces basic primitives for agent execution. *** ### 6.1.1 Endpoints #### Context Query ``` GET /bcp/context/{account} ``` Returns normalized blockchain state. *** #### Intent Submission ``` POST /bcp/intent ``` Accepts declarative goal objects. *** #### Policy Validation ``` POST /bcp/policy/validate ``` Verifies constraints. *** #### Execution ``` POST /bcp/execute ``` Triggers execution via smart accounts. *** ### 6.1.2 Execution Flow ``` Agent → Request Context Agent → Generate Intent BCP → Validate Policy BCP → Generate Execution Plan Smart Account → Execute BCP → Return Proof ``` *** ## 6.2 BCP V1 — Advanced Agent Coordination V1 introduces: #### Multi-chain Context Aggregation Unified cross-chain state views. #### Simulation Engines Pre-execution state forecasting. #### Route Optimization MEV-aware execution planning. #### Intent Market Integration Third-party solver coordination. #### Proof Framework Cryptographic execution attestations. *** ## 7. Security Model BCP relies on multiple security layers: #### Authorization Delegation through trustless agent standards. #### Policy Enforcement Pre-execution rule validation. #### Simulation Risk forecasting and rollback prevention. #### Verifiable Proofs Execution attestation and auditability. *** ## 8. Interoperability BCP is designed to integrate with existing Ethereum standards. *** ### 8.1 ERC-4337 BCP execution plans are translated into UserOperations. *** ### 8.2 ERC-6900 BCP policies can be implemented as modular account extensions. *** ### 8.3 ERC-8004 (Proposed) Defines agent delegation and authorization. *** ## 9. Real-World Use Cases *** ### 9.1 Autonomous DeFi Portfolio Agents Agents rebalance assets based on risk-adjusted yield metrics. *** ### 9.2 DAO Governance Agents Agents vote according to predefined treasury policies. *** ### 9.3 Cross-Chain Payment Routing Agents optimize transaction routes across L2s and bridges. *** ### 9.4 On-chain Service Automation Agents subscribe, renew, and manage decentralized services. *** ## 10. Implementation Considerations *** ### 10.1 Off-chain BCP Providers Initial implementations may run as decentralized indexing and execution networks. *** ### 10.2 On-chain Policy Modules Policy engines can be deployed as verifiable smart contracts. *** ### 10.3 Standardization Path BCP may evolve through: * Ethereum Improvement Proposals * Open agent interoperability consortiums * Integration with AI model orchestration standards *** ## 11. Limitations * Requires standardized indexing infrastructure * Introduces additional coordination latency * Policy standardization remains unsolved * Cross-chain trust models need formal verification *** ## 12. Future Research Directions * ZK-based context verification * Intent auction markets * Agent reputation scoring * Autonomous policy learning * Decentralized execution solvers *** ## 13. Conclusion Blockchain Context Protocol introduces an agent-native interface for blockchain coordination. By shifting interaction from transaction construction to intent execution, BCP enables safer, more interoperable, and programmable agent ecosystems. BCP is not a replacement for blockchain execution standards. Instead, it represents a coordination layer enabling AI systems to safely reason about and operate within decentralized environments. # Blockchain Context Protocol Giving AI Agents a Native Interface to Blockchains Version: v1.0 Protocol Specification | Status: Draft Standard Author: Anandi Sheladiya — Independent Researcher\ Email: \ Date: July 2026 Also available as a preprint on [ResearchGate](https://www.researchgate.net/publication/408877989_Blockchain_Context_Protocol_Giving_AI_Agents_a_Native_Interface_to_Blockchains) (DOI: [10.13140/RG.2.2.16419.00807](https://doi.org/10.13140/RG.2.2.16419.00807)) *** ## Abstract Blockchains expose state and execution through transaction-centric interfaces such as JSON-RPC. These interfaces are optimized for deterministic execution but are poorly suited for autonomous AI agents that operate using goals, constraints, and reasoning workflows. The Blockchain Context Protocol (BCP) proposes a standardized interface layer that allows AI agents to interact with blockchain systems using structured context, declarative intents, verifiable execution plans, and policy-based constraints. BCP introduces an agent-native interaction model that sits above existing blockchain execution standards such as ERC-4337, ERC-6900, and emerging agent authorization proposals. Rather than replacing transaction infrastructure, BCP introduces a reasoning and coordination layer enabling safe, explainable, and programmable agent behavior. ## 1. Introduction ### 1.1 Motivation Autonomous agents are increasingly performing tasks involving blockchain systems, including: * DeFi portfolio management * Automated trading and arbitrage * DAO governance participation * Treasury operations * Cross-chain asset routing * On-chain service orchestration Current blockchain interfaces require agents to: * Construct raw transactions * Query fragmented state across RPC endpoints * Rely on centralized indexers * Implement proprietary safety and simulation logic This results in: * Poor interoperability * Increased security risk * Limited explainability * High implementation complexity #### Problem Statement Blockchains lack a standardized machine-readable context layer suitable for AI-driven decision systems. ### 1.2 Design Goals BCP aims to: * Provide structured blockchain state for agent reasoning * Enable declarative intent-based execution * Introduce verifiable policy enforcement * Support multi-step execution planning * Provide execution proofs and explainability * Remain compatible with existing blockchain standards ## 2. Background ### 2.1 JSON-RPC Limitations JSON-RPC provides low-level transaction and state access. It assumes: * Caller already knows execution steps * Caller performs off-chain reasoning * Execution success is binary RPC lacks: * Semantic context * Policy frameworks * Intent abstraction * Execution planning primitives ### 2.2 Emerging Agent Infrastructure Several standards address agent execution primitives. BCP complements these standards by providing a coordination interface. ## 3. System Overview BCP introduces four primary components: * **Context Layer** — Provides normalized blockchain state. * **Intent Layer** — Defines goal-oriented agent requests. * **Policy Layer** — Defines constraints and safety boundaries. * **Execution Layer** — Plans and executes verifiable actions. ## 4. Architecture ``` +------------------------------------------------------+ | AI AGENT | | Planning . Reasoning . Learning | +-----------------------^--------------------------------+ | | +------------------------------------------------------+ | Blockchain Context Protocol (BCP) | | | | Context Engine -> State Normalization | | Intent Engine -> Goal Translation | | Policy Engine -> Constraint Verification | | Execution Planner -> Action Strategy | +-----------------------^--------------------------------+ | | +------------------------------------------------------+ | Smart Account / Agent Authorization | | ERC-4337 . ERC-6900 . ERC-8004 | +-----------------------^--------------------------------+ | | +------------------------------------------------------+ | BLOCKCHAIN | +------------------------------------------------------+ ``` Figure 1. BCP layered architecture, positioned above smart-account authorization and below agent reasoning. ## 5. BCP Core Concepts ### 5.1 Context Object BCP defines standardized state objects. *Example* ```json { "account": { "address": "0xAgent", "balances": [ {"asset": "USDC", "amount": "5000"}, {"asset": "ETH", "amount": "2"} ], "positions": [ {"protocol": "Aave", "collateral": "ETH", "health": 1.8} ] }, "network": { "chain": "ethereum", "gas": 45 } } ``` ### 5.2 Intent Object Intents describe desired outcomes instead of transactions. ```json { "goal": "Optimize yield", "constraints": { "max_risk": "medium", "max_slippage": "0.5%" } } ``` ### 5.3 Policy Object Policies define enforceable execution rules. ```json { "rules": [ {"max_trade_size": "20%"}, {"allowed_protocols": ["Aave", "Uniswap"]} ] } ``` ### 5.4 Execution Plan Execution plans define multi-step strategies. ```json { "steps": [ {"action": "withdraw", "protocol": "Aave"}, {"action": "swap", "protocol": "Uniswap"} ] } ``` ## 6. Protocol Specification ### 6.1 BCP Core Interface — Minimal Interface The Core Interface introduces basic primitives for agent execution. #### 6.1.1 Endpoints **Context Query** GET `/bcp/context/{account}` Returns normalized blockchain state. **Intent Submission** POST `/bcp/intent` Accepts declarative goal objects. **Policy Validation** POST `/bcp/policy/validate` Verifies constraints. **Execution** POST `/bcp/execute` Triggers execution via smart accounts. #### 6.1.2 Execution Flow * Agent → Request Context * Agent → Generate Intent * BCP → Validate Policy * BCP → Generate Execution Plan * Smart Account → Execute * BCP → Return Proof ### 6.2 BCP Extended Interface — Advanced Agent Coordination The Extended Interface introduces: * **Multi-chain Context Aggregation** — Unified cross-chain state views. * **Simulation Engines** — Pre-execution state forecasting. * **Route Optimization** — MEV-aware execution planning. * **Intent Market Integration** — Third-party solver coordination. * **Proof Framework** — Cryptographic execution attestations. ## 7. Security Model BCP relies on multiple security layers: * **Authorization** — Delegation through trustless agent standards. * **Policy Enforcement** — Pre-execution rule validation. * **Simulation** — Risk forecasting and rollback prevention. * **Verifiable Proofs** — Execution attestation and auditability. ## 8. Interoperability BCP is designed to integrate with existing Ethereum standards. ### 8.1 ERC-4337 BCP execution plans are translated into UserOperations. ### 8.2 ERC-6900 BCP policies can be implemented as modular account extensions. ### 8.3 ERC-8004 (Proposed) Defines agent delegation and authorization. ## 9. Real-World Use Cases ### 9.1 Autonomous DeFi Portfolio Agents Agents rebalance assets based on risk-adjusted yield metrics. ### 9.2 DAO Governance Agents Agents vote according to predefined treasury policies. ### 9.3 Cross-Chain Payment Routing Agents optimize transaction routes across L2s and bridges. ### 9.4 On-chain Service Automation Agents subscribe, renew, and manage decentralized services. ## 10. Implementation Considerations ### 10.1 Off-chain BCP Providers Initial implementations may run as decentralized indexing and execution networks. ### 10.2 On-chain Policy Modules Policy engines can be deployed as verifiable smart contracts. ### 10.3 Standardization Path BCP may evolve through: * Ethereum Improvement Proposals * Open agent interoperability consortiums * Integration with AI model orchestration standards ## 11. Limitations * Requires standardized indexing infrastructure * Introduces additional coordination latency * Policy standardization remains unsolved * Cross-chain trust models need formal verification ## 12. Future Research Directions * ZK-based context verification * Intent auction markets * Agent reputation scoring * Autonomous policy learning * Decentralized execution solvers ## 13. Conclusion Blockchain Context Protocol introduces an agent-native interface for blockchain coordination. By shifting interaction from transaction construction to intent execution, BCP enables safer, more interoperable, and programmable agent ecosystems. BCP is not a replacement for blockchain execution standards. Instead, it represents a coordination layer enabling AI systems to safely reason about and operate within decentralized environments. Licensed under CC BY 4.0. Cite as: Sheladiya, A. (2026). *Blockchain Context Protocol: Giving AI Agents a Native Interface to Blockchains*. DOI: 10.13140/RG.2.2.16419.00807 # Medium 1. [Crypto Telegram Trading Bot - A Technical Guide](https://medium.com/@anandi.sheladiya/crypto-telegram-trading-bot-a-technical-guide-b85b1bc25475) 2. [Building A Crypto Casino Platform](https://medium.com/@anandi.sheladiya/building-a-crypto-casino-platform-1b7ae01330cb) 3. [Modular vs Monolithic Blockchains: Ethereum’s Long-Term Bet](https://medium.com/@anandi.sheladiya/modular-vs-monolithic-blockchains-ethereums-long-term-bet-c4c68e51abe7) 4. [EIP-4844 (Proto-Danksharding): Scaling Ethereum with Blobs](https://medium.com/@anandi.sheladiya/eip-4844-proto-danksharding-scaling-ethereum-with-blobs-86d6ed08616a) 5. [EVM Opcodes: The DNA of Ethereum Smart Contracts](https://medium.com/@anandi.sheladiya/evm-opcodes-the-dna-of-ethereum-smart-contracts-4e99ebfc5162) 6. [How Rollups Can Be Monetized: Sequencer, Data Availability, and MEV](https://medium.com/@anandi.sheladiya/how-rollups-can-be-monetized-sequencer-data-availability-and-mev-c35a75101c93) 7. [Merkle Trees, Patricia Tries, and How Ethereum Stores Data](https://medium.com/@anandi.sheladiya/merkle-trees-patricia-tries-and-how-ethereum-stores-data-408e27492245) 8. [Writing Secure Smart Contracts: A Developer’s Guide](https://medium.com/@anandi.sheladiya/writing-secure-smart-contracts-a-developers-guide-f0499213dde5) 9. [Training AI Models on Decentralized Compute Networks: A Technical Deep Dive](https://medium.com/@anandi.sheladiya/training-ai-models-on-decentralized-compute-networks-a-technical-deep-dive-3be435851e4d) 10. [Inside ERC-6900: Building Modular Smart Accounts on Ethereum](https://medium.com/@anandi.sheladiya/inside-erc-6900-building-modular-smart-accounts-on-ethereum-f77bc3ea4a07) 11. [Ethereum’s Pectra Upgrade: What Developers Need to Know](https://medium.com/@anandi.sheladiya/ethereums-pectra-upgrade-what-developers-need-to-know-bd86464ca00d) 12. [The AI Job-Hunter Powered by Blockchain: A New Work Paradigm](https://medium.com/@anandi.sheladiya/the-ai-job-hunter-powered-by-blockchain-a-new-work-paradigm-2e0378789d10) 13. [A Complete Guide to Smart Contract Security: From Slither to Foundry](https://medium.com/@anandi.sheladiya/a-complete-guide-to-smart-contract-security-from-slither-to-foundry-639b0a463d14) 14. [From Banks to Blocks: How Traditional Banking Can Move Onchain with Crypto](https://medium.com/@anandi.sheladiya/from-banks-to-blocks-how-traditional-banking-can-move-onchain-with-crypto-84e869fa9b69) 15. [Post-Quantum Blockchain: Securing the Next Generation of Web3](https://medium.com/@anandi.sheladiya/post-quantum-blockchain-securing-the-next-generation-of-web3-a92df63e0e93) 16. [From JPMorgan to Stripe: How Companies Choose Between Proprietary and Public Blockchains](https://medium.com/@anandi.sheladiya/from-jpmorgan-to-stripe-how-companies-choose-between-proprietary-and-public-blockchains-945cf93121e9) 17. [Real-World Assets & On-Chain Credit: Unlocking the Future of Finance](https://medium.com/@anandi.sheladiya/real-world-assets-on-chain-credit-unlocking-the-future-of-finance-194f8eaaf08b) 18. [Aptos vs. Sei vs. Ethereum — A Deep Dive into Execution Architectures](https://medium.com/@anandi.sheladiya/aptos-vs-sei-vs-ethereum-a-deep-dive-into-execution-architectures-2c8736ef4e2a) 19. [Stablecoins: The Architecture of Digital Money](https://medium.com/@anandi.sheladiya/stablecoins-the-architecture-of-digital-money-969dfbcd1345) 20. [Arbitrum One vs Arbitrum Nova: A Deep Technical Comparison for Builders](https://medium.com/@anandi.sheladiya/arbitrum-one-vs-arbitrum-nova-a-deep-technical-comparison-for-builders-06f74793595a) 21. [Account Abstraction & ERC‑4337: The Next Smart Accounts](https://medium.com/@anandi.sheladiya/account-abstraction-erc-4337-the-next-smart-accounts-847160e35280) 22. [Voice AI Agents on Blockchain: The Next Interface for Web3](https://medium.com/@anandi.sheladiya/voice-ai-agents-on-blockchain-the-next-interface-for-web3-5bba53bf1652) 23. [Web3 Infrastructure for Trusted AI Agents](https://medium.com/@anandi.sheladiya/web3-infrastructure-for-trusted-ai-agents-d672ba86fbb0?postPublishedType=initial) 24. [Building Trustless Automation: n8n Workflows Powered by Blockchain](https://medium.com/@anandi.sheladiya/building-trustless-automation-n8n-workflows-powered-by-blockchain-217d74d649ec?postPublishedType=initial) 25. [Ethereum Interoperability Layer: Rebuilding Composability in a Rollup-Centric World](https://medium.com/@anandi.sheladiya/ethereum-interoperability-layer-rebuilding-composability-in-a-rollup-centric-world-75317f436473) 26. [Blockchain Context Protocol: A Native Interface for AI ↔ Blockchain Interaction](https://medium.com/@anandi.sheladiya/blockchain-context-protocol-a-native-interface-for-ai-blockchain-interaction-df99461f5483) 27. [EIP-8004: Enabling Autonomous AI Agents in Web3](https://medium.com/@anandi.sheladiya/eip-8004-enabling-autonomous-ai-agents-in-web3-e439ec86a9c0) 28. [Quantum Communication: Building Networks Secured by the Laws of Physics](https://medium.com/@anandi.sheladiya/quantum-communication-the-internet-that-can-detect-eavesdroppers-3b962eac78d2) 29. [Swarm Intelligence for Fair Ethereum Rollup Sequencing](https://medium.com/@anandi.sheladiya/swarm-based-intelligent-sequencing-for-ethereum-rollups-applying-multi-agent-reinforcement-3cb79a436a42) # EDCON - Tokyo'24 I had the privilege of attending **EDCON 2024 in Tokyo**, a leading global Ethereum conference that brought together builders, researchers, and leaders from across the Web3 ecosystem. One of the most impactful moments was hearing **Vitalik Buterin** share his vision for the future of Ethereum — covering decentralization at scale, the importance of public goods, and the evolving role of Layer 2s. His insights reinforced the need for simplicity, security, and sustainability in protocol design. Throughout the event, I explored critical topics such as: * Ethereum’s post-Dencun roadmap * Modular rollup architectures and data availability * Account abstraction and smart contract wallets * Cross-chain interoperability * Governance mechanisms for decentralized communities EDCON 2024 was more than a conference — it was a convergence of ideas, innovation, and global collaboration. The conversations, connections, and learnings from Tokyo continue to inspire how I approach building in Web3.

# Danang - Web3 Builder's Summit 24 Joined the **Web3 Builder’s Summit 2024 in Da Nang, Vietnam**, a gathering of forward-thinking developers, founders, and Web3 ecosystem contributors. The summit focused on hands-on innovation across modular blockchain architecture, cross-chain infrastructure, and next-gen developer tools. What stood out was the strong emphasis on practical use cases — from AI-integrated dApps to emerging identity standards and scalable Layer 2 solutions. It was an inspiring experience to connect with builders from across Asia and exchange ideas on shaping the future of decentralized technologies.

Hello, World!

Welcome, {props.name}!

Welcome to Next.js!

About Us

{post.title}

Blog Posts

{post.title}

Profile Picture

Welcome to My Website

Welcome to Django!