Celo is a mobile-first, carbon-neutral blockchain that offers decentralized finance tools and services intended to be accessible to anyone with a mobile phone.

In addition to the blockchain client, some core components of the Celo protocol are implemented at the smart contract level and even off-chain (e.g. phone number verification via SMS).

Celo's mission is to build a financial system that creates the conditions for prosperity—for everyone.

By using a pBFT-based PoS consensus protocol, Celo can process and achieve consensus on blocks extremely quickly, which can contribute to high TPS numbers while still maintaining a robust and decentralized 

In addition to high throughput, pBFT also gives you 1 block finality, so you never have to worry about your users having their transactions rolled back or re-orged. This means that transactions are finalized in 5 seconds, and this latency can be easily reduced as the network grows.

Celo is a fork of the Go-Ethereum codebase which means that it is fully EVM compatible up to the latest hard fork. This means that your signature schemes, pre-compiles, and any truffle tools you’re used to work perfectly out of the box.

With the growth of DeFi, many dapps need access to stablecoins, which means that any serious alternative to Ethereum must have a stablecoin on the platform.

The Celo stablecoin platform is an integral part of the Celo network with Celo Dollars (cUSD), Celo Euro (cEUR) and Celo Brazilian Real (cREAL) already live.

Celo supports paying for transaction fees using ERC-20-like tokens, with cUSD being the first of these tokens. This means that your dapp users can send cUSD with ease, even if they don’t have the CELO asset in their wallets. Additionally, if your dapp has a token, you can create an on-chain governance proposal to whitelist it so that it, too can be used to pay for gas.

The production Celo network, Mainnet was previously known as the Release Candidate 1 network. Deployed by the Celo community starting 4/22/20, the network is currently working towards enabling the Celo stability mechansim. Much of the activity is being driven by the validator organisations that featured on the leaderboard of 

If you're a developer considering building on the Celo platform, or want to try out the Celo Wallet, start with 

 immediately and use it for experimenting with. 

 assume you are using Alfajores. The network is managed by cLabs, who operate all of its validators, and its software and deployed contracts will track mainnet.

If you're interested in operating one or more nodes that make up Celo's infrastructure, start with 

. Baklava's validators and full nodes are operated by the community. It is intended to provide a venue to test new builds of the Celo Blockchain software, trial on-chain governance proposals, and for node operators to build operational best practices. Support for developers and users of the Wallet is not the primary focus.

The Baklava Testnet is a non-production Testnet for the Validator community.

: Build familiarity with the processes used on Mainnet, and to verify the security and stability of your infrastructure with the new software.

: Discover bugs in new software releases before they reach Mainnet.

: Experiment with new infrastructure configurations in a low-risk environment.

For Earth Day 2023, the Celo Community has proposed a new 

, which strives to position Celo to become deflationary as well as further Celo's sustainability commitment . With each transaction, 

 proposes that 80% of the base fee would be burned and 20% would be sent to a Carbon Offset address to purchase high-quality carbon offsets. This testnet is intended to support this new ‘Ultragreen’ mechanism before this change is later proposed for a future hardfork.

Introduction

Celo is oriented around providing the simplest possible experience for end-users, who may have no familiarity with cryptocurrencies and may be using low-cost devices with limited connectivity.

To achieve this, Celo takes a full-stack approach, where each layer of the stack is designed with the end-user in mind while considering other stakeholders (e.g. operators of nodes in the network) involved in enabling the end-user experience.

An open cryptographic protocol that allows applications to make transactions with and run smart contracts in a secure and decentralized fashion. The Celo blockchain code has shared ancestry with

 and maintains full EVM compatibility for smart contracts. However, it uses a

 (BFT) consensus mechanism (Proof-of-Stake) rather than Proof-of-Work and has different block format, transaction format, client synchronization protocols, and gas payment and pricing mechanisms.

A set of smart contracts running on the Celo blockchain that comprise much of the logic of the platform features including ERC-20 stable currencies, identity attestations, proof-of-stake, and governance. These smart contracts are upgradeable and managed by the decentralized governance process.

Applications for end users built on the Celo Platform. The Celo Wallet app, the first of an ecosystem of applications, allows end-users to manage accounts and make payments securely and simply by taking advantage of the innovations in the Celo Protocol.

Applications take the form of external mobile or backend software: they interact with the Celo blockchain to issue transactions and invoke code that forms the Celo Core Contracts’ API. Third parties can also deploy custom smart contracts that their own applications can invoke, which in turn can leverage Celo Core Contracts. Applications may use centralized cloud services to provide some of their functionality: in the case of the Celo Wallet, push notifications, and a transaction activity feed.

The Celo blockchain and Celo Core Contracts together comprise the Celo Protocol.

Celo Stack

Celo Composer allows you to quickly build, deploy, and iterate on decentralized applications using Celo. It provides a number of frameworks, examples, and Celo-specific functionality to help you get started with your next dApp.

The Greeting dApp will be a React dApp connected to a smart contract that users can use to greet other wallets on the Celo blockchain.

The easiest way to start with Celo Composer is by using @celo/celo-composer. This CLI tool lets you quickly build dApps on Celo for multiple frameworks, including React (with either react-celo or rainbowkit-celo), React Native (w/o Expo), Flutter, and Angular. To get started, just run the following command and follow the steps:

2. Select "React" as the front-end template.

3. Select "Hardhat" as the smart contract framework.

4. Select "No" for subgraph, we don't need subgraph for this dApp but in case you need it is available.

6. Run the "yarn" command in the project directory, to install all dependencies.

After Walletconnect v2 launched, every dApp requires WalletConnect Project ID to use it so let's get one!

7. Sign up for Walletconnect and create a project using the button on top right corner.

9. Create a ".env" file in packages/react-app and paste the projectID

10. You should now be able to run the dApp using the following command and see the below output.

Initialization

Create "Greeter.sol" in "packages/hardhat/contracts" and add the following code.

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

contract Greeter {

    constructor() {}

}

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

contract Greeter {
    mapping(address => string) public greetings;

    constructor() {}
}

3. Add "NewGreeting" event which will be monitored by the frontend to get the previous greetings on load.

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

contract Greeter {
    mapping(address => string) public greetings;

    event NewGreeting(string greeting, address sender);

    constructor() {}
}

4. Finally, the "greet" function that takes in the address that the user wants to greet ("to") and the "greeting" itself.

This is how the final code would look like

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

contract Greeter {
    mapping(address => string) public greetings;

    event NewGreeting(string greeting, address sender);

    constructor() {}

    function greet(address to, string memory _greeting) external {
        greetings[to] = _greeting;
        emit NewGreeting(_greeting, msg.sender);
    }
}


1. We can compile and deploy this contract on-chain, before that, we will need a private key of an account that will deploy the contracts

2. Create a duplicate file like ".envexample" in packages/hardhat directory, rename it too ".env" (mandatory) and use the private key you got from Metamask as the value for the PRIVATE_KEY variable. You can remove the MNEMONIC variable if you are using the private key.

3. Celo Composer already has the configuration to deploy to Celo mainnet and testnet network, if you are wallet does not have any testnet funds then you can get them from 

4. We need to create a deploy script to deploy the Greeter contract, since the Greeter project is a really popular starting point for new devs we have a deploy script already create in the packages/hardhat/scripts folder called "sample-script.js".

5. Let's understand the "main" deploy function

async function main() {
  const Greeter = await hre.ethers.getContractFactory("Greeter"); // We get the contract to deploy
  const greeter = await Greeter.deploy(); // Passing constructor arguments

  await greeter.deployed(); // Send Deploy Transaction and wait

  console.log("Greeter deployed to:", greeter.address); // Print out the deployed contract address
}

6. Change directory in your terminal to packages/hardhat and we can run the deploy scripts using the following command:

npx hardhat run scripts/sample-script.js --network alfajores

7. On successful deployment, you should get the following output:

8. You can view the contract on the testnet 

1. You can see it is not verified, so let's verify it. For verification, you will need a CeloScan API key you can get it from 

2. Paste this api key in already created "packages/hardhat/.env"

3. Now you can use the following command to verify the contract:

npx hardhat verify <CONTRACT_ADDRESS> --network alfajores

4. On successful verification, you should see the following output.

Smart Contracts

For the frontend dApp, we need to add the functionality of letting user connect their wallet. Since you are using Celo Composer, this is already done!

You can run the following command in the terminal you serve your dApp on localhost:

You should be able to see the following output:

Based on whether the user has connected the wallet or not we might want to hide the UI. We can achieve this using wagmi's useAccount hook!

export default function Home() {
    const { isConnected } = useAccount();

    if (!isConnected) return null;

    return (
        <div>
            <div className="h1">
                There you go... a canvas for your next Celo project!
            </div>
        </div>
    );
}

After the user connects their wallet, the first thing the dApp needs to do is to start watching for new "NewGreeting" events emitted by the smart contracts in the current session of the user.

You will need GreeterABI, create a file named "GreeterABI.js" in packages/react-app/abis.

Copy Greeter ABI from packages/hardhat/artifacts/contracts/Greeter.sol/Greeter.json.

Paste the ABI into GreeterABI.js as follows:

export default function Home() {
    const { isConnected } = useAccount();
    const [greetings, setGreetings] = useState([]);


    const unwatch = useContractEvent({
        address: "0x77619E547bCBc4693ac6f7309a2f099f0aa4fc21",
        abi: GreeterABI,
        eventName: "NewGreeting",
        listener(logs) {
            let newGreeting = logs.map((log) => log.args);
            setGreetings([...greetings, ...newGreeting]);
        },
    });

    useEffect(() => {
        return () => {
            if (unwatch) {
                unwatch();
            }
        };
    }, []);

    if (!isConnected && isClient) return null;

    return (
        <div>
            <div>
                <table className="table mt-7 w-full">
                    <caption className="mb-2 text-lg font-bold">
                        Greetings
                    </caption>
                    <tbody className="h-96 overflow-y-auto">
                        {greetings.map(({ greeting, sender }, index) => {
                            return (
                                <tr
                                    key={index}
                                    className="flex items-center space-x-2 w-full"
                                >
                                    <td className="p-2">{sender}</td>
                                    <td className="p-2">{greeting}</td>
                                </tr>
                            );
                        })}
                    </tbody>
                </table>
            </div>
        </div>
    );
}


To Greet, the user needs to specify two things to perform a "greet" function call on the smart contract:

Here is the code for the InputField component.

import { InputHTMLAttributes } from "react";

function InputField({
    label,
    value,
    onChange,
    type,
    placeholder,
    className,
}) {
    return (
        <div className={className}>
            <label className={`block mb-2 font-medium text-gray-500 `}>
                {label}
            </label>
            <input
                type={type}
                className={`bg-white border border-black text-black text-base focus:ring-blue-500 focus:border-blue-500 block w-full p-2.5 ${className}`}
                placeholder={placeholder ?? ""}
                required
                value={value}
                onChange={onChange}
            />
        </div>
    );
}

export default InputField;



export default function Home() {
    const { isConnected } = useAccount();
    
    const [recipient, setRecipient] = useState("");
    const [greeting, setGreeting] = useState("");

    if (!isConnected && isClient) return null;

    return (
        <div className="w-[500px]">
            <div className="w-full flex flex-col gap-5 items-stretch">
                <InputField
                    label="Enter recipient"
                    value={recipient}
                    onChange={({ target }) => setRecipient(target.value)}
                />
                <InputField
                    label="Enter Greeting"
                    value={greeting}
                    onChange={({ target }) => setGreeting(target.value)}
                />
            </div>
            // Greetings table code...
        </div>
    );
}


After the user has specified the recipient address and the greeting, we need to trigger the "greet" contract call from the frontend.

Here is the code for "GreetButton.tsx" (packages/react-app/components/GreetButton.tsx)

I am using a custom Button component but you can use a normal button too.

import GreeterABI from "../abis/GreeterABI";
import { useContractWrite, usePrepareContractWrite } from "wagmi";
import Button from "./Button";

const STORAGE_ALFAJORES = {
    address: "0x77619E547bCBc4693ac6f7309a2f099f0aa4fc21", // Greeter Contract Address
    abi: GreeterABI,
};

export default function GreetButton({
    chainId,
    greeting,
    recipientAddress,
}) {
    const { config } = usePrepareContractWrite({
        ...STORAGE_ALFAJORES,
        functionName: "greet",
        args: [recipientAddress, greeting ?? ""],
    });
    const {
        data,
        isLoading,
        isSuccess,
        write: store,
    } = useContractWrite(config);

    if (!chainId) return null;
    if (greeting === undefined) return null;

    return (
        <Button
            text="Submit"
            isLoading={isLoading}
            disabled={greeting == "" || recipientAddress == ""}
            onClick={store ?? (() => {})}
        />
    );
}


The GreetButton components can be used as follows:

export default function Home() {
    const { isConnected } = useAccount();
    const { chain } = useNetwork();
    const [recipient, setRecipient] = useState("");
    const [greeting, setGreeting] = useState("");    

    if (!isConnected && isClient) return null;

    return (
        <div className="w-[700px]">
            <div className="w-full flex flex-col gap-5 items-stretch">
                <InputField
                    label="Enter recipient"
                    value={recipient}
                    onChange={({ target }) => setRecipient(target.value)}
                />
                <InputField
                    label="Enter Greeting"
                    value={greeting}
                    onChange={({ target }) => setGreeting(target.value)}
                />
                <GreetButton
                    chainId={chain?.id}
                    greeting={greeting}
                    recipientAddress={recipient}
                />
            </div>
            // Greetings table code...
        </div>
    );
}

This is all we need! This is how the final output should look like!

The user can enter the recipient's address, enter the greeting and click the "Submit" button to trigger a transaction! Once the Transaction gets confirmed, the user will see the greeting right below. 

Frontend

When building projects for hackathons, you might want to use many other protocols and tools along with Celo. Here are some that you will find useful!

Alternative Developer Environments & SDKs

Find many more resources and tutorials in the 

Celo Ecosystem

Intro to Celo

Celo

Harpal Jadeja

Build scalable DApps in any mainstream software stack, be it Python with NumPy, or Rust with all its crates. Use all the fancy cryptography libraries in vogue, or any sophisticated machine learning framework of choice.

Overcoming web3 development challenges with Cartesi rollups

Today, developers who aspire to create applications in the Web3 world are facing two main problems:

Computational constraints of the blockchain and high fees.

Lack of a mature software stack for decentralized applications.

 solve these problems by providing an app-specific rollup protocol with a virtual machine that runs Linux distributions, creating a richer and broader design space for DApp developers. Cartesi Rollups offer a modular scaling solution, deployable as layer-2, layer-3, or sovereign rollups, while maintaining strong base layer security guarantees.

Computational constraints of the blockchain

Ethereum’s rollups-centric roadmap divides the 

 problem of the blockchain trilemma into two prongs: 


Rollups solutions are poised to break the 

 constraints of blockchains. One particular solution that offers significant gains in computational scalability is application-specific rollups with interactive dispute resolutions, built on top of a general-purpose base layer. In this setup, the base layer is used for asset settlement, composability between applications, and dispute resolution, whereas the bulk of the computation is shifted to each application’s own rollup.

In traditional Web2  software development, a full-fledged operating system provides developers with the tooling and libraries required to build and run applications. Despite the promising potential of Web3, the availability of essential tooling and libraries remains scarce and inadequate.

 solve this problem by providing a deterministic RISC-V-based VM - the 

 - which is capable of running Linux or other operating systems in a rollup. By doing this, Cartesi brings a computer like the ones we use everyday to the blockchain and allows developers to use rich preexisting code, libraries, tools, operating systems, compilers, interpreters, frameworks, databases and ecosystems for decentralized applications.     

 are application-specific optimistic rollups that can execute DApps with the full support of a Linux runtime along with existing Linux toolchains. In the 

Every DApp is deployed on its own customizable application-specific rollup chain with a dedicated CPU.

DApps don't compete with each other in Cartesi’s ecosystem for scarce blockspace. Rather, each DApp has the entire blockspace just for itself.

 provide significant gains in computational scalability.

 offer a full-fledged operating system that offers industry-grade tooling for developers to create more expressive and computationally intensive blockchain applications.


 ecosystem is based on a special RISC-V-based VM - the 

 - which is capable of running Linux or other operating systems within a rollups framework. This enables the development of scalable decentralized applications in traditional programming languages. The Cartesi Machine is capable of handling more intensive and intricate computations than the Ethereum Virtual Machine (EVM), which gives developers the power to build DApps that handle previously impossible use cases.

 can be used as a layer two (i.e. on top of Ethereum), layer three (i.e. on top of Arbitrum, Optimism, or ZK-EVM chains) or sovereign rollups (i.e. on top of Celestia).

 retain the strong security guarantees of the base layer by implementing fraud proofs with interactive dispute resolution.


, a fully deterministic and transparent RISC-V virtual machine. This allows for intricate and intensive computations to be performed in a verifiable way. One can build fraud proofs of any program executed in the Cartesi Machine, and optimistically prove the result of a RISC-V computation to any complex-enough base layer, such as Ethereum.


In summary, as long as there is one honest validator from a permissionless set of validators, Ethereum can give the correct settlement for any computation.

Cartesi Rollups overview

The user facing interface, which will often provide a UI (e.g., a web application) but may also be a command line interface (e.g., a hardhat task using ethers, or a command line using python).

 The verifiable logic that will run inside the Cartesi Rollups infrastructure; this will store and update the application state given user input, and will produce outputs in the form of 

 (transactions that can be carried out on layer-1) and 

 (information that can be validated on layer-1).

Aside from the back-end running inside the Cartesi Rollups infrastructure, the DApp front-end can of course also make use of external resources such as 3rd-party services. Indeed, for more complex DApps it is expected that there will be other back-ends besides the one running verifiable logic. These would be used whenever the application doesn’t really need a service to be decentralized and trustless, such as providing fast and accessible data caches, helping users communicate with each other, or interfacing with other non-blockchain services.

Conversely, it is also possible for complex DApps to provide more than one front-end application, with the goal of supporting different kinds of users and use cases.

Let’s try locally running a simple existing DApp written in Python, called Echo-Python. The Echo-Python DApp simply copies (or "echoes") each input received as a corresponding output notice. 

Before you begin, make sure that you have 

1. Clone the cartesi/rollups-examples Github repository by running the following command:

git clone https://github.com/cartesi/rollups-examples.git


2. Navigate to the DApp example directory by running the following command:

3. Build the Echo DApp by running the following command:

4. Start the application by running the following command:

docker compose -f ../docker-compose.yml -f ./docker-compose.override.yml up

Now that the application is up and running, let’s send out a request.

From the rollups-examples base directory, navigate to the frontend-console one:

3. Build the frontend console application:

4. Send an input to the current locally deployed DApp:

yarn start input send --payload "Hello, Cartesi."

5. Verify the outputs (notices) generated by your input, to display your DApp notices run the following command:

6. After completing all the steps above, you should get a response similar to the following:

[ {"index":0,"input":0,"payload":"Hello, Cartesi."}]

Congratulations, now you’ve successfully run the Cartesi DApp!

You can shutdown the environment  with ctrl+c and then running:


docker-compose -f ../docker-compose.yml -f ./docker-compose.override.yml down -v

Using Cartesi

 — The home for Cartesi documentation and learning for all kinds of developers, blockchain technology professionals, and researchers.

 — When developing an application, it is often important to easily test and debug it. For that matter, it is possible to run the Cartesi Rollups environment in host mode.

 — In a Cartesi DApp, the front-end and back-end parts of the application communicate with each other through the Rollups framework. This is accomplished in practice by a set of HTTP APIs.

 — APIs available for DApp developers to interact with the Cartesi Rollups framework.

, core Cartesi contributors and the wider developer ecosystem are always eager to help.

Dive into the Cartesi Hackathon track at upcoming events. With Cartesi Rollups, the technical depth meets accessibility, unlocking the full potential of Linux in a decentralized realm.

Our horizon stretches beyond events and hackathons. We're fostering a dynamic community where developers can connect with our contributors on Discord; brainstorm ideas, receive mentorship and become valued members of this ecosystem. 

Resources

From fundamentals to first dApp deployment

Intro to Cartesi

Cartesi

Nico Shishkin

This guide assumes you've already completed the 

 which overviews Superfluid and shows you the bare basics of whipping up money streams in Solidity.

Here, we'll get into Super Apps, a powerful Superfluid smart contract development feature. Let's get into it!

Overview

 Super Apps are smart contracts that are registered with the Superfluid Protocol allowing them to 

 to money streams. This reactivity is programmed in 

Callbacks are custom code that a developer can implement in a Super App that triggers when a stream to the Super App is created, updated, or deleted. This code could enact anything from minting an NFT to even initiating a new stream - it's super flexible.

That's the nutshell explanation you need for this guide, but if you'd like more, check out our 

With Super Apps, applications can be made that mesh together custom logic with money streaming actions to create scalable dApps with innovative user experiences.

Since Super Apps can react to money streams, they create an intermediate layer of programmability to Super Agreement's that wouldn't be possible with just wallet-to-wallet action.

For instance, you could create a lending Super App where loan repayment is be done via money stream rather than manual and repetitive repayment transactions. Also, imagine a Super App supporting on-chain subscriptions paid through money streams with a built-in affiliate program that automatically redirects portions of subscription streams to referrers. The possibilities with Super Apps are endless!

Super Apps

To show how to set up Super Apps, we're going to build a simple "BUIDLxDispenser" Super App and deploy it on Mumbai

All it will do is react to a stream of fDAIx by sending the sender a stream of BUIDLx tokens. If the sender stops streaming fDAIx to it, the BUIDLxDispenser will cancel the their stream of BUIDLx tokens.

 link to find the BUIDLxDispenser contract. Note that the IDE will open all the environment folders at once; you can close them such that the file directory looks like this:

First, we make these imports which are needed for setting up the contract to interact with the Superfluid Protocol:

import {ISuperfluid, ISuperToken} from "@superfluid-finance/ethereum-contracts/contracts/interfaces/superfluid/ISuperfluid.sol";

import {SuperTokenV1Library} from "@superfluid-finance/ethereum-contracts/contracts/apps/SuperTokenV1Library.sol";

import {SuperAppBaseFlow} from "@superfluid-finance/ethereum-contracts/contracts/apps/SuperAppBaseFlow.sol";

 which lays out callback functions for our Super App that we can override to implement our desired functionality (

For this contract, we're going to store the fDAIx Super Token that will be streamed to the contract and BUIDLx Super Token that will be streamed into the contract.

 we're providing the host (which gets stored in a public 

 variable) and three booleans. The booleans stand for the following:

 - True if the Super App will be made to react to the creation of streams to it. False otherwise. 

 - True if the Super App will be made to react to the updating of streams being sent to it. False otherwise. 

 - True if the Super App will be made to react to the deletion of streams being sent to it. False otherwise.

Because our Super App is only going to respond to streams being 

  constructor(
        ISuperToken _fDAIx,
        ISuperToken _BUIDLx,
        ISuperfluid _host
    ) SuperAppBaseFlow(
        _host,
        true,
        false,
        true
    ) {

        fDAIx = _fDAIx;
        BUIDLx = _BUIDLx;
        ...
    }

The following code here is to make our lives easier by minting the BUIDLxDispenser contract 10 million BUIDL tokens and wrap it into BUIDLx.

BUIDL token has a public mint function which lets anyone mint their own BUIDL whenever they want. Makes life easy for this tutorial!

    // Get the underlying BUIDL ERC20 token from the BUIDLx Super Token 
    IBUIDL buidlToken = IBUIDL( BUIDLx.getUnderlyingToken() );

    // Minting the contract 1,000,000 BUIDL tokens to start off
    buidlToken.mint(address(this), 10_000_000e18);

    // Approving the BUIDL tokens to be wrapped into BUILDx
    buidlToken.approve(address(BUIDLx), 10_000_000e18);

    // Wrapping the BUIDL into BUIDLx - now 
    BUIDLx.upgrade(10_000_000e18);


 respond to streams of fDAIx. To make sure of that, the 

function isAcceptedSuperToken(ISuperToken superToken) public view override returns (bool) {
    return superToken == fDAIx;
}

If we hadn't set this, then you could stream any Super Token to the BUIDLxDispenser and trigger the callbacks. As a rule of thumb, make sure you set your accepted Super Tokens when writing your Super Apps to avoid unexpected behavior.

Let's skip down to the other two functions in this contract: 

. These internal functions are our callbacks!

If I start a stream to the BUIDLxDispenser contract, 

 is triggered and if I delete the stream 

 function onFlowCreated(
    ISuperToken superToken,
    address sender,
    bytes calldata ctx
)

Guides

Interested in contributing? Ping us at guides@ethglobal.com

Intro to Celo

Intro to Cartesi

Building a Superfluid Super App

Introduction to Unlock Protocol

Creating ERC20 Token on Polygon

Intro to Sequence Smart Contract Wallet

Introduction to MetaMask Snaps

Introduction to Optimism

Introduction to Livepeer

Verifying Storage on Filecoin

Introduction to libp2p

Smart Contract Development Guidelines

Bridging Tokens & Data

Intro to Push Protocol

Intro to Ethereum Name Service

Money Streaming with Solidity 101

Getting started with Metamask