DEV Community: wispy

Convergence Finance Exploit Report

wispy — Fri, 22 Aug 2025 15:13:04 +0000

On August 1, 2024, the DeFi protocol Convergence Finance suffered an exploit that resulted in losses of approximately $210,000 USD.

The attack targeted a critical vulnerability in the CvxRewardDistributor contract, which allowed the attacker to mint 58,718,395 CVG tokens —the entire planned staking emissions— and quickly liquidate them on Curve, draining the protocol’s liquidity.

This incident serves as a clear example of how poor input validation in smart contracts can lead to devastating consequences.

Exploit Simulation in a Forked Environment

To technically analyze and validate the attack, a testing environment was set up using Foundry, forking the Ethereum mainnet. This approach allowed us to accurately reproduce the protocol’s real state at the time of the exploit.

Within this environment, the following were deployed:

The vulnerable version of the CvxRewardDistributor contract.
A malicious contract that mimicked the claimCvgCvxMultiple() signature and returned inflated values.

Executing claimMultipleStaking() with this malicious contract as an argument resulted in the same on-chain behavior observed during the exploit: fraudulent minting followed by liquidation.

📂 Repository with the simulation:
Convergence PoC in Foundry

The Affected Contract

The CvxRewardDistributor contract was responsible for distributing staking rewards in both CVG and Convex (CVX). Its critical function was claimMultipleStaking(), designed to allow users to claim accumulated rewards from multiple staking contracts.

📌 Note: The function should have validated that the contracts being called were legitimate (e.g., through a whitelist) and ensured that the totalClaim value corresponded to actual rewards rather than arbitrary values returned by external contracts.

Root Vulnerability

The contract failed to validate the legitimacy of the addresses provided in claimContracts[]. This allowed attackers to pass in malicious contracts that returned arbitrary values, artificially inflating cvgClaimable.

Step-by-Step Attack Flow

Preparation: Initial funds were sourced from Tornado Cash 0x912c705958f527b08289320c20Ca6c90463AB572.
Malicious contract: It mimicked the claimCvgCvxMultiple() signature and returned an arbitrary number with no legitimate calculation.
Execution: The attacker called claimMultipleStaking() with the malicious contract included in claimContracts[].
Fraudulent mint: 58,718,395 CVG were minted.
Immediate liquidation: The tokens were rapidly sold in Curve pools for WETH and other assets, extracting approximately $210,000 USD in liquidity.

📌 Exploit transaction: 0x636be30e58acce0629b2bf975b5c3133840cd7d41ffc3b903720c528f01c65d9
📌 Malicious contract: 0x03560A9D7A2c391FB1A087C33650037ae30dE3aA

Economic Impact

Tokens minted: 58,718,395 CVG
Liquidity drained: ≈ $210,000
Context: This amount represented nearly the entirety of the staking emissions, negatively impacting the protocol’s TVL and the stability of its liquidity pools.

Protocol and Community Response

Immediate alert (August 1): Convergence warned users to stop interacting with the protocol.
Official post-mortem (August 2): The root cause (missing validation) was identified, and CVG emissions were paused.
Recovery attempt (August 6): An on-chain message was sent to the attacker in an effort to negotiate the return of funds.
External reports: Security firms such as PeckShield and QuillAudits confirmed the exploit and released technical alerts.
Fixes: Validation checks were implemented, and follow-up audits were conducted prior to reopening staking.

Conclusion

The Convergence Finance exploit underscores the need for more rigorous development standards in DeFi. The vulnerability was not present in the original codebase; it emerged after the audits, when the team introduced gas-saving changes and removed a critical validation. While such adjustments may be well-intentioned, they can inadvertently open the door to catastrophic failures.

Key takeaways from this case include:

Do not sacrifice security for gas optimization. Micro-optimizations should never come at the cost of removing essential validations.
Strict input validation. External addresses should never be trusted without safeguards such as whitelists or interface checks.
Defense in depth. Techniques like fuzzing and adversarial scenario testing could have exposed the manipulation.
Ongoing audits. Any post-audit changes must undergo additional reviews before being deployed on mainnet.
Coordinated response. Early communication and collaboration with the community helped contain the impact.

Ultimately, developers should integrate these lessons to strengthen their development and testing processes. Every public function in a smart contract represents a potential attack vector—security must always take precedence over gas optimization.

Proof of Stake vs. Proof of Work: A Security Analysis in Blockchain

wispy — Tue, 29 Jul 2025 20:56:00 +0000

In this article, we explore how Proof of Stake (PoS) secures blockchain networks, its main strengths and weaknesses, and how it mitigates threats such as double-spending and 51% attacks. After this analysis, we’ll compare its security features with those of Proof of Work (PoW).

Note: This article assumes basic knowledge of PoW and PoS. If you need a refresher, check out this Coinbase resource.

PoS vs. PoW: Key Differences and Limitations

Both mechanisms validate blocks, secure the network, and serve as protection against Sybil attacks, but they differ in their approach:

Proof of Work (PoW) relies on solving complex cryptographic puzzles: the node that solves the problem first gets to add the block and receive the reward. This process provides strong security by making it extremely costly to alter the chain (as all hashes would need to be recalculated). However, it requires specialized hardware and consumes enormous amounts of energy.
Proof of Stake (PoS) selects validators based on the amount of coins they have staked. There’s no computational competition; selection is random but weighted by stake. This significantly reduces energy consumption and makes participation more accessible, although it may tend to centralize power in the hands of large token holders.

Both methods face limitations:

PoW: High energy costs and entry barriers (mining is concentrated in large pools).
PoS: Risk of stake accumulation and less historical maturity compared to PoW.

Strengths and Weaknesses of PoS in Terms of Security

PoS offers a security model based on economic incentives:

Aspect	Strength	Weakness
Attack Cost	Requires owning and locking up the majority of the stake, making attacks extremely expensive and increasing the token's price.	If more than 50% of the stake is accumulated, there's a risk of a 51% attack unless properly mitigated.
Slashing	Malicious actions or double-signing are punished by slashing the validator’s stake, discouraging dishonest behavior.
Efficiency	No need for intensive computation results in minimal energy consumption and improved scalability.
Accessibility	Any user with funds can participate in validation without specialized hardware.	May incentivize power concentration among large token holders.
Technological Maturity		Being a newer model, it has undergone less stress testing in real-world environments.

Defense Against Common Attacks

PoS includes mechanisms designed to prevent both double-spending and 51% attacks:

Double-Spending and 51% Attacks: In PoS, the network requires each new block to be validated by a quorum of honest nodes. If an attacker attempts to rewrite the chain (via double-spending or majority control), the system enforces slashing, confiscating the stake of malicious validators. Additionally, acquiring over 50% of the circulating stake is extremely costly and self-reinforcing: as token demand rises, the price of executing such an attack increases, along with the attacker’s exposure to slashing penalties.

In this way, PoS effectively addresses major vulnerabilities through:

Economic Guarantees: The potential loss of staked assets far outweighs the gains from submitting a fraudulent block..
Validation Quorum: The requirement for multiple honest signatures makes it difficult to insert invalid blocks.
Disincentives to Centralization: Many PoS protocols include caps or distribution mechanisms to prevent excessive concentration of power.

Security Comparison: PoS vs. PoW

While both mechanisms secure the blockchain, their approaches differ:

Feature	Proof of Work (PoW)	Proof of Stake (PoS)
Validator Selection	Hashrate competition: the first to solve the puzzle wins.	Stake-weighted lottery: eliminates the need for computational races.
Double-Spending Protection	Altering blocks requires redoing all computations—an extremely high computational cost.	Slashing and quorum: contradictory signatures lead to guaranteed loss of stake.
51% Attack Resistance	Very costly: controlling >50% of mining power requires massive investment.	Economically expensive, but theoretically easier than PoW if the market is illiquid—though penalties remain a deterrent.
Energy Consumption	Gigawatt-hours of electricity consumed daily.	Near zero: doesn't rely on intensive computation.

Conclusion

Proof of Stake offers a secure and sustainable paradigm: by staking funds as collateral, it creates an economic incentive that discourages fraud and effectively mitigates both double-spending and 51% attacks. While PoS carries theoretical risks of stake centralization and still needs time to prove its long-term resilience, its energy efficiency and slashing mechanism make it a highly competitive alternative to Proof of Work.

Ultimately, the choice between PoW and PoS depends on each network’s priorities: if the goal is battle-tested security, PoW remains a strong option; if scalability and sustainability are the focus, PoS provides an innovative model that balances security with efficiency.

References

Take Your Vibe Trading to the Next Level: New AI Scanning Feature in Mode Terminal

wispy — Mon, 09 Jun 2025 13:00:07 +0000

What is Mode's AI Terminal?

The Mode AI Terminal is a smart assistant that combines real-world knowledge with access to contextual protocols to simplify on-chain transactions. It uses natural language processing, allowing you to ask questions and perform actions using natural language.

Its architecture is based on AI models that interpret user requests and, through reasoning, determine which contextual protocols to use via the GOAT SDK. The platform is constantly evolving, with new features added regularly to enhance the user experience.

If you encounter any limitations, you can reach out to Mode via Telegram or Discord.

Practical Use Cases

A clear example of its capabilities is when a user asks about trading opportunities. The terminal can:

Use Synth to retrieve the latest BTC price predictions
Write a Python script to calculate the probability of making a profit on a leveraged long position
Offer to open this position based on the latest BTC price data from CoinGecko

Security and Precautions

When the AI Terminal performs an on-chain action, it prepares the transaction or contract interaction for the user to confirm in their wallet. Since this technology is experimental, caution is advised: always review the transaction before signing it. If you're unsure about what you're about to do, it's best not to sign the transaction.

This security philosophy also applies to the new analysis tools, where accuracy and verification are essential.

New Feature: AI-Powered Position Scanner

New Feature: Analyze Your Positions with Just an Image

Mode’s AI Terminal can now analyze screenshots from platforms like Binance, Hyperliquid, Bybit, or Mode Trade to calculate in real time:

Liquidation probability
Associated risk information
Recommendations or suggested actions to avoid liquidation

How Does It Work?

You simply need to upload an image of your position taken from one of these platforms, and the AI Terminal will handle the rest. For example:

Take a screenshot of your position in Mode Trade.
Upload it directly to the terminal.
The AI extracts the data from the image and returns a detailed analysis with the probability of that position being liquidated.

This tool marks a major step forward in risk management. As highlighted in the official tweet, tools like this could have helped many traders avoid costly liquidations—showcasing the true power of combining AI with financial analysis.

Use Cases

Check the risk of your current position just by uploading an image.
Get useful insights without having to enter data manually.
Improve your risk management and avoid unexpected liquidations.

Conclusion

The new visual analysis feature takes Vibe Trading to the next level. This tool combines AI + UX to help you make better trading decisions without leaving the terminal.

Upload an image, analyze your risk, and make better decisions. It’s that simple.
And this is just the beginning: with innovative features like this being released regularly, the terminal is solidifying its place as a powerful tool to optimize your financial decisions.

Explore this and more features now:
👉 https://app.mode.network/terminal/

Quick Guide: Create Your Account ID on Orderly

wispy — Fri, 30 May 2025 18:58:22 +0000

Introduction

In this tutorial, you’ll learn how to generate your Orderly Account ID — a crucial step to authenticate yourself and use their private APIs.

Before you can sign requests or integrate trading features with Orderly, you need this unique identifier linked to your wallet and the broker you’re working with.

We’ll go over what Orderly is, why the Account ID matters, and how to generate it step by step using JavaScript.

What is Orderly?

Orderly is a decentralized trading infrastructure (DEX infra) that combines the efficiency of a centralized exchange (CEX) with the transparency and self-custody of DeFi. It doesn’t have its own user interface; instead, it provides an order engine and a liquidity layer that can be easily integrated by other projects.

Thanks to its modular design, developers can build DEXs, wallet integrations, trading bots, or in-game swaps — all using its shared liquidity. Its vision is to connect multiple blockchains (both EVM and non-EVM) into a single order book, enabling seamless omnichain trading without bridges or friction.

What is the Account ID used for?

The Account ID is the first requirement to authenticate with the Orderly API. All private endpoints—such as placing orders or checking balances—require authentication using cryptographic keys.

This process, known as API Authentication, ensures that requests to the API come from a valid user by signing each message with a private key (Orderly key). To make this work, you must include the orderly-account-id in the headers of every request.

In short, without an Account ID, you can’t generate valid signatures or access the API’s private features. That’s why the first step before interacting programmatically with Orderly is to create your Account ID.

How to Create an Account ID

To authenticate with the Orderly API, you first need to generate your Account ID. This identifier is derived from your wallet and the brokerId of the builder you’re working with.

Each wallet can have multiple Account IDs—one for each builder—and these IDs are not connected to each other.

1. Make sure you have Node.js installed.
2. Install the ethers library (if you haven’t already):

npm install ethers

3. Getting the broker_id

To generate your Account ID, you need to know the broker_id. Orderly provides an endpoint called chain_info where you can check the available broker_ids for each network.

Follow these steps:

Go to the chain_info endpoint
Click the Try it button
In the input field, enter a sample broker_id like woofi_pro
You’ll see a list of all available broker_ids by network

4. Create a .js file and paste the following code:

import { AbiCoder, keccak256, solidityPackedKeccak256 } from "ethers";

const userAddress = "0xYOUR_ADDRESS"; // Replace with your wallet
const brokerId = "BROKER_ID"; // Replace with the brokerId

export function getAccountId(userAddress, brokerId) {
  const abicoder = AbiCoder.defaultAbiCoder();
  return keccak256(
    abicoder.encode(
      ['address', 'bytes32'],
      [userAddress, solidityPackedKeccak256(['string'], [brokerId])]
    )
  );
}

const accountId = getAccountId(userAddress, brokerId);
console.log(accountId);

5. Run the file with:

node filename.js

You’ll see your Account ID printed in the console, something like this:

0x440adacb805d48efc87ba34dd6401f8fc8b45ee55126ccd9a14f33f5b85d403c

This is the value you’ll use as orderly-account-id in the headers of your API requests.

Conclusion

Getting your Orderly Account ID is the first step toward securely interacting with its trading infrastructure. This ID allows you to authenticate your API requests and start building on the Orderly ecosystem—whether it's creating a DEX, integrating swaps into a wallet, or automating trades with bots.

With just a few steps and common tools like Node.js and ethers, you’re ready to start developing with Orderly.

INTEGRATION OF DAPPS WITH MODE: WALLET AND SMART CONTRACTS | PART 2: CONNECTING SMART CONTRACTS TO THE FRONT-END

wispy — Tue, 10 Dec 2024 14:53:41 +0000

Welcome to the second part of our tutorial series. Before diving into new content, let's do a quick recap of what we covered in Part 1:

Part 1 Recap:

Setting up Next.js and Reown Cloud
Installing dependencies (Reown and Wagmi)
Implementing wallet connection, including Mode chains (mainnet and testnet)
Functionality testing

If you haven’t gone through the previous tutorial yet, we recommend doing so before proceeding, as we will be building upon those concepts and configurations.

Objectives of Part 2:

Connect an existing smart contract to a front-end on the Mode network.
Interact with the contract from the front-end, performing read and write operations.
Use Mode's testnet to develop and test our dApp.

Recommendations

Basic knowledge of Solidity and smart contract development.
Familiarity with front-end development using Next.js.
Completion of Part 1 of this series (although it’s not strictly necessary).

Quick Option: If you prefer to start with the front-end already set up with a connect wallet and the Mode chains (testnet and mainnet), you can clone the repository here.

This tutorial will provide you with a solid foundation for dApp development on the Mode blockchain, focusing on practical integration between smart contracts and the front-end. Let’s get started!

Smart Contract Development

In this section, we will create a simple smart contract for our project. Follow these steps:

Create a new file named HelloMode.sol in the src/ directory of your project.
Use the following sample code for a basic simpleStorage contract:

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

contract HelloMode {
    string private message = "Hello Mode Chads";

    function setMessage(string calldata newMessage) public {
        message = newMessage;
    }

    function getMessage() public view returns (string memory) {
        return message;
    }
}

Note: If you already have your own developed smart contract, you can skip the sample code and use yours instead.

This contract will serve as the foundation for our front-end interaction in the following steps of the tutorial.

Explanation of the Smart Contract

Features of the smart contract:

Stores a message in a private variable message, initialized with "Hello Mode Chads".
Offers two main functions:
- setMessage: Allows changing the stored message.
- getMessage: Allows reading the current message without modifying it.

Compilation and Deployment of the Smart Contract

In this tutorial, we will not delve into the process of compiling and deploying smart contracts. However, it is a crucial step in DApp development. For those interested in exploring this topic further, Mode offers excellent resources:

For a detailed guide on how to deploy smart contracts using Foundry, Hardhat, Remix, or Thirdweb, check the official Mode documentation.

Although we won't delve into these processes, here are the basic commands using Foundry:

Compilation: forge build
Deployment: forge create --rpc-url https://sepolia.mode.network --private-key <YOUR_PRIVATE_KEY> contracts/HelloMode.sol:HelloMode --constructor-args <arg1> <arg2> <arg3>

Note: If you are going to use these commands, you must have Foundry installed. If you haven't done so yet, you can find detailed instructions in the official Foundry documentation.

If the deployment was successful, you should see something like this:

For a detailed tutorial on compiling and deploying with Foundry, check this link.

Note: Remember, we are using Mode's testnet for this tutorial, which is ideal for development and testing before moving to the mainnet.

To interact with a smart contract from the front-end, we need two essential elements:

Address
- The address is the unique identifier of the contract on the blockchain.
- It is obtained after the contract is deployed.
- It is a hexadecimal string that identifies the contract's location on the network.
ABI (Application Binary Interface)
- The ABI is an interface that defines how to interact with the contract.
- It is generated when the contract is compiled.
- It describes the functions and structures of the contract in JSON format.

Obtaining the ABI:

In Foundry: It can be found in the out directory after compilation.
In Remix: Available in the "Compilation Details" tab.

Project Setup

1 Create a .json file in your project. You can name it whatever you like; in this tutorial, we will use abi.json. Add the following content:

{

    "address": "", // Deployed contract address

    "abi":  // Contract ABI

}

2 Import the file into your main component: Open page.tsx and add the following import line:

    import abi from "../../abi.json";

Note: Although we are using abi as the import name here, you can choose any name that is clear to you, such as contract or smartContract.

Recap

So far, we have:

Created and deployed our smart contract.
Obtained the address and the ABI of the contract.
Stored this data in a .json file in our project.
Imported this file into our main component (page.tsx).

With these steps completed, we are ready to start reading from and writing to our smart contract from the front-end.

Interacting with the Contract

Now that we have access to the address and ABI of our contract from page.tsx, let's interact with it by reading and writing data.

Reading from the Smart Contract

We will use useReadContract from wagmi to read information from the contract. Wagmi is a React Hooks library that simplifies interaction with smart contracts on Ethereum.

1 Look up useReadContract in the wagmi documentation:
- Go to the hooks section (functions that start with "use").
- Find useReadContract (the name may vary in future versions of wagmi).
2 Import useReadContract in your page.tsx:

import { useReadContract } from 'wagmi'

3 Set up useReadContract in your component:

const result = useReadContract({
    abi: abi.abi,
    address: abi.address as `0x${string}`,
    functionName: 'getMessage',
})

Note:

abi: abi.abi: The first abi is the property of the object, while the second refers to the imported ABI.
as '0x${string}': This is to satisfy TypeScript typing for Ethereum addresses.

4 Create a state for the message using a React hook:

const [message, setMessage] = useState("")

useState allows you to add state to functional components.

5 Display the message in your component:

{message == "" ? 'Hello Mode' : message}

Remember: If you're using hooks like useState, make sure to include 'use client' at the top of page.tsx to avoid errors.

Your page.tsx should look like this:

'use client'
import Image from "next/image";
import styles from "./page.module.css";
import { useEffect, useState } from "react";
import abi from "../../abi.json";
import { useReadContract } from 'wagmi'

export default function Home() {
  const [message, setMessage] = useState("")
  const result = useReadContract({
    abi: abi.abi,
    address: abi.address as `0x${string}`,
    functionName: 'getMessage',
  })

  return (
    <div className={styles.page}>
      <main className={styles.main}>
        <w3m-button />
        {message === "" ? 'Hello Mode' : message}
        {/* Rest of your component */}
      </main>
    </div>
  )
}

And the front-end like this:

Now let's update message with information from the contract in real-time.

Using useEffect to Update the Message

We will use the useEffect hook from React. This hook allows you to run side effects in functional components, such as updating state based on changes to certain variables.

Implement useEffect in your component:

  useEffect(() => {
    if (result.data) {
      console.log({ result: result.data });
      setMessage(result.data as string);
    }

  }, [result])

Explanation:

This useEffect will run every time result changes.
[result] at the end indicates that the effect depends on result.
If result.data exists, we update message with that value.

Update your component to use this logic:

export default function Home() {
  const [message, setMessage] = useState("")
  const result = useReadContract({
    abi: abi.abi,
    address: abi.address as `0x${string}`,
    functionName: 'getMessage',
  })

  useEffect(() => {
    if (result.data) {
      console.log({ result: result.data });
      setMessage(result.data as string);
    }

  }, [result])

  return (
    <div className={styles.page}>
      <main className={styles.main}>
        <w3m-button />
        {message === "" ? 'Hello Mode' : message}
        {/* Rest of your component */}
      </main>
    </div>
  )
}

With this, the message will change from "Hello Mode" to "Hello Mode Chads" (or whatever text is stored in the contract).

To verify that this works:

Observe the change in the front-end from "Hello Mode" to "Hello Mode Chads".
You can modify the value in the contract to something like 'Hello Chads Mode' to see the change reflected.

Recap

We have used two main hooks:

useState: To manage the message state in the component.
useEffect: To update the message when we get data from the contract.

result contains the information read from the contract. When result changes, useEffect checks for data and updates the message on the front-end.

The next step will be to implement the functionality to write to the contract from the front-end.

useWriteContract

After reading information from the smart contract, we will now write data from the front-end. For this, we will use the writing functions, just as we did with useReadContract, but now with useWriteContract.

useWriteContract is a hook provided by wagmi that allows us to perform transactions that modify the state of a smart contract. Through this hook, we can invoke contract functions that write or change data on the blockchain.

Note: If you're following this tutorial, always check the current wagmi documentation, as the names or features of hooks may change over time.

Implementing `useWriteContract`

We import useWriteContract in the same way we did with useReadContract. Add this import in your page.tsx file:

import { useReadContract, useWriteContract } from 'wagmi'

In the Home component, we configure useWriteContract as follows:

const { writeContract } = useWriteContract()

Your page.tsx file should now look like this:

'use client'
import Image from "next/image";
import styles from "./page.module.css";
import abi from "../../abi.json";
import { useReadContract, useWriteContract } from 'wagmi';
import { useEffect, useState } from "react";

export default function Home() {
  const [message, setMessage] = useState("")
  const result = useReadContract({
    abi: abi.abi,
    address: abi.address as `0x${string}`,
    functionName: 'getMessage',
  })

  const { writeContract } = useWriteContract() // <- Here we use the writing hook

  useEffect(() => {
    if (result.data) {
      console.log({ result: result.data });
      setMessage(result.data as string);
    }
  }, [result])

  return (
    <div className={styles.page}>
      <main className={styles.main}>
        <w3m-button />
        {message === "" ? "Hello Mode" : message}
        {/* Rest of the code */}
      </main>
    </div>
  )
}

Creating a Form to Capture Data

To write data to the contract, we need to capture it from the front-end. We will use a form to obtain the value we want to send to the contract.

Add this form below where we display the message:

<form onSubmit={changeMessage}>
          <input type="text" name="name" />
          <button type="submit">Send</button>
</form>

Function `changeMessage`

Now, we will create an asynchronous function called changeMessage that captures the data from the form and sends it to the smart contract:

  const changeMessage = async (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();
    const form = event.target as HTMLFormElement;
    const inputUsed = (form.elements[0] as HTMLInputElement).value as string;
  };

Explanation:

event.preventDefault() prevents the form from reloading the page.
form.elements[0].value gets the value entered in the text field.

Executing `writeContract`

To send the data to the contract, we use writeContract. According to the wagmi documentation, the basic logic to execute this hook is as follows:

    writeContract({
          abi,
          address: '0x6b175474e89094c44da98b954eedeac495271d0f',
          functionName: 'transferFrom',
          args: [
            '0xd2135CfB216b74109775236E36d4b433F1DF507B',
            '0xA0Cf798816D4b9b9866b5330EEa46a18382f251e',
            123n,
          ],
       })

We add this logic inside our changeMessage function:

  const changeMessage = async (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();
    const form = event.target as HTMLFormElement;
    const inputUsed = (form.elements[0] as HTMLInputElement).value as string;
    writeContract({
          abi,
          address: '0x6b175474e89094c44da98b954eedeac495271d0f',
          functionName: 'transferFrom',
          args: [
            '0xd2135CfB216b74109775236E36d4b433F1DF507B',
            '0xA0Cf798816D4b9b9866b5330EEa46a18382f251e',
            123n,
          ],
       })
  };

We set up the logic to interact with the ABI, the contract address, and the function with the necessary arguments. This is what the complete component should look like:

'use client'
import Image from "next/image";
import styles from "./page.module.css";
import abi from "../../abi.json";
import { useReadContract, useWriteContract } from 'wagmi'
import { FormEvent, useEffect, useState } from "react";

export default function Home() {
  const [message, setMessage] = useState("")
  const result = useReadContract({
    abi: abi.abi,
    address: abi.address as '0x${string}',
    functionName: 'getMessage',
  })

  const { writeContract } = useWriteContract()

  useEffect(() => {
    if (result.data) {
      console.log({ result: result.data });
      setMessage(result.data as string);
    }
  }, [result])

  const changeMessage = async (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();

    const form = event.target as HTMLFormElement;
    const inputUsed = (form.elements[0] as HTMLInputElement).value as string;
    writeContract({
      abi: abi.abi,
      address: abi.address as '0x${string}',
      functionName: 'setMessage',
      args: [inputUsed],
    })
  };

  return (
    <div className={styles.page}>
      <main className={styles.main}>
        <w3m-button />
        {message == "" ? '' : message}

        <form onSubmit={changeMessage}>
          <input type="text" name="name" />
          <button type="submit">Send</button>
        </form>

        Rest of the code.....

And this is how your front-end should appear:

With this structure, you can now send data to the smart contract from the front-end. You should see the changes reflected in the contract when you enter a new value and press "Send"!

Conclusion

Congratulations on completing our series "Integrating DApps with Mode: Wallet and Smart Contracts"! You have made significant progress in decentralized application development, acquiring crucial skills to create complete and functional DApps on the Mode network.

Throughout this series, you have achieved:

Set up a Next.js project for Web3 development.
Integrated ReoWn (formerly WalletConnect) into your application.
Implemented wallet connection with support for the Mode network.
Connected a smart contract to your front-end on the Mode network.
Performed read and write operations on the blockchain from your user interface.
Used the Mode testnet for development and testing.

Now you have the skills to leverage Web3 capabilities in a Next.js application and interact with the Mode network through smart contracts. Remember, this is just the starting point for developing more advanced DApps on Mode. We encourage you to continue exploring and building on these concepts.

Next Steps

Experiment with more complex contracts.
Explore advanced features of the Mode network.
Participate in hackathons or community projects on Mode.
Share your creations with the Mode developer community.

Support and Resources

If you encounter any issues or have questions, feel free to join the Mode Discord and obtain the developer role. Here is how to get the role. The community is always ready to help.

Additional Resources:

Thank you for being part of this educational series! We hope these tutorials have provided you with the tools and confidence needed to embark on exciting development projects on Mode. Learning in the blockchain space is ongoing, so stay updated with the latest news from Mode and the Web3 ecosystem in general.

We look forward to seeing the amazing DApps you will build on Mode. The future of decentralized applications awaits you!

INTEGRATION OF DAPPS WITH MODE: WALLET AND SMART CONTRACTS | PART 1: CONNECTING THE WALLET

wispy — Tue, 10 Dec 2024 14:53:20 +0000

This tutorial is also available in video format. If you prefer to follow along visually, you can watch it here. Let's get started!

Welcome to the first part of our series, "Integrating DApps with Mode: Wallet and Smart Contracts"! In this introductory tutorial, we'll dive into connecting wallets to a Next.js application, with a special focus on integrating the Mode blockchain.

Throughout this guide, you will learn how to:

Set up a basic Next.js project to create the foundation for your decentralized application
Install and configure reown to enable wallet connections and smart wallet support
Add Mode network to the wallet options (and any EVM chain)

The wallet integration you'll learn in this tutorial is a fundamental step in developing decentralized applications (DApps). By enabling users to connect their wallets to your application, you'll establish the necessary foundation to interact with the Mode. While we're focusing specifically on this connection, mastering this component is essential for any DApp you plan to build in the future.

Once you complete this part, you'll be ready to move on to Part 2 of the series, where we'll explore how to connect a smart contract to the front end we create here, further expanding your application's capabilities. Ready to take this important first step in developing your DApp with Mode? Let's get started!

Installing Next.js

1 Open your terminal and run the following command to install Next.js:

`npx create-next-app@13.4.19`

2 During the installation, configure your project with the following options:

Project name: mode-chain
TypeScript: yes (optional)
- Selecting yes enables TypeScript for static typing, helping to catch errors early and improve code quality. Choosing no configures your project to use JavaScript.
ESLint: yes (optional)
- If you choose yes, ESLint will be integrated to help detect errors and maintain code quality. Selecting no means that no linting rules will be applied by default.
Tailwind CSS: no (optional)
- Choosing no means Tailwind CSS will not be installed, so you won’t have access to its utility classes for rapid styling. You can always integrate Tailwind CSS later if you decide you want to use it for custom styling.
src/ directory: yes (optional)
- Selecting yes creates a src/ folder to organize your source code. If you choose no, your code will reside in the project's root directory.
App Router: yes (optional)
- If you select yes, a router will be set up to manage navigation in your application. Choosing no means you'll need to implement navigation manually later on.
Import alias: yes (optional)
- By choosing yes, you can use import aliases, which helps in organizing your code and improving readability. If you select no, you'll have to use standard relative paths for imports.

3 Once the installation is complete, navigate to the project directory with:

`cd mode-chain`

4 To view the initial front-end, run:

`npm run dev`

You should see an output similar to this in your terminal:

5 Open your browser and go to http://localhost:3000. You can also directly open the link by Ctrl + left-click on the URL that appears in the terminal.
This is what your application looks like before integrating reown:

Cloud Configuration

Project ID and reown (formerly known as WalletConnect) Setup

Visit https://cloud.reown.com/sign-in and create an account (I recommend creating an account instead of connecting a wallet, as this can lead to several issues).
Create a new project by clicking "Create New Project."
You will see two options:
- Name: Enter your project name (for example, "mode-chain").
- Link Home page URL: You can leave this field blank if you prefer.
Click on "Continue." Then, two new options will appear: AppKit and WalletKit. Select AppKit and choose React.
After creating the project, you will be directed to the “QuickStart” section. Here you will find:
1. Install package: In my case, I’ll select npm and wagmi. The reown installation command will be:
  
  npm i @reown/appkit @reown/appkit-adapter-wagmi wagmi viem @tanstack/react-query
2. Get started: This section will provide you with code for:
  - wagmi configuration (including your Project ID automatically)
  - Context Provider
  - Layout
  These code snippets are crucial for the implementation and will be used in the following sections of the tutorial.

The Project ID is a unique identifier that allows you to use reown services in your application.

Installing reown

After setting up your project in reown Cloud, follow these steps to install reown in your Next.js project:

In the "QuickStart" section of your project on reown Cloud, specifically under Install package, you will see the installation options. For this tutorial, we will use npm and wagmi.
Open a terminal in your project directory and run the following command:

npm i @reown/appkit @reown/appkit-adapter-wagmi wagmi viem @tanstack/react-query

This command installs all the necessary dependencies for reown and wagmi.

Note: If you prefer to use a different setup (e.g., yarn instead of npm, or ethers instead of wagmi), you can find specific instructions in the official reown documentation.

reown implementation

Wagmi Config

The Wagmi configuration is essential for integrating reown and the desired chains, including Mode Chain. Follow these steps:

Create a new folder called config at the root of your project.
Inside the config folder, create a file named index.tsx.
Copy the following code and paste it into config/index.tsx:

This is what your application looks like before integrating reown:

// config/index.tsx

import { cookieStorage, createStorage, http } from '@wagmi/core'
import { WagmiAdapter } from '@reown/appkit-adapter-wagmi'
import { mainnet, sepolia, mode, modeTestnet } from '@reown/appkit/networks'

// Get projectId from https://cloud.reown.com
export const projectId = 'YOUR_PROJECT_ID'

if (!projectId) {
    throw new Error('Project ID is not defined')
}

export const networks = [mainnet, sepolia, mode, modeTestnet]

//Set up the Wagmi Adapter (Config)
export const wagmiAdapter = new WagmiAdapter({
    storage: createStorage({
        storage: cookieStorage
    }),
    ssr: true,
    projectId,
    networks
})

export const config = wagmiAdapter.wagmiConfig

Main Features:

Replace YOUR_PROJECT_ID with the project ID you obtained from reown Cloud.
In the line import { mainnet, sepolia, mode, modeTestnet } from '@reown/appkit/networks':
- mainnet and sepolia are Ethereum chains included by default (mainnet and Sepolia testnet).
- We added mode (Mode mainnet) and modeTestnet (Mode testnet) to integrate Mode chains.
Session storage: CookieStorage is used to save session data, allowing users to continue where they left off when they return to the application.
WagmiAdapter: This adapter simplifies the connection setup with Wagmi using the Reown project. The ssr: true option is also defined to ensure the configuration works on the server side.

Context Provider

The Context Provider is necessary to initialize Web3Modal and wrap our application. Follow these steps:

Create a new folder called context at the root of your project.
Inside the context folder, create a file named index.tsx.
Copy the following code and paste it into context/index.tsx:

// context/index.tsx
'use client'

import { wagmiAdapter, projectId } from '../config'
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'
import { createAppKit } from '@reown/appkit/react'
import { mainnet, sepolia, mode, modeTestnet } from '@reown/appkit/networks'
import React, { type ReactNode } from 'react'
import { cookieToInitialState, WagmiProvider, type Config } from 'wagmi'

// Set up queryClient
const queryClient = new QueryClient()

if (!projectId) {
    throw new Error('Project ID is not defined')
}

// Set up metadata
const metadata = {
    name: 'mode-chain',
    description: 'AppKit Example',
    url: 'https://reown.com/appkit', // origin must match your domain & subdomain
    icons: ['https://assets.reown.com/reown-profile-pic.png']
}

// Create the modal
const modal = createAppKit({
    adapters: [wagmiAdapter],
    projectId,
    networks: [mainnet, sepolia, mode, modeTestnet],
    defaultNetwork: mainnet,
    metadata: metadata,
    features: {
        analytics: true, // Optional - defaults to your Cloud configuration
    }
})

function ContextProvider({ children, cookies }: { children: ReactNode; cookies: string | null }) {
    const initialState = cookieToInitialState(wagmiAdapter.wagmiConfig as Config, cookies)

    return (
        <WagmiProvider config={wagmiAdapter.wagmiConfig as Config} initialState={initialState}>
            <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
        </WagmiProvider>
    )
}

export default ContextProvider

Main Features:

Connection Modal: createAppKit creates the modal that will allow users to connect their wallets to the application. It is configured with the wagmiAdapter, projectId, and the supported networks (Ethereum and Mode).
Cookies: The cookieToInitialState function retrieves the cookies stored in the browser to initialize the application with the user's previous state, ensuring continuity of their session.
Clients and Providers: QueryClientProvider and WagmiProvider are responsible for providing the necessary context so that the entire application can interact with Web3 and the configured networks.

Layout

The Layout is crucial for integrating Web3ModalProvider throughout your Next.js application. Follow these steps:

Open the app/layout.tsx file in your project.
Replace the existing content with the following code:

// app/layout.tsx
import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";

import { headers } from "next/headers"; // added
import ContextProvider from '../../context'

export const metadata: Metadata = {
  title: "AppKit Example App",
  description: "Powered by WalletConnect"
};

export default async function RootLayout({
  children
}: Readonly<{
  children: React.ReactNode
}>) {
  const headerList = await headers();
  const cookies = headerList.get('cookie')

  return (
    <html lang="en">
      <body>
        <ContextProvider cookies={cookies}>{children}</ContextProvider>
      </body>
    </html>
  )
}

Main Features:

Headers and Cookies: The use of headers() in Next.js allows for retrieving cookies passed from the server, which is necessary for initializing the user's session state in the application.
Global Wrappers: Wraps the entire application within the ContextProvider, enabling Web3 functionalities (such as wallet connections) to be available across all pages of the application.

Trigger the Modal

To allow users to connect their wallets, we need to add a button that triggers the reown modal. Follow these steps:

Reown provides a web component <w3m-button /> that you can use directly in your application.
This component does not require importing, as it is a global HTML element.
To add the connection button, simply insert <w3m-button /> into any component of your application where you want it to appear.

Example usage:

export default function HomePage() {
  return (
    <div>
      <h1>Welcome to my DApp!</h1>
      <w3m-button />
    </div>
  )
}

After adding the connection button to your DApp, you should see a button with the text "Connect Wallet," similar to this:

When we connect the wallet, we can observe that we have access to both the Mode mainnet and the Mode testnet:

Note: If you prefer more control over the design or behavior of the button, you can create your own component using the AppKit hooks. Check the official documentation for more details.

Get ready for the next level!

In Part 2 of this series, we'll take your DApp to the next level by connecting a smart contract to the front end we just created. This will allow you to interact with the Mode blockchain more comprehensively, unlocking the full potential of your decentralized application.

Useful links:

Thank you for following this tutorial! If you have any questions or feedback, feel free to share them. See you in Part 2!

Exploring OP Stack and Superchain: The Future of Ethereum Layer 2

wispy — Wed, 27 Nov 2024 23:55:08 +0000

The OP Stack and the Superchain are key components in the evolution of the Ethereum ecosystem, proposed by the Optimism collective. The OP Stack is a modular open-source infrastructure that enables the creation of efficient and scalable Layer 2 (L2) blockchains. Meanwhile, the Superchain aims to integrate multiple L2s under a framework of interoperability, optimizing communication and asset exchange between them. This article explores these concepts in detail, highlighting their features and benefits, and providing a clear understanding for those interested in the innovations of Optimism.

What is the OP Stack?

The OP Stack is a standardized, shared, open-source development stack created by the Optimism collective. It serves as the set of software components that supports Optimism's infrastructure, including its current mainnet, OP Mainnet, and the concept of the Superchain. This infrastructure enables the construction of secure and scalable Layer 2 (L2) blockchains that collaborate to address Ethereum's scalability issues. Essentially, the OP Stack is a “template” that allows organizations or projects to launch their own blockchain compatible with the Ethereum ecosystem without having to build everything from scratch.

Structure and Components of the OP Stack

Optimism Bedrock: Optimism Bedrock is the current version of the OP Stack, designed to deploy production-ready Optimistic Rollups. Its modular structure allows for future evolution, including greater flexibility in integrating additional components.
Evolution Towards the Superchain: As the concept of the Superchain develops, the OP Stack will increasingly focus on creating an interoperable network of L2 blockchains, facilitating secure interactions and more efficient asset transfers between different chains.

Key Advantages of the OP Stack

Cost Reduction: Transactions on an OP Stack-based Layer 2 blockchain are significantly cheaper than those on the Ethereum mainnet, resulting in substantial cost savings for both users and businesses.
Time and Resource Savings: By using the OP Stack, companies can leverage an optimized and pre-existing infrastructure, eliminating the need to develop a blockchain from scratch.
Integrated Security and Scalability: By adopting the OP Stack architecture, projects benefit from a proven infrastructure that provides a reliable foundation, along with inherent scalability from the Rollup model.
Interoperability with the Superchain: Implementing the OP Stack enables seamless integration of the blockchain into Optimism's Superchain, allowing for secure communication between chains and the exchange of assets. This interoperability feature provides flexibility for users and maximizes asset liquidity.

A Modular and Scalable Future

The OP Stack is a constantly evolving project. The Bedrock version simplifies the creation of Layer 2 Rollups, but in the future, its modular design is expected to allow the integration of various features, such as cross-chain messaging mechanisms, which will promote complete interoperability within the Superchain ecosystem.

Superchain

The Vision of Scalability

The vision of scalability in blockchain aims to create an ecosystem capable of supporting a decentralized web: an internet without intermediaries and built on open protocols. Current scalability limitations have prevented blockchain from reaching its full potential, leaving many applications off-chain. However, we now have a clearer vision of how to design a truly scalable blockchain, which we refer to as the Superchain.

Foundational Superchain concepts

Horizontal scalability requires multiple chains…

Horizontal scalability is achieved by adding multiple chains that operate in parallel, distributing the processing load among them. This way, each chain manages only a portion of the work, preventing any single chain from becoming overloaded and allowing the system as a whole to process more transactions.

…but traditional multi-chain architectures are insufficient

Traditional multi-chain architectures face two key challenges:

Each new chain requires its own security model, increasing systemic risk as the ecosystem expands.
Creating new chains is costly, as it requires the implementation of new validators and block producers.

To address these issues, Optimism proposes a shared Layer 1 blockchain that serves as a common source of truth for all Layer 2 solutions within the multi-chain system.

With a Layer 1 serving as a shared source of truth, it becomes possible to:

Apply a standard security model across all chains.
Eliminate the need for new validators, as each L2 chain would adopt the consensus of the L1.

In this way, the Superchain integrates the security and standardization of the L1 with the scalability of multiple L2s.

Not multi-chain, not mono-chain… Superchain

The Superchain is a decentralized blockchain platform that connects multiple layer 2 (L2) chains under a unified framework of security and technology known as the OP Stack. This standardized architecture allows each chain to function as an interchangeable resource within a unified network. Unlike traditional multi-chain and mono-chain systems, the Superchain enables developers to build applications that operate seamlessly across chains, eliminating systemic risks and implementation costs. The interoperability of OP Chains ensures that tools and wallets interact uniformly with all chains, simplifying the experience for both developers and users.

Summary of the Superchain

The Superchain is a network of layer 2 (L2) blockchains, known as OP Chains, that share the security of Ethereum (L1), a communication layer, and an open-source infrastructure called the OP Stack.
Each OP Chain is standardized to function as an interchangeable resource, allowing developers to build applications that can be deployed across the Superchain without relying on a specific chain. This means that an application can run on any OP Chain within the network, and developers can switch chains without affecting the functionality of their applications.
The OP Chains are officially managed by the Optimism Collective, ensuring that all of them adhere to the same standards and create a unified and secure ecosystem.

To view the list of available OP Chains, visit this link. For more details about the Superchain and its architecture, check here.

Today, the Superchain is a concept and an ongoing project, not yet a concrete reality. The documentation represents the best current estimate of what the components, features, and roadmap of the Superchain will be. Ultimately, its realization will depend on the contributions from the entire Optimism Collective (and will evolve alongside them).

Conclusion

In conclusion, the OP Stack and the Superchain represent a significant advancement in the scalability and interoperability of the Ethereum ecosystem. The OP Stack provides a modular and efficient infrastructure that allows developers to create Layer 2 (L2) blockchains more easily and cost-effectively, leveraging the benefits of the Optimistic Rollup model. As the concept of the Superchain evolves, it paves the way for an interconnected network of L2s, where chains can communicate and share assets seamlessly, maximizing liquidity and efficiency within the ecosystem. Together, the OP Stack and the Superchain not only enhance the user and developer experience but also strengthen security and standardization within the Optimism community.
If you would like to dive deeper, here are some technical resources on the OP Stack and the Superchain

OP Stack - By Optimism Docs
Superchain explainer - By Optimism Docs
What is the Superchain? The Complete Guide - By thirdweb
What is Superchain? A Complete Guide - By QuillAudits

Exploring SuperSim: Simulating Interoperability on the Superchain with OP Stack

wispy — Wed, 30 Oct 2024 17:00:35 +0000

Recently, I had the opportunity to try out a new tool called SuperSim. As a Mode ambassador, I was able to test it and wanted to share my feedback. Given my ongoing research into L2 solutions, particularly the Optimism ecosystem, this tool caught my attention as a potential asset in understanding how L2s function in practice.

In this article, I'll walk you through my experience with SuperSim — from the testing process to the challenges I faced, the lessons I learned, and how all of this deepened my understanding of L2 solutions.

What is SuperSim?

SuperSim is a lightweight tool designed to simulate the Superchain, which consists of a single L1 chain and multiple L2 chains built with the OP-Stack. Its main advantage is simplicity: it allows devs to run multiple local nodes with a single command, significantly easing the coordination of message passing between these chains. Moreover, it does not require complex devnet configurations, as everything is managed through CLI commands that automatically adjust if no configuration options are specified. Each chain operates as an instance of anvil, a widely used testing tool in local environments.

SuperSim enables working with pre-deployed anvil nodes and contracts based on the OP Stack, as well as forking multiple remote chains, which allows for replicating the state of the entire Superchain for more realistic testing. Additionally, it simplifies message simulation between L1 and L2, such as deposits, and interoperability between L2 chains, with a built-in auto-relayer that streamlines communication. It will soon include additional features, such as withdrawals and account abstraction services based on the ERC-4337 standard, like bundlers and paymasters, as well as the implementation of smart wallets.

How was the Developer Experience?

The installation process for SuperSim was quite straightforward since it is built on Foundry, a widely used tool. However, when I attempted to install SuperSim in an Ubuntu environment running on Windows via WSL, I encountered a problem: the provided commands assumed that Homebrew was already installed, which is not the default case on Ubuntu. To resolve this, I installed Linuxbrew, a version of Homebrew for Linux.

If you have Ubuntu and want to install Homebrew to try it out, here’s the link that explains the entire process: Homebrew on Linux

Thanks to this installation, I successfully executed the necessary commands to install SuperSim in my WSL environment.

Once I installed Homebrew, I proceeded with the installation of SuperSim, which turned out to be quite straightforward.

The “First steps” section is the best place to start, which is divided into two sections. The first involves depositing ETH from L1 to L2, and the second involves sending an interoperable SuperchainERC20 token from chain 901 to 902.

1. Deposit ETH from the L1 into the L2 (L1 to L2 message passing)
First, I verified the balance on L2 (chain 901) to ensure I had an accurate starting point. After confirming the balance, I initiated a transaction from L1 (chain 900) by sending 0.1 ether. Once the transaction was completed, I checked the L2 balance again, which had increased accordingly, reflecting the successful transfer.

2. Send an interoperable SuperchainERC20 token from chain 901 to 902 (L2 to L2 message passing)

The goal of this step is to transfer an ERC20 token from one L2 (chain 901) to another L2 (chain 902). Typically, a cross-chain L2 to L2 transfer involves two key transactions:

- Send transaction on the source chain (chain 901): This initiates the token transfer on chain 901. During this transaction, the token is locked on the source chain, and the transfer details are prepared to be sent to the destination chain.

- Relay message transaction on the destination chain (chain 902): Once the transfer details reach chain 902, a transaction on the destination chain is triggered to finalize the token reception. This transaction ensures that the tokens are available on chain 902.

Optimizing with --interop.autorelay
To simplify this process, SuperSim offers the --interop.autorelay flag, automatically triggering the relay message transaction on the destination chain. This removes the need for manually sending the relay message, significantly improving the developer experience.

Here’s what I did:

1. I started SuperSim with the auto-relay mode enabled.
I did this by running the following command:

supersim --interop.autorelay

2. Mint tokens on chain 901 to prepare them for transfer.
I executed the following command to mint 1000 L2NativeSuperchainERC20 tokens to the recipient's address:

cast send 0x420beeF000000000000000000000000000000001 "mint(address _to, uint256 _amount)" 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 1000 --rpc-url http://127.0.0.1:9545 --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

3. Initiate the send transaction on chain 901, transferring the tokens from chain 901 to chain 902.
I did this using the following command:

cast send 0x420beeF000000000000000000000000000000001 "sendERC20(address _to, uint256 _amount, uint256 _chainId)" 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 1000 902 --rpc-url http://127.0.0.1:9545 --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

4. I waited a few seconds for the relay message to appear on chain 902.
Here is the message:

INFO [10-22|13:24:00.942] L2ToL2CrossChainMessenger#RelayedMessage sourceChainID=901 destinationChainID=902 nonce=0 sender=0x420beeF000000000000000000000000000000001 target=0x420beeF000000000000000000000000000000001

5. Finally, I checked the balance on chain 902 to confirm that the tokens had been successfully transferred and that the balance had increased.
I ran the following command to verify the balance:

cast balance --erc20 0x420beeF000000000000000000000000000000001 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 --rpc-url http://127.0.0.1:9546

Following this guide was fairly easy, given that I have been researching how L2s work, particularly in the context of Optimism. If you want to dive deeper into this topic, I recently published an article on optimistic rollups which you can read here.

After completing the "First steps" section, I explored the interoperability guide titled "Message Relay Manual with cast," which describes how to send messages between different blockchain layers. In this guide, we manually transfer SuperchainERC20 tokens without using the automatic relay feature. The process involves starting the transfer on one layer and then sending the necessary message to complete it on the other layer, if you want to better understand what this involves, here's the link so you can try it too.

While following the guide, I encountered an error during the "Send the relayMessage transaction" step:

Error: server returned an error response: error code 3: execution reverted: custom error 0xeda86850, data: "0xeda86850".

Although I double-checked that I was following the steps correctly, the error persisted, and attempts to find solutions using AI were unsuccessful.

I decided to seek support from the Optimism community. I joined the Optimism Discord and asked in the general chat where I could discuss the issue related to SuperSim. There, I was provided with a link to the repository where I could create a discussion.

Upon opening the link, I found several options offering different approaches, some more technical than others, such as "Feedback," "Ideas," "General," and "Developer Questions." First, I identified which category would best fit my situation. Since I didn't find any discussions related to the error I was experiencing in the "Developer Questions" section, I decided to create one in the "General" category.

I added a title that was as descriptive as possible for the problem I was facing and provided detailed, clear, and coherent context regarding my error, ensuring I included all relevant information for others to understand my situation. Finally, I created the discussion outlining the error and the context of my work.

A few days later, I received a response informing me that they had updated the documentation and asked me to check if the problem persisted. To my satisfaction, the error was resolved; it appeared to be an issue with the original documentation. I’m glad it has been corrected, and I can now effectively test SuperSim.

This was my first time creating a discussion on GitHub, and I found it to be an interesting experience. I'm very pleased with the prompt response and quick solution I received.

You can view the complete discussion here. If you'd like to create a discussion, you can do so here.

Learnings and Reflections

Thanks to following the steps in the "First Steps" guide, I successfully bridged ETH from Layer 1 to Layer 2 and transferred an interoperable SuperchainERC20 token between Layer 2, all done locally.

Additionally, while exploring the interoperability guide titled "Message Relay Manual with cast," I learned how to create a message identifier for cross-chain call transmission. This guide outlines the manual message relay process for transferring the SuperchainERC20 token, including key steps such as initiating the transfer on the source chain and relaying the message on the destination chain. This experience has provided me with a broader understanding of interactions between L2s, expanding my knowledge of L2s and the Optimism ecosystem.

In summary, this experience reinforces the importance of interoperability in multi-chain environments and highlights the usefulness of tools like SuperSim to facilitate these interactions.I plan to create content about what I learn and share my insights along the way.

For more details and to try SuperSim, you can check out the official documentation here.

My social media:

x.com/wispyiwnl
warpcast.com/wispyiwnl

Unit Test ModeSpray

wispy — Wed, 18 Sep 2024 14:19:14 +0000

In this article, I will share my experience conducting a unit test on one of ModeSpray's smart contracts. This is the first test I have carried out, marking the beginning of my journey in web3 security, a path I started about a month ago. Documenting this process not only helps me consolidate what I have learned but can also serve as a guide for others just starting in this field.

As a Security Researcher, I have been analyzing various dApps in the Mode Network ecosystem, available in their registered applications here. During this analysis, I found ModeSpray and decided to focus on assessing the security of its smart contract. Below, I detail my approach and the results obtained during this test.

ModeSpray

Before diving into the test I performed, I want to explain what ModeSpray is.

Mode Spray is a dApp that simplifies the process of sending tokens on Mode. The user-friendly interface allows users to send tokens to multiple wallets in a single transaction. It uses an optimized process to cut down on the transaction fees incurred in transferring funds. You can use Mode Spray to pay contributors, send out grants or just transfer tokens to friends in one go super fast.

ModeSpray is open-source, and you can view the code here, in addition to being open to contributions.

Unit Test

A unit test is a test that verifies the correct functioning of an individual unit of code, such as a function. It evaluates the behavior of a single part of the code in isolation, ensuring that each component fulfills its intended purpose and allows for easy identification and resolution of errors.

I conducted the test with Foundry, following the article by RareSkills which helped reinforce my knowledge. For this article, I recommend having basic knowledge of Solidity.

Environment Setup

I will walk you through the process I followed to configure everything and start the test (this part is more for documenting the process, it can be skipped).

I had already installed Foundry. If you do not have it installed and want to install it, you can follow the instructions in the Foundry Documentation.

The setup process was as follows:

Clone the repository git clone “REPOSITORY_URL”
Access the repository cd modespray
Open the repository in VSCode code .
Initialize a Foundry project Open the terminal in VSCode and initialize a Foundry project. forge init
Install OpenZeppelin forge install OpenZeppelin/openzeppelin-contracts

Smart Contract Description

The BaseSpraycontract, which inherits from OpenZeppelin's Ownable, allows the distribution of ether among multiple recipients. Below, I provide a brief description of its functionality:

Constructor: Initializes the Ownablecontract with an initialOwneraddress as the owner.
disperseEther function:
1. Parameters: Accepts two arrays in memory: _recipients (recipient addresses) and _amounts (amounts to distribute).
2. Require:
3. The _recipients and _amounts arrays must have the same length. If not, the function reverts.
4. The _recipients array cannot be empty. If it is empty, the function reverts.
Calculation of totalValue: Accumulates the sum of all _amounts values to determine the total amount to be distributed.
Balance verification: Ensures that the contract's balance is sufficient to cover totalValue. If not, the function reverts with the message “Insufficient balance”.
Ether distribution: Iterates over the recipients and makes the corresponding transfers.
Event: Emits the TokenDispersed event with the transaction details.

// SPDX-License-Identifier: MIT
// Compatible with OpenZeppelin Contracts ^5.0.0
pragma solidity ^0.8.20;

import '@openzeppelin/contracts/access/Ownable.sol';
import '@openzeppelin/contracts/utils/Address.sol';
import '@openzeppelin/contracts/token/ERC20/ERC20.sol';

/// @custom:security-contact wolfcito.eth+security@gmail.com
contract BaseSpray is Ownable {
    event TokenDispersed(
        address indexed sender,
        address[] recipients,
        uint256[] values,
        address token
    );

    constructor(address initialOwner) Ownable(initialOwner) {}

    function disperseEther(
        address[] memory _recipients,
        uint256[] memory _amounts
    ) external payable {
        require(
            _recipients.length == _amounts.length,
            'Number of recipients must be equal to the number of corresponding values'
        );

        require(_recipients.length > 0, 'Recipients array cannot be empty');

        uint256 totalValue = 0;

        for (uint256 i = 0; i < _recipients.length; i++) {
            totalValue += _amounts[i];
        }

        require(address(this).balance >= totalValue, 'Insufficient balance');

        for (uint256 i = 0; i < _recipients.length; i++) {
            Address.sendValue(payable(_recipients[i]), _amounts[i]);
        }

        emit TokenDispersed(msg.sender, _recipients, _amounts, address(0));
    }

}

Code Analysis and Test Scenario

Before detailing the test functions I created, I want to mention the tools I used. These tools helped me verify different aspects of the contract and ensure that the scenarios I designed worked correctly.

During this test, I used the following Foundry functions:

assertEq(value1, value2): Verifies that value1and value2are equal. If not, the test fails.
assertGt(value1, value2): Verifies that value1is greater than value2. If not, the test fails.
vm.expectRevert(): Sets an expectation that an operation will revert (fail) during the test, allowing verification of the expected error.
vm.expectEmit(): Sets an expectation that a specific event will be emitted during the test, allowing verification that the correct event was emitted.
vm.deal(address, amount): Assigns a specific amount of ether to an address, useful for simulating balance conditions in tests.
console.log(message): Prints messages to the console during tests, useful for debugging and inspecting data.

With the environment configured and the context of the BaseSpraycontract and Foundry functions established, let's review how I conducted the unit test:

Creating the Test Contract

Contract version
I used the same contract version I was going to test, in this case 0.8.20.
Import
I imported the libraries:

import {Test, console} from “forge-std/Test.sol”; imports the Testlibrary for test functions and consolefor printing debugging messages to the console.

import {BaseSpray} from “../src/BaseSpray.sol”; imports the BaseSpray contract. I recommend importing only the contract to be tested to avoid having the EVM compile unnecessary code from other contracts in the same file.

Creating the Test Contract I created the contract and named it BaseSprayTest using is Test to inherit the test library.

contract BaseSprayTest is Test {} indicates that BaseSprayTest inherits from Test, providing access to Foundry's testing functions.

Declaration of variables and events I declared the necessary variables and events for the test.

Variables:

BaseSpray baseSpray; declares a variable named baseSpray of type BaseSpray, which will be used to create and manage an instance of the BaseSpray contract in the tests. This variable is initialized later to interact with the contract.

address owner = address(0x55555); creates a test address for the contract owner. In this case, 0x55555 is the address assigned for testing.

Event:

event TokenDispersed(

address indexed sender,

address[] recipients,

uint256[] values,

address token

); is emitted to log the token distribution, including the sender, recipients, distributed values, and token type. I created it in the test contract to verify that the contract emits this event correctly during tests.

Function setUp I created the setUpfunction, which runs before each test to initialize the contract.

function setUp() public {

baseSpray = new BaseSpray(owner);

} runs before each test to ensure a clean state. In this case, it deploys a new BaseSpray contract with the specified owner.

Test Functions

After understanding the contract's functionality, especially the disperseEther function, I started designing test scenarios by formulating key questions. I verified whether the contract's logic executed correctly, such as whether the owner was properly assigned (even though the onlyOwner modifier is not used in this contract, it is good practice to confirm the assignment), whether the require statements validated conditions correctly, and whether the function's logic worked as expected, among other issues.

First function test_initialOwner:

With this function, I verified that the owner is assigned correctly:

By using assertEq(baseSpray.owner(), owner, "Owner does not match"); I am stating that the owner of the baseSpray contract must be equal to owner, and if it is not, it will throw the message "Owner does not match".

Second function test_disperseEtherWorks:

With this function, I verify that the disperseEther function works correctly when there is enough balance in the contract and the parameters are valid:

With vm.deal(address(this), 3 ether); I am giving 3 ether to the contract.
With baseSpray.disperseEther{value: 3 ether}(recipients, amounts); I am calling the disperseEther function of the baseSpray contract and telling it to send 3 ether to the addresses in recipients and using amounts to specify how much ether to send to each address in recipients.
With assertEq(recipients[0].balance, 1 ether, "Should have 1 ether"); I am verifying that after calling the disperseEther function, the correct amount is given to the first address I created. If this is not correct, it will throw the message "Should have 1 ether".
With assertEq(recipients[1].balance, 2 ether, "Should have 2 ether"); I am verifying that the second address I created receives the 2 ether after calling the disperseEther function. If this is not correct, it will throw the message "Should have 2 ether".
With assertEq(address(baseSpray).balance, 0, "Contract should have 0 ether"); I am verifying that after the contract makes the transfers, it should not have any ether left.

Third function functiontest_requireUnequalLengthsRecipientsAmounts:

With this function, I verify that the disperseEther function reverts (fails) when the contract does not have enough balance to make the transfers.

With vm.expectRevert("Insufficient balance"); I expect the function to revert (fail) due to insufficient balance with the message "Insufficient balance".
With baseSpray.disperseEther(recipients, amounts); I am calling the disperseEther function of the baseSpray contract.
With assertEq(address(baseSpray).balance, 0, "Contract should have 0 ether"); I am verifying that the contract does not have any ether.

Fourth function test_requireRecipientsLengthGreaterThanZero:

With this function, I verify that the disperseEther function reverts (fails) when the _recipients array is empty:

With vm.expectRevert(); I expect the function to revert (fail) without specifying the error message.
With baseSpray.disperseEther(new address , amounts); I am calling the disperseEther function of the baseSpray contract but passing an empty recipients array.
With assertEq(address(baseSpray).balance, 0, "Contract should have 0 ether"); I am verifying that the contract does not have any ether.

Fifth function test_requireRecipientsLengthEqualToZero():

With this function, I verify that the disperseEther function emits the TokenDispersed event when called correctly:

With vm.expectEmit(true, true, true, true); I expect the event to be emitted. The four true`` parameters indicate that all indexed fields and non-indexed fields should be verified.
With emit TokenDispersed(address(this), recipients, amounts, address(0)); I emit the event with the parameters I created.
With baseSpray.disperseEther{value: 3 ether}(recipients, amounts); I call the disperseEther function with the previously specified recipients and amounts.

Sixth function test_forLoopTotalValue:

In this function, I test the for loop that accumulates the sum of all values in _amounts to determine the total to be distributed.

What I did here was create a variable of type uint256, called it totalValue, and assigned it the amount of the first address and the second address. Then, with assertEq, I verified that the contract's balance was indeed equal to the totalValue.

Seventh function test_revertWhenBalanceLessThanTotalValue:

Verifies that recipients has a length of zero and expects a revert.

Here, I gave the amounts a total of 3 ether and gave the contract 2 ether. Then I used vm.expectRevert, called the function disperseEther, and tried to send 3 ether to the recipients addresses.

Eighth function test_contractBalanceAfterTransaction:

Verifies that the contract balance is zero after executing the transaction.

Here, I performed the transaction normally, assigning ether to the contract equal to the amount in amounts. After calling the disperseEther function, I verified that the contract balance was zero with assertEq.

Ninth function test_TokenDispersedEvent:

Verifies that the TokenDispersed event is emitted correctly.

I executed the disperseEther function normally, assigning the parameters correctly. Before calling the function, I used vm.expectEmit and added a console.log with the message "Expected emit set". Then I called the function, and added another console.log after calling the disperseEther function with the message "disperseEther called". Here, I was mostly testing how the console.log function works.

Running the Tests

To run the tests, simply execute the command:
forge test

Test Result

After running the tests, it is confirmed that the BaseSpray contract functions correctly in the specified scenarios and appropriately handles error cases. This experience has allowed me to deepen my understanding of unit testing and ensure the robustness of smart contracts.

Conclusion

Conducting this unit test allowed me to verify some scenarios of the ModeSpray smart contract. Although it is a basic test, I am satisfied with taking another step forward in my development as a Security Researcher. My next steps will include attempting to attack the contract with the most common attack vectors and performing fuzz testing.

I would like to thank RareSkills for helping me strengthen my knowledge in Foundry, which enabled me to perform this test on ModeSpray.

Thank you for reading this article. If you enjoyed it and wish to follow my progress as a Security Researcher in web3, as well as stay updated on my upcoming articles, you can follow me on Twitter, now known as X.

ModeSpray Twitter: https://x.com/ModeSpray

RareSkills Twitter: https://x.com/RareSkills_io

RareSkills Article: http://rareskills.io/post/foundry-testing-solidity

Wispy Twitter: https://x.com/wispyiwnl

Mode - Blockchain Developer Apprenticeship

wispy — Mon, 09 Sep 2024 14:11:18 +0000

On June 17th, Mode, in collaboration with Bcamp, launched a blockchain-focused bootcamp. This bootcamp lasts for 7 weeks, with a class every Monday. During these sessions, topics such as Solidity in production, an overview of Mode, Web3 security, and global job searching will be covered. The bootcamp is designed for participants to develop a project of their choice. In the first week, the various available projects will be presented, and participants will select one to work on based on their interests (all projects are blockchain-focused and must be developed on Mode).

In this article, we will review each week of the bootcamp, how it was experienced, what topics were covered, the project development process, and more.

June 17th - Week 1: Welcome to BCamp!

In this session, BCamp will be introduced. The projects to be undertaken during the bootcamp will be reviewed, and there will be an opportunity to meet the project mentors and other participants.

Week 1 Objective: Code Review and Project Selection

Submit a code review of IceWater.
Rate the teams based on your interest in joining them.

Agenda:

Welcome to BCamp.
Guest Speaker - Fede Sarquis (Mode Developer Relations).
Project Overview.
General Overview of Cohort Logistics:
- Weekly Challenges and Presentations.
- Final Evaluation Panel.
- Weekly MVP Nominations.
- First Week Challenge.

In the first week, BCamp was introduced.

During the welcome session, it was discussed how BCamp is an educational organization dedicated to empowering ambitious individuals by providing valuable software development experience. Their ultimate goal is to help participants successfully enter the tech industry.

The program lasts 7 weeks, from June 17th to August 2nd, 2024. BCamp is described as a hybrid between an internship and a hackathon, which they call "apprenticeship." Each Monday, a live session takes place from 11:30 AM to 1:00 PM PST. The program includes a competition with 3 teams in the finals, weekly MVP awards, and cohort MVP prizes.
There was also a special guest.

Guest Speaker - Fede Sarquis (Mode Developer Relations)

CryptoFede spoke about his transition from the corporate world to the crypto space, emphasizing the importance of continuous learning in the rapidly growing field of Web 3.0 development. He praised the open-minded culture, internationality, and collaboration in the crypto space, and highlighted the challenges of mastering the Solidity programming language. He stressed the importance of building networks and relationships in the Web 3 space and shared his goal at Mode of empowering developers and helping them create successful applications within the ecosystem. He suggested that the Bcamp initiative could serve as a better alternative to hackathons, as it offers a longer period for participants to build a portfolio and network.

After Fede's talk, the bootcamp projects were shared.

Project Overview:

202Ware Project: The 202Ware project aims to develop a platform on the MODE network that allows artists to upload and mint their works as NFTs. Through LivingChain Showcase, artists can receive community votes to be featured in a magazine and earn tokens as rewards. These tokens can be used to access events and other rewards. This initiative creates a transparent and secure environment for artists to showcase their work, engage with the community, and enrich the magazine’s content.

Plinko & Similar Casino Games Project: The Plinko & Similar Casino Games project aims to develop a Plinko casino game on the Mode network to enhance transparency and trust in online gambling. The solution proposes running the game logic on the blockchain and using random number generation oracles like Chainlink VRF to ensure fair outcomes. Smart contracts make the game rules public and protect users' data and funds. Additionally, the Mode network allows global access without geographical restrictions, enabling players from around the world to participate and setting a new standard of fairness in blockchain-based gambling games.

Ticketchain Project: Ticketchain aims to create a decentralized ticketing platform on the Mode network to address common issues in ticketing systems, such as high fees, ticket resale, and counterfeiting. The solution provides organizers with the ability to create and manage events, sell and verify tickets, while buyers can securely purchase, transfer, and resell tickets with reduced fees. The platform uses blockchain technology to ensure the transparency and authenticity of tickets. Ticketchain enhances trust in the ticket buying and selling process and optimizes event management.

Mode Score Project: The Mode Score project aims to develop a dApp that evaluates users' capital efficiency across various web3 ecosystems through an "Idle Score." The application will calculate a capital efficiency score, ranging from 0 to 100, by connecting the user's wallet or entering their address, and then recommend investment opportunities within the Mode ecosystem or others, based on the idle capital detected. This tool enhances portfolio management by helping users identify and seize investment opportunities, increasing capital efficiency, and promoting the use of Total Value Locked (TVL) in blockchain.

BitLance Project: BitLance is a decentralized platform designed to connect advertisers and freelancers without the high fees of traditional platforms like Upwork and Fiverr. Using smart contracts on the Ethereum blockchain (Mode network), BitLance ensures job completion and freelancer payment, charging a small commission of 1-2% in addition to gas fees, and allowing payments in cryptocurrencies. This approach reduces the costs associated with conventional freelancing platforms and offers a rating system to assess user reliability, providing a more cost-effective and transparent alternative.

Generative Art for Liquidity Position NFTs: Generative Art for Liquidity Position NFTs aims to improve long-term liquidity retention in blockchain protocols by incorporating generative art into NFTs. Instead of relying solely on profits, the emotional value of these NFTs is used to incentivize liquidity providers to maintain their positions, thereby increasing the "stickiness" of liquidity in the protocols. Maintaining solid liquidity is crucial for the success of a protocol, as deep liquidity reduces investor mistrust and increases transaction volume, benefiting the protocol with higher revenue.

Peer-to-Peer Coin Flip Game: The Peer-to-Peer Coin Flip Game aims to provide a fair and transparent alternative to centralized betting through a coin flip game based on smart contracts. Users create and join challenges with specific bets, and a random number generator verifies the outcome. The smart contract ensures trustless execution and immediate payouts. This solution removes intermediaries, offering fair odds and transparent results, reducing the risk of fraud and increasing user trust in the betting system.

Memecoin Audit Bot : The Memecoin Audit Bot aims to identify and prevent fraud in the memecoin market through a static analysis tool. This bot monitors new ERC-20 smart contracts, reviews verified source code, and generates reports on potential security issues. Its significance lies in enhancing security and transparency in the memecoin market, protecting investors, and promoting responsible investment practices.

Collateral-Free Small Loans: Collateral-Free Small Loans addresses the challenge of offering loans without collateral, tackling issues like risk assessment, default management, and liquidity. The solution is a platform that enables trust-based and relationship-driven loans, with robust risk evaluation and native stablecoins to maintain liquidity. It will integrate with other DeFi protocols and feature a user-friendly interface. This approach facilitates access to decentralized financial services and promotes the adoption of Web3 and DeFi by eliminating the need for collateral.

Blockchain Shipping and Receiving Application: The Blockchain Shipping and Receiving Application aims to integrate shipping documentation and logs to improve the tracking of materials during transportation. The solution involves developing an application that uses smart contracts to record loading and unloading, handle payments, and manage rest stops, all on the blockchain. This approach enhances the accuracy of shipment tracking by providing an immutable and real-time accessible record, reducing errors and delays.

They also discussed the logistics that will be followed during the bootcamp.

They explained the topics that would be covered each week and how the Final Judging Panel and weekly MVP nominations would work.

Weekly Topics:

June 17th - Session 1: Welcome to BCamp!
June 24th - Session 2: Meet Your Team
July 1st - Session 3: Project Proposals and Guest Speaker on Solidity in Production
July 8th - Session 4: Project Presentations and Overview of Mode
July 15th - Session 5: Team Presentations and Guest Speaker on Web3 Security
July 22nd - Session 6: Pitch for the Finals and Global Job Search
July 29th - Session 7: Final Project Presentations
August 2nd - Expert Judging Panel

Final Judging Panel: The Final Judging Panel will operate as follows: Industry experts will be invited to join the panel to evaluate and provide feedback on the projects that reach the final stage.

Weekly MVP Nominations: There will be weekly polls to choose the MVP, who will be given one minute during the session to be thanked and share more about their experience.

First Week Challenge: This week’s challenge involves providing a code review for the IceWater contract, which is a stablecoin with three intentional bugs of varying levels. The code review should be submitted in PDF format. Finding the bugs is not a requirement; the primary goal is for participants to start interacting with blockchain and smart contracts. After submitting the code review, participants can choose which project they want to work on.

June 24th - Week 2: Meet Your Team

In this session, the teams will be announced, and you will get to meet your team in a breakout room.

Objective of Week 2: Project Planning.

It’s time to start development!

Get to know your team, establish task division, and create a meeting schedule that works for everyone.
Finalize an initial plan for your project with some form of architecture (such as a diagram or README.md).
Prepare a 3-minute presentation to introduce your project, including the plans and architecture you have developed.

Agenda:

Announcement of team assignments.
Meet Your Team!

This week, the submissions for the Week 1 code review challenge were discussed. Several people identified the first bug, and 2 or 3 found the second bug, but no one detected the third bug. These bugs were intentionally added to encourage participants to interact with Solidity code.

It was explained that, in the following weeks, each team will need to give a 3-minute progress update presentation until Week 5. In Weeks 6 and 7, presentations will be 7 minutes long. Examples of presentations were shown and shared, and it was recommended that each team start organizing, as project development will commence this week.

This week, each team got to know each other and began project development.

July 1st - Week 3: Project Proposals and Guest Speaker on Solidity in Production.

In this session, each team will have the opportunity to present their projects for 3 minutes. Additionally, we will welcome a guest speaker, Justin Bebis, CEO of Conclave!

Objective of Week 3: Project Fundamentals

Write pseudocode and set up the project file structure; once ready, begin developing the alpha version.
Prepare a 3-minute presentation for next week's session covering the progress made this week.

Agenda:

Guest Speaker: Justin Bebis
Project Proposals Presentations
Alien Awards
Tasks for This Week

Week 3 began with guests Eidolon and Goober from Conclave, who shared their experience in writing production code in Solidity. They focused on smart contract architecture and front-end and back-end applications, highlighting the importance of security, minimalist design, and thorough testing. They recommended tools such as Foundry and Slither and discussed the challenges of invariant testing. Eidolon and Goober explained that auditors identify potential flaws but do not guarantee error-free code, emphasizing the need to combine audits with independent reviews. They also discussed EVM compatibility, Solidity versioning, and the importance of being prepared for emergencies and vulnerabilities. They shared their experiences entering the crypto world and stressed the relevance of continuous learning and collaboration.

During this week, each team had their 3-minute presentation to discuss the project they are working on.

July 8th - Week 4: Project Presentations and Overview of Mode

In this session, each team will have the opportunity to present their projects for 3 minutes.

Additionally, a representative from Mode will join us to review their product and codebase.

Objective of Week 4: Development 1

Start or continue developing your project with the goal of compiling and running something this week.
Prepare a 3-minute presentation for next week’s session that showcases this week’s progress.

Agenda:

Highlight of the Learner
Project Presentations
Negotiation Exercise

Overview of Mode

Fede explained that Mode is a Layer 2 solution based on Optimism technology, designed to improve efficiency and reduce transaction costs on Ethereum. He highlighted the vision of the Superchain, which aims to interconnect multiple chains to facilitate fund transfers and application integration, creating a more efficient and cost-effective ecosystem. He also emphasized the importance of contributing to the OP Stack project, which is essential for the development and enhancement of these technologies.

During this week, each team had their 3-minute presentation to showcase the progress they’ve made on their projects.

July 15 - Week 5: Team Presentations and Guest Speaker on Web3 Security

In this session, each team will have the opportunity to present their projects for 3 minutes. Additionally, we will welcome a guest speaker from SphereX.

Objective for Week 5: Development 2

Finalize an alpha version of your application/dApp.
Prepare a 3-minute presentation for next week's session. This will be your team's final presentation before the judges to determine if you will advance to the finals.

Agenda:

Learner Spotlight
Project Presentations

Ariel from Spyx addressed security challenges in Web3, highlighting code visibility, the risk of direct financial theft, the decentralized nature, and the anonymity of actors. He emphasized the importance of secure key management and mitigating reentrancy attacks, explaining how a malicious actor can exploit vulnerabilities in smart contracts. He also discussed blockchain protocol design and the protection of private keys using tools such as Multi-Party Computation, multi-sig contracts, and hardware wallets. He recommended using development and auditing tools to write secure code and perform thorough reviews.

During this week, each team had their 3-minute presentation to show the progress of their projects.

July 22nd - Week 6: Finals Pitch and Global Job Search

This week, Samuel Miranda discussed strategies for standing out in the competitive job market. An informational interview exercise was also conducted.

Additionally, each project will have 3 minutes to present their projects and make their final pitch to reach the finals.

Objective of Week 6: Testing

Test your application/dApp and make final adjustments.
Prepare a 7-minute presentation about your project for the final session, highlighting the progress made.

In Week 6, strategies for improving LinkedIn profiles and finding employment in a competitive market were covered. Emphasis was placed on personalizing profiles, including relevant skills in the headline, crafting a personal narrative in the "About" section, and adding recommendations to boost credibility and SEO optimization. Sharing posts on relevant topics and work experiences was also recommended. An informational interview exercise was conducted, and the importance of networking and creating LinkedIn groups to facilitate connections was discussed.

During this week, each team had their 7-minute presentation to showcase the progress of their projects.

July 29th - Week 7: Session 7: Final Project Presentations

Development Completed

The last weekly session! Each team will have the opportunity to deliver a final 7-minute presentation.

Additionally, the teams advancing to the finals will be announced.

Teams that make it to the finals must prepare a 7-minute presentation for Friday, August 2nd, when the final judging panel will determine the winners of this cohort.

CryptoFede shared his insights on the Web3 industry, emphasizing the importance of active participation and feedback. He discussed the challenges of finding work in the sector, advising not to be discouraged by unrealistic job descriptions and to engage in extensive networking. He also mentioned the SuperHack hackathon and the Optimism awards as great opportunities to showcase our projects, earn money, and increase our visibility in the Web3 world.

In the final session of the bootcamp, teams delivered their final presentations. The top three finalist teams will now be selected and must prepare a 7-minute presentation for Friday, August 2nd. On that day, the winner of the bootcamp will be chosen.

The 3 projects that made it to the finals are:

Liquidity NFTs
Mode Score
BitLance

Liquidity NFTs:

The Liquidity NFTs team presented their final project on a landing page. The presentation included the following features and functionalities:

Generative Art for Liquidity Positions:
- Purpose: To create generative art for liquidity positions in the form of NFTs. The goal is to enhance the "stickiness" of liquidity by providing emotional value in addition to financial value.
Smart Contract Development:
- Compatibility and Optimization: The team faced compatibility issues between Solidity versions (0.6.5 for DEX contracts and 0.8.0 for ERC 404) and had to limit the contract size. They addressed these issues by creating a separate contract for token management and implementing multiple optimizations.

Key Components:

LP 404 Factory: Modification of the ERC 404 contract to incorporate on-chain metadata logic, allowing the minting of ERC 20 LP tokens alongside ERC 721 (NFTs) tokens that represent ownership in the liquidity pool.
NFT Visualization:
- NFT Viewer: Users can request information about their NFTs using the contract address and token ID. Attributes are stored on IPFS and rendered via a canvas.
User Interface and Live Demo:
- Front-End Interface: The interface allows users to create and manage ERC 20 token pairs, view balances, deposit and withdraw tokens, and view generated NFTs.
- Live Demo: The demonstration showed the process of creating a token pair, retrieving contract information, depositing tokens, and minting NFTs.

Conclusion

The Liquidity NFTs team delivered an innovative solution that combines emotional and financial incentives to maintain liquidity on DEX platforms. With a robust smart contract structure and an intuitive interface, the project is well-positioned to integrate with major DEXs like Uniswap and expand to other protocols that require liquidity.

Mode Score

The ModeScore team, during their 10-minute presentation, showcased the final project on a landing page hosted on Vercel. The presentation included the following features and functionalities:

Landing Page:
- Navigation: The homepage features a navigation menu that redirects to sections like features, team information, and contact.
- Contact Form: Users can send messages through a form, with emails being forwarded to the team's inbox.
Wallet Connection:
- Wallet Connection API: The application allows users to connect their wallet using Metamask and other connection options. This functionality is managed through an API that supports over 420 types of wallets, providing flexibility and accessibility for users.
User Dashboard:
- Data Visualization: Once the wallet is connected, users can view their financial score, details of their assets, and recent transactions. The dashboard displays the ModeScore, congratulating the user on their first step toward financial efficiency.
- Interactive Interface: The dashboard includes a sidebar navigation that allows users to view specific details of their assets and transactions. Users can also switch between different cryptocurrencies, such as ETH and MODE.
Score Calculation Algorithm:
- Integration with Covalent API: The backend uses the Covalent API to retrieve detailed data from the user's wallet.
- Complex Algorithm: An algorithm that calculates the financial score based on multiple factors, including wallet activity, transaction history, balance, and more.
Score Presentation:
- Score Range: Users receive a score ranging from 300 to 900, with personalized messages explaining their financial situation.
- Credibility Details: Detailed visualization of the evaluated parameters, including credibility and transaction traffic.
Deployment and Accessibility:
- Back-End: Deployed on Render, handling requests and data processing.
- Front-End: Deployed on Vercel, providing a user-friendly and accessible interface.

Conclusion

The ModeScore team delivered a comprehensive and well-designed application that enables users to assess and optimize their digital assets. With an intuitive interface and a sophisticated algorithm, ModeScore positions itself as an essential tool for efficient investment management in the Mode ecosystem.

BitLance

The Bitlance team presented their final project, a decentralized freelance platform. The presentation included the following features and functionalities:

Bitlance: Decentralized Freelance Platform
- Problems in Web 2: Freelance platforms in Web 2 face issues such as fees up to 20%, payments taking up to two weeks, and lack of transparency.
- Bitlance Solution: Lower fees, instant payments through smart contracts, and transparent data.
Project Structure:
- Front-End and Back-End: Users interact with the web interface and can connect their wallet via Metamask or Rainbow Wallet. The back-end only stores the user's email and name.
- Mode Network: Communication with the Mode network to manage data and transactions.
System Features:
- Login and User Profile: Users can log in and view their profile, both as clients and freelancers.
- Job Creation and Application: Clients can create job listings, and freelancers can apply to them.
- Job and Payment Management: Clients can select freelancers for their jobs, and payments are managed through a smart contract acting as an escrow account.
Work and Payment Process:
- Client: The client creates a job and specifies the payment in LINK tokens.
- Freelancer: The freelancer applies for the job and waits for client approval.
- Approval and Completion: Once approved, the freelancer completes the job, and the client releases the payment from the escrow account upon job completion.
Live Demo:
- Demo Interaction: The demo showcased the complete flow from job creation, freelancer application, client selection of the freelancer, job completion, and final payment to the freelancer.
- Transactions on the Network: LINK tokens on the Mode network were used to demonstrate the movement of funds between the client's and freelancer's accounts.

Conclusion: The Bitlance team delivered a solution that addresses issues faced by Web 2 freelance platforms through a decentralized platform with lower fees, instant payments, and increased transparency. The project is well-positioned to enhance the freelance experience for both freelancers and clients within the blockchain ecosystem.

Each team must prepare a 10-minute presentation for Friday, August 2, the day when the winning project of the bootcamp will be chosen.

August 2nd - Week 8: Expert Evaluation Panel

Industry experts will form an evaluation panel to assess and provide feedback on the projects that reach the final. Additionally, the MVPs of the cohort will be announced, and awards will be distributed.

In the final evaluation session of the incubation program, it was announced that third place went to the ModeScore project and second place to the Bitlance team. The winning project was Liquidity for NFT Positions, excelling in the categories of innovation and product vision. The judges praised the quality of the projects and the enthusiasm of the participants, highlighting that many demonstrated a high level of commitment and collaboration.

During the final discussion, there was enthusiasm for the projects and participation in the program, with a focus on ongoing connection and support among community members. Future sponsorships and opportunities for participating teams were mentioned, especially in areas such as game development and blockchain-based solutions.

The intent to use the program as a platform to promote and connect emerging talent with real market opportunities was discussed, emphasizing the potential for collaboration with various platforms and projects.

The event concluded with thanks and a call to maintain connections through LinkedIn and other networks, encouraging participants to stay in touch and explore new opportunities.

A Successful Journey

The recent bootcamp, which brought together 47 participants, has been an incredibly enriching experience for everyone involved. Throughout the program, each team had the opportunity to develop and present projects addressing a wide range of challenges and innovations in the blockchain space.

This event not only helped boost individual talent but also laid the groundwork for future developments in the blockchain ecosystem, particularly within the Mode Network. The diversity of projects and the creativity demonstrated by the teams highlight the potential for creating solutions that enhance the efficiency, security, and scalability of decentralized applications. These advancements could influence new technological proposals, attracting more developers and users to the network, thus strengthening its adoption.

We would like to express our sincere gratitude to Mode and Bcamp for making this event possible. Their support was crucial to the success of the bootcamp. A special thanks to Fede, whose commitment was outstanding throughout the entire process.

As the projects continue to evolve, it's likely that collaborations and ideas will emerge, driving new applications within the Mode ecosystem. This initiative not only fosters short-term innovation but could also serve as a catalyst for larger-scale projects, contributing to the growth and development of the blockchain sector as a whole. The impact of this bootcamp could, in the long term, influence the strategic direction of Mode Network, setting a precedent for future training and development programs.

We look forward to seeing how these projects will continue to evolve and significantly contribute to the Mode Network ecosystem and beyond, driving new solutions for the blockchain industry.

DEV Community: wispy

Convergence Finance Exploit Report

Exploit Simulation in a Forked Environment

The Affected Contract

Root Vulnerability

Step-by-Step Attack Flow

Economic Impact

Protocol and Community Response

Conclusion

Proof of Stake vs. Proof of Work: A Security Analysis in Blockchain

PoS vs. PoW: Key Differences and Limitations

Strengths and Weaknesses of PoS in Terms of Security

Defense Against Common Attacks

Security Comparison: PoS vs. PoW

Conclusion

References

Take Your Vibe Trading to the Next Level: New AI Scanning Feature in Mode Terminal

What is Mode's AI Terminal?

Practical Use Cases

Security and Precautions

New Feature: AI-Powered Position Scanner

New Feature: Analyze Your Positions with Just an Image

How Does It Work?

Use Cases

Conclusion

Quick Guide: Create Your Account ID on Orderly

Introduction

What is Orderly?

What is the Account ID used for?

How to Create an Account ID

Conclusion

INTEGRATION OF DAPPS WITH MODE: WALLET AND SMART CONTRACTS | PART 2: CONNECTING SMART CONTRACTS TO THE FRONT-END

Part 1 Recap:

Objectives of Part 2:

Recommendations

Smart Contract Development

Explanation of the Smart Contract

Compilation and Deployment of the Smart Contract

Obtaining the ABI:

Project Setup

Recap

Interacting with the Contract

Reading from the Smart Contract

Using useEffect to Update the Message

Recap

useWriteContract

Implementing useWriteContract

Creating a Form to Capture Data

Function changeMessage

Executing writeContract

Conclusion

Next Steps

Support and Resources

Additional Resources:

INTEGRATION OF DAPPS WITH MODE: WALLET AND SMART CONTRACTS | PART 1: CONNECTING THE WALLET

Installing Next.js

Cloud Configuration

Project ID and reown (formerly known as WalletConnect) Setup

Installing reown

reown implementation

Wagmi Config

Context Provider

Layout

Trigger the Modal

Exploring OP Stack and Superchain: The Future of Ethereum Layer 2

What is the OP Stack?

Structure and Components of the OP Stack

Key Advantages of the OP Stack

A Modular and Scalable Future

Superchain

The Vision of Scalability

Foundational Superchain concepts

Horizontal scalability requires multiple chains…

…but traditional multi-chain architectures are insufficient

Not multi-chain, not mono-chain… Superchain

Summary of the Superchain

Conclusion

Exploring SuperSim: Simulating Interoperability on the Superchain with OP Stack

What is SuperSim?

How was the Developer Experience?

Implementing `useWriteContract`

Function `changeMessage`

Executing `writeContract`