DEV Community: Bader Youssef

Introduction to Writing RISC-V Contracts in Rust on Polkadot

Bader Youssef — Thu, 12 Feb 2026 21:17:06 +0000

Smart contracts have long been the primary method for developing applications in Web3.

However, the underlying technology hasn't changed much over the years. The EVM (Ethereum Virtual Machine) has long been the default option for smart contract development. It served its purpose well, bootstrapping an entire industry of decentralized applications.

Today, it is a massive ecosystem that has become the de facto standard for interacting with Web3 infrastructure.

Here’s the catch, though:

The EVM is an emulation layer, not an actual machine.

Compared to the rest of the software world, it is a virtual machine designed for a specific network, which comes with limitations. Although it is general-purpose in a sense, it does not give developers the full capabilities of a typical tech stack or the standard, high-performance tooling that powers the rest of the internet. If we want to create a new standard for Web3 software, it needs to be on par with (or ideally, better than) the status quo.

This isolation is what holds back the next generation of complex, high-compute applications. We should be able to create and deploy applications the same way we do in the ‘conventional‘ sense on Web3.

The Current State of Smart Contracts

Smart contracts today are rather simplistic in terms of developer experience and execution. The developer writes high-level code, compiles it to bytecode, and the EVM executes that bytecode instruction-by-instruction. While effective, it is slow compared to native execution.

By relying on a custom virtual machine, we lose access to the decades of optimization that have gone into standard hardware architectures like RISC-V.

This is where PolkaVM comes in.

PolkaVM is a RISC-V-based virtual machine that allows developers to write smart contracts in Rust, Go, and other languages that can be compiled by LLVM, just like traditional software. It represents a shift to "bare metal" execution.

It still executes deterministic logic and maintains persistent state, but it grants developers flexibility beyond the typical bounds of a custom, virtual machine sandbox.

The Bigger Picture: Polkadot & Revive

Taking a step back, it is important to note that Polkadot supports Solidity through Revive (pallet-revive). Revive is a compiler pipeline that targets PolkaVM (RISC-V) while keeping Ethereum tooling compatibility as a first-class goal.

Think of it as a translation layer. On the node side, you can run an Ethereum JSON-RPC adapter (often referred to as an eth-rpc adapter) so tools like MetaMask, Hardhat, or Foundry can speak "normal Ethereum JSON-RPC" while the node translates those calls into the underlying Polkadot runtime and contract environment.

When you send a transaction, the adapter and runtime plumbing route it into the PolkaVM execution engine, taking advantage of the performance and security properties of the underlying RISC-V VM.

If you want a reference point on Ethereum RPC support on Polkadot Hub, see:

You can also see how smart contracts on Polkadot Hub generally work:

Get Started - Smart Contracts on Polkadot

The "Bare Metal" Environment

Solidity is not our only option. As mentioned previously, we can write contracts in any language that compiles to RISC-V, such as Rust.

Writing for PolkaVM is similar to writing for an embedded environment. You are operating on "bare metal," without an operating system (OS).

This is a no_std environment. The Rust standard library (std) assumes OS services for things like threads, files, and some allocation plumbing. Since we don't have an OS, we cannot use std in the usual way.

However, you can still use core (always available) and alloc if you provide a global allocator.

Memory: Stack vs. Heap

To understand why no_std is challenging, we need to look at how computers manage memory:

The Stack

The Mechanism: Linear memory, Last-In/First-Out (LIFO). It’s fast because “allocating” is often just moving a pointer.
The Limitation: The compiler needs to know sizes up-front. This makes truly dynamic structures harder.

The Heap

The Mechanism: Dynamic memory for data structures that can grow/shrink at runtime (like Vec and String).
The Cost: It needs an allocator to manage free space and fragmentation.

In a standard environment, the allocator is provided for you. In a no_std environment, you start without one.

This doesn’t mean "no heap is possible" - it means you don’t get heap allocation for free. If you want dynamic data, you provide an allocator.

Entering the Allocator

What if we could have an allocator for the heap, even in a no_std environment?

We can. By adding a memory allocator like picoalloc, we can manage a fixed chunk of memory (typically a statically reserved region) as a heap.

// We designate a fixed region of memory for the allocator to manage.
#[global_allocator]
static mut ALLOC: picoalloc::Mutex<...> = ...;

This unlocks the standard alloc crate, allowing you to use useful types like Vec<T> even in a no_std environment.

Host Functions & ABI

If the contract runs in an isolated environment, how does it interact with the blockchain?

It uses a host interface (in Revive’s stack this is commonly accessed via the pallet-revive-uapi crate). When the contract needs to store data, transfer tokens, emit events, or inspect chain context, it calls host functions.

Here are representative host functions you’ll see in pallet-revive-uapi (names match the HostFn surface):

Host Function	Purpose
`set_storage` / `get_storage`	Write/read contract storage (key/value).
`call` / `instantiate`	Call another contract / deploy a new contract instance.
`deposit_event`	Emit an event (topics + data).
`caller` / `origin`	Get the caller and origin addresses.
`call_data_size` / `call_data_copy`	Read transaction input (calldata).
`return_value`	Return data (and optionally revert) and stop execution.
`balance` / `balance_of`	Query balances.

Reference:

pallet-revive-uapi docs

Data Persistence (Storage)

If you’re writing your PVM contract in Rust, storage is fairly conventional. It is a raw key-value store:

Keys: Fixed-size byte arrays (commonly 32 bytes).
Values: Variable-length byte arrays.

For example:

const VALUE_KEY: [u8; 32] = [0u8; 32];

This would then be stored using a host function like set_storage:

api::set_storage(
  StorageFlags::empty(),
  &VALUE_KEY,
  &value_bytes
);

The ABI (Application Binary Interface)

The ABI defines how functions are identified within the contract. In Ethereum-style ABIs, a 4-byte selector targets specific functions.

We identify functions using selectors:

Take the text signature: "flip()"
Hash it (Keccak-256)
Take the first 4 bytes

This 4-byte ID acts as the “key” to select a function entry point.

Our Rust contracts can use a Solidity interface as their ABI. This ensures Ethereum tooling compatibility: tools like Foundry’s cast can talk to your contract through an Ethereum JSON-RPC endpoint.

This also means other contracts (Rust or Solidity) can call into your contract on-chain using the same ABI expectations.

Creating an Ethereum ABI for a PVM Contract

To define an Ethereum-compatible ABI, you have two options:

Create an external Solidity file that defines your contract’s ABI.
Use the sol! macro in alloy.

Let’s look at how this works using sol! with an external file. Suppose our Solidity interface contains a public function called flip(). We import the contract as follows:

sol!("Flipper.sol");

The macro expands this at compile-time into Rust types with selectors:

// Generated code (simplified)
struct flipCall {}

impl SolCall for flipCall {
    // 4-byte selector for flip()
    const SELECTOR: [u8; 4] = keccak256("flip()")[0..4];
}

This gives us:

Type safety: Decode into Rust types rather than hand-parsing bytes.
Standard selectors: Same selector scheme as the EVM ABI.

We can then reference the selector like so: Flipper::flipCall::SELECTOR in our dispatch loop. Once we determine which function the user is trying to call, we invoke the corresponding Rust function to do the work.

The Build Pipeline

The PVM build process consists of two stages:

Rust -> ELF: The compiler generates a standard ELF binary (riscv64emac-unknown-none-polkavm).
Refinement (Polkatool): A specialized linker performs "tree shaking" (removing dead code) and optimization to produce the final .polkavm file.

This .polkavm file is the artifact deployed on-chain.

Building and Deploying a Flipper Contract in Rust

Enough talk: let's build a flipper contract and deploy it on the Polkadot Testnet. This contract will store a single boolean value and allow anyone to flip it between true and false.

Prerequisites

Before jumping into the code, we need to ensure your environment is set up with the necessary tools, a wallet, and testnet funds.

1) Install Developer Tools

You will need Git, Rust, and Foundry installed on your machine.

Rust:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Foundry:

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

Git: If you don't have Git installed, download it from:

https://git-scm.com/install/

2) Generate a Wallet

We need a private key to sign transactions. We can use Foundry's cast tool to generate one:

cast wallet new

Next, save the wallet so we can use it for signing later:

cast wallet import pvm-account --private-key <your-private-key-from-cast-wallet>

3) Get Testnet Funds

We are deploying to the Polkadot testnet (Paseo / Asset Hub), so we’ll use a faucet:

Go to the Polkadot Faucet.
Select "Polkadot testnet (Paseo)" from the network list.
Ensure the chain is on "Assethub".
Enter the address you generated above.
Click "Get Funds" (this may take a few minutes).

Scaffold

To get started, clone a prepared template:

git clone -b template https://github.com/CrackTheCode016/flipper-pvm flipper
cd flipper

Note: There is a CLI tool under development that can automate project creation and scaffolding (see: cargo-pvm-contract). For this tutorial, we work manually from the template above.

The template is already configured with the files we need:

src/flipper.rs for logic
Flipper.sol for the ABI interface

Implement Flipper (`src/flipper.rs`)

Open src/flipper.rs. The template provides scaffolding (allocator via picoalloc, panic handler, and the Solidity interface definition), but the core logic is missing.

We need to fill in the todo!() blocks for storage, event emission, and the dispatch loop.

The Logic & Storage

We’ll store our flipper state in VALUE_KEY. Locate get_value and set_value.

Inside fn get_value(), replace todo!() with:

let mut value_bytes = vec![0u8; 32];
let mut output = value_bytes.as_mut_slice();

match api::get_storage(StorageFlags::empty(), &VALUE_KEY, &mut output) {
    Ok(_) => {
        // Check if the last byte is non-zero (Solidity stores bool as uint8)
        output[31] != 0
    }
    Err(_) => false, // Default to false if not set
}

Inside fn set_value(value: bool), replace todo!() with:

let mut value_bytes = [0u8; 32];
value_bytes[31] = if value { 1 } else { 0 };

api::set_storage(StorageFlags::empty(), &VALUE_KEY, &value_bytes);

The Event

Find emit_flipped. Replace todo!() with:

let _event = Flipper::Flipped { new_value };

// The signature hash is the first topic (the event ID)
let topics = [Flipper::Flipped::SIGNATURE_HASH.0];

// We manually encode the data (bool as u256/32 bytes)
let mut data = [0u8; 32];
data[31] = if new_value { 1 } else { 0 };

api::deposit_event(&topics, &data);

The Entry Point

Implement the call() function (the main entry point). Replace todo!() with:

// 1. INPUT HANDLING
let call_data_len = api::call_data_size();
let mut call_data = vec![0u8; call_data_len as usize];
api::call_data_copy(&mut call_data, 0);

// 2. SELECTOR EXTRACTION
// We expect at least 4 bytes for the function selector
if call_data.len() < 4 {
    api::return_value(ReturnFlags::REVERT, b"Input too short");
}

let selector: [u8; 4] = call_data[0..4].try_into().unwrap();

// 3. DISPATCHING
match selector {
    // Handle flip() function call
    Flipper::flipCall::SELECTOR => {
        let current = get_value();
        let new_value = !current;
        set_value(new_value);
        emit_flipped(new_value);
    }

    // Handle get() function call
    Flipper::getCall::SELECTOR => {
        let current = get_value();

        // 4. RETURN ENCODING
        let mut return_data = [0u8; 32];
        return_data[31] = if current { 1 } else { 0 };
        api::return_value(ReturnFlags::empty(), &return_data);
    }

    _ => {
        // Unknown function selector - revert
        api::return_value(ReturnFlags::REVERT, b"Unknown function");
    }
}

Build

Generate the artifacts for on-chain upload:

cargo build

If successful, you should see flipper.debug.polkavm within the target directory.

Deploy & Interact

Set your RPC endpoint:

export ETH_RPC_URL="https://services.polkadothub-rpc.com/testnet"

Deploy:

cast send --account pvm-account --create "$(xxd -p -c 99999 target/flipper.debug.polkavm)"

If successful, you should see output similar to:

blockHash             0xf215391078dd412eb90095e5c5ad4454a761299ef51ce9ad44e0dc5178f957ee
blockNumber           2
contractAddress       <YOUR_CONTRACT_ADDRESS>
cumulativeGasUsed     0
effectiveGasPrice     50000000000
from                  0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac
gasUsed               295239...
status                1 (success)...
to                    0xc01Ee7f10EA4aF4673cFff62710E1D7792aBa8f3

Copy the contractAddress and set:

export RUST_ADDRESS=<YOUR_CONTRACT_ADDRESS>

Interaction

# Check current value (should be false)
cast call $RUST_ADDRESS "get() returns (bool)"

# Flip it!
cast send --account pvm-account $RUST_ADDRESS "flip()"

# Check again (should be true)
cast call $RUST_ADDRESS "get() returns (bool)"

Explorer example:

https://polkadot.testnet.routescan.io/address/0x2044DB81C13954e157Cb9F1E006006a70b7CEA89

Conclusion

PolkaVM demonstrates a future where web3 applications are not mini-apps, but full-scale programs running on real technology stacks. Building on Web3 should not be having to compromise on design due to technological limitations; rather, it should expand and broaden our horizons while providing a more resilient and robust future for computing.

Working at this low level of smart contract development opens new avenues for computationally expensive applications, where every byte counts. Other contracts on-chain, whether written in Rust or Solidity, can call these optimized contracts, leveraging their lower costs and more practical execution models.

Beginners Guide to Polkadot API (PAPI) - You've Got Mail!

Bader Youssef — Wed, 12 Mar 2025 17:40:04 +0000

Welcome to the Beginners Guide to Polkadot API series!

This tutorial will focus on learning how to build and compose decentralized applications (dApps) on the Polkadot network. We will also define what that means exactly and explain how to create your first light client-powered app on Polkadot.

If you're new to Polkadot (and blockchain development in general), keep reading; otherwise, you can skip to the tutorial below.

Quick Introduction: What is Polkadot?

Polkadot's is a protocol that coordinates and secures different rollups (often called parachains) allowing for a horizontally scaling, heterogeneously sharded, multi-chain approach to Web3. One of the keywords here is heterogeneously sharded, meaning that each shard, or blockchain (or state machine, if you want to get more technical), contains its unique domain-specific logic. Anyone can build a rollup and inherit security from the Polkadot relay chain using the Polkadot SDK. A rollup can be quite literally anything from a bridge to Ethereum and other protocols (Hyperbridge), a decentralized knowledge graph️ (OriginTrail), or even a cloud computing and oracle platform that is powered by old smartphones (Acurast)

Once deployed, rollups can use cross-consensus messaging (XCM) to communicate with one another. This is not limited to just rollups within Polkadot, but even to other protocols, such as Ethereum.

Composing Applications Using the Polkadot Stack

As Polkadot has a wide range of different application-specific rollups at our creative disposal, the concept of composing apps should not be a foreign one. Similar to how a traditional, web2 application may use different services, APIs, and technologies to build a full-stack application, we can utilize the different parts of the Polkadot stack to build a web3 native application. You even go as far as to host your application on a web3 service to bypass the conventional means of deployment completely.

The Composer - The Polkadot API (PAPI)

Although you can use a number of languages to build apps on Polkadot, such as Rust, Python, or Typescript/Javascript, we'll be using Polkadot API, or PAPI, which is a Typescript library for interacting with Polkadot (and its rollups). The main differentiator with PAPI is its light-client-first approach, in which it has native support for communicating to Polkadot via a light client.

The light client implementation, called smoldot, runs in the background and ensures that we have the latest, verified chain state. Using PAPI, you can even interact with multiple rollups on Polkadot at once.

Why Are Light Clients Important?

Light clients are one of the two options for connecting to a blockchain, with the other usually depending on a single RPC provider (which often runs on a centralized server). They are typically a more secure, trust-minimized, efficient way of communicating to a blockchain. Light clients verify the state of the blockchain using Merkle proofs, ensuring it has not only the latest but correct state. As it just verifies the headers of the blocks, it has no need to download the whole state, making it ideal for resource-constrained environments.

Unlike RPC connections, they do not depend on a single RPC provider and can be embedded in both the browser and natively.

"You've Got Mail!" - Polkadot API Boilerplate and Example

With the explanation out of the way, let's get our hands dirty with some code.

Project Introduction

Our project will be quite simple - it will be a CLI application that runs in the terminal, which watches the relay chain for a certain extrinsic (a transaction). This extrinsic will be the system.remarkWithEvent extrinsic, meaning it is coming from the system pallet (module) on the Westend test network.

The system.remarkWithEvent extrinsic allows us to send any arbitrary data on-chain, with the end result being a hash that is the address and the word "email" combined (address+email). We'll hash this combination and watch for remarks on a chain that are addressed to us. The system.remarkWithEvent extrinsic emits an event that we can use PAPI to watch the chain for.

Once we receive a remark addressed to us, we will play the infamous "You've Got Mail!" sound byte.

Prerequisites

You should have the following installed as a prerequisite:

npm (or other package manager)
node
git
Polkadot.js Browser Extension (wallet)

You will also need an account with Westend tokens. Below you can find guides for both Polkadot.js and the faucet:

Cloning the repository

For this tutorial, you can choose to run the example directly by cloning the main branch of the repository, or to use a boilerplate/template and follow the tutorial.

We need to clone the template, which has everything we need to get started with the Polkadot API and Typescript. Be sure you clone the correct branch (empty-cli) which already provides all dependencies:

git clone https://github.com/CrackTheCode016/polkadot-api-example-cli --branch empty-cli

Once cloned, run the following to ensure npm dependencies are installed:

cd polkadot-api-example-cli
npm install

Exploring the Template (Light Clients!)

When we open the repository, we should see the following code (excluding imports):

async function withLightClient(): Promise<PolkadotClient> {
    // Start the light client
    const smoldot = start();
    // The Westend Relay Chain
    const relayChain = await smoldot.addChain({ chainSpec: westEndChainSpec })
    return createClient(
        getSmProvider(relayChain)
    );
}

async function main() {
    // CLI Code goes here...
}

main()

The notable function to pay attention to is the withLightClient function. This function uses the built in light client functionality (powered by smoldot) to actually create a light client that syncs and interacts with Polkadot right there in our application.

Creating the CLI

Next, let's create our CLI, which is to be done within the confines of the main function. We will include an option (-a / --account), which will be the account we will watch for our "mail":

const program = new Command();
console.log(chalk.white.dim(figlet.textSync("Web3 Mail Watcher")));
program.version('0.0.1').description('Web3 Mail Watcher - A simple CLI tool to watch for remarks on Polkadot network');
    .option('-a, --account <account>', 'Account to watch')
    .parse(process.argv);

// CLI Arguments from commander
const options = program.opts();

Watching for Remarks

Next, we need to start watching the Westend network for remarks sent to our account. As was done before, all code should be within the main function:

    // We check for the --account flag, if its not provided we exit
    if (options.account) {
        console.log(chalk.black.bgRed("Watching account:"), chalk.bold.whiteBright(options.account));
        // We create a light client to connect to the Polkadot (Westend) network
        const lightClient = await withLightClient();
        // We get the typed API to interact with the network
        const dotApi = lightClient.getTypedApi(wnd);
        // We subscribe to the System.Remarked event and watch for remarks from our account
        dotApi.event.System.Remarked.watch().subscribe((event) => {
            // We look for a specific hash, indicating that its our address + an email
            const { sender, hash } = event.payload;
            // We calculate the hash of our account + email
            const calculatedHash = bytesToHex(blake2b(`${options.account}+email`, { dkLen: 32 }));
            // If the hash matches, we play a sound and log the message - You got mail!
            if (`0x${calculatedHash}` == hash.asHex()) {
                sound.play("youve-got-mail-sound.mp3")
                console.log(chalk.black.bgRed(`You got mail!`));
                console.log(chalk.black.bgCyan("From:"), chalk.bold.whiteBright(sender.toString()));
                console.log(chalk.black.bgBlue("Hash:"), chalk.bold.whiteBright(hash.asHex()));
            }
        });
    } else {
        // If the account is not provided, we exit
        console.error('Account is required');
        return;
    }

This code is doing quite a bit, so let's break it down:

First, we check for the existance of the --account argument, and log that we are watching that account, else we exit. We are using the chalk package to add color to our console.log statements.
Next, we create our light client.
We use a light client and the Westend chain specification (wnd) to access a typed API.
Once we have our API, we then begin to reactively watch the account for the event that corresponds to the remark. We analyze the payload, looking for a hash which is calculated as follows:
- hash of: account_address+email
When an event containing this hash is identified, it then plays the "You've Got Mail!" soundbite.

Compiling and running

Once we have all of our code in place, we should compile and run the repository:

npm start -- --account <account-address>

Upon running, we should have the following output:

❯ npm start -- --account 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY

> youve-got-mail-web3@1.0.0 start
> tsc && node ./dist/index.js --account 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY

 __        __   _    _____   __  __       _ _  __        __    _       _
 \ \      / /__| |__|___ /  |  \/  | __ _(_) | \ \      / /_ _| |_ ___| |__   ___ _ __
  \ \ /\ / / _ \ '_ \ |_ \  | |\/| |/ _` | | |  \ \ /\ / / _` | __/ __| '_ \ / _ \ '__|
   \ V  V /  __/ |_) |__) | | |  | | (_| | | |   \ V  V / (_| | || (__| | | |  __/ |
    \_/\_/ \___|_.__/____/  |_|  |_|\__,_|_|_|    \_/\_/ \__,_|\__\___|_| |_|\___|_|

Watching account: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
[smoldot] Smoldot v2.0.34
[smoldot] Chain initialization complete for westend2. Name: "Westend". Genesis hash: 0xe143…423e. Chain specification starting at: 0x10cf…b908 (#23920337)

Testing the CLI

Now that our application is actively watching for remark events on-chain, we can move to testing to see if it works!

As mentioned previously, you will need a Westend account with some tokens to pay for fees.

Navigate to the PAPI Dev Console > Extrinsics. You then want to select the System pallet, and the remark_with_event call:

Next, we want to be sure we get the correct input for the text field. We want to be sure we are following the convention we set forth in our application:

address+email

If for example, we are watching 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY, then the field should look like the following:

Once this input is in place, you may click the Submit extrinsic button, where you can sign using the Polkadot.js browser wallet:

Heading back to our CLI, we should soon see the following, along with the fact that "YOU'VE GOT MAIL!" (as in the sound should play):

 __        __   _    _____   __  __       _ _  __        __    _       _
 \ \      / /__| |__|___ /  |  \/  | __ _(_) | \ \      / /_ _| |_ ___| |__   ___ _ __
  \ \ /\ / / _ \ '_ \ |_ \  | |\/| |/ _` | | |  \ \ /\ / / _` | __/ __| '_ \ / _ \ '__|
   \ V  V /  __/ |_) |__) | | |  | | (_| | | |   \ V  V / (_| | || (__| | | |  __/ |
    \_/\_/ \___|_.__/____/  |_|  |_|\__,_|_|_|    \_/\_/ \__,_|\__\___|_| |_|\___|_|

Watching account: 5Cm8yiG45rqrpyV2zPLrbtr8efksrRuCXcqcB4xj8AejfcTB
You've got mail!
From: 5Cm8yiG45rqrpyV2zPLrbtr8efksrRuCXcqcB4xj8AejfcTB
Hash: 0xb6999c9082f5b1dede08b387404c9eb4eb2deee4781415dfa7edf08b87472050

Conclusion

This application can be expanded in a number of ways, whether that is by adding a chatroom through remarks, or by using some of the rollups on Polkadot to expand the functionality.

DEV Community: Bader Youssef

Introduction to Writing RISC-V Contracts in Rust on Polkadot

The Current State of Smart Contracts

The Bigger Picture: Polkadot & Revive

The "Bare Metal" Environment

Memory: Stack vs. Heap

The Stack

The Heap

Entering the Allocator

Host Functions & ABI

Data Persistence (Storage)

The ABI (Application Binary Interface)

Creating an Ethereum ABI for a PVM Contract

The Build Pipeline

Building and Deploying a Flipper Contract in Rust

Prerequisites

1) Install Developer Tools

2) Generate a Wallet

3) Get Testnet Funds

Scaffold

Implement Flipper (src/flipper.rs)

The Logic & Storage

The Event

The Entry Point

Build

Deploy & Interact

Interaction

Conclusion

Beginners Guide to Polkadot API (PAPI) - You've Got Mail!

Quick Introduction: What is Polkadot?

Composing Applications Using the Polkadot Stack

The Composer - The Polkadot API (PAPI)

Why Are Light Clients Important?

"You've Got Mail!" - Polkadot API Boilerplate and Example

Project Introduction

Prerequisites

Cloning the repository

Exploring the Template (Light Clients!)

Creating the CLI

Watching for Remarks

Compiling and running

Testing the CLI

Conclusion

Implement Flipper (`src/flipper.rs`)