DEV Community: Ahmed Castro

Cómo lanzar en Arbitrum

Ahmed Castro — Sat, 30 Aug 2025 08:37:19 +0000

Establecé tu entorno

Ingresá a la Arbitrum Sepolia Faucet de Google colocá tu address y dale click en receive 0.05 ETH.

Luego bridgeá de Sepolia a Arbitrum Sepolia desde el bridge oficial de Arbitrum. Te recomiendo enviar solo 0.04 para también cubrir los costos del envío.

Ahora conectá tu wallet a Arbitrum Sepolia haciendo click en Add to Metamask en cualquier opción que está funcionando en Chainlist.

Lanzá desde Remix

Colocá tu wallet en Arbitrum Sepolia.

Al momento de lanzar, asegurate que tu environment seleccionado sea Injected Provider.

Ahora podés lanzar el contrato.

Lanzá desde Foundry

Para desplegar utilizando el RPC público de Arbitrum Sepolia Testnet, ejecuta:

forge create ... --rpc-url=https://sepolia-rollup.arbitrum.io/rpc --legacy

Lanzá desde Hardhat

Modifica tu archivo de configuración de Hardhat hardhat.config.ts para que se dirija al RPC público de Arbitrum Sepolia.


const config: HardhatUserConfig = {
  ...
  networks: {
    arbitrumSepolia: {
      url: "https://sepolia-rollup.arbitrum.io/rpc" || "",
      accounts:
        process.env.PRIVATE_KEY !== undefined ? [process.env.PRIVATE_KEY] : [],
    },
  },
};

How Local Storage Wallets on Ethereum Work

Ahmed Castro — Thu, 07 Aug 2025 20:07:27 +0000

You need wallets in order to interact with decentralized apps on Ethereum, also called dApps. It holds your private key, signs your transactions, and proves your identity on-chain. Most people are familiar with browser extensions or mobile apps like MetaMask or Rabby. But there's another approach, local storage wallets, that provides more speed and better user experience.

This article explains what a local storage wallet is, how it works, and what it means for your experience on platforms like realtimeplay.xyz, a 100% on-chain casino with ultra-fast experience on MegaETH.

What Is a Local Storage Wallet?

A local storage wallet is a lightweight Ethereum wallet created and stored directly in your browser’s local storage, this is the same technology your browser uses to remember things like website settings or form data. This means the wallet is:

Created automatically by your browser.
Stored only on your device, never on a server.
Ready to use immediately, without needing to install anything.

In technical terms, it's just a key pair (a public Ethereum address and a private signing key) stored securely in the browser using JavaScript APIs like window.localStorage.

Why Use a Local Storage Wallet?

Traditional wallets are great for managing multiple assets and interacting across the Ethereum ecosystem. But they're not always ideal when you're trying to:

Create a quick wallet for fast onboarding.
Interact with a dApp that needs sub-second feedback.
Avoid the overhead of external wallet prompts or popups.

With a local storage wallet:

There’s no extension to install.
No user approval needed for every transaction.
The experience is immediate, perfect for games that need to feel instant and fluid.

This is especially important in environments like MegaETH, where every action is an on-chain transaction and execution happens in milliseconds.

Is It Safe?

Local storage wallets give you full control and that includes responsibility.

You own the keys. No one else, not even the dApp, can access them.
But they’re stored in your browser, so clearing your cache or using incognito mode could mean losing access unless you back it up.

Many apps offer a “download backup” or “export wallet” option. If you plan to use your wallet regularly, make sure to back it up securely.

How Does It Work on realtimeplay.xyz?

When you visit realtimeplay.xyz, a local storage wallet is generated for you automatically (if you don’t already have one). This wallet lets you:

Instantly start playing without installing anything.
Sign and send transactions directly to the chain.
Enjoy a casino experience that feels like a Web2 app but is fully on-chain.

You can also export your wallet if you ever want to import it into another Ethereum wallet app or manage it yourself.

What Happens If I Refresh or Close My Browser?

As long as you’re not in incognito mode and haven’t cleared your browser data, your wallet will persist. The next time you open the site, the same wallet is ready to use.

But again, if you clear your local storage, the wallet is gone along with access to any funds or progress. Always back it up if you care about keeping it.

How to Create a Secure Telegram Bot🔒 with EIP-712

Ahmed Castro — Sun, 20 Jul 2025 17:16:54 +0000

Telegram has around one billion active users per month and is a very important part of dApps and Web3 interfaces and communities. However, many Telegram bots still use insecure interaction methods.

By completing this guide, you’ll learn a better way to connect users to decentralized applications via Telegram. This tutorial shows how to authenticate Telegram users using their Web3 wallets, without ever accessing their private keys.

In this tutorial you’ll learn how to:

Create a secure Telegram bot: Build a bot that authenticates users via Web3 wallet signatures without storing private keys.
Implement ERC-712 signatures: Create an authentication flow where the user signs human-readable messages.
Enable flexible authentication: Users can interact with any type of application via Telegram, from secret groups to DeFi transactions or airdrops.

To see the full project, check out the complete code.

Application flow.

1. Create a New Telegram Bot

Creating a Telegram bot is very simple. Just send a direct message to the Telegram account @BotFather. Send the command /newbot, follow the instructions, and you’ll receive a token that we’ll use to interact with the Telegram library in the next step.

Send /newbot to @botfather to create a new Telegram bot.

2. Launch the Telegram Bot Backend

First, install the dependencies. Make sure you have Node.js installed, I recommend via nvm.

Once Node.js is installed, run:

npm install node-telegram-bot-api ethers dotenv express cors

Now, create a .env file with the following:

.env

BOT_TOKEN=your_telegram_bot_token
CHAIN_ID=1
WEB_DAPP_URL=http://localhost:3000

Edit the CHAIN_ID depending on the chain your dApp or community is. You can use Chainlist to figure out the chain id of the blockchain you're using. If your bot is chain agnostic use 1 as id, this is the Ethereum chain id.

Don’t forget to create a .gitignore file to avoid uploading .env to public repositories:

.gitignore

.env
node_modules

This is the bot.js file. It launches a bot that listens to Telegram messages and verifies wallet signatures. Telegram bots use polling to get messages locally, for production, consider using a webhook and hosting the server remotely.

For this tutorial, we’ll use polling. Learn more about webhooks in the Telegram Bot API docs.

When a user sends message with the authenticate text, the bot replies with a link to the web dApp. The dApp will sign a message and send it to the bot, which verifies the signature and welcomes the user.

// We'll use the official telegram bot library and ethers to verify the user's signature
const TelegramBot = require("node-telegram-bot-api");
const { ethers } = require("ethers");
require("dotenv").config();
const express = require("express");
const cors = require("cors");

const bot = new TelegramBot(process.env.BOT_TOKEN, { polling: true });
const CHAIN_ID = process.env.CHAIN_ID;
const WEB_DAPP_URL = process.env.WEB_DAPP_URL;

const app = express();
app.use(cors());
app.use(express.json());

// Initializes the Telegram bot 
(async () => {
    try {
        bot.botInfo = await bot.getMe();
        app.listen(8080, () => {
            console.log("\nServer is running on port 8080");
            console.log("Bot is running...");
        });
    } catch (error) {
        console.error(error);
        process.exit(1);
    }
})();

// The /verify enpoint is used to verify the signature and send a welcome message to the user
app.post("/verify", async (req, res) => {
    const { userId, message, signature } = req.body;
    try {
        const signerAddress = await getAuthenticationSigner(userId, message, signature);
        await bot.sendMessage(
            Number(userId), 
            `Welcome! You're authenticated as ${signerAddress}.\n\nEnjoy your welcome gift! 🎁`
        );
        res.json({ success: true, signerAddress });
    } catch (error) {
        console.error("Verification error:", error);
        res.status(400).json({ success: false, error: error.message });
    }
});

// getAuthenticationSigner returns the signer address
function getAuthenticationSigner(userId, message, signature) {
    // accessRequest es el esquema de datos real del mensaje que queremos verificar
    const accessRequest = {
        userId: userId,
        message: message,
    };
    // domain is your dApp general information, this should be the same for every message
    const domain = {
        name: "Telegram Group Access",
        version: "1",
        chainId: CHAIN_ID,
    };
    // types is your data schema, the structure of the data we want to verify
    const types = {
    AccessRequest: [
            { name: "userId", type: "uint256" },
            { name: "message", type: "string" },
        ]
    };
    // verifyTypedData check if the signature in the ERC-712 format and returns the signer address through ecrecover, this is done internally by the ethers library
    return ethers.verifyTypedData(domain, types, accessRequest, signature);
}

// This is the main function, it gets executed when the bot receives a message
bot.on("message", async (msg) => {
    const text = msg.text || "";
    // Verifica si el mensaje es "authenticate" y si es así, envía un mensaje al usuario para que visite el sitio web
    if (text.toLowerCase() === "authenticate") {
        // userId es el id del usuario en Telegram
        const userId = msg.from.id;
        // Enviamos el usuario a la dapp web para autenticarse
        bot.sendMessage(userId, `Please visit: ${WEB_DAPP_URL}?userId=${userId}`);
        return;
    }
});

console.log("\nBot is running...");

Run the bot:

node bot.js

Your bot is now running on http://127.0.0.1:8080.

Next, we’ll create the web dApp that interacts with it.

3. Create a Web dApp to Sign Messages

We’ll create 3 files:

index.html: The HTML page with the wallet connection and sign button
signature_messaging.js: Handles signing and sending the message
wallet_connection.js: Manages wallet connection

The dApp is a simple HTML page with a Sign button that opens the user’s wallet to sign a message.

Clicking the Sign button opens the ERC712 signature modal.

index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
</head>
<body>
  <div>
    <!-- Connect Wallet button, only visible is wallet is not connected -->
    <input id="connect_button" type="button" value="Connect" onclick="connectWallet()" style="display: none"></input>
    <h1>Telegram Bot Authentication</h1>
    <p id="web3_message"></p>
    <h3>Sign Authentication Request</h3>
    <!-- This is the authentication button, will pop up the wallet signature modal -->
    <button type="button" id="sign" onclick="_signMessage()">Sign</button>
    <p id="signature"></p>
  </div>
    <!-- In this tutorial we'll use web3.js, you can have the same results with ethers.js or viem -->
  <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/web3/1.3.5/web3.min.js"></script>
  <script type="text/javascript" src="wallet_connection.js"></script>
  <script type="text/javascript" src="signature_messaging.js"></script>
</body>

  <script>
    // The signMessage function is called when the user clicks the sign button
    function _signMessage()
    {
      const urlParams = new URLSearchParams(window.location.search);
      const userId = urlParams.get('userId');
      signMessage(userId, "I'm requesting access to the Telegram group.")
    }
  </script>
</html>

signature_messaging.js signs the message using the ERC712 standard and sends it to the bot backend via eth_signTypedData_v4.

signature_messaging.js

const BOT_API_URL = 'http://localhost:8080'
// Signs the message using the ERC-712 format
async function signMessage(userId, message)
{
  // ERC-712 expects you to send the message in a very specific format
  const msgParams = JSON.stringify({
    types: {
      EIP712Domain: [
        { name: 'name', type: 'string' },
        { name: 'version', type: 'string' },
        { name: 'chainId', type: 'uint256' },
      ],
      AccessRequest: [
        { name: 'userId', type: 'uint256' },
        { name: 'message', type: 'string' }
      ],
    },
    primaryType: 'AccessRequest',
    domain: {
      name: 'Telegram Group Access',
      version: '1',
      chainId: NETWORK_ID,
    },
    message: {
      userId: userId,
      message: message,
    },
  });

  // ERC-712 introduced the eth_signTypedData_v4 method, now is widely adopted by wallets
  const signature = await ethereum.request({
    method: "eth_signTypedData_v4",
    params: [accounts[0], msgParams],
  });

  document.getElementById("signature").textContent="Signature: " + signature;

  // Send the message to the telegram bot
  await sendSignature(userId, message, signature);
}

// Send the signature to the Telegram bot
async function sendSignature(userId, message, signature) {
  // We start by grouping the data to be sent to the bot
  const requestData = {
    userId: userId,
    message: message,
    signature: signature
  };

  try {
    // Now we send the data to the Telegram bot at the /verify POST endpoint
    // If all is correct, the bot will send a welcome message to the user
    const response = await fetch(BOT_API_URL + '/verify', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(requestData)
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    alert("Message sent successfully!");
  } catch (error) {
    console.error('Error:', error);
    alert("Failed to send message: " + error.message);
  }
}

Then, wallet_connection.js handles connecting to the wallet and updating the UI:

If you target a specific network id, edit NETWORK_ID.

wallet_connection.js

// Constants
const NETWORK_ID = 1
var accounts
var web3

// Automatically refreshes the browser if your wallet changes
function metamaskReloadCallback() {
  window.ethereum.on('accountsChanged', (accounts) => {
    document.getElementById("web3_message").textContent="Account changed, refreshing...";
    window.location.reload()
  })
  window.ethereum.on('networkChanged', (accounts) => {
    document.getElementById("web3_message").textContent="Network changed, refreshing...";
    window.location.reload()
  })
}

// Get a new Web3 instance
const getWeb3 = async () => {
  return new Promise((resolve, reject) => {
    if(document.readyState=="complete")
    {
      if (window.ethereum) {
        const web3 = new Web3(window.ethereum)
        window.location.reload()
        resolve(web3)
      } else {
        reject("must install MetaMask")
        document.getElementById("web3_message").textContent="Error: Please connect to MetaMask";
      }
    }else
    {
      window.addEventListener("load", async () => {
        if (window.ethereum) {
          const web3 = new Web3(window.ethereum)
          resolve(web3)
        } else {
          reject("must install MetaMask")
          document.getElementById("web3_message").textContent="Error: Please install Metamask";
        }
      });
    }
  });
};

// Loads the dApp and gets a Web3 object instance
async function loadDapp() {
  metamaskReloadCallback()
  document.getElementById("web3_message").textContent="Please connect to Metamask"
  var awaitWeb3 = async function () {
    web3 = await getWeb3()
    web3.eth.net.getId((err, netId) => {
      if (netId == NETWORK_ID) {
        var awaitContract = async function () {
          document.getElementById("web3_message").textContent="You are connected to Metamask"
          web3.eth.getAccounts(function(err, _accounts){
            accounts = _accounts
            if (err != null)
            {
              console.error("An error occurred: "+err)
            } else if (accounts.length > 0)
            {
              onWalletConnectedCallback()
              document.getElementById("account_address").style.display = "block"
            } else
            {
              document.getElementById("connect_button").style.display = "block"
            }
          });
        };
        awaitContract();
      } else {
        document.getElementById("web3_message").textContent="Please connect to Scroll";
      }
    });
  };
  awaitWeb3();
}

// Connect the user wallet
async function connectWallet() {
  await window.ethereum.request({ method: "eth_requestAccounts" })
  accounts = await web3.eth.getAccounts()
  onWalletConnectedCallback()
}

// Callbacked called when the user connected his wallet, you would typically read the user state on-chain here
const onWalletConnectedCallback = async () => {
}

// Starts the dApp
loadDapp()

Install a web server like lite-server:

npm install -g lite-server

Then, in the same directory as index.html:

lite-server

Your dApp is now running at http://127.0.0.1:3000.

4. Test Your Bot

Now let’s test it:

Send authenticate to the bot.
Visit the site the bot replies with, connect to Scroll Mainnet, and sign the message.
Check the bot’s reply in Telegram.

This flow securely authenticates users and enables actions on their behalf without storing private keys.

Next Steps

In this tutorial, we authenticated Telegram users via a Web3 wallet. We used the ERC712 standard and the eth_signTypedData_v4 method, and the Telegram API to send and receive messages.

In the next tutorial, we’ll use this authentication to control access to a Telegram group.

Thanks for reading this article!

Follow Filosofía Código on dev.to and in Youtube for everything related to Blockchain development.

One-click Loans on Aave with EIP-7702

Ahmed Castro — Sun, 20 Jul 2025 16:44:30 +0000

Historically, Ethereum has had a high barrier to entry with interfaces that are difficult to understand and use. In May 2025 Ethereum released EIP-7702, which is in my opinion, is the most significant improvement for user experience released on Ethereum. Thanks to it, an EOA, that is a regular Ethereum account, can temporarily become a smart contract.

Historically, taking out a loan on Aave takes three transactions. In this article we’ll see how to do it in a single transaction using EIP‑7702.

In this article we’ll show how to use EIP‑7702 to get a loan on Aave with one click. Aave is the largest collateralized lending platform on Ethereum, handling over $50 billion. Before this upgrade, borrowing required at least three transactions, whereas with EIP‑7702 we bundle those three actions into one.

Let’s start by understanding how Aave works, and then we’ll build step by step a frontend that does the entire process with a single button.

How to Get a Loan on Aave

Let's suppose you want $300 in WBTC by posting $1000 in DAI as collateral. To do this, you first have to approve the Aave contract to transfer your DAI via the approve function, then supply your DAI as collateral by calling supply, and finally borrow by calling borrow. From the user’s point of view this isn’t obvious, and until now we had no way to express it in a single transaction.

Example of an Aave position with a $300 WBTC loan backed by $1000 in DAI collateral.

In our example we’ll go through step by step how to do the same process with a single button. We’ll see how to enable EIP‑7702 in your wallet so that it can aggregate transactions, and then we’ll build a frontend to interact with Aave from your smart-contract wallet.

Temporarily Turn Your Wallet into a Smart Contract

With EIP‑7702 you can inject arbitrary code into your wallet. Another option, to save gas, is to have your wallet point to any other contract so that it “copies” the code at that address, we call this wallet delegation. In this example we’ll deploy and delegate to a Multicall7702 contract based on Multicall, a contract that batches multiple transactions but I adapted it for EIP‑7702 so it only allows the deployer to execute it. Otherwise your wallet would be exposed.

First, we’ll deploy the Multicall7702 contract and then point our wallet at that contract.

Wallet interfaces don’t yet support EIP‑7702, so for now we’ll use Foundry instead. Also, as dApp developers we shouldn’t worry about handling delegation in our interfaces. For security reasons, this should be implemented at the wallet level, not the dApp level.

Deploy the Multicall7702 Contract

Deploy the following contract on the network where you want to try this example and save the address. I’ll deploy it on Scroll Testnet, where you can connect via Chainlist and get funds from the faucet by messaging @scroll_up_sepolia_bot and then typing /drop 0xYOUR_WALLET_ADDRESS in the faucet chat.

If you deploy on another chain, I’ll explain the changes you need to make along the way.

The only change you must make before deploying the Multicall7702 contract is to replace 0xYOUR_EOA_ADDRESS with the wallet you want to convert:

// SPDX-License-Identifier: MIT
// Derived from MakerDAO’s Multicall3
// NOT AUDITED, DO NOT USE IN PRODUCTION
pragma solidity 0.8.12;

contract Multicall7702 {
    struct Call3Value { address target; bool allowFailure; uint256 value; bytes callData; }
    struct Result { bool success; bytes returnData; }

    address immutable public owner = 0xTU_DIRECCION_EOA;

    function aggregate3Value(Call3Value[] calldata calls) public payable returns (Result[] memory returnData) {
        require(owner == msg.sender, "Only owner"); // Prevent others from executing on your behalf
        uint256 valAccumulator;
        uint256 length = calls.length;
        returnData = new Result[](length);
        Call3Value calldata calli;
        for (uint256 i = 0; i < length;) {
            Result memory result = returnData[i];
            calli = calls[i];
            uint256 val = calli.value;
            unchecked { valAccumulator += val; }
            (result.success, result.returnData) = calli.target.call{value: val}(calli.callData);
            assembly {
                if iszero(or(calldataload(add(calli, 0x20)), mload(result))) {
                    mstore(0x00, 0x08c379a000000000000000000000000000000000000000000000000000000000)
                    mstore(0x04, 0x0000000000000000000000000000000000000000000000000000000000000020)
                    mstore(0x24, 0x0000000000000000000000000000000000000000000000000000000000000017)
                    mstore(0x44, 0x4d756c746963616c6c333a2063616c6c206661696c6564000000000000000000)
                    revert(0x00, 0x84)
                }
            }
            unchecked { ++i; }
        }
        require(msg.value == valAccumulator, "Multicall3: valor incorrecto");
    }
}

Delegate Your Wallet to Multicall7702

Install Foundry if you don’t have it:

curl -L https://foundry.paradigm.xyz | bash
foundryup

To delegate your wallet, run the following command—replacing YOUR_PRIVATE_KEY and 0xYOUR_CONTRACT_ADDRESS. If you’re on another chain, change the --rpc-url (you can get it from Chainlist):

cast send \
  --rpc-url https://scroll-public.scroll-testnet.quiknode.pro \
  --private-key YOUR_PRIVATE_KEY \
  --auth 0xYOUR_CONTRACT_ADDRESS $(cast az)

You can verify the delegation with:

cast code \
  --rpc-url https://scroll-public.scroll-testnet.quiknode.pro \
  0xYOUR_EOA_ADDRESS

You should see your Multicall7702 address in the form:

0xef0100YOUR_EOA_ADDRESS

Here 0xef0100 is the EIP‑7702 delegation prefix plus your contract address, meaning your wallet points to your Multicall7702 code.

Build the Frontend

Next, we’ll create a minimal frontend demo of EIP‑7702. All the code is commented so you can understand what’s needed for compatibility with this new standard.

In our dApp, the user will select how much WBTC to borrow backed by DAI. If you want to use other tokens, I’ll note the necessary changes.

We’ll build a very simple EIP‑7702–enabled dApp implementation.

We’ll use two files: index.html for the UI and blockchain_stuff.js for the logic. Place them side by side in a new folder.

index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
</head>
<body>
  <input id="connect_button" type="button" value="Connect" onclick="connectWallet()" style="display: block"></input>
  <p id="account_address" style="display: none"></p>
  <p id="web3_message"></p>
  <p id="contract_state"></p>
  <label for="lending_token_amount">DAI supply amount:</label>
  <input type="input" value="" id="lending_token_amount" placeholder="e.g. 1000"></input>
  <br>
  <label for="borrowed_token_amount">WBTC borrow amount:</label>
  <input type="input" value="" id="borrowed_token_amount" placeholder="e.g. 0.005"></input>
  <br>
  <input type="button" value="One click loan" onclick="_oneClickLoan()"></input>
  <br>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/web3/1.3.5/web3.min.js"></script>
  <script src="blockchain_stuff.js"></script>
</body>
</html>

<script>
  function _oneClickLoan() {
    const lendingTokenAmount = document.getElementById("lending_token_amount").value;
    const borrowedTokenAmount = document.getElementById("borrowed_token_amount").value;
    oneClickLoan(lendingTokenAmount, borrowedTokenAmount);
  }
</script>

In the following file adjust NETWORK_ID, LENDING_ADDRESS, BORROWED_TOKEN, and AAVE_POOL_ADDRESS for your target chain and tokens.

blockchain_stuff.js

// Edit this if you want to change in other chain
const NETWORK_ID = 534351 // Scroll Sepolia

// Edit if you want to use other assets or other chain
const LENDING_ADDRESS = "0x7984e363c38b590bb4ca35aed5133ef2c6619c40" //Aave Testnet DAI en Scroll Sepolia
const BORROWED_TOKEN = "0x5ea79f3190ff37418d42f9b2618688494dbd9693" //Aave Testnet WBTC en Scroll Sepolia
const AAVE_POOL_ADDRESS = "0x48914C788295b5db23aF2b5F0B3BE775C4eA9440" // Aave Testnet Pool en Scroll Sepolia

// ABI we'll use, you should keep this in separate .json files to keep your code clean
const MULTICALL_ABI = [
  {
    "inputs": [
      {
        "components": [
          {"internalType": "address", "name": "target", "type": "address"},
          {"internalType": "bool", "name": "allowFailure", "type": "bool"},
          {"internalType": "uint256", "name": "value", "type": "uint256"},
          {"internalType": "bytes", "name": "callData", "type": "bytes"}
        ],
        "internalType": "struct Multicall3.Call3Value[]",
        "name": "calls",
        "type": "tuple[]"
      }
    ],
    "name": "aggregate3Value",
    "outputs": [
      {
        "components": [
          {"internalType": "bool", "name": "success", "type": "bool"},
          {"internalType": "bytes", "name": "returnData", "type": "bytes"}
        ],
        "internalType": "struct Multicall3.Result[]",
        "name": "returnData",
        "type": "tuple[]"
      }
    ],
    "stateMutability": "payable",
    "type": "function"
  }
];

const ERC20_ABI = [
  {
    "inputs": [
      {"internalType": "address", "name": "spender", "type": "address"},
      {"internalType": "uint256", "name": "value", "type": "uint256"}
    ],
    "name": "approve",
    "outputs": [
      {"internalType": "bool", "name": "", "type": "bool"}
    ],
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "inputs": [],
    "name": "decimals",
    "outputs": [
      {"internalType": "uint8", "name": "", "type": "uint8"}
    ],
    "stateMutability": "view",
    "type": "function"
  }
];

const AAVE_POOL_ABI = [
  {
    "inputs": [
      {"internalType": "address", "name": "asset", "type": "address"},
      {"internalType": "uint256", "name": "amount", "type": "uint256"},
      {"internalType": "address", "name": "onBehalfOf", "type": "address"},
      {"internalType": "uint16", "name": "referralCode", "type": "uint16"}
    ],
    "name": "supply",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "inputs": [
      {"internalType": "address", "name": "asset", "type": "address"},
      {"internalType": "uint256", "name": "amount", "type": "uint256"},
      {"internalType": "uint256", "name": "interestRateMode", "type": "uint256"},
      {"internalType": "uint16", "name": "referralCode", "type": "uint16"},
      {"internalType": "address", "name": "onBehalfOf", "type": "address"}
    ],
    "name": "borrow",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  }
];

// Variables we will use
var lendingTokenContract
var borrowedTokenContract
var aavePoolContract
var myERC7702Account

var accounts
var web3

// Automatically reload when the user selects a new chain or uses another account
function metamaskReloadCallback() {
  window.ethereum.on('accountsChanged', (accounts) => {
    document.getElementById("web3_message").textContent="Se cambió el account, refrescando...";
    window.location.reload()
  })
  window.ethereum.on('networkChanged', (accounts) => {
    document.getElementById("web3_message").textContent="Se el network, refrescando...";
    window.location.reload()
  })
}

// Function to initalize Web3
const getWeb3 = async () => {
  return new Promise((resolve, reject) => {

    if(document.readyState=="complete")
    {
      if (window.ethereum) {
        const web3 = new Web3(window.ethereum)
        window.location.reload()
        resolve(web3)
      } else {
        reject("must install MetaMask")
        document.getElementById("web3_message").textContent="Error: Porfavor conéctate a Metamask";
      }
    }else
    {
      window.addEventListener("load", async () => {
        if (window.ethereum) {
          const web3 = new Web3(window.ethereum)
          resolve(web3)
        } else {
          reject("must install MetaMask")
          document.getElementById("web3_message").textContent="Error: Please install Metamask";
        }
      });
    }
  });
};

// Function to initalize the dApp, read the contracts and connects the wallet
async function loadDapp() {
  metamaskReloadCallback()
  document.getElementById("web3_message").textContent="Please connect to Metamask"
  var awaitWeb3 = async function () {
    web3 = await getWeb3()
    web3.eth.net.getId((err, netId) => {
      if (netId == NETWORK_ID) {
        var awaitContract = async function () {
          lendingTokenContract = new web3.eth.Contract(ERC20_ABI, LENDING_ADDRESS);
          borrowedTokenContract = new web3.eth.Contract(ERC20_ABI, BORROWED_TOKEN);
          aavePoolContract = new web3.eth.Contract(AAVE_POOL_ABI, AAVE_POOL_ADDRESS);

          document.getElementById("web3_message").textContent="You are connected to Metamask"
          onContractsInitCallback()
          web3.eth.getAccounts(function(err, _accounts){
            accounts = _accounts
            if (err != null)
            {
              console.error("An error occurred: "+err)
            } else if (accounts.length > 0)
            {
              onWalletConnectedCallback()
              document.getElementById("account_address").style.display = "block"
            } else
            {
              document.getElementById("connect_button").style.display = "block"
            }
          });
        };
        awaitContract();
      } else {
        document.getElementById("web3_message").textContent="Please connect to Goerli";
      }
    });
  };
  awaitWeb3();
}

async function connectWallet() {
  await window.ethereum.request({ method: "eth_requestAccounts" })
  accounts = await web3.eth.getAccounts()
  onWalletConnectedCallback()
}

loadDapp()

// Wallet executed when you change the accounts, this is a good place to read the on-chain state
const onContractsInitCallback = async () => {
}

// Callback called when the user connects the wallet, in this case we'll initalize smart account wallet
const onWalletConnectedCallback = async () => {
  myERC7702Account = new web3.eth.Contract(MULTICALL_ABI, accounts[0]);
}

// Function that is called from the frontend that receives the desired amount of collateral and borrow amounts
const oneClickLoan = async (lendingTokenAmount, borrowedTokenAmount) => {
    // Convert from ether to wei format depending on the amount of decimals of each token
    const scrDecimals = await lendingTokenContract.methods.decimals().call();
    const borrowedDecimals = await borrowedTokenContract.methods.decimals().call();
    const supplyAmount = Web3.utils.toBN(
        (parseFloat(lendingTokenAmount) * Math.pow(10, parseInt(scrDecimals))).toLocaleString('fullwide', {useGrouping:false})
    );
    const borrowAmount = Web3.utils.toBN(
        (parseFloat(borrowedTokenAmount) * Math.pow(10, parseInt(borrowedDecimals))).toLocaleString('fullwide', {useGrouping:false})
    );

    // We generate the contract calls encoded in a compatible way with our multicall contract
    const approveCall = lendingTokenContract.methods.approve(AAVE_POOL_ADDRESS, supplyAmount).encodeABI();
    const supplyCall = aavePoolContract.methods.supply(LENDING_ADDRESS, supplyAmount, accounts[0], 0).encodeABI();
    const interestRateMode = 2;
    const referralCode = 0;
    const borrowCall = aavePoolContract.methods.borrow(
        BORROWED_TOKEN,
        borrowAmount.toString(),
        interestRateMode,
        referralCode,
        accounts[0]
    ).encodeABI();

    const calls = [
        {
          target: LENDING_ADDRESS,
          allowFailure: false,
          value: 0,
          callData: approveCall
        },
        {
          target: AAVE_POOL_ADDRESS,
          allowFailure: false,
          value: 0,
          callData: supplyCall
        },
        {
          target: AAVE_POOL_ADDRESS,
          allowFailure: false,
          value: 0,
          callData: borrowCall
        }
      ];

      // We execute a call directed our ERC-7702 wallet
      const result = await myERC7702Account.methods.aggregate3Value(calls)
      .send({ from: accounts[0], gas: 0, value: 0 })
      .on('transactionHash', function(hash){
        document.getElementById("web3_message").textContent="Executing...";
      })
      .on('receipt', function(receipt){
        document.getElementById("web3_message").textContent="Success.";    })
      .catch((revertReason) => {
        console.log("ERROR! Transaction reverted: " + revertReason.receipt.transactionHash)
      });
}

Test Your dApp

Install Node.js if you don’t have it, I recommend via NVM:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
nvm install 22
# Restart or reload your terminal

Install a web server:

npm i -g lite-server

Then start the frontend:

lite-server

Your web app will be at http://localhost:3000. Once you get your loan you can inspect the bundled transactions in detail on Etherscan and the Aave frontend.

In Etherscan you will be able to see how everything happened in a single transaction.

To continue learning about this and other new features made possible by this upgrade, see the EIP‑7702 Specification.

Thanks for reading this article!

Follow Filosofía Código on dev.to and in Youtube for everything related to Blockchain development.

Préstamos en un solo click usando EIP-7702 en Aave

Ahmed Castro — Sun, 20 Jul 2025 15:52:39 +0000

Históricamente, Ethereum ha tenido una alta barrera de entrada con interfaces difíciles de entener y usar. En mayo de 2025 se lanzó la mejora que en mi opinión es la más significativa en experiencia de usuario en Ethereum, el EIP‑7702. Gracias a ella, una EOA, o sea una cuenta tradicional de Ethereum, puede convertirse temporalmente en un contrato inteligente.

Históricamente, obtener un préstamo en Aave toma 3 transacciones, en este artículo veremos como realizarlo en una sola transacción usando el EIP-7702

En este artículo mostraremos cómo usar EIP‑7702 para obtener un préstamo en Aave con un solo click. Aave es la plataforma de préstamos colateralizados más grande de Ethereum, que maneja más de 50 billones de dólares. Antes de esta mejora, tomar un préstamo implicaba al menos tres transacciones, mientras que con EIP‑7702, agrupamos esas tres acciones en una sola.

Empecemos por entender cómo funciona Aave y luego construiremos paso a paso un frontend que realiza todo el proceso con un único botón.

Cómo Obtener un Préstamo en Aave

Supongamos que quieres obtener $300 en WBTC dejando $1000 en DAI como garantía, lo que también llamamos colateral. Para hacerlo primero debes aprobar que el contrato de Aave sea capaz de depositar tu DAI mediante la función approve, luego depoitas tu DAI como colateral llamando la función suuply y finalmente obtienes el préstamo ejecutando la función borrow. Desde el punto de vista del usuario esto no es evidente y antes no teníamos una manera de expresarlo con una sola transacción.

Ejemplo de una posición en Aave con un préstamo de $300 en WBTC con $1000 en DAI como garantía

En nuestro ejemplo veremos paso por paso cómo realizar el mismo proceso con un solo botón. Veremos cómo hablitar el EIP-7702 en tu wallet para que sea capaz de agrupar transacciones y luego construiremos un frontend para interactuar con Aave desde tu smart contract wallet.

Convierte tu Wallet Temporalmente en un Smart Contract

Con EIP-7702 puedes inyectar cualquier codigo a tu wallet. Otra opción, para ahorrar gas, es hacer que tu wallet apunte a cualquier otro contrato de manera que "copia el código" de esa dirección, a esto le llamamos delegación de wallet. En este ejemplo vamos a lanzar y delegar hacia un contrato Multicall7702 basado en Multicall que es un contrato que agrupa varias transacciónes pero adapaté para EIP-7702 pues solo permite al creador del contrato ejecutarlo. De no hacerlo, tu wallet quedaría expuesta.

Primero lanzaremos el contrato Multicall7702 y luego haremos que nuestra wallet apunte hacia ese contrato.

Las interfaces de wallet aún no soportan EIP-7702, así que por ahora usaremos foundry en su lugar. Además, como desarrolladores de dApps no deberíamos de preocuparnos por realizar delegación en nuestras interfaces. Por razones de seguridad esto debería implementarse a nivel de Wallet, no de dApp.

Lanza el Contrato Multicall7702

Lanza el siguiente contrato en la red que deses probar este ejemplo y guarda el address. Yo lo lanzaré en Scroll Testnet, donde puedes conectarte desde chainlist y obtener fondos en el faucet envíando un mensaje a @scroll_up_sepolia_bot y luego escribir /drop 0xTU_WALLET_ADDRESS en el chat de faucet.

Si lanzas en otra chain explicaré durante el proceso qué cambios debes hacer.

El único cambio que debes realizar antes de lanzar este contrato es reemplazar 0xTU_DIRECCION_EOA con la wallet que deseas convertir en EOA.

// SPDX-License-Identifier: MIT
// Derivado del Multicall3 de Makerdao
// NO HA SIDO AUDITADO, NO USAR EN PRODUCCIÓN
pragma solidity 0.8.12;

contract Multicall7702 {
    struct Call3Value { address target; bool allowFailure; uint256 value; bytes callData; }
    struct Result { bool success; bytes returnData; }

    address immutable public owner = 0xTU_DIRECCION_EOA;

    function aggregate3Value(Call3Value[] calldata calls) public payable returns (Result[] memory returnData) {
        require(owner == msg.sender, "Only owner"); // Added this to prevent others from executing transactions on your behalf
        uint256 valAccumulator;
        uint256 length = calls.length;
        returnData = new Result[](length);
        Call3Value calldata calli;
        for (uint256 i = 0; i < length;) {
            Result memory result = returnData[i];
            calli = calls[i];
            uint256 val = calli.value;
            unchecked { valAccumulator += val; }
            (result.success, result.returnData) = calli.target.call{value: val}(calli.callData);
            assembly {
                if iszero(or(calldataload(add(calli, 0x20)), mload(result))) {
                    mstore(0x00, 0x08c379a000000000000000000000000000000000000000000000000000000000)
                    mstore(0x04, 0x0000000000000000000000000000000000000000000000000000000000000020)
                    mstore(0x24, 0x0000000000000000000000000000000000000000000000000000000000000017)
                    mstore(0x44, 0x4d756c746963616c6c333a2063616c6c206661696c6564000000000000000000)
                    revert(0x00, 0x84)
                }
            }
            unchecked { ++i; }
        }
        require(msg.value == valAccumulator, "Multicall3: valor incorrecto");
    }
}

Delega tu Wallet a Multicall7702

Instala foundry si no lo tienes.

curl -L https://foundry.paradigm.xyz | bash
foundryup

Para delegar tu wallet ejecuta el siguiente comando reemplazando los valores de TU_LLAVE_PRIVADA y 0xDIRECCION_DE_TU_CONTRATO. Se deseas lanzar en otra chain, cambia la --rpc-url que puedes obtener desde Chainlist.

cast send \
  --rpc-url https://scroll-public.scroll-testnet.quiknode.pro \
  --private-key TU_LLAVE_PRIVADA \
  --auth 0xDIRECCION_DE_TU_CONTRATO $(cast az)

Puedes verificar que la delegación fue exitosa con este comando.

cast code \
  --rpc-url https://scroll-public.scroll-testnet.quiknode.pro \
  0xTU_DIRECCION_EOA

Donde deberías la dirección de Multicall7702 en el siguiente formato.

0xef0100TU_DIRECCION_EOA

Esto es el prefijo de delegación EIP-7702 0xef0100 más la dirección del contrato. Esto significa que tu wallet apunta hacia el codigo de tu contrato Multicall7702.

Construye el Fontend

A continación realizaremos un frontend con el código mínimo para tener un demo funcional del EIP-7702. Con todo el código comentado para que puedas entender qué se necesita para ser compatible con este nuevo estándar.

En nuestra dApp, el usuario será capáz de seleccionar una cantidad de WBTC que desea obtener como préstamo respaldado por DAI. Si deseas usar otras monedas también indicaré los cambios necesarios que debes realizar.

Vamos a construir una implementación muy simple de una dApp habilitada con EIP-7702

Vamos a ocupar dos archivos, index.html para describir toda la UI y blockchain_stuff.js para toda la lógica.

Crea una carpeta nueva y colócalos uno al lado del otro.

index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
</head>
<body>
  <input id="connect_button" type="button" value="Connect" onclick="connectWallet()" style="display: block"></input>
  <p id="account_address" style="display: none"></p>
  <p id="web3_message"></p>
  <p id="contract_state"></p>
  <label for="lending_token_amount">DAI supply amount:</label>
  <input type="input" value="" id="lending_token_amount" placeholder="e.g. 1000"></input>
  <br>
  <label for="borrowed_token_amount">WBTC borrow amount:</label>
  <input type="input" value="" id="borrowed_token_amount" placeholder="e.g. 0.005"></input>
  <br>
  <input type="button" value="One click loan" onclick="_oneClickLoan()"></input>
  <br>
  <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/web3/1.3.5/web3.min.js"></script>
  <script type="text/javascript" src="blockchain_stuff.js"></script>
</body>
</html>

<script>
  function _oneClickLoan()
  {
    lendingTokenAmount = document.getElementById("lending_token_amount").value
    borrowedTokenAmount = document.getElementById("borrowed_token_amount").value
    oneClickLoan(lendingTokenAmount, borrowedTokenAmount)
  }
</script>

En cuanto a javascript el siguiente archivo contiene toda la lógica necesaria para conectar tu wallet e interactuar con tu wallet como si fuera un contrato.

Si deseas lanzar en una chain que no sea Scroll Sepolia deberás editar el NETWORK_ID y también edita LENDING_ADDRESS y BORROWED_TOKEN para seleccionar los tokens que quieras como préstamo y colateral. Finalmente edita la AAVE_POOL_ADDRESS en base a los deployments oficiales de Aave.

blockchain_stuff.js

// Si deseas lanzarlo en otra red edita esto
const NETWORK_ID = 534351 // Scroll Sepolia

// Edita los siguientes datos
const LENDING_ADDRESS = "0x7984e363c38b590bb4ca35aed5133ef2c6619c40" //Aave Testnet DAI en Scroll Sepolia
const BORROWED_TOKEN = "0x5ea79f3190ff37418d42f9b2618688494dbd9693" //Aave Testnet WBTC en Scroll Sepolia
const AAVE_POOL_ADDRESS = "0x48914C788295b5db23aF2b5F0B3BE775C4eA9440" // Aave Testnet Pool en Scroll Sepolia

// ABIs que usaremos, para mantener el código más limpio podrías crear archivos json con cada ABI
const MULTICALL_ABI = [
  {
    "inputs": [
      {
        "components": [
          {"internalType": "address", "name": "target", "type": "address"},
          {"internalType": "bool", "name": "allowFailure", "type": "bool"},
          {"internalType": "uint256", "name": "value", "type": "uint256"},
          {"internalType": "bytes", "name": "callData", "type": "bytes"}
        ],
        "internalType": "struct Multicall3.Call3Value[]",
        "name": "calls",
        "type": "tuple[]"
      }
    ],
    "name": "aggregate3Value",
    "outputs": [
      {
        "components": [
          {"internalType": "bool", "name": "success", "type": "bool"},
          {"internalType": "bytes", "name": "returnData", "type": "bytes"}
        ],
        "internalType": "struct Multicall3.Result[]",
        "name": "returnData",
        "type": "tuple[]"
      }
    ],
    "stateMutability": "payable",
    "type": "function"
  }
];

const ERC20_ABI = [
  {
    "inputs": [
      {"internalType": "address", "name": "spender", "type": "address"},
      {"internalType": "uint256", "name": "value", "type": "uint256"}
    ],
    "name": "approve",
    "outputs": [
      {"internalType": "bool", "name": "", "type": "bool"}
    ],
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "inputs": [],
    "name": "decimals",
    "outputs": [
      {"internalType": "uint8", "name": "", "type": "uint8"}
    ],
    "stateMutability": "view",
    "type": "function"
  }
];

const AAVE_POOL_ABI = [
  {
    "inputs": [
      {"internalType": "address", "name": "asset", "type": "address"},
      {"internalType": "uint256", "name": "amount", "type": "uint256"},
      {"internalType": "address", "name": "onBehalfOf", "type": "address"},
      {"internalType": "uint16", "name": "referralCode", "type": "uint16"}
    ],
    "name": "supply",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "inputs": [
      {"internalType": "address", "name": "asset", "type": "address"},
      {"internalType": "uint256", "name": "amount", "type": "uint256"},
      {"internalType": "uint256", "name": "interestRateMode", "type": "uint256"},
      {"internalType": "uint16", "name": "referralCode", "type": "uint16"},
      {"internalType": "address", "name": "onBehalfOf", "type": "address"}
    ],
    "name": "borrow",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  }
];

// Variables que usaremos
var lendingTokenContract
var borrowedTokenContract
var aavePoolContract
var myERC7702Account

var accounts
var web3

// Cuando el usuario cambie de cuenta o red, se refresca la página
function metamaskReloadCallback() {
  window.ethereum.on('accountsChanged', (accounts) => {
    document.getElementById("web3_message").textContent="Se cambió el account, refrescando...";
    window.location.reload()
  })
  window.ethereum.on('networkChanged', (accounts) => {
    document.getElementById("web3_message").textContent="Se el network, refrescando...";
    window.location.reload()
  })
}

// Función para inicializar web3
const getWeb3 = async () => {
  return new Promise((resolve, reject) => {

    if(document.readyState=="complete")
    {


      if (window.ethereum) {
        const web3 = new Web3(window.ethereum)
        window.location.reload()
        resolve(web3)
      } else {
        reject("must install MetaMask")
        document.getElementById("web3_message").textContent="Error: Porfavor conéctate a Metamask";
      }
    }else
    {
      window.addEventListener("load", async () => {
        if (window.ethereum) {
          const web3 = new Web3(window.ethereum)
          resolve(web3)
        } else {
          reject("must install MetaMask")
          document.getElementById("web3_message").textContent="Error: Please install Metamask";
        }
      });
    }
  });
};

// Función para iniciar la app, lee los contractos y conecta la wallet
async function loadDapp() {
  metamaskReloadCallback()
  document.getElementById("web3_message").textContent="Please connect to Metamask"
  var awaitWeb3 = async function () {
    web3 = await getWeb3()
    web3.eth.net.getId((err, netId) => {
      if (netId == NETWORK_ID) {
        var awaitContract = async function () {
          lendingTokenContract = new web3.eth.Contract(ERC20_ABI, LENDING_ADDRESS);
          borrowedTokenContract = new web3.eth.Contract(ERC20_ABI, BORROWED_TOKEN);
          aavePoolContract = new web3.eth.Contract(AAVE_POOL_ABI, AAVE_POOL_ADDRESS);

          document.getElementById("web3_message").textContent="You are connected to Metamask"
          onContractsInitCallback()
          web3.eth.getAccounts(function(err, _accounts){
            accounts = _accounts
            if (err != null)
            {
              console.error("An error occurred: "+err)
            } else if (accounts.length > 0)
            {
              onWalletConnectedCallback()
              document.getElementById("account_address").style.display = "block"
            } else
            {
              document.getElementById("connect_button").style.display = "block"
            }
          });
        };
        awaitContract();
      } else {
        document.getElementById("web3_message").textContent="Please connect to Goerli";
      }
    });
  };
  awaitWeb3();
}

async function connectWallet() {
  await window.ethereum.request({ method: "eth_requestAccounts" })
  accounts = await web3.eth.getAccounts()
  onWalletConnectedCallback()
}

loadDapp()

// Este callback se ejecuta cuando se han cargado los contractos, usualmente aquí puedes leer los datos de los contractos
const onContractsInitCallback = async () => {
}

// Este callback se ejecuta cuando se ha conectado la wallet, en este caso asignamos el contracto de multicall a nuestra wallet 7702
const onWalletConnectedCallback = async () => {
  myERC7702Account = new web3.eth.Contract(MULTICALL_ABI, accounts[0]);
}

// Función que se llama desde el frontend que recibe las cantidades del préstamo
const oneClickLoan = async (lendingTokenAmount, borrowedTokenAmount) => {
    // Convierte de formato ether a wei dependiendo de la cantidad de decimales de cada token
    const scrDecimals = await lendingTokenContract.methods.decimals().call();
    const borrowedDecimals = await borrowedTokenContract.methods.decimals().call();
    const supplyAmount = Web3.utils.toBN(
        (parseFloat(lendingTokenAmount) * Math.pow(10, parseInt(scrDecimals))).toLocaleString('fullwide', {useGrouping:false})
    );
    const borrowAmount = Web3.utils.toBN(
        (parseFloat(borrowedTokenAmount) * Math.pow(10, parseInt(borrowedDecimals))).toLocaleString('fullwide', {useGrouping:false})
    );

    // Generamos las llamadas de los contratos y las encodeamos de manera que sea compatible con nuestro contrato de multicall
    const approveCall = lendingTokenContract.methods.approve(AAVE_POOL_ADDRESS, supplyAmount).encodeABI();
    const supplyCall = aavePoolContract.methods.supply(LENDING_ADDRESS, supplyAmount, accounts[0], 0).encodeABI();
    const interestRateMode = 2;
    const referralCode = 0;
    const borrowCall = aavePoolContract.methods.borrow(
        BORROWED_TOKEN,
        borrowAmount.toString(),
        interestRateMode,
        referralCode,
        accounts[0]
    ).encodeABI();

    const calls = [
        {
          target: LENDING_ADDRESS,
          allowFailure: false,
          value: 0,
          callData: approveCall
        },
        {
          target: AAVE_POOL_ADDRESS,
          allowFailure: false,
          value: 0,
          callData: supplyCall
        },
        {
          target: AAVE_POOL_ADDRESS,
          allowFailure: false,
          value: 0,
          callData: borrowCall
        }
      ];

      // Ejecutamos la llamada dirigida a nuestra wallet 7702
      const result = await myERC7702Account.methods.aggregate3Value(calls)
      .send({ from: accounts[0], gas: 0, value: 0 })
      .on('transactionHash', function(hash){
        document.getElementById("web3_message").textContent="Executing...";
      })
      .on('receipt', function(receipt){
        document.getElementById("web3_message").textContent="Success.";    })
      .catch((revertReason) => {
        console.log("ERROR! Transaction reverted: " + revertReason.receipt.transactionHash)
      });
}

Prueba tu dApp

Instala Node si aún no lo tienes. Te recomiendo instalarlo a través de NVM.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
nvm install 22
# Reinicia o recarga tu terminal

Instala un servidor web.

npm i -g lite-server

I levanta el frontend.

lite-server

Tu webapp debería estár en http://localhost:3000.

Una vez obtengas tu préstamo puedes ver el detalle de lo ocurrido en Etherscan y en el frontend de Aave.

En Etherscan podrás ver el detalle de todas las transacciones agrupadas en una sola

Para seguir aprendiendo sobre esta y otras nuevas funcionalidades que hace posible este cambio puedes ver la Especificación EIP-7702.

¡Gracias por ver este artículo!

Sígueme en dev.to y en Youtube para todo lo relacionado al desarrollo en Blockchain en Español.

Cómo crear una dApp en Tiempo Real en Ethereum sin código espagueti

Ahmed Castro — Fri, 18 Jul 2025 16:07:48 +0000

Dediqué dos semanas construyendo una dApp en tiempo real, y este artículo resume cómo tuve que repensar la arquitectura, el diseño y la experiencia de usuario para una blockchain con bloques de 10ms.

La dApp que construimos con un amigo es un juego de carta alta simple: el jugador y la casa sacan una carta y gana la más alta. El reto es generar números aleatorios 100% on-chain con la menor latencia posible.

¿Un Casino?

Sí!

Hay algo que me gusta de los casinos. Entiendo que los jugadores deben ser responsables y que pueden ser peligrosos, pero aún así, simplemente me gustan.

De hecho, la primera aplicación blockchain que lancé fue un casino.

Eso fue en 2013, era un backend en Ruby on Rails conectado a un nodo local de Dogecoin que corría en mi máquina.

No existían los contratos inteligentes, así que decidí bajarlo porque no tenía forma de probar que operaba de manera justa.

Soy de un país del tercer mundo donde construir cosas es difícil, y en ese entonces era aún más complicado. Ese proyecto fue muy significativo para mí porque fue la primera vez que monetizaba mi trabajo, y también porque me permitió conectar con mucha gente a través de IRC. Bonitos recuerdos!

Después aprendí sobre los smart contract de Ethereum y decidí intentarlo de nuevo, esta vez usando Chainlink VRF.

Mi segundo intento fue Breadacle, un juego de lanzar una moneda donde apuestas si el pan sale tostado o quemado.

Ahora podía demostrar que mi juego es justo, que no estaba haciendo trampa pero era demasiado lento. También era caro, y tenía a los oráculos como dependencia, tenía que confiar en ellos.

Construyendo un juego justo y rápido

Hoy, con blockchain baja latencia, pude construir un juego rápido, verificable y sin oráculos.

Esta vez lo hice con un esquema de Commit-Reveal, un proceso de 3 transacciones que deben ejecutarse muy rápido.

Actualmente nuestro demo tiene una latencia promedio de 1.3s por partida. Esto significa 3 transacciones ocurrieron en 1.3 segundos, lo cual nos parece que está bien, pero no es suficiente. Creemos que podemos bajarlo a menos de 500ms con mejoras en la infraestructura de blockchain rápidas combinadas con nuestras propias optimizaciones.

En esta arquitectura, el jugador ejecuta el cliente en su browser, y la casa (o sea yo) hostea un backend que responde a cada partida de los jugadores.

Cómo funciona el Backend

Para poder servir a muchos jugadores, el backend necesita escuchar nuevas partidas, indexarlas en memoria y procesarlas en batch con Multicall.

En caso de caídas, podemos tener una base de datos centralizada como respaldo. O mejor aún, usar el estado on-chain como recuperación. A lo que me refiero es usar la blockchain como backup, lo cual me parece bastante interesante.

Alternativamente, si los RPCs públicos son demasiado lentos para los jugadores, podemos abrir un endpoint para consultar el estado del juego desde nuestro servidor. Esto es debatible, por un lado puede hacer que el juego sea más rápido, pero por el otro significa que la casa (yo) podría engañar al jugador para que revele su número secreto antes de que yo publique el mío.

Por ahora no hemos podido probar esto completamente porque el juego lo construimos sobre MegaETH (una cadena con bloques cada 20ms, ¡muy rápida! que en el futuro debería ser sub 10ms), pero aún no hemos conseguido acceso al WebSocket que en este momento está restringido solo a equipos internos.

Estamos listos para probarlo una vez que obtengamos esa clave WSS.

El Frontend, en mi opinión la parte más interesante

Poco a poco descubrí que construir una dApp en tiempo real es muy diferente a una dApp común o una app móvil.

Cuando hacés una dApp en tiempo real tenés que dejar de pensar en flujos de listeners/callbacks y empezar a pensar como un desarrollador de videojuegos.

Como dato adicional, y un poco de autopromoción descarada: antes era desarrollador de videojuegos. Construí mi propio motor de juegos, lancé un juego en Steam con él, desarrollé un SDK en C que fue usado por decenas de miles de jugadores concurrentemente y fui entrevistado por Unreal Engine en un stream en vivo.

Así que lo más importante que noté fue que, en lugar de programar pensando en callbacks y eventos, hay que usar un gameLoop() como este:

gameLoop() {
  readState()
  processInputs()
  sendTransactions()
  processUI()
}

Esta función procesa todo el juego y debe ser llamada continuamente a intervalos muy rápidos.

Esto es porque las apps en tiempo real, como los juegos, son muy caóticas y si intentas manejar todo con callbacks como en una dApp normal, vas a terminar con código espagueti y una UX con glitches.

Esto aplica no solo a juegos, también a DeFi, redes sociales, identidad, etc.

Cosas a tener en cuenta:

1. Leer el estado solo una vez por tick

Un tick es una vuelta del gameLoop() y deberías hacer solo una llamada call() a Ethereum. Cada llamada toma de 100ms a 300ms, son demasiado lentas.

Esto incluye verificar el nonce y el gasPrice. Así que no uses web3.js, ethers o viem — construye las transacciones manualmente. Lleva el nonce tú mismo y lee el gasPrice solo una vez cada 5 minutos.

Considera escribir una función que te devuelva toda la información que necesitas en cada tick. Me gusta llamarla “Llamada Singleton” y la mía se ve así:

function getGameState(address player) external view returns (
  uint player_balance,
  State gameState,
  bytes32 playerCommit,
  bytes32 houseHash,
  uint256 gameId,
  GameResult[] memory recentHistory
)

Devuelvo el balance del jugador para no tener que llamarlo aparte, y los últimos 10 juegos para mostrarlos en el frontend. No es elegante, pero es funcional. Alternativamente, puedes usar Multicall.

2. Buffer de inputs

Cuando el usuario hace click, no reacciones de inmediato. Guarda la acción en una lista y procésala más tarde.

Este concepto es muy común en juegos de pelea, donde necesitas presionar combinaciones precisas.

Mi juego no es tan complejo, pero aún así, en JS no tenemos control sobre los threads. Así que puedes:
a. implementar un buffer de inputs
b. entrar al infierno de los thread locks

Recomiendo empezar con una lista simple y procesar solo una acción por tick. Si tu app se siente lenta, puede ser que la chain que estás usando no sea lo suficientemente rápida.

3. Wallet en localStorage

Obviamente no quieres que el usuario tenga que confirmar cada transacción.

Así que genera una llave privada en el navegador:

function generateWallet() {
  const account = web3.eth.accounts.create();
  localStorage.setItem('localWallet', JSON.stringify({
    address: account.address,
    privateKey: account.privateKey
  }));
  return account;
}

Esto crea una wallet y la guarda en el navegador de manera que nadie que no sea tu dApp pueda accederlas. Está de más decir que esto no es para almacenar fondos a largo plazo pues si se borran los datos del navegador también se pierden los fondos.

En mi casino de 3 transacciones, puedo incluso revelar el número aleatorio automáticamente, sin que el usuario haga clic.

Esto ya lo usan juegos como Dark Forest y otros juegos de mundos autónomos.

4. Paralelización

Piensa en cómo hacer cada acción lo antes posible y cómo dar feedback al jugador rápidamente.

En mi caso, puedo iniciar un nuevo juego incluso antes de que el anterior termine.

Normalmente sería:

El jugador envía el commit
El jugador detecta que la casa respondió
El jugador envía el reveal

Podemos paralelizar iniciando un nuevo juego antes de que el reveal esté confirmado on-chain siempre y cuando supongamos que el secuenciador ordenará todo en FIFO.

Además, cuando el jugador ya tiene el número de la casa, puede calcular el resultado sin esperar a que esté on-chain.

Esto lo llamo “Renderizado Optimista”.

Estas optimizaciones son importantes, pero como no controlamos al secuenciador, debemos implementar formas de recuperación o reintento automático si algo no ocurrió como esperamos.

¡Gracias por ver este artículo!

Sígueme en dev.to y en Youtube para todo lo relacionado al desarrollo en Blockchain en Español.

Introducción a Préstamos Programables en Morpho

Ahmed Castro — Wed, 02 Jul 2025 19:00:06 +0000

Desde agentes de IA descentralizados hasta la automatización de tesorerías DAO y bots avanzados de trading en DeFi, las finanzas programables cada vez ofrecen nuevas posibilidades. En este tutorial aprenderemos cómo sacar un préstamo 100% on chain. Lo haremos de una manera práctica y fácil de replicar, por medio de Morpho v1 donde sacaremos un préstamo de WETH poniendo USDC como colateral en la red de Base Mainnet.

En este tutorial verás como protegerte de la volatilidad depositando USDC para sacar el préstamo de WETH en una sola transacción. Luego, cómo repagar tu deuda y recuperar el colateral. Todo de una manera personalizable que puede ser integrada en muchos casos de uso.

Préstamos Monolíticos vs. Multi‑Mercado

Protocolos grandes como Aave y Compound adoptaron una arquitectura monolítica, es decir que ofrecen un único mercado que agrupa toda la liquidez. Esto genera una piscina de liquidez grande y provee estabilidad en el mercado pero hace que los cambios en gobernanza seran más difíciles de adaptar a las condiciones de mercado.

Aave ofrece un único mercado a nivel de protocolo, mientras que Morpho adopta un enfoque de múltiples mercados.

Morpho ofrece una solución multi‑mercado, donde diferentes organizaciones pueden crear y actualizar nuevos mercados. Morpho llama a estas organizaciones Curadores, y los usuarios pueden elegir entrar al mercado de curadores que prefieran. Los Curadores establecen sus propios parámetros como ser token prestado, token de colateral, el módulo de tasa de interés (IRM), oráculo, relación de colateralización, etc., mientras que Morpho proporciona la infraestructura y el motor de emparejamiento. El resultado es una mayor flexibilidad de mercados y más opciones para los usuarios, todo accedido desde una interfaz unificada.

La API de Morpho

Morpho ofrece cuatro funciones principales:

supplyCollateral: Deposita colateral para luego poder pedir un préstamo.
borrow: Obtiene los fondos del préstamo.
repay: Devuelve los fondos prestado más intereses.
withdrawCollateral: Recupera tu colateral una vez saldada la deuda.

Para hacerlo más simple, nuestro contrato vá a agruparsupplyCollateral + borrow en una sola función llamada borrowAgainstCollateral() call, y repay + withdrawCollateral en repayAndWithdraw().

Parámetros de mercado

En cada llamada, Morpho espera un struct llamado MarketParams que contiene la información del mercado en el que vamos a participar. Esto es porque Morpho soporta muchos mercados.

struct MarketParams {
    address loanToken;
    address collateralToken;
    address oracle;
    address irm;
    uint256 lltv;
}

En este ejemplo vamos a usar un mercado de WETH/USDC en Base con los parámetros a continuación:

Contrato de morpho en base: 0xBBBBBbbBBb9cC5e90e3b3Af64bdAF62C37EEFFCb
loanToken token del préstamo: 0x4200000000000000000000000000000000000006 (WETH)
collateralToken token colateral: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 (USDC)
oracle oráculo proveedor de precios: 0xD09048c8B568Dbf5f189302beA26c9edABFC4858
irm dirección de curva adaptativa: 0x46415998764C29aB2a25CbeA6254146D50D22687
lltv: 860000000000000000 (86 % ratio sobrecolateralización)

Si quieres usar otro mercado, cambia estas direcciones (todas están disponibles en la documentación de Morpho y la webapp de Morpho).

El mercado que usamos en este demo está disponible aquí.

Cada Curador puede elegir los pares colateral y préstamo, dependiendo de la oferta y demanda. También pueden escoger el oráculo más descentralizado que cubra un mercado específico (en este caso, Chainlink). Esto es muy importante ya que los oráculos son la parte menos descentralizada de un protocolo de préstamos. Además, dependiendo de la liquidez y volatilidad del mercado, los Curadores pueden fijar el nivel de sobrecolateralización necesario para tomar un préstamo, e incluso modificar cómo se adapta automáticamente en función de la liquidez del mercado mediante la curva adaptativa.

Implementación en Solidity

El contrato abstrae el proceso en dos funciones, una de préstamo y otra de pago.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";

// IERC20 interface needed to interact with USDC and WETH
interface IERC20 {
    function approve(address spender, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address recipient, uint256 amount) external returns (bool);
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
}

// Morpho interface to get and repay loans
interface IMorpho{
    struct MarketParams {
        address loanToken;
        address collateralToken;
        address oracle;
        address irm;
        uint256 lltv;
    }

    function supplyCollateral(
        MarketParams calldata marketParams,
        uint256 amount,
        address onBehalf,
        bytes calldata data
    ) external;

    function borrow(
        MarketParams calldata marketParams,
        uint256 amount,
        uint256 maxShares,
        address onBehalf,
        address receiver
    ) external returns (uint256 assetsBorrowed, uint256 sharesBorrowed);

    function repay(
        MarketParams calldata marketParams,
        uint256 amount,
        uint256 maxShares,
        address onBehalf,
        bytes calldata data
    ) external returns (uint256 assetsRepaid, uint256 sharesRepaid);

    function withdrawCollateral(
        MarketParams calldata marketParams,
        uint256 amount,
        address onBehalf,
        address receiver
    ) external;
}

// Demo contrat that abstracts borrowing and repayment into two functions
contract MorphoBorrower is Ownable {
    address public constant morphoAddress = 0xBBBBBbbBBb9cC5e90e3b3Af64bdAF62C37EEFFCb;     // Morpho address on Base

    address public constant loanToken = 0x4200000000000000000000000000000000000006;         // WETH on base
    address public constant collateralToken = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913;   // USDC on base
    address public constant oracle = 0xD09048c8B568Dbf5f189302beA26c9edABFC4858;            // Chainlink oracle for our market
    address public constant irm = 0x46415998764C29aB2a25CbeA6254146D50D22687;               // Adaptative curve strategy for our market
    uint256 public constant lltv = 860000000000000000;                                      // 86% loan to liquidation treshold

    constructor() Ownable(msg.sender) {}

    // Our target morpho market settings
    IMorpho.MarketParams public marketParams = IMorpho.MarketParams({
        loanToken: loanToken,
        collateralToken: collateralToken,
        oracle: oracle,
        irm: irm,
        lltv: lltv
    });

    uint256 public sharesBorrowed; // Asset borrow tracking

    // Borrow WETH against USDC
    function borrowAgainstCollateral(uint256 collateralAmount, uint256 borrowAmount) external onlyOwner {
        // Transfer USDC from user and supply it as collateral in the Morpho market
        IERC20(collateralToken).transferFrom(msg.sender, address(this), collateralAmount);
        IERC20(collateralToken).approve(morphoAddress, collateralAmount);
        IMorpho(morphoAddress).supplyCollateral(
            marketParams,
            collateralAmount,
            address(this),
            ""
        );

        // Open a borrow position on this smart contract account and transfer the borrowed WETH to the user
        (uint256 assetsBorrowed, uint256 shares) = IMorpho(morphoAddress).borrow(
            marketParams,
            borrowAmount,
            0,
            address(this),
            address(this)
        );
        sharesBorrowed = shares;
        IERC20(loanToken).transfer(msg.sender, assetsBorrowed);
    }

    function repayAndWithdraw(uint256 repayAmount, uint256 collateralAmount) external onlyOwner {
        // Transfer WETH from the user and repay the debt with it
        IERC20(loanToken).transferFrom(msg.sender, address(this), repayAmount);
        IERC20(loanToken).approve(morphoAddress, repayAmount);
        IMorpho(morphoAddress).repay(
            marketParams,
            0,
            sharesBorrowed,
            address(this),
            ""
        );

        // Transfer back excess loanToken
        IERC20(loanToken).transfer(msg.sender, IERC20(loanToken).balanceOf(address(this)));

        // Withdraw all collateral and send to sender
        IMorpho(morphoAddress).withdrawCollateral(
            marketParams,
            collateralAmount,
            address(this),
            msg.sender
        );
    }
}

Cómo usarlo

En la página de USDC en BaseScan, llama a approve(spender, amount) pasando como parámetro el contrato de MorphoBorower que recien lanzaste y la cantidad de USDC que vas a depositar, por ejemplo 3000, o sea 0.003 USDC ya que USDC tiene 6 decimales.

Aprueba tu contrato en la página de USDC en BaseScan.

Luego, saca un préstamo de WETH llamando a borrowAgainstCollateral(3000, 1_000_000_000), es decir, 0.003 USDC como colateral para pedir prestado 0.000000001 WETH. En este punto, el WETH estará en tu billetera y podrás usarlo como gustes.

Prueba solicitando 0.000000001 WETH con 0.003 USDC de colateral. Puedes ver un ejemplo de transacción aquí.

Para pagar tu deuda, aprueba WETH en BaseScan con una cantidad suficiente para cubrir capital + intereses (ej. 1_010_000_000). Luego llama a repayAndWithdraw(1_010_000_000, 3000). Cualquier WETH sobrante será reembolsado automáticamente y recuperarás tus 0.003 USDC.

Cuando tu deuda es saldada, todo el WETH sobrante será devuelto. Puedes ver un ejemplo transacción aquí.

¡Gracias por ver este artículo!

Sígueme en dev.to y en Youtube para todo lo relacionado al desarrollo en Blockchain en Español.

Intro to Programatic Loans in Morpho

Ahmed Castro — Wed, 18 Jun 2025 18:30:12 +0000

From decentralized AI agents to automated DAO‑treasury management and advanced DeFi trading bots, programmable finance has been rising and offers many new possibilities. In this tutorial we’ll learn-by-doing one such use case: taking out a loan by interacting with Morpho v1 to borrow WETH against USDC on Base.

Throughout the guide you’ll learn not only how to deposit USDC and borrow WETH in a single transaction, but also how to repay your debt and retrieve your collateral. You’ll see how to parameterize your calls so that you can switch to any other Morpho market and add your own custom code.

Monolithic vs. Multi‑Market Lending

Major protocols like Aave and Compound adopt a monolithic architecture: a single, unified market pools liquidity across all assets. This yields deep reserves and stability but makes governance changes harder to adapt to the ever changing market conditions.

Aave offers a single market protocol-wide, while Morpho a multi-market approach.

Morpho instead provides a multi‑market framework. Each whitelisted organizations can create and update new markets, Morpho call this organizations "Curators" and users can select to enter on the market created by the Curators of their choice. Curators manage their own parameters: loan token, collateral token, interest‑rate module (IRM), oracle, collateralization ratio, etc. while Morpho itself supplies the infrastructure and matching engine. The result is flexible markets and more options for users, all accessed via a unified interface.

The Morpho API

Morpho exposes four core functions to manage collateralized loans:

supplyCollateral: Deposit collateral so you can borrow.
borrow: Draw loan assets up to your borrowing power.
repay: Return borrowed principal plus interest.
withdrawCollateral: Retrieve your collateral once you’ve repaid.

For simplicity, our contract will wrap supplyCollateral + borrow into a single borrowAgainstCollateral() call, and repay + withdrawCollateral into repayAndWithdraw().

Market parameters

Because Morpho supports multiple markets, every call requires a MarketParams struct:

struct MarketParams {
    address loanToken;
    address collateralToken;
    address oracle;
    address irm;
    uint256 lltv;
}

In this example we’ll target the WETH/USDC market on Base:

Parameter	Description	Address / Value
Morpho contract	Base deployment	`0xBBBBBbbBBb9cC5e90e3b3Af64bdAF62C37EEFFCb`
`loanToken`	WETH	`0x4200000000000000000000000000000000000006`
`collateralToken`	USDC	`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`
`oracle`	On‑chain price feed	`0xD09048c8B568Dbf5f189302beA26c9edABFC4858`
`irm`	Adaptive‑Curve IRM	`0x46415998764C29aB2a25CbeA6254146D50D22687`
`lltv`	86 % liquidation-to-loan ratio (0.86 × 1e18)	`860000000000000000`

If you want to target a different market, simply swap out these addresses (all available in Morpho’s documentation and the morpho page.

You can get your target market from the Morpho app, in our demo we will target this market.

Each Morpho Market Curator can choose their desired collateral and loan token pairs based on market supply and demand. They can also choose their oracle of choice, this is very important because oracles are the least decentralized parts of a lending protocol so Curators can chose the most decentralized one that offers a specific market. In this case is chainlink. And also, depending on market liquidity and volatility they can choose a liquidation threshold, this means the amount of overcolateralization needed to get a loan, also curators can choose the way the liquidation threshold changes depending on market liquidity.

Solidity Implementation

Our contract will abstract the borrowing and repayment process into two single transactions.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";

// IERC20 interface needed to interact with USDC and WETH
interface IERC20 {
    function approve(address spender, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address recipient, uint256 amount) external returns (bool);
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
}

// Morpho interface to get and repay loans
interface IMorpho{
    struct MarketParams {
        address loanToken;
        address collateralToken;
        address oracle;
        address irm;
        uint256 lltv;
    }

    function supplyCollateral(
        MarketParams calldata marketParams,
        uint256 amount,
        address onBehalf,
        bytes calldata data
    ) external;

    function borrow(
        MarketParams calldata marketParams,
        uint256 amount,
        uint256 maxShares,
        address onBehalf,
        address receiver
    ) external returns (uint256 assetsBorrowed, uint256 sharesBorrowed);

    function repay(
        MarketParams calldata marketParams,
        uint256 amount,
        uint256 maxShares,
        address onBehalf,
        bytes calldata data
    ) external returns (uint256 assetsRepaid, uint256 sharesRepaid);

    function withdrawCollateral(
        MarketParams calldata marketParams,
        uint256 amount,
        address onBehalf,
        address receiver
    ) external;
}

// Demo contrat that abstracts borrowing and repayment into two functions
contract MorphoBorrower is Ownable {
    address public constant morphoAddress = 0xBBBBBbbBBb9cC5e90e3b3Af64bdAF62C37EEFFCb;     // Morpho address on Base

    address public constant loanToken = 0x4200000000000000000000000000000000000006;         // WETH on base
    address public constant collateralToken = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913;   // USDC on base
    address public constant oracle = 0xD09048c8B568Dbf5f189302beA26c9edABFC4858;            // Chainlink oracle for our market
    address public constant irm = 0x46415998764C29aB2a25CbeA6254146D50D22687;               // Adaptative curve strategy for our market
    uint256 public constant lltv = 860000000000000000;                                      // 86% loan to liquidation treshold

    constructor() Ownable(msg.sender) {}

    // Our target morpho market settings
    IMorpho.MarketParams public marketParams = IMorpho.MarketParams({
        loanToken: loanToken,
        collateralToken: collateralToken,
        oracle: oracle,
        irm: irm,
        lltv: lltv
    });

    uint256 public sharesBorrowed; // Asset borrow tracking

    // Borrow WETH against USDC
    function borrowAgainstCollateral(uint256 collateralAmount, uint256 borrowAmount) external onlyOwner {
        // Transfer USDC from user and supply it as collateral in the Morpho market
        IERC20(collateralToken).transferFrom(msg.sender, address(this), collateralAmount);
        IERC20(collateralToken).approve(morphoAddress, collateralAmount);
        IMorpho(morphoAddress).supplyCollateral(
            marketParams,
            collateralAmount,
            address(this),
            ""
        );

        // Open a borrow position on this smart contract account and transfer the borrowed WETH to the user
        (uint256 assetsBorrowed, uint256 shares) = IMorpho(morphoAddress).borrow(
            marketParams,
            borrowAmount,
            0,
            address(this),
            address(this)
        );
        sharesBorrowed = shares;
        IERC20(loanToken).transfer(msg.sender, assetsBorrowed);
    }

    function repayAndWithdraw(uint256 repayAmount, uint256 collateralAmount) external onlyOwner {
        // Transfer WETH from the user and repay the debt with it
        IERC20(loanToken).transferFrom(msg.sender, address(this), repayAmount);
        IERC20(loanToken).approve(morphoAddress, repayAmount);
        IMorpho(morphoAddress).repay(
            marketParams,
            0,
            sharesBorrowed,
            address(this),
            ""
        );

        // Transfer back excess loanToken
        IERC20(loanToken).transfer(msg.sender, IERC20(loanToken).balanceOf(address(this)));

        // Withdraw all collateral and send to sender
        IMorpho(morphoAddress).withdrawCollateral(
            marketParams,
            collateralAmount,
            address(this),
            msg.sender
        );
    }
}

How to Use

On the BaseScan's USDC page, call approve(spender, amount) by setting your MorphoBorrower address as spender and e.g. 3000 (which equals 0.003 USDC, since USDC has 6 decimals).

Approve your contract from BaseScan's USDC page.

Then, borrow ETH by calling borrowAgainstCollateral(3000, 1_000_000_000) that is, 0.003 USDC collateral to borrow 0.000000001 WETH. At this point the WETH will be in your wallet and you are free to use it.

Try getting a 0.000000001 WETH with a 0.0003 collateral. Explore an on-chain example here.

To repay your debt, approve WETH on BaseScan using enough to cover principal + interest (e.g. 1_010_000_000). Then call repayAndWithdraw(1_010_000_000, 3000). Any excess WETH will automatically be refunded, and you’ll receive back your 0.003 USDC.

When the debt is repayed, notice how all excess WETH is sent back to us. Explore the on-chain transaction here.

Congratulations! You’ve now interacted with Morpho v1 to take out and repay a loan. From here you can retarget any other Morpho market by swapping out the addresses in MarketParams, or integrate these functions into your own dApp, DAO workflow or AI agent for fully programmable lending strategies.

How to make an Ethereum Real-Time dApp with no Spaghetti code

Ahmed Castro — Sat, 31 May 2025 18:55:13 +0000

I spent two weeks building a real time dApp and this article summarizes how I had to rethink architecture, design and UX for very fast blocktimes.

The dApp that my friend and I built is a simple War game: the player and the house each draw a card, and the highest card wins. The challenge is generating 100% on-chain random numbers with the lowest latency possible.

A betting game?

Yes! I personally have a thing for casinos. I understand that players have to be responsible when playing and that they can be dangerous, but still, I just happen to like them.

As a matter of fact, the first blockchain application I released was a casino.

That was on 2013, it was a Ruby on Rails backend connecting a local Dogecoin node I ran.

There were no smart contracts so I decided to take it down because I had no way to prove that I was operating in a fair manner.

I'm from a 3rd world country where building is hard, and back then it was harder. This was my first time monetizing my work so that project was very meaningful to me, also I was able to connect to many people trough IRC. Fun times!

Then, I learned about Ethereum smart contracts and decided to give it another try, this time using Chainlink VRF.

My second aptempt was Breadacle, a coin toss game where you bet if the bread will come out toasted or burnt.

Now my game had great provably guarantees of fairness, but was way too slow. Also a bit expensive and still had to trust the oracles.

Building a fast and fair game

Now, with blockchains with low latency I can build a fast, provably fair, oracleless game.

This time I did it with a Commit-Reveal scheme. A 3 transaction process that has to happen very fast.

Currently, our demo offers 1.3s average gameplay latency, this means 3 transactions in 1.3s which we think it's ok but not good enough. We believe we can bring it down to sub 500ms times with improvements in real time chains infra optimization and our own too.

In this architecture the player runs the client in their browser and the house (me) hosts a backend that responds to each players game.

Let's explore both starting with the backend

To be able to serve many players, the backend need to listen to new player games, index them in memory, and batch them with Multicall.

In case of down time, we can have a centralized database that serves as backup. Or better yet, using the on-chain state to recover. So what I'm saying is using the chain as backup, quite interesting IMO.

Alternatively, in case public RPCs for players are too slow, we can open an endpoint to query the game state from our server. This is debatable, on one had hand this can make the game more responsive but on the other it means that the house (me) could trick the player to reveal his random number before I post mine.

In this point in time we haven't been able to test in fullness beacuse we built the game in MegaETH (a 20ms block time chain, very fast!) but we haven't been able to access a web socket that right now is restricted to internal teams only.

We are ready to test it once we get access to that WSS key.

Let's now talk about the frontend, imo the most interesting part.

The frontend

Little by little I found out that building a real time ethereum dApp is very different from a normal dApp frontend or moblile app.

When building a real time dApp we have to stop thinking about listener/callback flows and start thinking similar to what a gamedev would.

As a quick side note, and a shameless self promotion, I used to be a gamedev. Built my own game engine, release a game on steam with it, built a C SDK used by 10s of thousands of players concurrently and was interviewed by Unreal Engine in a livestream.

So the most important thing that I noticed is that instead of developing with a listeners and callbacks in-mind we need a gameLoop() such as

gameLoop() {
  readState()
  processInputs()
  sendTransactions()
  processUI()
}

This function process the entire game and should be called continuously with fast intervals.

This is because real time apps, just like games, are very chaotic and if you try to do everything with callbacks, like a normal dApp, you will end with spaghetti code and glitchy UX.

This should apply not only to games, but also defi, social, id, etc...

So a few things to note while doing something like this:

1. Only read the state once per tick

A tick is one gameLopp() pass and you should only make one call() to ethereum. Each call takes from 100ms to 300ms, they are too slow.

And yes, this includes nonce and gasPrice checks. So don't use web3.js, ethers or viem abstractions, build your transactions manually yourself. Do it by keeping track of your nonces locally and reading the gasPrice only once every 5 minutes or so.

Also consider writing a function that returns all the information that you will need every tick. I like to call it "Singleton Call" and currently mine looks like this:

    function getGameState(address player) external view returns (
        uint player_balance,
        State gameState,
        bytes32 playerCommit,
        bytes32 houseHash,
        uint256 gameId,
        GameResult[] memory recentHistory
    ) {
       ...
    }

Notice how I'm returning a list of the 10 latest games so I can display them in the frontend. And I'm even returning the player balance by calling player.balance internally just so I don't have to do it a separate call.

Yes, this function doesn't look elegant so a good alternative is to use Multicall instead. I like it better with no Multicall in the frontend to keep it simple, but to each their own.

2. Buffer inputs

When the user clicks a button, don't react to it immediatly. Instead, store it in a list and process it later.

This concept is very familiar in fighting games, where you have to press a very precise combination on inputs to trigger special attacks.

Of course, my game is not as complex as a fighting game but still, we don't have control of the multithreading nature of javascript. So you have two options: a. implement an input buffer b. enter the realm of thread locks hell.

I recommend starting with a list-based buffer and handling only one action per tick. Later, you can try processing multiple actions per tick or updating the UI before handling input in the game loop. But in general I would stick with a simple buffer, if the app feels unresponsive, it might be a sign that the chain you're using is not fast enough.

3. Local storage wallet

Of course you don't want your user to click to confirm every transaction. So instead generate a private key on the player's browser like this:

function generateWallet() {
  const account = web3.eth.accounts.create();
  localStorage.setItem('localWallet', JSON.stringify({
    address: account.address,
    privateKey: account.privateKey
  }));
  return account;
}

This will generate a new wallet and store it in the browser's local storage.

Of course users should not treat it as their cold storage because it just isn't. If they clean their browser data goodbye wallet.

Regardless, this will give the users a good experience. Remember that my casino game is a 3-transaction process? In my case I can even reveal the random number automatically, even without the player clicking on something.

This is currently being used by Dark forest and other autonomous world gmames.

4. Paralelization

You have to think how make every action as soon as possible and how to give feedback as fast as possible to the player.

In my case this meant that I can start a new game even before the last one finished.

So normally a game will be played like this:

Player sends commitment tx
Player detects the house responded
Player sends reveal transaction

We can parallelize by starting a new game even before the reveal is confirmed on-chain. This is expecting that our new commit will be sequenced after the reveal does.

Also, by the time the player has the house randomness he can know the game result.

So in the UI, we can show the game result even before the result is calculated on-chain.

I like to call this "Optimistic Rendering".

I think optimizations like these are very important and should be implemented, but of course, we don't have control of the sequencer. We are doing this expecting that the sequencer would operate in a FiFo manner. So we will also need to implement a way to recover and auto-retry in the rare case the sequencer didn't acted as expected.

Thanks for reading!

Please try our demo in MegaETH testnet at realtimeplay.xyz and follow us and give us feedback at @RealTimePlayXYZ.

This is open source work as always so PRs very welcome on github.

Esquema Commit-Reveal: Privacidad on-chain sin ZK

Ahmed Castro — Thu, 24 Apr 2025 15:13:02 +0000

Antes de la llegada de Zero Knowledge, ya existían algunas aplicaciones que lograban mantener cierta privacidad on-chain. Algunos ejemplos son el juego Cheese Wizards, el sistema de votaciones de Kleros o DutchX el sistema de subastas creado por Gnosis, entre otros proyectos que exploraron formas creativas de mantener datos ocultos a la vista pública de on-chain. En este artículo, vamos a estudiar de forma teórica y práctica el esquema Commit-Reveal, una técnica sencilla pero con bastante alcance que hace esto posible. Exploraremos su funcionamiento, sus limitaciones y algunos errores comunes al implementarlo.

“Adivina el número”: un juego 100% en Solidity

Para ilustrar este esquema de forma clara, vamos a construir un pequeño juego: “Adivina qué número estoy pensando”. Será una aplicación completamente on-chain, escrita únicamente en Solidity y que guarda datos privados sin necesidad de usar ZK.

En este tutorial vamos a construir un contrato de "Adivina el número".

Este juego nos permitirá introducir conceptos fundamentales como las funciones hash, que son la base de los commitments (respaldos o compromisos) usadas por este esquema.

Funciones hash

Una función hash es una función determinista que toma una entrada y produce una salida que aparenta ser aleatoria pero no lo es. Lo importante aquí es que estas funciones son irreversibles: es fácil calcular hash(a) → b, pero prácticamente imposible deducir a a partir de b.

Este comportamiento las hace ideales para almacenar secretos. Ethereum utiliza funciones hash como keccak256 en muchos contextos: desde la generación de claves públicas, hasta la construcción de bloques o el uso de mappings dentro de contratos.

A partir del hash de un valor no podemos deducir el valor original.

Adivina el número: versión ingenua

Veamos ahora una primera versión del juego en Solidity, que si bien funciona, tiene muchos problemas. ¿Puedes ver cuáles son?

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.22;

// Contrato de un ahorcado ingenuo: sujeto a diversos ataques
contract SimpleNumberGuess {
    // Has del número secreto
    bytes32 public numberCommitment;
    // Address del ganador del juego, quien lo adivine primero
    address public winner;
    // El juego inicia almacenando el hash del número por adivinar
    constructor(bytes32 _numberCommitment) {
        numberCommitment = _numberCommitment;
    }

    // Cualquier jugador participa eligiendo un número, el primero en adivinar será registrado como el ganador
    function guessNumber(uint8 guess) public {
        require(hashFunction(guess) == numberCommitment, "Invalid number");
        require(winner == address(0), "Number already guessed");
        winner = msg.sender;
    }

    // Función hash que usaremos para hashear y ocultar el número
    function hashFunction(uint8 value) public pure returns (bytes32) {
        return keccak256(abi.encodePacked(value));
    }
}

El contrato parece hacer lo correcto, guarda el hash del número secreto y permite que los jugadores lo adivinen. Pero en realidad presenta varias fallas graves.

Por un lado, cualquiera podría simplemente probar todos los números posibles (del 0 al 255 si usamos uint8) hasta encontrar uno cuyo hash coincida. Este ataque por fuerza bruta se vuelve facil de realizar si no protegemos el número con un salt.

Por otro lado, como las adivinanzas se envían en transacciones públicas, cualquier jugador podría ser frontrunneado (adelantado en la mempool por alguien que paga más gas) si su elección es la correcta.

Miremos entonces cómo el esquema Commit-Reveal lo soluciona.

¿Qué es el esquema Commit-Reveal?

El Commit-Reveal es una técnica muy común en criptografía que permite a una parte comprometerse con un valor sin revelarlo hasta un momento posterior. Se divide en dos fases:

Commit: Se publica el hash de un dato junto con un salt secreto. Este hash es el commitment.
Reveal: Más adelante, se revelan el dato y el salt. Cualquiera puede verificar que coinciden con el hash publicado anteriormente.

Veamos cómo se aplicaría esto en nuestro juego de “Adivina el número”.

Etapa 1: El Commit

El administrador del juego selecciona un número secreto y un salt aleatorio. Luego, calcula el hash de ambos usando keccak256 (función hash que viene en Ethereum por defecto) y lo publica en el contrato. Este valor será inmutable durante el resto del juego.

Etapa 2: Registro de participantes

Los jugadores eligen públicamente un número del 0 al 10. Este paso no requiere privacidad, por lo que pueden hacerlo directamente on-chain.

Etapa 3: El Reveal

Cuando termina el tiempo de juego, el administrador revela el número original y el salt. El contrato vuelve a calcular el hash y verifica que coincide con el commitment inicial.

Si todo es válido, se puede declarar al ganador.

Implementación completa del juego con Commit-Reveal

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.22;

// Contrato ejemplo de esquema commit-reveal
// Consiste en el juego de "Adivina cuál número del 0 al 10 estoy pensando"
contract SimpleNumberGuess {
    // Hash commitment of the secret number (capped via modulo 11)
    bytes32 public numberCommitment;
    // Flag que indica si el número ya fué revelado
    bool public revealed;
    // Número revelado, debe ser un número entro 0 a 10
    uint8 public secretNumber;
    // Almacena los addresses de los jugadores, únicamente un address por número
    mapping(uint8 => address) public guessers;

    // Al iniciar el juego enviamos el commitment del juego tal que numberCommitment = keccak256(número oculto, SALT)
    constructor(bytes32 _numberCommitment) {
        numberCommitment = _numberCommitment;
    }

    // Cualquier jugador puede participar siempre y cuando el juego ya inició, el número sea entre 0 y 10 y nadie más lo haya seleccionado
    function guessNumber(uint8 _guess) public {
        require(!revealed, "Game already revealed");
        require(_guess <= 10, "Guess must be between 0 and 10");
        require(guessers[_guess] == address(0), "Number already taken");
        guessers[_guess] = msg.sender;
    }

    // El número secreto es revelado hasheando de nuevo el número oculto junto con el salt y verificando que sea igual al commitment guardado anteriormente
    // Únicamente el creador del juego debería ser capáz de revelar el número secreto pues para hacerlo deberá revelar también el salt
    function reveal(uint8 number, uint256 salt) public {
        // El commitment debe ser igual al hash del número junto con el salt
        require(hashFunction(number, salt) == numberCommitment, "Invalid reveal");
        // Nos aseguramos que el número secreto sea un número entre 0 y 10 al hacer modulo 11
        // Este es un ejemplo sencillo y en realidad podemos omitir el salt pues usamos modulo, pero en casos mas avanzados sí es necesario para evitar ataques de fuera bruta
        secretNumber = number % 11;
        revealed = true;
    }

    /// Una vez terminado el juego podemos verificar quién es el ganador
    function checkWinner() public view returns (address) {
        require(revealed, "Number not revealed yet");
        return guessers[secretNumber];
    }

    /// Funcion hash que usamos off-chain para crear un commitment, y también on-chain para verificarlo
    function hashFunction(uint8 value, uint256 salt) public pure returns (bytes32) {
        return keccak256(abi.encodePacked(value, salt));
    }
}

Limitaciones del esquema Commit-Reveal

Aunque funciona y provee mucha utilidad, este esquema tiene limitaciones importantes. Una de ellas es que no existe garantía de que el dato será revelado. Si quien realizó el commitment no publica el dato y el salt, el juego simplemente queda inconcluso. Este es un problema de liveness.

Una solución que no es perfecta pero puede funcionar consiste en requerir que quien hace el commit deposite una cantidad de ETH que sólo podrá recuperar si realiza el reveal dentro de cierto plazo.

Otra limitación importante es que no se puede validar la veracidad o validez de los datos privados hasta que se revelan. No hay forma de aplicar lógica sobre esos datos durante la etapa de commit.

Ahí es donde las pruebas ZK ofrecen una mejora significativa pues permiten demostrar que un dato privado cumple ciertas condiciones, sin necesidad de revelarlo. Pero eso lo veremos en la siguiente artículo.

¡Gracias por ver este artículo!

Sígueme en dev.to y en Youtube para todo lo relacionado al desarrollo en Blockchain en Español.

ZK y Noir: El Tutorial Completo

Ahmed Castro — Wed, 23 Apr 2025 19:15:27 +0000

ZK te permite operar datos privados en Smart Contracts y en este tutorial vamos a realizar una aplicación ZK completa de principio a fin.

Aprenderemos de una manera práctica cómo interactúan las 3 partes principales de la arquitectura de una aplicación ZK: el circuito, el contrato y la webapp.

Vamos a recrear el juego del Ahorcado versión ZK. Por medio de este ejemplo práctico aprenderás sobre los errores más comunes y cómo solucionarlos.

Si lo prefieres, mirá el código completo en Github.

Ahorcado sin ZK, una versión ingenua

Antes de entrar de lleno en ZK observemos la siguiente implementación del juego del ahorcado en Solidity sin usar ZK.

La función hashFunction se encarga de calcular el commitment de la palabra que el usuario desea adivinar.

La función playWord se encarga de verificar si la palabra adivinada es correcta.

Aunque funciona, tiene un par de problemas fundamentales. ¿Puedes detectarlos?

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.22;

// Contrato demostración de equemas de commit-reveal
contract SimpleHangman {
    // El commitment de la palabra por adivinar, este se calcula con keccak256(word)
    // Aunque esto esconde una palabra, no provee ninguna garantía que es una palabra válida
    bytes32 public wordHash;
    // El address del ganador, quien adivinó la palabra
    address public winner;

    // Al iniciar el juego, almacenamos un commitment a la palabra con la que jugaremos
    constructor(bytes32 _wordHash) {
        wordHash = _wordHash;
    }

    // Intenta adivinar la palabra oculta
    // Esto es sujeto a un ataque de frontrunn, el atacante puede ver la palabra en la mempool y pagar mas gas para ganar
    function playWord(string memory word) public {
        require(winner == address(0), "Game already played");
        require(hashFunction(word) == wordHash, "Invalid word");
        winner = msg.sender;
    }

    // Nos ayuda hashear la palabra, puedes usarla para calcular el commitment antes de lanzar el contrato
    function hashFunction(string memory value) public pure returns(bytes32)
    {
        return keccak256(abi.encodePacked(value));
    }
}

Estos son los dos problemas fundamentales de este contrato:

Es suceptible a un ataque de frontrunn: El atacante puede ver la palabra en la mempool y pagar mas gas para ganar.
No existe una forma de verificar que la palabra ingresada es válida, es decir, que contenga solo letras y no números o símbolos.

Veamos ahora como solucionarlos con ZK.

Ahorcado versión ZK

Veamos como implementar un circuito en el lenguaje Noir que resuelva los problemas anteriores.

Si aún no lo tienes, instala noir con el comando a continación.

curl -L https://raw.githubusercontent.com/noir-lang/noirup/refs/heads/main/install | bash

Y actualiza a la versión mas reciente.

noirup

Inicia creando un nuevo proyecto de Noir.

nargo new zk_hangman
cd zk_hangman

Crea un circuito que nos servirá para demostrar que cierta palabra secreta solo contenga caracteres válidos. Además, adjunta el ganador cómo parámetro público para no estar sujeto a frontrunn.

src/main.nr

use dep::std;

// Circuito de ahorcado que evita frontrunn y verifica que la palabra sea valida
fn main(
    word: [Field; 10], // Palabra a adivinar, un maximo de 10 caracteres
    word_length: pub Field, // Longitud de la palabra, cantidad de caracteres
    winner: pub Field // Wallet del ganador, debe estar integrado en los parametros de la transaccion para evitar frontrunn
) -> pub Field {

    // Convierte la palabra a bytes para ser compatible con la implementacion de la libreria de keccak256 que usaremos
    // Ademas, verificamos que la palabra no contenga caracteres no alfabeticos
    let mut word_bytes = [0; 10];
    for i in 0..10 {
        if i < word_length as u8 {
            let current_char = word[i] as u8;
            let is_uppercase = (current_char >= 65) & (current_char <= 90);
            let is_lowercase = (current_char >= 97) & (current_char <= 122);
            assert(is_uppercase | is_lowercase);
        }
        word_bytes[i] = word[i] as u8;
    }

    // Obtenemos el hash de la palabra
    let hash_bytes = std::hash::keccak256(word_bytes, 10);

    // Convertimos el hash a un numero de 256 bits para ahorrar el tamano de la prueba
    let mut computed_hash = 0 as Field;
    for i in 0..30 {
        computed_hash = computed_hash * 256 + (hash_bytes[i] as Field);
    }

    println(computed_hash);
    println(hash_bytes);
    // Devolvemos el hash de la palabra, recuerda que los valores de retorno son parametros publicos en el contrato
    computed_hash
}

Ahora compila el circuito y genera los artefactos que serán usados desde la webapp.

nargo compile
bb write_vk -b ./target/zk_hangman.json -o ./target --oracle_hash keccak

Además genera el contrato verificador en Solidity.

bb write_solidity_verifier -k ./target/vk -o Verifier.sol

Lanza el Contrato de Ahorcado con ZK

Primero, lanza el contrato verificador Verifier.sol ubicado en el directorio zk_hangman/. Una vez lanzado, lanza el siguiente contrato pasando la dirección del verificador como parámetro en el constructor.

SimpleHangman.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.22;

// Interfaz de contrato verificador ZK
interface IVerifier {
    function verify(bytes calldata _proof, bytes32[] calldata _publicInputs) external view returns (bool);
}

// Contrato demostración de equemas de commit-reveal
contract SimpleHangman {
    // El commitment de la palablra por adivinar, este se calcula con keccak256(word)
    bytes32 public wordHash;
    // La cantidad de letras en la palabra secreta
    uint public wordLength;
    // El address de quien adivinó la palablra
    address public winner;
    // Contrato verificador de las pruebas ZK
    IVerifier verifier;

    constructor(address verifierAddress) {
        verifier = IVerifier(verifierAddress);
    }

    // Al iniciar el juego, almacenamos un commitment a la palabra con la que jugaremos
    function init(bytes calldata _proof, bytes32[] calldata _publicInputs) public {
        require(verifier.verify( _proof, _publicInputs), "Invalid proof");
        wordLength = uint(_publicInputs[0]);
        wordHash = _publicInputs[2];
    }

    // Intenta adivinar la palabra oculta
    function playWord(bytes calldata _proof, bytes32[] calldata _publicInputs) public {
        require(wordLength > 0, "Game hasn't been initialized");
        require(verifier.verify( _proof, _publicInputs), "Invalid proof");
        require(winner == address(0), "Game already played");
        bytes32 _wordHash = _publicInputs[2];
        require(_wordHash == wordHash, "Invalid word");
        winner = address(uint160(uint256(_publicInputs[1])));
    }

    // Nos ayuda hashear la palabra, puedes usarla para calcular el commitment antes de lanzar el contrato
    function hashFunction(string memory value) public pure returns(bytes32)
    {
        return keccak256(abi.encodePacked(value));
    }
}

Crea el Frontend

Instala las dependencias y la base mínima de tu proyecto.

curl -fsSL https://bun.sh/install | bash
bun i @noir-lang/noir_wasm@1.0.0-beta.3 @noir-lang/noir_js@1.0.0-beta.3 @aztec/bb.js@0.82.2

El frontend consta de los siguientes 5 archivos que explicaremos a continuación:

vite.config.js
index.html
index.js
zk_stuff.js
web3_stuff.js

Crea el archivo vite.config.js para poder levantar el proyecto usando el servidor vite.

vite.config.js

export default { optimizeDeps: { esbuildOptions: { target: "esnext" } } };

El archivo HTML define la interfaz de usuario y conecta al script principal de la aplicación.

index.html

<!DOCTYPE html>
<head>
  <style>
    .outer {
        display: flex;
        justify-content: space-between;
        width: 100%;
    }
    .inner {
        width: 45%;
        border: 1px solid black;
        padding: 10px;
        word-wrap: break-word;
    }
    #connected_section, #forms, #forms {
      display: none;
    }
  </style>
  <!-- Usaremos web3.js para interactuar con ethereum pero puedes usar ethers.js o viem -->
  <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/web3/1.3.5/web3.min.js"></script>
</head>
<body>
  <!-- El script principal de tu aplicación -->
  <script type="module" src="/index.js"></script>
  <h1>Noir app</h1>

  <!-- Botón para conectar la wallet y mostrar mensajes relacionados con la conexión -->
  <div id="web3_message"></div>
  <button id="connect_button" onclick="connectWallet()" style="display: none;">Connect Wallet</button>

  <div id="connected_section">
    <div id="wallet_address"></div>

    <!-- Sección para interactuar con el contrato para el admin y el jugador -->
    <div id="forms">
      <h3>Admin: Set Word</h3>
      <input id="admin_word" type="text" placeholder="Enter word (max 10 chars)" maxlength="10" />
      <button id="admin_submit">Submit as Admin</button>
      <h3>Player: Guess Word</h3>
      <input id="player_word" type="text" placeholder="Enter word (max 10 chars)" maxlength="10" />
      <input id="winner-address" type="text" pattern="^0x[a-fA-F0-9]{40}$" value="0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" />
      <button id="player_submit">Submit as Player</button>
    </div>
  </div>

  <!-- Sección para mostrar logs y resultados -->
  <div class="outer">
    <div id="logs" class="inner"><h2>Logs</h2></div>
    <div id="results" class="inner"><h2>Proof</h2></div>
  </div>
</body>
</html>

Este es archivo principal de la aplicación, este conecta a la lógica relacionada con ambos web3 yZK.

index.js

import { loadDapp, submitAdminProof, submitPlayerProof } from './web3_stuff.js';
import { generateProof, show } from './zk_stuff.js';

// Inicializa todo lo relacionado con web3
loadDapp();

// En esta aplicación, existen dos funciones que se ejecutan cuando el admin o el jugador presionan el botón de submit, ambas producen una prueba ZK que luego es enviada al contrato de Solidity

// Evento para cuando el admin crea la palabra, nota que el ganador es 0x0000000000000000000000000000000000000000 pues no será usado en el contrato de Solidity
document.getElementById("admin_submit").addEventListener("click", async () => {
  const word = document.getElementById("admin_word").value;
  const { proofBytes, publicInputs, rawProof } = await generateProof(
    word, 
    "0x0000000000000000000000000000000000000000"
  );

  await submitAdminProof(proofBytes, publicInputs);
  show("results", rawProof);
});

// Evento para cuando el jugador adivina la palabra, nota que el ganador puede ser definido por el jugador
document.getElementById("player_submit").addEventListener("click", async () => {
  const word = document.getElementById("player_word").value;
  const winnerAddress = document.getElementById("winner-address").value;
  const { proofBytes, publicInputs, rawProof } = await generateProof(
    word,
    winnerAddress
  );

  await submitPlayerProof(proofBytes, publicInputs);
  show("results", rawProof);
});

zk_stuff.js se encarga de generar las pruebas ZK para ambos el admin y el jugador.

zk_stuff.js

// Librerías de Aztec para generar pruebas ZK con Noir
import { UltraHonkBackend } from '@aztec/bb.js';
import { Noir } from '@noir-lang/noir_js';
import circuit from './zk_hangman/target/zk_hangman.json';

// Librerías extra para compatibilidad con zkWASM
import initNoirC from "@noir-lang/noirc_abi";
import initACVM from "@noir-lang/acvm_js";
import acvm from "@noir-lang/acvm_js/web/acvm_js_bg.wasm?url";
import noirc from "@noir-lang/noirc_abi/web/noirc_abi_wasm_bg.wasm?url";
await Promise.all([initACVM(fetch(acvm)), initNoirC(fetch(noirc))]);

// Función para mostrar logs y resultados en HTML
export const show = (id, content) => {
  const container = document.getElementById(id);
  container.appendChild(document.createTextNode(content));
  container.appendChild(document.createElement("br"));
};

// Función para generar pruebas ZK para ambos el admin y el jugador
export async function generateProof(word, winnerAddress) {
  // Inicializa Noir con el circuito precompilado en la carpeta circuit
  const noir = new Noir(circuit);
  const backend = new UltraHonkBackend(circuit.bytecode);

  // Convierte la palabra a un array de caracteres y la rellena con 0s hasta que tenga 10 caracteres
  const wordArray = Array.from(word)
    .map(char => char.charCodeAt(0).toString())
    .concat(Array(10 - word.length).fill("0"));

  // Generamos la prueba ZK
  show("logs", "Generating witness... ⏳");
  const { witness } = await noir.execute({ 
    word: wordArray,
    word_length: word.length,
    winner: winnerAddress
  });
  show("logs", "Generated witness... ✅");

  show("logs", "Generating proof... ⏳");
  const proof = await backend.generateProof(witness, { keccak: true });
  show("logs", "Generated proof... ✅");

  // Opcional: Verificamos la prueba ZK antes de enviarla al contrato de Solidity
  show('logs', 'Verifying proof... ⌛');
  const isValid = await backend.verifyProof(proof, { keccak: true });
  show("logs", `Proof is ${isValid ? "valid" : "invalid"}... ✅`);

  const proofBytes = '0x' + Array.from(Object.values(proof.proof))
    .map(n => n.toString(16).padStart(2, '0'))
    .join('');

  // Devolvemos la prueba ZK para ser enviada al contrato de Solidity
  return {
    proofBytes,
    publicInputs: proof.publicInputs,
    rawProof: proof.proof
  };
}

web3_stuff.js se encarga de inicializar web3 y de interactuar con el contrato de Solidity. Asegúrate de cambiar el address del contrato CONTRACT_ADDRESS con SimpleHangman que recién lanzamos.

web3_stuff.js

const NETWORK_ID = 17000 // Para este tutorial usaremos Holesky, para usar otra red solo cambia este valor
const CONTRACT_ADDRESS = "0xfb89Fb2a693e71B237cE2E6A4CC2EEbFb59034c9" // Dirección del contrato de demostración, cambia esta dirección por la del contrato de ahorcado ZK que recién creamos

// Définimos el ABI del contrato para ambas funciones de init y playWord
const CONTRACT_ABI = [
  {
    "inputs": [
      {
        "internalType": "bytes",
        "name": "_proof",
        "type": "bytes"
      },
      {
        "internalType": "bytes32[]",
        "name": "_publicInputs",
        "type": "bytes32[]"
      }
    ],
    "name": "init",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "inputs": [
      {
        "internalType": "bytes",
        "name": "_proof",
        "type": "bytes"
      },
      {
        "internalType": "bytes32[]",
        "name": "_publicInputs",
        "type": "bytes32[]"
      }
    ],
    "name": "playWord",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  }
];

let web3;
let accounts;
let contract;
let isAdmin = false;

// Función para recargar la página cuando se cambia de cuenta o de red
function metamaskReloadCallback() {
  window.ethereum.on('accountsChanged', () => {
    window.location.reload();
  });
  window.ethereum.on('chainChanged', () => {
    window.location.reload();
  });
}

// Función para inicializar web3
const getWeb3 = async () => {
  if (!window.ethereum) {
    throw new Error("Please install MetaMask");
  }
  return new Web3(window.ethereum);
};

// Carga el contrato de Ahoracado
const getContract = async (web3) => {
  return new web3.eth.Contract(CONTRACT_ABI, CONTRACT_ADDRESS);
};

// Inicializa la aplicación, conecta a la wallet e inicializa el contrato
async function loadDapp() {
  try {
    metamaskReloadCallback();
    web3 = await getWeb3();

    const netId = await web3.eth.net.getId();
    if (netId !== NETWORK_ID) {
      document.getElementById("web3_message").textContent = "Please connect to Holesky network";
      return;
    }

    contract = await getContract(web3);

    accounts = await web3.eth.getAccounts();
    if (accounts.length > 0) {
      onWalletConnected();
    } else {
      document.getElementById("web3_message").textContent = "Please connect wallet";
      document.getElementById("connect_button").style.display = "block";
      document.getElementById("connected_section").style.display = "none";
    }
  } catch (error) {
    console.error("Error loading dapp:", error);
    document.getElementById("web3_message").textContent = error.message;
  }
}

// Función para conectar la wallet
async function connectWallet() {
  try {
    accounts = await window.ethereum.request({ method: "eth_requestAccounts" });
    onWalletConnected();
  } catch (error) {
    console.error("Error connecting wallet:", error);
  }
}

// Callback para cuando se conecta la wallet
function onWalletConnected() {
  document.getElementById("connect_button").style.display = "none";
  document.getElementById("web3_message").textContent = "Connected!";
  document.getElementById("wallet_address").textContent = `Wallet: ${accounts[0]}`;
  document.getElementById("connected_section").style.display = "block";
  document.getElementById("forms").style.display = "block";
}

// Función llamada por el Admin para crear la palabra
async function submitAdminProof(proofBytes, publicInputs) {
  console.log(proofBytes);
  console.log(publicInputs);
  try {
    await contract.methods.init(proofBytes, publicInputs)
      .send({ from: accounts[0] })
      .on('transactionHash', (hash) => {
        document.getElementById("web3_message").textContent = "Transaction pending...";
      })
      .on('receipt', (receipt) => {
        document.getElementById("web3_message").textContent = "Success!";
      });
  } catch (error) {
    console.error("Error submitting admin proof:", error);
    document.getElementById("web3_message").textContent = "Transaction failed";
  }
}

// Función llamada por el jugador para adivinar la palabra
async function submitPlayerProof(proofBytes, publicInputs) {
  try {
    await contract.methods.playWord(proofBytes, publicInputs)
      .send({ from: accounts[0] })
      .on('transactionHash', (hash) => {
        document.getElementById("web3_message").textContent = "Transaction pending...";
      })
      .on('receipt', (receipt) => {
        document.getElementById("web3_message").textContent = "Success!";
      });
  } catch (error) {
    console.error("Error submitting player proof:", error);
    document.getElementById("web3_message").textContent = "Transaction failed";
  }
}

export { loadDapp, connectWallet, submitAdminProof, submitPlayerProof };

Ahora prueba tu zkDapp

Ejecuta lo siguiente en carpeta donde se encuentra tu archivo package.json.

bunx vite

Ahora deberías poder acceder a tu webapp. Desde tu wallet owner del contrato ingresa la palabra secreta para iniciar el juego. Desde cualquier otra intenta adivinar la palabra. Si la adivinaste, enviar la transacción on-chain sin riesgo a ser frontrunneado.

Una vez terminado el juego, puedes obervar el ganador on-chain.

Te dejo estos links para seguir aprendiendo sobre ZK:

Ejemplo oficial de noir por saleel
Documentación oficial
Mis videos sobre ZK

¡Gracias por ver este artículo!

Sígueme en dev.to y en Youtube para todo lo relacionado al desarrollo en Blockchain en Español.

Cómo crear un Bot de Telegram Seguro🔒 con el EIP-712

Ahmed Castro — Tue, 15 Apr 2025 18:02:19 +0000

Telegram tiene alrededor de un billón de usuarios activos al mes y es una parte fundamental de las dApps y comunidades Web3. Sin embargo, muchos bots de Telegram aún usan de métodos de interacción inseguros.

Al completar esta guía, conocerás una mejor manera de conectar a los usuarios con aplicaciones decentralizadas a través de Telegram. Este tutorial te mostrará cómo autenticar usuarios de Telegram con sus wallets Web3, sin acceder nunca a sus claves privadas.

En este tutorial aprenderás a:

Crear un bot de Telegram seguro: Construir un bot que autentique usuarios mediante firmas de wallets Web3 sin almacenar llaves privadas.
Implementar firmas ERC-712: Crear un flujo de autenticación donde el usuario firma mensajes en un formato legible.
Implementar autenticación flexible: A través de telegram los usuarios pueden interactuar con cualquier tipo de aplicación, desde grupos secreatos hasta cualquier tipo de transacción ya sea en DeFi o airdrops.

Para ver el proyecto completo, revisa el código completo.

Flujo de la apliación.

1. Crea un nuevo bot de Telegram

Crear un bot de Telegram es muy sencillo. Puedes hacerlo enviando un mensaje directo a la cuenta de Telegram @BotFather. Solo envíale el comando /newbot, sigue las instrucciones y obtendrás un token que usaremos para interactuar con la librería de Telegram en el siguiente paso.

Envía /newbot al @botfather para crear un nuevo Bot de Telegram.

2. Lanza el backend del bot de Telegram

Comencemos instalando las dependencias. Pero antes de eso, asegúrate de tener Node.js instalado. Te recomiendo usar nvm para instalarlo.

Una vez que tengas Node.js instalado, puedes instalar las dependencias con el siguiente comando:

npm install node-telegram-bot-api ethers dotenv express cors

Now, let's create the .env file with the following variables:

.env

BOT_TOKEN=your_telegram_bot_token
CHAIN_ID=1
WEB_DAPP_URL=http://localhost:3000

Cambia la CHAIN_ID dependiendo de la chain que tu dApp o comunidad usa. Puedes usar Chainlist para averiguar la chain qu estás usando. Si quieres que tu bot sea agnóstico a una chain, coloca el id 1, la chain id de Ethereum.

No olivdés crear el archivo .gitignore para evitar subir el archivo .env a un repositorio público.

.gitignore

.env
node_modules

Este es el archivo bot.js, que lanza un bot que escucha mensajes de Telegram y verifica la firma. Los bots de Telegram usan polling para recibir mensajes localmente, lo que significa que estarán haciendo llamadas constantes a los servidores de Telegram en busca de nuevos mensajes. En un entorno de producción con muchos usuarios, esto podría ser un problema, por lo que deberías usar el método de webhook y alojar el servidor de forma remota.

Para este tutorial usaremos el método de polling localmente. Si quieres aprender más sobre el método de webhook, puedes consultar la documentación de la API de Bots de Telegram.

Cuando el usuario envía el comando authenticate al bot, este le responderá con un mensaje para que visite la dApp web. La dApp web firmará un mensaje y lo enviará al bot, que verificará la firma y enviará un mensaje de bienvenida al usuario.

bot.js

// Usaremos la biblioteca oficial node-telegram-bot-api para interactuar con la API de Telegram y ethers para verificar la firma
const TelegramBot = require("node-telegram-bot-api");
const { ethers } = require("ethers");
require("dotenv").config();
const express = require("express");
const cors = require("cors");

const bot = new TelegramBot(process.env.BOT_TOKEN, { polling: true });
const CHAIN_ID = process.env.CHAIN_ID;
const WEB_DAPP_URL = process.env.WEB_DAPP_URL;

const app = express();
app.use(cors());
app.use(express.json());

// Inicia el bot de Telegram y el servidor API que recibe la firma y la verifica
(async () => {
    try {
        bot.botInfo = await bot.getMe();
        app.listen(8080, () => {
            console.log("\nServer is running on port 8080");
            console.log("Bot is running...");
        });
    } catch (error) {
        console.error(error);
        process.exit(1);
    }
})();

// El endpoint /verify se usa para verificar la firma y enviar un mensaje de bienvenida al usuario
app.post("/verify", async (req, res) => {
    const { userId, message, signature } = req.body;
    try {
        const signerAddress = await getAuthenticationSigner(userId, message, signature);
        await bot.sendMessage(
            Number(userId), 
            `Welcome! You're authenticated as ${signerAddress}.\n\nEnjoy your welcome gift! 🎁`
        );
        res.json({ success: true, signerAddress });
    } catch (error) {
        console.error("Verification error:", error);
        res.status(400).json({ success: false, error: error.message });
    }
});

// getAuthenticationSigner devuelve la dirección del firmante verificando la firma
function getAuthenticationSigner(userId, message, signature) {
    // accessRequest es el esquema de datos real del mensaje que queremos verificar
    const accessRequest = {
        userId: userId,
        message: message,
    };
    // domain es la información general sobre tu dapp, esto es lo mismo para todos los mensajes
    const domain = {
        name: "Telegram Group Access",
        version: "1",
        chainId: CHAIN_ID,
    };
    // types es el esquema de datos del mensaje que queremos verificar
    const types = {
    AccessRequest: [
            { name: "userId", type: "uint256" },
            { name: "message", type: "string" },
        ]
    };
    // verifyTypedData verifica la firma en el formato erc712 y devuelve la dirección del firmante mediante ecrecover
    // No necesitamos preocuparnos por esos detalles, ethers lo hace por nosotros
    return ethers.verifyTypedData(domain, types, accessRequest, signature);
}

// Esta es la función principal que se ejecuta cuando el bot recibe un mensaje
bot.on("message", async (msg) => {
    const text = msg.text || "";
    // Verifica si el mensaje es "authenticate" y si es así, envía un mensaje al usuario para que visite el sitio web
    if (text.toLowerCase() === "authenticate") {
        // userId es el id del usuario en Telegram
        const userId = msg.from.id;
        // Enviamos el usuario a la dapp web para autenticarse
        bot.sendMessage(userId, `Please visit: ${WEB_DAPP_URL}?userId=${userId}`);
        return;
    }
});

console.log("\nBot is running...");

Ahora corre el siguiente comando desde el mismo directorio donde se encuentra el archivo bot.js. Esto iniciariá el bot:

node bot.js

Tu bot ahora está correiendo en http://127.0.0.1:8080.

En el siguiente paso crearemos una dApp web que interactúa con nuestro bot.

3. Crea una dApp Web para Firmar Mensajes

En este paso crearemos 3 archivos:

index.html: El archivo HTML que define la conexión con la wallet y el botón para firmar.
signature_messaging.js: El archivo que define cómo se firma el mensaje y se envía al backend.
wallet_connection.js: El archivo que maneja la conexión con la wallet.

La dApp será un archivo HTML sencillo que contiene un botón Sign que abrirá la wallet del usuario para firmar un mensaje.

Al hacer clic en el botón de _Sign, este abrirá el modal de firma ERC712._

Comencemos con el archivo HTML que contiene el botón Sign que abrirá la wallet del usuario para firmar un mensaje.

index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
</head>
<body>
  <div>
    <!-- Botón de conexión a la Wallet, solo es visible si la Wallet no está conectada -->
    <input id="connect_button" type="button" value="Connect" onclick="connectWallet()" style="display: none"></input>
    <h1>Telegram Bot Authentication</h1>
    <p id="web3_message"></p>
    <h3>Sign Authentication Request</h3>
    <!-- Este es el botón de autenticación, levantará el modal de firma -->
    <button type="button" id="sign" onclick="_signMessage()">Sign</button>
    <p id="signature"></p>
  </div>
    <!-- En este tutorial usaremos web3.js, puedes obener los mismos resultados con ethers.js -->
  <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/web3/1.3.5/web3.min.js"></script>
  <script type="text/javascript" src="wallet_connection.js"></script>
  <script type="text/javascript" src="signature_messaging.js"></script>
</body>

  <script>
    // The signMessage function is called when the user clicks the sign button
    function _signMessage()
    {
      const urlParams = new URLSearchParams(window.location.search);
      const userId = urlParams.get('userId');
      signMessage(userId, "I'm requesting access to the Telegram group.")
    }
  </script>
</html>

El archivo signature_messaging.js define cómo se firma el mensaje y cómo se envía al backend. Usaremos el estándar ERC712 para firmar el mensaje, ya que este permite mostrar una explicación legible del mensaje en la wallet al momento de firmar.

Para lograr esto, necesitamos definir el dominio y los tipos del mensaje, lo cual define el esquema de datos del mensaje a firmar. Además, utilizaremos la función eth_signTypedData_v4, que es el método más avanzado y de actualidad para firmar mensajes y ya es compatible con todas las wallets modernas.

signature_messaging.js

const BOT_API_URL = 'http://localhost:8080'
// Firma el mensaje usando el formato ERC712
async function signMessage(userId, message)
{
  // ERC712 espera que envíes el mensaje en un formato específico
  // Definimos el Domain, que tiene información general sobre la dapp y debe ser el mismo para todos los mensajes
  // Luego, definimos los tipos del mensaje, que son los campos del mensaje
  // Finalmente, definimos el mensaje a firmar
  const msgParams = JSON.stringify({
    types: {
      EIP712Domain: [
        { name: 'name', type: 'string' },
        { name: 'version', type: 'string' },
        { name: 'chainId', type: 'uint256' },
      ],
      AccessRequest: [
        { name: 'userId', type: 'uint256' },
        { name: 'message', type: 'string' }
      ],
    },
    primaryType: 'AccessRequest',
    domain: {
      name: 'Telegram Group Access',
      version: '1',
      chainId: NETWORK_ID,
    },
    message: {
      userId: userId,
      message: message,
    },
  });

  // ERC712 introdujo el método eth_signTypedData_v4, que ahora es ampliamente soportado por todas las wallets
  const signature = await ethereum.request({
    method: "eth_signTypedData_v4",
    params: [accounts[0], msgParams],
  });

  document.getElementById("signature").textContent="Signature: " + signature;

  // Envía el mensaje al bot de Telegram
  await sendSignature(userId, message, signature);
}

// Envía la firma al bot de Telegram
async function sendSignature(userId, message, signature) {
  // Empecemos agrupando los datos para enviar al bot de Telegram
  const requestData = {
    userId: userId,
    message: message,
    signature: signature
  };

  try {
    // Envía los datos al bot de Telegram llamando al endpoint POST /verify
    // Si la firma es válida, el bot enviará un mensaje al usuario
    const response = await fetch(BOT_API_URL + '/verify', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(requestData)
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    alert("Message sent successfully!");
  } catch (error) {
    console.error('Error:', error);
    alert("Failed to send message: " + error.message);
  }
}

El archivo wallet_connection.js maneja la conexión a la wallet del usuario, hace un pop up con el bontón de Conectar y refresca la página cuando la wallet ha cambiado.

wallet_connection.js

// Constantes
const NETWORK_ID = 1
var accounts
var web3

// Refresca la página si la wallet cambia
function metamaskReloadCallback() {
  window.ethereum.on('accountsChanged', (accounts) => {
    document.getElementById("web3_message").textContent="Account changed, refreshing...";
    window.location.reload()
  })
  window.ethereum.on('networkChanged', (accounts) => {
    document.getElementById("web3_message").textContent="Network changed, refreshing...";
    window.location.reload()
  })
}

// Obtén una instancia de Web3
const getWeb3 = async () => {
  return new Promise((resolve, reject) => {
    if(document.readyState=="complete")
    {
      if (window.ethereum) {
        const web3 = new Web3(window.ethereum)
        window.location.reload()
        resolve(web3)
      } else {
        reject("must install MetaMask")
        document.getElementById("web3_message").textContent="Error: Please connect to MetaMask";
      }
    }else
    {
      window.addEventListener("load", async () => {
        if (window.ethereum) {
          const web3 = new Web3(window.ethereum)
          resolve(web3)
        } else {
          reject("must install MetaMask")
          document.getElementById("web3_message").textContent="Error: Please install Metamask";
        }
      });
    }
  });
};

// Carga la dApp, carga la dApp y obtén la instancia de Web3
async function loadDapp() {
  metamaskReloadCallback()
  document.getElementById("web3_message").textContent="Please connect to Metamask"
  var awaitWeb3 = async function () {
    web3 = await getWeb3()
    web3.eth.net.getId((err, netId) => {
      if (netId == NETWORK_ID) {
        var awaitContract = async function () {
          document.getElementById("web3_message").textContent="You are connected to Metamask"
          web3.eth.getAccounts(function(err, _accounts){
            accounts = _accounts
            if (err != null)
            {
              console.error("An error occurred: "+err)
            } else if (accounts.length > 0)
            {
              onWalletConnectedCallback()
              document.getElementById("account_address").style.display = "block"
            } else
            {
              document.getElementById("connect_button").style.display = "block"
            }
          });
        };
        awaitContract();
      } else {
        document.getElementById("web3_message").textContent="Please connect to Ethereum Mainnet";
      }
    });
  };
  awaitWeb3();
}

// Conecta tu wallet
async function connectWallet() {
  await window.ethereum.request({ method: "eth_requestAccounts" })
  accounts = await web3.eth.getAccounts()
  onWalletConnectedCallback()
}

// Callback de cuando tu wallet se conecta, en este ejemplo no la usamos
const onWalletConnectedCallback = async () => {
}

// Inicia la conexión
loadDapp()

Instala un servidor web para correr tu dApp. Te recomiendo lite-server.

npm install -g lite-server

Ahora corre tu dapp corriendo el siguiente comando en el mismo directorio en el que se encuentra el archivo index.html:

lite-server

Tu dApp ahora está correiendo en http://127.0.0.1:3000.

4. Prueba tu Bot

Ahora vamos a probar el bot.

Envía el comando authenticate al bot.
Ve al sitio web que el bot te envió, conéctate a Scroll Mainnet y firma el mensaje con tu wallet.
Revisa la respuesta del bot en Telegram.

Con este flujo es posible autenticar usuarios de forma segura y permitir acciones en su nombre sin almacenar claves privadas.

Próximos pasos

En este tutorial aprendimos cómo autenticar usuarios en Telegram usando una wallet Web3. Utilizamos el estándar ERC712 para firmar mensajes y el método eth_signTypedData_v4 para realizar la firma. También usamos la API de Telegram para enviar mensajes al usuario y recibir su respuesta.

En el próximo tutorial aprenderemos cómo usar esta autenticación para controlar el acceso a un grupo de Telegram.

¡Gracias por ver este artículo!

Sígueme en dev.to y en Youtube para todo lo relacionado al desarrollo en Blockchain en Español.