Forem: Okoli Evans

The Controversy of On-Chain Privacy: Monero, Tornado Cash, and Strk20

Okoli Evans — Tue, 14 Apr 2026 07:59:53 +0000

Privacy onchain has never just been a technical problem, it's more a political one.

I've been in this space long enough to have watched the same cycle repeat itself: a team ships something that gives users genuine financial privacy, regulators decide it's a money laundering vehicle, exchanges delist it or the developer gets arrested, and the whole thing becomes a cautionary tale. Meanwhile the underlying need — the legitimate need for financial confidentiality — remains. It just waits for the next builder who is brave enough to try.

This article is about that cycle. About three different bets on how to solve on-chain privacy, what each one got right, what it got wrong, and why the most recent entry — STRK20, a privacy protocol published by StarkWare researchers in March 2026 — might be the first design that actually survives contact with the real world.

The Controversy in Plain Terms

Now the irony of the whole thing is that public blockchain is a globally readable ledger. Every amount, every sender, every receiver is permanently visible to anyone who looks. I can't attribute this to design flaw or failure, it's just the natural evolution process of most things; first make it work, refine later.

The case for financial privacy isn't radical: your salary is your business, your business treasury is your business, your savings are your business.

But the moment you build something that actually delivers that privacy on-chain, you inherit a problem. The same tool that protects a Nigerian entrepreneur from a predatory counterparty also protects a black hat trying to move stolen funds. Regulators don't distinguish easily between the two, and that ambiguity has defined the entire history of on-chain privacy.

Monero: Privacy as Ideology

Monero is the purest expression of the privacy-as-a-right philosophy. Every transaction is private by default, with no opt-out and no exceptions. The engineering behind it is really impressive:

Ring signatures blend your spend with several decoy inputs to obscure the sender.
Stealth addresses generate a fresh one-time address per recipient
RingCT hides amounts completely

Monero does have view keys — a mechanism that lets you voluntarily share your incoming transaction history with a third party like a tax authority or auditor. So it's not a total black box. But the compliance surface is narrow and critically flawed: outgoing transactions are much harder to prove, no auditing entity is baked into the protocol, and there's zero enforcement that users register or share anything.

Compliance is entirely optional, entirely user-initiated, and entirely unverifiable at scale.

The ideology is coherent. The problem is what it looks like from the outside.

When regulators see a system where compliance is possible in theory but structurally unenforceable in practice, they don't give it credit for the theory. They see a system they can't audit, can't subpoena, and can't work with under any meaningful circumstances.

The response was predictable: systematic delistings.

Major exchanges removed it. Some jurisdictions moved to ban it outright. Today, Monero survives with a loyal community — but largely at the margins.

The incomplete compliance path wasn't a strength, it was a ceiling.

Tornado Cash: When Code Became Criminal

Tornado Cash took a different approach. It wasn't a new chain — it was a smart contract on Ethereum.

Users deposited fixed denominations of ETH and ERC-20 tokens — DAI, USDC, WBTC — and later withdrew to a new address, breaking the on-chain link using zero-knowledge proofs.

Simple. Elegant. Effective.

Then in August 2022, the US Treasury sanctioned it.
Not a company.
Not a person.
A piece of code.

Interacting with it became legally risky. Its GitHub was taken down. Roman Storm, one of its core developers, was arrested and charged with money laundering conspiracy, sanctions violations, and operating an unlicensed money transmitting business.

The industry responded with "code is not a crime."

And philosophically, that argument matters — holding a developer criminally liable for how users choose to use open-source software sets a disturbing precedent that the whole industry should be paying attention to.

But from a product perspective, Tornado had the same structural problem as Monero:
No compliance path.
No mechanism — under any circumstance, for any authorized party — to trace funds through it.

That wasn't just a philosophical position. It was a design decision that handed regulators a clean narrative and prosecutors a clean case.

STRK20: A Different Bet Entirely

STRK20 starts from a different premise:

The real issue isn't privacy. It's accountability.

If you can build a system where:

Privacy is the default
But accountability is possible under legitimate legal processes

…then you remove the core argument regulators have used against every previous system.

That’s the bet.

How STRK20 Actually Works

The Note Model

Like Zcash and Aztec, STRK20 uses a UTXO-style “note” system:

Each note encodes owner, token, and amount
Transfers = spending notes + creating new ones

Standard foundation. The differentiation is everything built around it.

Nullifiers Without Commitments

When a note is spent:

A nullifier marks it as used
The actual note identity remains hidden

Unlike Zcash:

No Merkle tree of commitments
Notes live directly in Starknet contract storage (encrypted)

This:

Reduces proof complexity
Lowers storage overhead
Leans into Starknet’s architecture

Channel-Based Discovery (Key Innovation)

Traditional problem (Zcash):

You must scan and attempt to decrypt everything
Complexity: O(total transactions)

STRK20 flips this.

Notes are stored at locations derived from a shared secret between sender and recipient.

So:

The recipient already knows where to look
No global scanning

Structure:

Channels → Subchannels → Notes
Sequential indexing enforced (no gaps allowed)

Discovery cost becomes:

O(your activity)

Not the network’s.

That’s a massive scalability unlock.

The Compliance Framework

This is the controversial core.

When registering:

A user encrypts their viewing key to an auditing entity
The encrypted key is stored on-chain

The auditing entity:

Uses a threshold system (multi-party control)
Can decrypt viewing keys only under valid legal request

Capabilities:

Trace incoming and outgoing transactions
Perform forward and backward tracing
Only expose data for the target user

Important constraint:

No leakage about unrelated users

Sequential indexing ensures:

No hidden transactions
No skipping records

If you have the viewing key, you see everything for that user.

Multi-Asset + DeFi Integration

Most previous privacy systems built a separate pool for each asset.

Tornado Cash had distinct contracts for ETH, DAI, USDC.

STRK20 runs everything through a single pool — multiple token types, one contract. Simpler architecture, better anonymity set, less fragmentation.

The DeFi integration is where it gets genuinely clever.

The fundamental problem with using a privacy protocol inside a DEX is timing: your ZK proof has to be generated before the transaction executes, but AMM swap outputs depend on pool state at execution time. The pool might shift between when you generate the proof and when it settles. You can't commit to a number you don't know yet.

STRK20 solves this with open notes — a special note type that starts empty and gets filled by an external contract after the swap executes.

The user's proof creates a placeholder note for the destination token with zero amount. The helper contract performs the swap, receives the output, and deposits it into that pre-registered note. The whole flow is atomic — it either all happens or none of it does.

The privacy tradeoff is honest and minimal: swap amounts and token types are visible on-chain, but the AMM's public state would have revealed that anyway. What stays hidden is the only thing that matters — who made the swap.

Unified Cairo Codebase

Most ZK systems split:

Circuit logic (Circom/Noir)
Smart contract logic (Solidity)

STRK20 uses:

Cairo for everything

Thanks to StarkWare’s prover:

The ZK proof = proof of Cairo execution

Benefits:

One language
One logic system
Easier auditing
Shared infrastructure with Starknet

Comparing the Three

Feature	Monero	Tornado Cash	STRK20
Privacy	Strong, default	Moderate	Strong
Compliance	None	None	Built-in
Discovery	N/A	N/A	O(user activity)
Multi-asset	No	No	Yes
DeFi	None	None	Native
Survival	Marginalized	Sanctioned	Designed to coexist
Code Model	N/A	Split	Unified

The Real Controversy STRK20 Surfaces

STRK20 doesn't eliminate the debate. It reframes it.
The criticism is legitimate: there is a trusted auditing entity, a master decryption capability exists, and that is a centralisation point with no equivalent in Monero or the original Tornado Cash. Privacy purists will call this a betrayal of the principle. I understand that position.

But I keep coming back to the alternative. Not the theoretical alternative — the actual, documented one. Delistings. Sanctions. A developer facing decades in prison for writing open-source code.

Pure privacy systems haven't survived regulatory pressure, and surviving isn't optional if you want anyone beyond a niche to actually use what you build.

Bringing the billions onchain goes beyond a small niche of users to the open society, including individuals, institutions, organizations and so on.

So the question STRK20 forces you to answer is honest and uncomfortable in equal measure:

Is privacy that works for millions better than privacy that works for a few?

That's a values question as much as a technical one.

Closing

This debate was never really about cryptography. It's about power — who gets to see your money, when, and under whose authority.

Monero said nobody. Tornado Cash said nobody. Both paid for it in ways that are still unfolding.

STRK20 says something more precise: nobody, unless the law specifically requires it, and even then only the person under investigation.

Not their neighbours in the pool.
Not their counterparties.
Just them.

That's not ideological purity. But ideology doesn't keep protocols alive — and dead protocols don't protect anyone's privacy.

And honestly? The compliance argument isn't just about regulatory survival. We've seen what unaccountable financial privacy looks like in practice — ransomware payouts, sanctions evasion, illicit financing moving through mixers at scale. Those aren't hypotheticals. They're documented history. Dismissing that to win a philosophical argument is its own kind of dishonesty.

The strongest case for STRK20 isn't that it compromises on privacy. It's that it takes both things seriously at once — the individual's right to financial confidentiality, and society's legitimate interest in accountability when the law demands it. Not one at the expense of the other.

That balance is harder to build. It's also harder to tear down.

But this is just my own view, I'm eager to hear what everyone thinks... leave a comment or tweet at me https://x.com/OkoliEvans

Cheerio...

Resouces:
https://www.starknet.io/blog/make-all-erc-20-tokens-private-with-strk20/
https://eprint.iacr.org/2026/474

AVNU Paymaster & Gas Sponsorship on Starknet

Okoli Evans — Sun, 22 Mar 2026 23:24:52 +0000

A Practical Guide for Building Gasless dApps

PART ONE

Understanding AVNU Paymaster

Imagine this:

You're a normal Web2 user.

You've been hearing about Web3 for a while, and you finally decide to try it out.

You find a cool game.

The UI looks clean. It feels legit for a gamer.

So you go through the process:

You install MetaMask.
You follow a YouTube tutorial.
You create your wallet.

You come back, connect your wallet, and click the main button:

"Start"

And then you see this:

"Insufficient ETH for gas fees."

You pause.

What is gas?
Why do I need ETH?
I just want to start my game…

At this point, most users don't go buy ETH.

They leave.

This is the gas fee problem — and it quietly kills Web3 adoption.

No matter how good your product is, requiring users to hold a native token before doing anything is friction most won't tolerate, especially new web3 users.

On Starknet, AVNU Paymaster has successfully fixed this problem.

Built on Starknet's account abstraction model, it allows:

Your dApp to sponsor gas fees entirely for users
Or users to pay fees in supported tokens (like USDC, USDT)

No STRK required for normal transactions.
No onboarding friction.

What Is a Paymaster?

A Paymaster is a smart contract that handles transaction fees on behalf of a user. Users do not pay gas fees — the fees are paid by a sponsor on behalf of the user.

This unlocks a UX potential for dApps running on Starknet. Coupled with native account abstraction on Starknet, builders can now achieve web2 level of UX in their applications.

PART TWO

Paymaster Setup

Setup paymaster account and create API key on AVNU portal.

Go to https://portal.avnu.fi/
Click on connect wallet and sign in
Create your account

The next page will require you to enter your name and your contact details, fill in the required details accordingly. Once you are done, click on create account and it takes you straight to your dashboard:

Click on Create Your First Key to create your API key. Enter your project name (can be anything) and click on create key.

If you got everything right, you'll see this page:

Click on add credits to fund your paymaster account. The credit is what is actually used to make payments on behalf of your users.
Monitor your dashboard

Once live, you can track everything from the dashboard — gas sponsored, success rate, number of unique accounts sponsored, burn rate, etc.

Now that we have completed the paymaster setup, next is to show how you can integrate it in your dApp.

PART THREE

Integration Guide

Prerequisites

Node.js (v18+)
JavaScript / TypeScript project

Step 1 — Install Dependencies

The PaymasterRpc class is imported directly from the starknet package. If you don't have it installed yet, add it to your project:

npm install starknet

Step 2 — Initialise the Paymaster

The PaymasterRpc class is your connection to the AVNU Paymaster service. Initialise it with your chosen network endpoint and API key:

import { PaymasterRpc } from 'starknet';

const paymaster = new PaymasterRpc({
  nodeUrl: 'https://starknet.paymaster.avnu.fi', // mainnet
  // nodeUrl: 'https://sepolia.paymaster.avnu.fi', // testnet (free)
  headers: {
    'x-paymaster-api-key': process.env.AVNU_API_KEY,
  },
});

Step 3 — Execute a Sponsored Transaction

Pass the paymaster into the Account constructor, then call executePaymasterTransaction():

import { Account, RpcProvider, PaymasterRpc } from 'starknet';

const account = new Account({
  provider,
  address: process.env.ACCOUNT_ADDRESS,
  signer: process.env.PRIVATE_KEY,
  paymaster,
});

const result = await account.executePaymasterTransaction(calls, {
  feeMode: { mode: 'sponsored' }, // You sponsor, user pays nothing
});

✅ No gas required from the user
✅ Paid from your AVNU credits

Step 4 — Secure Your API Key (Server Proxy)

Never expose your API key in frontend code.

Create a server-side proxy that forwards requests to AVNU with your key attached. Here's a Next.js example:

// app/api/paymaster/route.ts
export async function POST(request: Request) {
  const body = await request.json();

  const response = await fetch('https://starknet.paymaster.avnu.fi', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-paymaster-api-key': process.env.AVNU_API_KEY!,
    },
    body: JSON.stringify(body),
  });

  return Response.json(await response.json());
}

Here's the same pattern in an Express backend — this is taken directly from Zapcode's production wallet.js:

router.post('/paymaster', async (req, res) => {
  try {
    const response = await fetch(AVNU_PAYMASTER_URL, {
      method: 'POST',
      headers: avnuHeaders, // includes x-paymaster-api-key, stored server-side
      body: JSON.stringify(req.body),
    });
    const data = await response.json();
    res.status(response.status).json(data);
  } catch (err) {
    console.error('[paymaster]', err.message);
    res.status(500).json({ error: err.message });
  }
});

Step 5 — Use the Proxy on the Client

Point your PaymasterRpc to your own proxy route instead of directly to AVNU — your API key never touches the browser:

const paymaster = new PaymasterRpc({
  nodeUrl: '/api/paymaster', // your proxy route
});

Full Working Code Example

Here's a complete, annotated JavaScript file combining all the steps above. Replace the placeholder values with your own before running.

// avnu-paymaster-example.js
import { Account, RpcProvider, PaymasterRpc } from "starknet";
import * as dotenv from "dotenv";
dotenv.config();

async function main() {
  // 1. Set up the Starknet RPC provider
  const provider = new RpcProvider({
    // For Sepolia testnet: "https://starknet-sepolia.g.alchemy.com/starknet/version/rpc/v0_10/YOUR_ALCHEMY_KEY"
    nodeUrl: "https://starknet-mainnet.g.alchemy.com/starknet/version/rpc/v0_10/YOUR_ALCHEMY_KEY",
  });

  // 2. Initialise the AVNU Paymaster
  const paymaster = new PaymasterRpc({
    // For Sepolia testnet: "https://sepolia.paymaster.avnu.fi"
    nodeUrl: "https://starknet.paymaster.avnu.fi",
    headers: {
      "x-paymaster-api-key": process.env.AVNU_API_KEY,
    },
  });

  // 3. Set up account — paymaster is passed in the constructor
  const account = new Account({
    provider,
    address: process.env.ACCOUNT_ADDRESS,
    signer: process.env.PRIVATE_KEY,
    paymaster,
  });

  // 4. Define the contract calls to execute (we use STRK for demo)
  const STRK_ADDRESS = "0x04718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d";

  const calls = [
    {
      contractAddress: STRK_ADDRESS,
      entrypoint: "transfer",
      calldata: [
        "0xRECIPIENT_ADDRESS",  // recipient wallet address
        "1000000",               // amount (STRK has 18 decimals — adjust accordingly)
        "0",
      ],
    },
  ];

  // 5. Execute — user pays nothing, your AVNU credits cover the gas
  console.log("Submitting sponsored transaction...");
  const result = await account.executePaymasterTransaction(calls, {
    feeMode: { mode: "sponsored" },
  });

  console.log("Transaction hash:", result.transaction_hash);

  // 6. Wait for on-chain confirmation
  await provider.waitForTransaction(result.transaction_hash, {
    retryInterval: 2000,
  });

  console.log("Confirmed!");
}

main().catch(console.error);

Create a .env file in your project root:

AVNU_API_KEY=your_api_key_from_portal
ACCOUNT_ADDRESS=0xYOUR_STARKNET_ACCOUNT_ADDRESS
PRIVATE_KEY=0xYOUR_PRIVATE_KEY

Run it:

node avnu-paymaster-example.js

Testing & Verifying Your Integration

Test on Sepolia first — switch your PaymasterRpc nodeUrl to sepolia.paymaster.avnu.fi. Credits are unlimited and free.

Check your dashboard — after running a transaction, go to your AVNU Portal explorer on your dashboard. You should see:

The transaction hash appear in your logs
The gas cost deducted (on Sepolia this is simulated — no real cost)
Transaction status: confirmed or failed

Common errors:

Error	Fix
401 Unauthorised	API key is missing or incorrect — check your `.env` file
Account not compatible	Your wallet must be Ready (ArgentX) or Braavos and deployed on-chain
Insufficient credits	Top up your credit balance in the AVNU Portal (mainnet only)
Transaction rejected	Check your calldata and contract address are correct

Conclusion & Next Steps

You now have everything you need to integrate AVNU Paymaster into your Starknet dApp. To recap what you've built:

Set up your account and API key in the AVNU Portal
Initialised the PaymasterRpc provider with starknet.js
Executed a fully sponsored transaction — gas paid by your dApp
Set up a secure server-side proxy to protect your API key

Gas sponsorship is one part of the AVNU paymaster guide. In the next guide, we'll cover the second mode — letting users pay gas in any token (USDC, USDT, LORDS, wstETH, and more) — which opens up entirely new possibilities for builders on Starknet.

Useful Links

AVNU Portal — portal.avnu.fi
AVNU Paymaster Docs — docs.avnu.fi/docs/paymaster
starknet.js — starknetjs.com
GitHub — github.com/avnu-labs/paymaster

For questions or feedback, kindly leave a comment or send a message at https://x.com/okolievans

From Web2 to Web3: A Practical Guide to Building a Gasless Crypto Payment Flow (With Starknet & StarkZap)

Okoli Evans — Thu, 19 Mar 2026 10:58:54 +0000

A hands-on guide for React/Node developers to integrate wallets, social login, and USDC payments — without learning blockchain from scratch or writing many lines of code.

Why Most Web2 Developers Get Stuck trying to build on Web3

Most Web2 developers coming into Web3 hit the same wall — and usually with very little guidance.

You start with the docs, and immediately run into a wall of jargon: nonces, calldata, account abstraction, gas estimation. Before long, you’re three hours deep in a Stack Overflow rabbit hole wondering why you didn’t just use Stripe.

This guide is for developers who already know React, Node.js, or any backend stack — but haven’t really touched Web3 beyond reading about it or seeing monkey pictures on X.

By the end of this article, you’ll have built a complete Web3 payment flow:

Social login (email / Google)
Embedded wallets (no seed phrases)
Gasless transactions
On-chain USDC payments

And you’ll do it without needing to understand zero-knowledge proofs or low-level blockchain concepts.

Everything here comes from building Zapcode — a real QR-based USDC payment system on Starknet. These are production patterns, not toy examples.

What Is Starknet (And Why It Matters)

Starknet is a Layer 2 scaling network on Ethereum.

Here’s what matters in practice:

Transactions are fast
Fees are extremely low (fractions of a cent)
Security is still backed by Ethereum

Under the hood, Starknet batches transactions and proves them on Ethereum using zero-knowledge proofs. But you don’t need to think about that.

As a developer, you can treat it like:

“Ethereum — but more advanced and more scalable.”

What Is StarkZap?

StarkZap is an SDK that sits on top of Starknet and abstracts the hardest parts of Web3 development. One command to rule them all: npm install starkzap, to install Starkzap package.

Instead of dealing with:

Raw calldata
Account deployment
Signing flows
Gas mechanics

You get simple APIs.

What StarkZap Gives You

Wallet creation — no seed phrases required
Account deployment — handled automatically
ERC20 transfers — send USDC with a clean API
Fee sponsorship — users pay zero gas via AVNU
Social login — email / Google login via Privy
Bitcoin support — via Starknet cross-chain infrastructure
Staking module — for DeFi-style apps

That last one — social login — is what changes everything.

Making Crypto Feel Like Web2: Social Login

The biggest UX problem in Web3 is wallet setup.

“Install MetaMask. Save these 12 words. Don’t lose them.”

Most users drop off right there.

Privy fixes this.

Users log in with email or Google, and a wallet is created for them behind the scenes. From their perspective, it feels like any normal app.

Here’s how we set it up:

Install privy: npm install @privy-io/react-auth

then:

// apps/frontend/src/main.tsx
import { PrivyProvider } from '@privy-io/react-auth'

<PrivyProvider
  appId={import.meta.env.VITE_PRIVY_APP_ID}
  config={{
    loginMethods: ['email', 'google'],
    appearance: { theme: 'dark' },
  }}
>
  <App />
</PrivyProvider>

That’s it.

Backend Setup (Important Gotcha)

You need two Privy clients:

Installation command: npm install @privy-io/server-auth @privy-io/node

// apps/backend/src/lib/privy.js
import { PrivyClient } from '@privy-io/server-auth'
import PrivyNode from '@privy-io/node'

export const privy = new PrivyClient(
  process.env.PRIVY_APP_ID,
  process.env.PRIVY_APP_SECRET,
)

export const privyNode = new PrivyNode({
  appId:            process.env.PRIVY_APP_ID,
  appSecret:        process.env.PRIVY_APP_SECRET,
  authorizationKey: process.env.PRIVY_AUTHORIZATION_KEY,
})

This distinction matters more than it looks:

server-auth → authentication
node → wallet operations & signing

If you mix them, things break in non-obvious ways.

Onboarding a User Wallet

When a user scans a QR code in Zapcode, we need to:

Create a wallet
Fund it (for deployment)
Deploy it on-chain
Make it usable

StarkZap handles most of this:

// apps/frontend/src/pages/PayPage.tsx
const sdk = new StarkZap({
  network: 'mainnet',
  paymaster: { nodeUrl: `${API_URL}/api/wallet/paymaster` },
})

const onboard = await sdk.onboard({
  strategy:      OnboardStrategy.Privy,
  accountPreset: accountPresets.argentXV050,
  deploy:        'if_needed',
  feeMode:       'user_pays',
  privy: {
    resolve: async () => {
      const token = await getAccessToken()
      const res   = await fetch(`${API_URL}/api/wallet/starknet`, {
        method:  'POST',
        headers: { Authorization: `Bearer ${token}` },
      })
      const { wallet: w } = await res.json()
      return {
        walletId:  w.id,
        publicKey: w.publicKey,
        serverUrl: `${API_URL}/api/wallet/sign`,
      }
    },
  },
})

The key part:

deploy: 'if_needed'

First-time users get deployed. After that, it’s invisible.

The One Catch: Account Deployment Costs

AVNU sponsors transactions — but not account deployment.

New wallets must pay a small STRK fee.

How We Solved It

We use a treasury wallet:

const BUYER_PREFUND = BigInt('300000000000000000') // 0.3 STRK

await sendStrk(wallet.address, BUYER_PREFUND, 'buyer')

This is a one-time cost per user.

After that → everything is gasless.

Sending a USDC Payment

Here’s the actual payment logic:

const tx = await walletRef.current.execute(
  [{
    contractAddress: USDC_MAINNET,
    entrypoint:      'transfer',
    calldata:        [
      merchant.walletAddress,
      String(Math.round(parsed * 1_000_000)),
      '0',
    ],
  }],
  { feeMode: 'sponsored' },
)

From the user’s perspective:

Click → Pay → Done

No gas. No wallets. No confusion.

Gasless Transactions (How It Works)

AVNU’s paymaster covers gas fees:

router.post('/paymaster', async (req, res) => {
  const response = await fetch('https://starknet.paymaster.avnu.fi', {
    method:  'POST',
    headers: {
      'Content-Type':        'application/json',
      'x-paymaster-api-key': process.env.AVNU_API_KEY,
    },
    body: JSON.stringify(req.body),
  })
  const data = await response.json()
  res.status(response.status).json(data)
})

Why This Matters

Users don’t need:

ETH
STRK
Any understanding of gas

This removes one of the biggest barriers in Web3 UX.

Server-Side Signing

router.post('/sign', async (req, res) => {
  const { walletId, hash } = req.body

  const result = await privyNode
    .wallets()
    .rawSign(walletId, { params: { hash } })

  res.json({ signature: result.signature })
})

StarkZap handles calling this automatically.

Real-World Flow (Zapcode)

Here’s what the full system looks like:

Merchant signs up → gets wallet + QR code
Buyer scans → logs in with email
Wallet created + deployed automatically
Buyer enters amount → clicks Pay
USDC transfers instantly (gasless)

All without users knowing anything about crypto.

Common Pitfalls (Learned the Hard Way)

Starknet.js v9 changed Account constructor
You must use two Privy clients
Wallet ownership depends on your authorization key One way to avoid silent errors is to use the latest versions of the packages.

Final Thoughts: Web3 Is Finally Usable

You don’t need to understand zero-knowledge proofs to build on Starknet.

You don’t need to know what account abstraction means to ship a real product.

StarkZap handles the complexity — you focus on the experience.

If you’re a Web2 developer who’s been curious about Web3 but kept bouncing off the complexity wall:

This is your way in.

The tooling is ready.

The UX is finally good enough and getting better.

You can ship real applications now in just a few lines of code. Use Starkzap.

Resources

Zapcode Live: https://zapcodex.netlify.app/
Zapcode Github: https://github.com/OkoliEvans/zapcode

StarkZap: https://github.com/keep-starknet-strange/starkzap
StarkZap sample codebases and projects: https://github.com/keep-starknet-strange/awesome-starkzap

AVNU: https://portal.avnu.fi

Privy: https://privy.io

If you build something with StarkZap, drop it below.

I’d genuinely love to see what you ship.

Understanding Digital Signatures: The Role of v, r, s in Cryptographic Security and Signature Verification.

Okoli Evans — Sun, 11 Jun 2023 20:27:41 +0000

Pre-script: This article is not intended for newbies, knowledge of Ethereum and/or solidity is presumed.

Transactions on Ethereum are signed messages originating from Externally Owned Accounts (EOAs). There are more to this simple description though, as not all of such messages are valid transactions. Valid transactions must contain these required parameters: Nonce, Recipient, Value, Data, Gas price, Gas limit, Chain Id and v, r, s, and the transaction must be signed using the EOA’s private key (and we’ll see why shortly).

Understanding the concept of digital signatures without prior understanding of the components of that signature may be a bit much for some people, so we’ll first try to explain some of these concepts (of course these concepts are well detailed in the Ethereum book).

Nonce is an acronym for Number used ONCE. It’s an integer that keeps track of the number of messages signed and transmitted from an account. It increments per transaction, and a nonce cannot be used more than once. Any transaction signed with an already used nonce is rejected by the network.

Value is the amount of ether or token forwarded with the message. Transactions containing only values are known as ‘payments’.

Data is the payload forwarded with the transaction. These are mostly function calls (payload containing function selector) directed to contract accounts, as most EOAs do not contain bytecodes and hence cannot handle such calls. Transactions containing only data are known as ‘invocations’. Aside from these, transactions can also contain both data and value, or nothing at all.

Chain ID represents the blockchain network to which the transaction is to be sent. The use of chain id means that transactions created for one blockchain cannot be valid on another blockchain. This protects transactions from replay attacks, as transactions become invalid if sent to another network. (see EIP-155 for more on this).

v, r, s are signature variables generated from EOA’s private keys and used for digital signatures creation and verification. (More on this shortly).

The Idea of Private keys and Public keys
Private keys are a secret set of randomly generated integers used in cryptography for creating public keys and signing transactions. These keys are neither required nor transmitted on Ethereum network, they are sole properties and responsibilities of EOAs, and anyone with access to them has access to all the accounts generated from that private key.

Now, how do we generate public keys from private keys? Magic.

Ethereum makes use of public key cryptography, also known as asymmetric cryptography, to create public-private key pairs. Elliptic curve cryptography (which is a form of asymmetric cryptography) is used to calculate the public key from the private key in an irreversible equation using the elliptic curve algorithm secp256k1.

Two things to bear in mind:
i) ‘A public key is a point on the elliptic curve, meaning it is a set of x and y coordinates that satisfy the elliptic curve equation’. Hence public keys are two numbers joined together, each number representing a point on the elliptic curve.

ii) The elliptic curve algorithm used to calculate these points is a one way function. In practice it is very easy to calculate the public key from a private key, but impossible to reverse the process and recover the private key that generated that public key. This means that the algorithm cannot be reversed to get a private key that generated a public key. Not even quantum computers have been able to achieve this.

Transaction serialization

Now that we understand the concept of public and private keys and how they are generated, let us go a step further to explain how transactions are serialized before they are broadcasted to the network.

Serialization is the concept of preparing signed messages for broadcast to the Ethereum network by using a particular function (algorithm) to create a particular sequence of bytes. The function used for formatting the transaction is a generally accepted standard on the network, such that transactions formatted with this standard are accepted on the blockchain irrespective of the library, language or application used by any particular node. On the Ethereum network the standard used for this purpose is the RLP encoding algorithm (the Recursive-length prefix algorithm).

Concept of Digital Signatures

Digital signatures are synonymous with traditional official signatures. It’s simply a way to authorize a transaction or message on the internet. Any signed transaction contains a digital signature, and the signature is a proof of validity of such message.

Digital signatures are very important because they provide a proof of the account where a transaction originates from (tx.origin in Solidity), and the signer of such a transaction cannot deny that the signature originated from his account. Digital signatures also provide proof that the content of a message or transaction is not tampered with, because any change in the content of the message will produce a signature entirely different from the original one.

How Digital Signatures are Created

On the lower level, digital signatures are generated from Elliptic Curve Digital Signature Algorithm ( ECDSA ), and this algorithm consists of two parts. The first part is the signature creating algorithm, while the second part is the signature verifying algorithm.

Digital signatures are created when a private key signs an already serialized transaction. Actually the serialized transaction here is the Keccak256 hash of the RLP-encoded message. The mathematical function for signing transaction is:

S i g = Fsig(Fkeccak256(m), k)
where: k = the signing private key
           m= the RLP encoded message
           Fkeccak256 = Keccak256 hash function
           Fsig = the signing algorithm
           Sig = the resulting signature

The function Fsig produces a signature (S i g) that generates the two values r and s, which are instrumental in signature verification. S i g = r, s
(more on this in the Ethereum book referenced below).

I found this explanation by Svetlin Nakov, (PhD) to be very detailed and thus helpful:

“The ECDSA signing algorithm (RFC 6979) takes as input a message msg *+ a private key privKey *and produces as output a signature, which consists of a pair of integers {r, s}.

…The calculated signature {r, s} is a pair of integers, each in the range [1...n-1]. It encodes the random point R = k * G, along with a proof s, confirming that the signer knows the message h and the private key privKey. The proof s is by idea verifiable using the corresponding pubKey.”
(See reference for more info or links ).

Signature Verification
This is handled by the second part of the ECDSA algorithm. To verify a transaction one must have the signature ( r and s ), the serialized transaction and the public key. This public key must correspond to the private key used in signing the transaction initially. The signature verification algorithm takes these listed components and returns a boolean value depending on if the signature is valid or not; true for valid signature, false for invalid. The mathematical computations and the processes involved are complex and cannot be covered in this article, but below is the summary of the verification process (again, as explained in Svetlin Nakov’s book):

i. Calculate the message hash, with the same cryptographic hash function used during the signing.

ii. Calculate the modular inverse of the signature proof, that is the inverse of signature generation function (see function above).

iii. Recover the random point, r, generated during the signing from the x-coordinate.

iv. Generate from R' its x-coordinate: r' = R'.x

v. Calculate the signature validation result by comparing whether r' == r

“The general idea of the signature verification is to recover the point R' using the public key and check whether it is the same point R, generated randomly during the signing process.”

Again, this is a simple summary of the entire concept of signature generation and verification, by Sveltin Nakov:

“The signing signing encodes a random point R (represented by its x-coordinate only) through elliptic-curve transformations using the private key privKey and the message hash h into a number s, which is the proof that the message signer knows the private key privKey. The signature {r, s} cannot reveal the private key due to the difficulty of the ECDLP problem.

The signature verification decodes the proof number s from the signature back to its original point R, using the public key pubKey and the message hash h and compares the x-coordinate of the recovered R with the r value from the signature.”

The signature is valid if the x-coordinate recovered, r’, is the same as the one randomly generated during the signing, r.

What about v?
As already explained, in public key generation using elliptic curve cryptography, two possible public keys are generated at every instance. This is because the elliptic curve algorithm is symmetry across the x-axis, so for any value of x that is generated, there are two possible values that fit the curve; one on each side of the x-axis.
Question now is, how does this algorithm pick the correct value of x to concatenate with the y value? This is where v comes in.

According to the Ethereum Yellow paper, “ v is a 1 byte value specifying the parity and finiteness of the coordinates of the curve point for which r is the x-value.”

To make it simpler, v is added to the signature verification function to help detect the correct value of r between the two possible generated values R and R’. If v is even, the R is the correct value, if v is odd, then R’.

For more clarification, this is a snippet from the Ethereum book:
“At block #2,675,000 Ethereum implemented the "Spurious Dragon" hard fork, which, among other changes, introduced a new signing scheme that includes transaction replay protection (preventing transactions meant for one network being replayed on others). This new signing scheme is specified in EIP-155. This change affects the form of the transaction and its signature, so attention must be paid to the first of the three signature variables (i.e., v), which takes one of two forms and indicates the data fields included in the transaction message being hashed.

…The special signature variable v indicates two things: the chain ID and the recovery identifier to help the ECDSArecover function check the signature. It is calculated as either one of 27 or 28, or as the chain ID doubled plus 35 or 36.

…The recovery identifier (27 or 28 in the "old-style" signatures, or 35 or 36 in the full Spurious Dragon–style transactions) is used to indicate the parity of the y component of the public key.”

The whole idea of Spurious Dragon upgrade was to mitigate the security challenges of replay attacks and signature malleability, and this was achieved by the introduction of chain ID and recovery identifier into the variable v.

ECRECOVER

ecrecover is a global function in solidity used for signature verification. It takes the massage hash and the signature verification variables v, r, s, and returns an address. The returned address can then be compared against other addresses to find a match.

address signer = ecrecover(msgHash, v, r, s);

SECURITY ALERT: The ecrecover function above is vulnerable to signature replay attack because of the reasons already explained above, so do well to avoid using it in your contracts. Openzeppelin’s ECDSA library is secure and tested for this purpose.

Conclusion

Cryptography is the backbone of blockchain technology. And a public system for value exchange and transactions such as the blockchain should be 100% secure, and should also ensure data integrity, authenticity and confidentiality.

Digital signature is an efficient way to not only keep track of transaction origins, but also to ascertain that transactions are not compromised after they are signed and transmitted. The creation and verification of digital signatures are made possible by the variables v, r, s.

If you find this article interesting, or perhaps cryptography, these resources are available for you.

Resources:
https://ethereum.stackexchange.com/questions/45461/verify-ecdsa-signature-in-solidity -> ECDSA and signature verification implementations

https://ethereum.stackexchange.com/questions/79302/why-do-we-use-serialize-function-of-ethereumjs-tx-package-before-broadcastin -> RLP encoding and tx serialization

https://ethereum.github.io/yellowpaper/paper.pdf -> Ethereum Yellow Paper

https://github.com/ethereumbook/ethereumbook/blob/develop/06transactions.asciidoc#digital-signatures -> Ethereum book: Digital Signatures

https://cryptobook.nakov.com/digital-signatures/ecdsa-sign-verify-messages -> Sveltin Nakov: Digital signatures

https://medium.com/cryptronics/signature-replay-vulnerabilities-in-smart-contracts-3b6f7596df57 -> Signature Vulnerabilities

Ethereum as a Global State Machine.

Okoli Evans — Sat, 28 Jan 2023 18:01:05 +0000

Right from inception, the Ethereum project was clearly spelled out in a well prepared document called Ethereum whitepaper. Ethereum has always been developed, tweaked and updated to meet the goal that is the Ethereum project.

What is the Ethereum project? A short summary to this question is that Ethereum was born to be a global state machine that is truly decentralized.

The word global here is pretty self-explanatory... leaving us with state machine.

A global state machine is a globally distributed system that achieves and maintains one outcome or result simultaneously across its entire network. State here refers to the current result at that instant. On a state machine, the outcome is always the same across the entire system or networks, or in the case of Ethereum, nodes.

Now, maintaining a state on a distributed network implies that there is a mechanism to track the change in state in real time across the entire network; this also implies that the entire distributed networks when given a set of code must arrive at the same result after executing the program.

So how do we track state transitions across a global network of computers? It gets tricky... to ensure that Ethereum network is deterministic, all the nodes(computers) across the world that powers the Ethereum blockchain must run an Ethereum compliant program called client.

An Ethereum client must not necessary be written in a particular programming language, but it must be written according to the specifications provided in the Ethereum yellow paper (different from Ethereum white paper).
Those programs written according to the Ethereum specifications are called Ethereum clients.

Ethereum clients, when installed and ran on a computer connects that computer to the Ethereum blockchain network.
Anybody can download any of these clients and install on their system and become an Ethereum node.

Once such system successfully connects to the Ethereum blockchain network, it will download past records of the transactions recorded on the network... afterwards it will become a fullnode; and a validator if the owner meets the preset requirements.

Ethereum is not just distributed, it is also decentralized. That is why it depends on independent computers across the world to run the network. No single computer has a control over what happens on the network, decisions are collectively made by the majority of all the computers on the network. The process by which this democracy is achieved on the network is overseen by an algorithm known as 'consensus mechanism'.

PS: This is still pretty high level; no very technical stuff yet. Anyone can easily understand even without any prior knowledge of blockchain network. If you are intrigued by what you read, feel free to dive down the rabbit hole; simply type in 'what is blockchain technology' on Google and take it on from there. Cheerio.

programming #blockchain #Ethereum #ethereumblockchain

Err: fetching data via API works on localhost but doesn't work on live server

Okoli Evans — Wed, 07 Sep 2022 05:34:55 +0000

As a young developer, there are some minor bugs you might encounter that will be pretty confusing. Every new developer, and even experienced devs encounter this every now and then. The thing about software development is that a single comma, semicolon or colon in a wrong place will likely make your code not compile, or render an element or function undefined.

When I started out newly, I once spent two days searching for a bug, only to find out that the issue was just a '}' in a wrong place... bugs are completely normal.

So I was working on a demo movie app some time ago, it happened that the API fetch and every components worked perfectly on localhost, but wasn't fetching when deployed on live server. It was really confusing for me then that I had to abandon the project altogether. Recently I was going through my repositories and found the abandoned project, so I decided to try and fix it.

Issue:

const handleSubmit = async () => { setLoading(true); const response = await fetch( `http://www.omdbapi.com/?s=${searchParam}&apikey=70c11897` ); const data = await response.json(); console.log(data); if (data) { setMovieList(data.Search); localStorage.setItem("movieList", JSON.stringify(data.Search)); setLoading(false); setSearchParam(""); } };

It turned out that the problem was a very simple one. The API URL I was using was 'http://apiurl.com/key'. Now the problem is most web engines don't render insecure links, so my API URL was blocked from fetching data on live server. The simplest solution right? All I needed to do was add 's' to the 'http' like so 'https://apiurl.com/key'.

Fixed:

const handleSubmit = async () => { setLoading(true); const response = await fetch( `https://www.omdbapi.com/?s=${searchParam}&apikey=70c11897` ); //notice the 's' now added to 'http' const data = await response.json(); console.log(data); if (data) { setMovieList(data.Search); localStorage.setItem("movieList", JSON.stringify(data.Search)); setLoading(false); setSearchParam(""); } };

Like I said, some bugs can be pretty confusing for beginners, but hey, even the best developers were once beginners and coding is one skill that requires tenacity, determination and resourcefulness. So when you encounter a bug, seek for solution on open source websites or ask experienced devs for help. I hope this helps someone. ☺