Not because Farcaster wasn’t building. Not because the idea was bad.

It’s just that crypto social is HARD, and Farcaster reached that point where the vision and the reality start fighting each other.

And now Neynar is taking over.

The crazy part is… Farcaster started super pure.

Dan left Coinbase with this one strong thought: “Why does my entire online identity depend on one app’s mood?”

One algorithm tweak, one random ban, one policy change… and boom, you’re done.

So the whole Farcaster pitch was basically:

• you own your identity

• you own your followers

• apps can change, but you don’t disappear

And honestly, that idea still slaps.

He teams up with Varun, they build it on Ethereum (later Optimism), and it feels like: “Okay… this might actually be the future of social.”

2022 - 23 Farcaster was crazy.

Not big. Not loud. But clean.

They raised $30M in seed funding with a16z, and Warpcast became the main app; the community was small but solid.

You’d open the app, and it didn’t feel like a warzone.

No constant spam. No bots screaming “gm” under every post. No engagement farming Olympics.

It was just builders, founders, nerds, and actual conversations. 2023 was more of that. Slow growth, but the vibe stayed good.

Then 2024 happened… and that’s where the pressure entered the chat.

$150M Series A led by Paradigm. $1B valuation.

And once you hit that number, you’re not allowed to be “a cool niche app” anymore.

Now everyone expects you to become the next global social network overnight. Which is insane, because social networks aren’t built like that.

They’re not like DeFi protocols where you ship and liquidity comes.

Social is messy. People are messy.

But to be fair, Farcaster did drop something genuinely exciting that year: Frames. (Later called Mini Apps.) That was the moment where even haters were like: “Okay, wait… this is different.”

Because suddenly, you weren’t just posting content, you could do stuff inside the post.

Mint. Trade. Claim. Sign. Whatever.

It felt like the beginning of a whole new internet.

And then 2025 was basically: “this is why we can’t have nice things.”

This is where it started going downhill.

> DAUs dropped like ~40%.

> Revenue dropped like ~85%.

> Spam increased. Bots increased.

> Frames started getting abused.

And then the social politics started:

Power badges drama. Channel name confiscations. Endless arguing.

It started feeling like Farcaster was slowly turning into the same thing it was trying to escape.

Not fully, but enough that you could feel it. And honestly… this is normal. Any open system that gets attention eventually gets farmed.

It’s like gravity.

Clanker was the one “W” that actually mattered.

Clanker was the moment that make it interesting. In October 2025, Farcaster acquired Clanker basically a social trading protocol that let people trade straight from the feed, in a super native way.

And it wasn’t just “cool tech.” It was working.

Clanker reportedly generated $50M+ in fees, which is not “nice traction” that’s real usage with real money behind it.

That move made me think: maybe Farcaster doesn’t win by becoming the next Twitter. Maybe it wins by becoming the place where onchain apps get distribution through social.

Because Clanker wasn’t just content. It was economic behavior happening socially and that’s where Farcaster is naturally strong.

But even then… the big picture didn’t change.

Growth slowed. Costs stayed high. And expectations were still insane because of the $1B narrative.

And this is the part people don’t say out loud:

Farcaster didn’t have a “product problem.” It had an expectation problem.

Everyone wanted it to become Twitter.

But Farcaster was never built like Twitter.

It’s built like infrastructure.

Then boom: January 21, 2026.

Neynar acquires Farcaster.

Valuation isn’t publicly confirmed, but it’s rumored to be close to $1B.

Dan and Varun step back from day to day operations.

And the announcement is basically: “Nothing changes immediately. App works. Clanker works. But Neynar is taking over the contracts, repos, dev calls, everything.”

Which tells you this isn’t a shutdown. This is a handoff.

Like “you drive now.”

And honestly? Neynar taking over makes sense.

Because Neynar isn’t some random buyer.

They’ve been in the Farcaster ecosystem from day one.

They were one of the earliest clients, and their infra literally powers a huge part of the developer ecosystem already.

So it’s not like Farcaster got sold to a stranger.

It got handed to the team that was already holding the plumbing.

My take: Farcaster was always infrastructure pretending to be a social app.

This is the real thing.

Farcaster tried to be two things at the same time:

1. a consumer social app (Warpcast as the destination)

2. a protocol (the layer apps build on)

And the market judged it like it was #1.

But all the actual wins came from #2.

Frames. Mini apps. Clanker. Onchain actions. Developer ecosystem.

That’s infrastructure behavior.

Not “we’re competing with Instagram” behavior.

So this acquisition feels like Farcaster finally admitting: “Yeah… we’re not going to brute force mainstream social.”

“We’re going to become the base layer.”

So what happens now?

The question isn’t “can Farcaster survive?”

It’s: Can Neynar make Farcaster feel good again, without ruining what makes it open?

Because if they execute properly, Farcaster becomes:

• the default social graph for crypto

• the place where mini apps actually thrive

• the layer where social + transactions become normal

• the onchain distribution engine

And that’s a huge win.

Not flashy like “we beat X.” But way more real.

Summary

Farcaster didn’t die. It just stopped pretending.

Now it gets to become what it always was underneath: infrastructure with a social feed on top.

Let’s see if Neynar can turn that into actual market fit.

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

But InfoFi isn’t dead, it’s evolving (and that’s a good thing)

The idea was simple and powerful: If information moves markets, then people who generate high-quality information should be rewarded. Not just influencers with reach but researchers, analysts, builders, and early signal-spotters who consistently add real value.

And honestly, that vision still makes sense.

But what’s changed is this: the first wave of InfoFi wasn’t the final form. A lot of it was experimental, messy, and sometimes misunderstood. So instead of saying “InfoFi is dead,” the more accurate take is:

InfoFi is growing up. The hype phase is fading, and the useful parts are starting to stay.

What InfoFi was trying to solve

Crypto runs on information:

• Narratives move liquidity

• Research influences conviction

• Signals decide entries and exits

• Community sentiment drives momentum

• Timing matters more than most people admit

Yet most of the value created by information has traditionally been captured by:

• Platforms (social media)

• Insiders (private groups)

• Exchanges (flow)

• Loud accounts (distribution)

InfoFi aimed to rebalance that.

The goal wasn’t “financialize tweets.” It was to create a world where: Good information becomes a real economic layer.

Why the first wave struggled

InfoFi faced a few natural challenges, not because it was a bad idea, but because the space is hard.

1) Quality is difficult to measure Information isn’t like a token with a clear price. A research post can stay valuable for weeks or become outdated within hours. Sometimes it’s “right” but too early, and sometimes it’s “wrong” but sparks a useful insight.

So building a fair system that rewards quality (not just popularity) is genuinely complex.

2) Incentives shape behavior Whenever rewards exist, people adapt. That’s not always bad, it’s just reality.

If a platform rewards:

• speed → you’ll get faster posting

• engagement → you’ll get more viral

• confidence → you’ll get stronger opinions

That doesn’t mean InfoFi can’t work. It just means the incentive design matters more than the branding.

3) “Alpha” has a sharing problem Some information loses value the moment it becomes public. That’s not manipulation, it’s just how markets work.

So the best InfoFi systems should support flexible distribution from public posts to gated access so creators can share insights responsibly without assuming every edge must be broadcast instantly.

This keeps your point without making InfoFi sound like “private groups 2.0

What InfoFi got right

Even with the early bumps, InfoFi introduced some important shifts:

Creators started thinking like operators Instead of “posting for clout,” more people began building:

• Research brands

• Signal products

• Gated communities

• Dashboards

• Onchain analytics services

Markets started valuing signal density People are tired of noise. The demand for “less talk, more signal” is real, and InfoFi helped push that forward.

Crypto began experimenting with reputation as an asset Not perfect yet, but important. Over time, credibility will become measurable through:

• Historical accuracy

• Transparent track records

• Onchain activity

• Verifiable credentials

That’s a big step for the space.

What InfoFi is becoming (the next phase)

Instead of “InfoFi is dead,” it’s better to say: InfoFi is moving from hype → infrastructure.

Here’s what the next version looks like:

1) Proof-based information The future isn’t “trust me.” It’s “verify this.”

Info tied to:

• Onchain data

• Reproducible analysis

• Backtesting

• Open methodology

wins long term.

2) Public-first, with premium layers

Not everything needs to be fully public immediately but InfoFi wins when the public layer gets smarter.

The strongest systems will combine:

• open research that improves public signal quality

• optional premium access for deeper or time-sensitive insights

• credibility that compounds through transparency over time

The goal isn’t to hide information. It’s to reward real work while keeping public markets healthier.

3) Outcome linked incentives Instead of rewarding posts, systems will reward results:

• prediction accuracy over time

• performance of a strategy

• usefulness measured through outcomes

• verifiable contributions

That’s how you avoid “engagement farming.”

4) AI-native signal generation Humans won’t just sell opinions. They’ll sell systems: agents that scan, filter, and execute based on rules.

So the value shifts from: “Who posted first?” to “Who built the best engine?”

The real conclusion : InfoFi isn’t disappearing.

It’s just leaving the “everything is a narrative” phase and entering the “signal + verification” phase.

The first wave proved something important: People want better information markets.

The next wave will make them more sustainable by improving:

• incentive design

• reputation systems

• distribution models

• and verification primitives

So no, InfoFi isn’t dead. It’s becoming real.

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Most of us assume “secure computing” means strong passwords, encrypted disks, and locked-down cloud servers. But in reality, the biggest weakness isn’t always the app you’re using, it’s the layer underneath it. Operating systems get compromised. Admin accounts get abused. Cloud workloads get inspected. Logs get copied. Memory gets scraped.

So the real question becomes: What happens when the system you’re running on can’t be trusted?

That’s the exact gap a Trusted Execution Environment (TEE) is designed to close.

What is a Trusted Execution Environment (TEE)?

A Trusted Execution Environment is a secure, isolated zone inside modern CPUs from Intel, AMD, and ARM where sensitive code and data can run in a protected “bubble,” even if the rest of the machine is compromised.

Think of it as a private room inside your processor.

Even if malware gains full control of the operating system, even if someone gets root access, even if the cloud host is malicious, the TEE is built to ensure the execution inside is hidden and tamper resistant.

This is what makes TEEs different from traditional security tools.

Encryption protects data at rest (on disk) and in transit (over the network). But TEEs protect data in use, while it’s actively being processed, the moment when most attacks succeed.

Why TEEs matter: the “in use” privacy problem

Here’s the uncomfortable truth about normal computing:

To compute the data, the system has to decrypt it.

And once it’s decrypted in memory, anyone with enough access (or the right exploit) can potentially read it. That includes:

• Compromised OS or kernel-level malware

• Malicious or careless administrators

• Hypervisor attacks in shared cloud environments

• Debug tools, memory dumps, and logging pipelines

• Insider threats at infrastructure providers

This is why privacy in cloud computing often depends on trust: trust the provider, trust the admins, trust the machine.

TEEs flip that model.

They make privacy enforceable by hardware, not dependent on good behavior.

What happens inside a TEE?

Inside a Trusted Execution Environment:

1) Data decrypts only while being used
Your sensitive inputs are decrypted only inside the secure boundary. Outside the TEE, they remain encrypted.

2) Code executes in a hardware-locked bubble
The CPU enforces isolation so the workload can run without interference from the OS or other processes.

3) Everything re-encrypts before leaving
When results move out of the TEE, they can be encrypted again so the rest of the system only sees protected outputs.

4) Even root access can’t peek inside
This is the key point: TEEs are designed so even the highest-privilege software on the machine cannot inspect what’s happening inside the enclave.

That means a compromised operating system doesn’t automatically mean compromised secrets.

The real superpower: Remote Attestation

One of the most important features TEEs enable is remote attestation.

Attestation allows a TEE to prove to an external party:

• What code is running inside?

• that it hasn’t been altered or tampered with

• that it’s executing inside a real, hardware backed secure enclave

So instead of trusting a cloud server, you can verify it cryptographically.

This brings you closer to trust-minimized compute not perfectly trustless, but significantly stronger than traditional models.

What TEEs unlock in the real world

TEEs aren’t theoretical. They’re already being used to power some of the most important privacy-first systems today.

1) Private AI and confidential inference

AI is hungry for data, and that data is often sensitive: medical records, financial histories, internal business documents, private chats.

TEEs allow models to run inference on sensitive inputs while keeping the data hidden from the host machine. That means:

• Prompts are protected from host access

• Companies can process confidential datasets

• AI workloads can run without exposing raw inputs

This is a major step toward privacy-preserving AI without needing to fully redesign ML infrastructure.

2) Secure agents and autonomous workflows

AI agents are becoming more powerful and more dangerous if compromised.

Agents handle:

• API keys

• signing credentials

• user permissions

• private decision-making logic

• transaction execution

Running agent logic inside a TEE helps ensure the agent’s secrets and actions can’t be hijacked by a compromised environment.

This matters for onchain agents, DeFi automation, trading systems, and enterprise copilots.

3) Confidential transactions and protected signing

Crypto security often comes down to one thing: key safety.

TEEs can isolate signing operations, so private keys never leak into the broader system. This supports:

• secure transaction signing

• confidential execution for certain onchain operations

• reduced risk of key exfiltration

It’s not a replacement for hardware wallets in every case, but it’s a powerful option for scalable systems that require automation.

4) Privacy-first cloud computing

Most cloud computing is built on trust: trust the cloud provider, trust the region, trust the administrators.

TEEs make it possible to run workloads where even the cloud provider can’t easily inspect the contents.

That’s huge for:

• regulated industries

• sensitive enterprise workloads

• data collaboration across organizations

• confidential analytics

TEEs vs “just trust us” security

A lot of security products rely on policies, permissions, and access control. Those are useful, but they’re still enforced by software.

TEEs change the enforcement layer.

They don’t just say “admins shouldn’t access this.”
They say: even if they try, the hardware won’t allow it.

That’s why TEEs represent a shift from trust-based security to hardware-enforced privacy.

Where you can deploy TEEs today

TEEs are already available across major infrastructure providers and confidential compute ecosystems.

You can deploy TEE-backed workloads today using:

• AWS

• Google Cloud

• Microsoft Azure

• Phala Network

• EigenCloud

• Super Protocol

This makes it easier than ever to start building private-by-default applications without waiting for “future cryptography” to mature.

The bottom line

A Trusted Execution Environment is one of the most practical privacy breakthroughs in modern computing.

It creates a secure zone inside the CPU where sensitive code and data can run, protected even if the operating system is compromised, even if root access is abused, even if the infrastructure host is untrusted.

In a world where AI is everywhere, agents are executing actions autonomously, and cloud computing runs critical systems, TEEs give us something we’ve been missing for a long time: real privacy for computation enforced by hardware, not trust.

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

This limitation isn’t about intelligence, it's about infrastructure.

For AI agents to become truly autonomous, they need two things: a common way to talk to each other, and a native way to pay for services when value is exchanged. That’s where A2A and x402 come in.

The Structural Problem with Today’s AI Systems

Most AI agents are built to serve a single application or user. Even when multiple agents exist, they are typically connected through custom integrations or centralized platforms. If one agent wants data or computation from another, developers must hardcode the interaction, manage authentication, and handle payments off-chain.

This approach doesn’t scale. It prevents agents from dynamically discovering services, negotiating access, or acting independently in real time. In practice, agents remain sophisticated tools rather than autonomous actors.

What’s missing is a shared, open standard, something equivalent to what HTTP did for the web.

A2A: A Communication Layer for Agents

A2A, or Agent-to-Agent communication, introduces that missing layer. It defines a common way for agents to discover one another, send requests, and exchange structured responses, regardless of who built them or where they run.

In an A2A world, an agent doesn’t need to know in advance which other agent provides a service. It can simply ask. One agent might request weather data, another might ask for analytics, and a third might seek specialized computation. Each interaction follows a shared protocol, making agent collaboration as natural as application-to-application communication on the internet.

But communication alone doesn’t create autonomy. If every paid interaction still requires human approval or centralized billing, agents remain dependent on external systems.

Why Autonomous Agents Need Native Payments

Real services have real costs. Computation, data access, and intelligence aren’t free. For agents to operate independently, they need a way to handle payments programmatically, without breaking the flow of execution.

This is where x402 Protocol becomes critical.

Instead of treating payment as an exception or failure, x402 reframes it as part of the protocol itself. When an agent requests a service that isn’t free, the responding agent doesn’t reject the request. Instead, it returns a structured “402 Payment Required” response containing everything needed to complete the transaction.

That response includes the price, the settlement method, and the on-chain details required for payment. The requesting agent can then evaluate whether the service is worth the cost, sign a transaction, and settle it autonomously. Once payment is complete, the service is delivered all without human intervention.

A Shift in How We Think About Automation

Together, A2A and x402 represent more than technical upgrades. They introduce a new way of thinking about automation itself.

A2A x402 to allow them to communicate in an open, interoperable environment. x402 to allow them to transact and assign economic value to services. When combined, they turn agents into participants in an economy rather than passive executors of instructions.

This moves us away from rigid, preconfigured workflows and toward dynamic systems where agents can discover services, compare costs, and make decisions in real time.

From Isolated Agents to Machine Economies

Once agents can both communicate and pay, entirely new structures become possible. Networks of agents can form markets for data, computation, and intelligence. Specialized agents can monetize their capabilities directly. Demand and supply can emerge organically between machines, governed by protocols instead of platforms.

This is what a true machine-to-machine economy looks like: autonomous, programmable, and open. There’s no central coordinator deciding who can participate. Any agent that follows the standards can join, offer services, and get paid.

Why This Matters Now

As AI becomes more capable, the risk isn’t that agents will be too powerful, it’s that they’ll remain trapped inside centralized systems. Without open communication and native payment rails, we’ll simply recreate today’s platforms with smarter automation on top.

A2A and x402 point toward a different future. One where intelligence is composable, services are discoverable, and value flows directly between machines. Just as the internet unlocked global information exchange, these protocols lay the groundwork for autonomous economic coordination between AI systems.

When agents can finally talk and pay intelligence stops being isolated. It becomes economic. And that’s the foundation for the next era of AI.

Resources & Links

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Most digital systems verify things by asking for data.

To prove your age, you reveal your date of birth.
To prove your identity, you upload documents.
To prove a transaction is valid, you expose balances, inputs, and execution details.

This model works, but it comes with a structural flaw: verification is tightly coupled with disclosure. Data is collected even when it is not strictly necessary, stored longer than intended, and often reused or correlated in ways users never agreed to.

On public blockchains, this problem becomes even more visible. Transparency enables trustless verification, but it also makes privacy difficult to preserve as applications grow more complex.

Zero-knowledge proofs exist because this trade-off is not fundamental.

What Is a Zero-Knowledge Proof?

A zero-knowledge proof (ZKP) is a cryptographic protocol that allows one party, called the prover, to convince another party, called the verifier, that a statement is true without revealing any information beyond the truth of that statement.

The verifier does not learn the data, the inputs, or the method used to reach the result. They learn only that the claim is valid.

This concept was formalized in the mid-1980s by cryptographers Shafi Goldwasser, Silvio Micali, and Charles Rackoff. For many years, it remained mostly theoretical. Advances in cryptography and computing have since made it practical for real-world systems.

How Zero-Knowledge Proofs Work

At a high level, zero-knowledge proofs rely on the idea that some challenges can only be answered correctly by someone who truly knows the secret information.

If the prover is guessing, they might succeed once by chance. But as the verifier repeats randomized challenges, the probability of cheating successfully becomes vanishingly small. After enough repetitions, the verifier becomes confident that the prover has real knowledge without ever seeing the secret itself.

In real systems, this logic is implemented using cryptographic circuits. A circuit takes private inputs, applies a series of constraints, and produces an output. A zero-knowledge proof demonstrates that the prover knows inputs that satisfy all constraints, without revealing the inputs themselves.

The Guarantees That Define Zero-Knowledge

Every zero-knowledge proof satisfies three formal properties.

If the statement is true, an honest prover can always convince an honest verifier. If the statement is false, no dishonest prover can reliably convince the verifier. And if the statement is true, the verifier learns nothing beyond that fact.

These guarantees are mathematical. They do not depend on trust, incentives, or institutional control.

Interactive and Non-Interactive Proofs

Early zero-knowledge protocols were interactive, requiring multiple rounds of communication between the prover and verifier. While sound, this approach does not scale well in distributed environments.

Modern systems rely on non-interactive zero-knowledge proofs, where the prover generates a single proof that can be verified by anyone. This is essential for blockchains and decentralized systems, where proofs must be reusable and independently verifiable.

Major Families of Zero-Knowledge Proof Systems

Different ZKP constructions optimize for different trade-offs.

• zk-SNARKs produce very small proofs that are fast to verify, making them efficient for on-chain verification. Their main trade-off is the need for a trusted setup phase.

• zk-STARKs remove the need for a trusted setup and rely on hash-based cryptography. They offer stronger transparency and better assumptions against future quantum attacks, but produce larger proofs.

• PLONK-style systems introduce universal setups that can be reused across many programs, improving flexibility and developer experience.

Bulletproofs are non-interactive proofs that require no trusted setup and are commonly used for confidential transactions.

Each system represents a different balance between efficiency, transparency, and security.

Why Zero-Knowledge Proofs Matter for Blockchains

Public blockchains are transparent by design. Every transaction, balance, and state transition is visible.

This transparency enables trustless verification, but it also introduces privacy. Execution paths become public, user behavior becomes linkable, and every node must re-execute every computation.

Zero-knowledge proofs offer a different model. Instead of publishing execution, systems publish proofs of correctness. Instead of replaying computation, verifiers check succinct cryptographic evidence. Instead of exposing data, users reveal only the facts that matter.

This is why zero-knowledge proofs are foundational to private transactions, scalable layer-2 systems, verifiable off-chain computation, and decentralized identity.

Recent Advances in Zero-Knowledge Proofs

Zero-knowledge proofs are no longer a niche technique. Recent progress has significantly expanded their scope.

Recursive proofs allow proofs to verify other proofs, enabling large-scale aggregation. Zero-knowledge virtual machines make it possible to run general programs inside proof systems without designing custom circuits for each application. Ongoing research focuses on reducing prover costs, improving performance, and strengthening long-term security assumptions.

What was once theoretical is now becoming core infrastructure.

From Disclosure to Verification

Zero-knowledge proofs change how systems establish trust.

Instead of asking, “Can you show me the data?”
They ask, “Can you prove this is true?”

That shift from disclosure to verification is one of the most important ideas in modern cryptography. As digital systems continue to scale, zero-knowledge proofs offer a way to preserve correctness, trust, and privacy at the same time.

Resources & Links

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

If you’re new to blockchain, one of the first things you’ll hear is that everything is transparent. Transactions are public. Balances are visible. Contract interactions can be inspected by anyone.

This transparency is not a flaw, it’s the reason blockchains work in the first place. It makes systems auditable, reduces blind trust, and allows independent verification instead of relying on intermediaries.

However, as blockchains move from simple value transfers to more complex applications, transparency alone starts to show its limits. Not because transparency is wrong but because it isn’t sufficient for every kind of computation.

What “Transparent by Design” Actually Means

On most public blockchains today, the ledger is globally shared. Every transaction, state update, and contract execution is written to a public record.

While users interact through addresses rather than names, real-world usage patterns often make those addresses linkable over time. Transaction histories can be analyzed, behaviors inferred, and relationships reconstructed even without explicit identity data.

More importantly, smart contracts don’t just store outcomes; they expose execution paths. The logic, inputs, and state transitions required to reach a result are visible because they must be validated by the network.

This is an intentional design choice and a powerful one. But it also means developers need to be deliberate about what logic belongs on a fully transparent execution layer.

Why “Just Encrypt It” Doesn’t Fully Solve the Problem

A common first instinct is to encrypt sensitive data before writing it to the chain. But encryption alone doesn’t solve the core issue.

Blockchains don’t just store data. They execute logic. And data used in this execution process are made public. Inputs, outputs, and state transitions often reveal more than intended, even if raw values are hidden.

What most applications need is not secrecy for secrecy’s sake. They need verifiability without disclosure. They need to prove that something happened correctly without showing everything that happened.

This is where the idea of a privacy layer becomes unavoidable.

Privacy as a Complement, Not a Replacement

As blockchain adoption expands into areas like finance, identity, and enterprise workflows, privacy requirements become more nuanced.

In many cases:

• Regulators need auditability

• Users need confidentiality

• Businesses need assurances without exposing proprietary logic

This isn’t about hiding information from everyone, it’s about selective visibility. Transparency where it’s required, privacy where it’s justified.

That’s why privacy is no longer treated as an optional add-on. It’s increasingly viewed as a complementary layer that enables broader classes of applications without compromising the core principles of blockchains.

How Modern Blockchains Approach Privacy

Instead of trying to hide everything, modern privacy-focused systems separate two concerns.

The first is public verification. The network still needs to be able to verify that rules were followed and that state transitions are valid.

The second is private execution. The actual data and logic that led to those transitions don’t need to be exposed to everyone.

This separation is what technologies like zero-knowledge proofs enable. They allow a system to say, “this computation was done correctly,” without revealing the inputs, intermediate steps, or full history behind it.

From a developer’s point of view, you can think of this as moving sensitive logic off the public surface, while still anchoring trust and settlement on a shared chain.

Enter Miden

One concrete example of this approach is Miden.

@0xMiden is a privacy chain that executes programs on a user’s device and then posts compact cryptographic proofs onchain. Instead of exposing every state change, it proves that the correct rules were applied.

What makes Miden particularly interesting is that it doesn’t treat privacy as an afterthought. Privacy is part of how execution works, not something bolted on at the edges.

Thinking Differently About Transactions

Most blockchains move assets by directly updating account balances. If Alice sends tokens to Bob, Alice’s balance goes down, and Bob’s balance goes up. That change is visible to the entire network.

Miden uses a different mental model based on notes.

A note is best thought of as a sealed envelope. Alice creates a note that contains assets and specifies who is allowed to open it. The note itself can be posted publicly, but only the intended recipient can consume it.

When Bob consumes the note, the assets move into his vault, and the note is invalidated. The important part is that Alice’s transaction and Bob’s transaction are not directly linked in a way that reveals a clear transfer graph.

This two-step process improves privacy and scalability at the same time. Transfers can happen in parallel, and observers can’t trivially reconstruct who paid whom.

Why This Matters for Developers

If you’re coming from traditional backend development, this model should feel familiar in spirit.

When a payment API confirms that a transaction succeeded, it doesn’t expose the internal database writes, fraud checks, or reconciliation steps. It returns a verifiable outcome, not the internal machinery.

Privacy-focused rollups apply a similar principle. The chain verifies correctness, but doesn’t need to see every internal detail that led to that result.

This doesn’t make blockchain “simple” or “familiar” ; privacy preserving execution is still an evolving and complex area. But it offers a clearer mental model for building applications that respect real-world constraints.

Building Something Simple, Privately

A good way to understand this model is by building a small stateful application, like a counter.

The counter’s value updates privately, but the network can still verify that increments happened correctly. You don’t need to reveal the full history of interactions. You just prove that the rules were followed.

Once you grasp this pattern, extending it becomes natural. User-specific state, role-based access, and complex workflows all fit into the same mental model.

At that point, Privacy in Blockchain is still a strange world, it’s not battle tested yet.

Where This All Leads

Privacy-preserving execution environments unlock entire categories of applications that struggle on transparent chains alone.

Confidential DeFi systems where balances and positions aren’t public. Identity systems where credentials are proven without being exposed. Enterprise workflows where internal logic stays internal, but outcomes are verifiable. Games where fairness can be proven without revealing the hidden state.

In all of these cases, privacy is not about obscuring behavior or avoiding accountability. It is about enabling verifiable interactions while preserving contextual confidentiality a requirement that many real-world systems already operate under.

The Bigger Picture

Blockchain transparency addressed the problem of trust between unknown parties. Privacy addresses a different, equally important dimension: control over information disclosure during verification.

Architectures like Miden demonstrate that verifiability and confidentiality are not mutually exclusive. With the right execution model, systems can preserve public correctness guarantees while minimizing unnecessary data exposure.

For developers exploring blockchain today, this shift is fundamental. The future isn’t simply about placing more logic on-chain it’s about making deliberate choices around what must be public, what can remain private, and enforcing that boundary through cryptography rather than policy.

Seen this way, privacy doesn’t replace existing blockchain infrastructure or diminish its sophistication. It extends it allowing already powerful systems to support a broader range of applications under real-world constraints.

Resources & Links

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Miden :

Miden

Practical privacy for the future of finance.

https://miden.xyz

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Prediction Markets Ask One Simple Question: Do you believe it enough to pay for it?

Spend a few minutes online and you’ll see endless certainty. People confidently predict elections, markets, launches, prices, and world events that haven’t happened yet. Most of these claims are emotional, loud, and completely free to make.

That’s exactly why they’re often wrong.

Prediction markets exist to change this dynamic by introducing something missing from online discourse: cost.

Once confidence has a price, behavior changes.

What prediction markets actually are

A prediction market lets people trade on the outcome of future events.

Instead of posting opinions, participants buy and sell shares tied to specific outcomes. If a market asks whether an event will happen, a “Yes” share might trade at $0.70. That price implies a 70% probability. If the event happens, the share pays out $1. If it doesn’t, it pays out nothing.

You’re not predicting prices or timing markets.
You’re pricing likelihood.

The market price becomes a real time signal of collective belief.

Why people mistake them for gambling

Because money is involved, prediction markets often get dismissed as gambling. But the similarity ends at risk.

Gambling is driven by randomness and entertainment. Prediction markets are driven by information and incentives.

As Vitalik Buterin has said, prediction markets are social epistemic tools. They force beliefs to compete under real consequences. Luck dominates casinos. Accuracy dominates prediction markets.

- If you’re consistently wrong, you lose.
- If you’re consistently right, you compound.

The real problem prediction markets solve

On social media, there is no penalty for being wrong. Anyone can push a confident narrative, collect engagement, and disappear when reality contradicts them.

Prediction markets flip that incentive structure.

- Strong beliefs must be backed
- Wrong beliefs lose money
- Right beliefs earn it

Over time, weak opinions get filtered out. Participants research more, exaggerate less, and update their views faster. The output isn’t certainty, it’s better probability estimates.

Something feeds and algorithms have never figured out how to do.

This isn’t niche anymore

Prediction markets have grown rapidly over the last year.

• Total value locked has climbed from tens of millions to hundreds of millions of dollars

• Monthly trading volume now reaches into the tens of billions

• Estimated total annual volume for 2025 is around $44B

This level of growth only happens when a product solves a real coordination problem.

How the major platforms differ

The core idea is the same, but each platform explores a different design space.

Polymarket

Polymarket is the most liquid and culturally relevant prediction market today. It focuses on a wide range of markets across politics, crypto, technology, and global events. Because it’s crypto native and permissionless, markets form quickly around emerging narratives. Its strength lies in fast price discovery and deep liquidity, making it a real-time signal for internet native events.

Kalshi

Kalshi operates under full U.S. regulatory approval, which changes the audience entirely. It enables institutions, hedge funds, and traditional traders to participate legally. Markets are more structured and conservative, but the credibility and regulatory clarity make Kalshi’s probabilities especially influential in policy, macro, and institutional contexts.

Limitless

Limitless focuses on ultra short term markets that resolve in minutes or hours rather than weeks or months. This compresses feedback loops and rewards fast, accurate information processing. It’s less about long-term forecasting and more about real-time belief expression, making it closer to an information reflex than a forecasting instrument.

Each platform is experimenting with the same question:
 How do we price truth more efficiently?

Why prediction markets matter beyond trading

Prediction markets are increasingly used as an information layer.

Founders track them to gauge product launches. Traders use them to assess macro and political risk. Researchers and institutions reference them as live sentiment indicators.

When opinions become tradable and probabilities become public, belief stops being abstract. It becomes measurable.

The challenges are real, but solvable

Prediction markets still struggle with ambiguous questions, oracle design, and dispute resolution. Poorly worded markets can lead to confusion or manipulation.

These are design problems, not structural failures. As platforms mature, clearer standards, better governance, and improved resolution mechanisms continue to raise reliability.

The bigger picture

Prediction markets don’t tell you what to think.

They show you what people actually believe and how much it costs them to believe it.

In a world flooded with free opinions, that signal matters.

Prediction markets aren’t gambling.
They’re what happens when belief finally has a price.

Resources & Links

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Kalshi :

Kalshi - Prediction Market for Trading the Future

Kalshi is a regulated exchange & prediction market where you can trade on the outcome of real-world events. Buy and sell Event Contracts.

https://kalshi.com

Polymarket :

Polymarket | The World's Largest Prediction Market

Polymarket is the world's largest prediction market, allowing you to stay informed and profit from your knowledge by betting on future events across various topics.

https://polymarket.com

Limitless :

Limitless Exchange

Forecast the future on Limitless, financial prediction market

https://limitless.exchange

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

For perspective, PayPal processed roughly $1.7 trillion in the same period, while Visa processed about $16 trillion. Stablecoins now sit directly between them. What was once dismissed as crypto’s most boring category has quietly become one of the largest payment networks on Earth.

This didn’t happen by accident.

Why Stablecoins Won by Being Boring

Stablecoins didn’t succeed because they were exciting. They succeeded because they were useful.

Stablecoins didn’t win hearts by being exciting. They won markets by being functional.

For decades, global money movement has relied on infrastructure built long before the internet became the backbone of commerce. International wires remain slow, expensive, and opaque. A typical transfer can cost around $40, take three to five business days, and pass through multiple intermediaries, each adding fees and friction.

Stablecoins replace this entire process with something radically simpler: a digital dollar that can be sent globally in seconds, at near-zero cost, without regard for banking hours or geography. Settlement happens in real time. Transparency is built in. Money becomes programmable.

This is not a feature upgrade it’s a structural shift. Just as cloud computing replaced on-prem servers and APIs replaced paperwork, stablecoins are replacing correspondent banking rails that were never designed for a global, always-on economy.

Infrastructure that works doesn’t need excitement. It just needs adoption.

The Trading Narrative Is Breaking

For much of their early life, stablecoins were seen primarily as a tool for traders, a place to park value between volatile crypto assets. That framing made sense in the early days, but it no longer explains the data.

Recent metrics show stablecoin usage decoupling from crypto trading activity. Even during periods of lower speculation, stablecoin volumes continue to grow. This signals a fundamental shift in how and why these assets are being used.

Today, stablecoins are increasingly powering everyday economic activity. They are used for payments, remittances, payroll, merchant settlement, treasury management, and savings especially in regions facing inflation or capital controls. For many users, stablecoins are no longer “crypto.” They are simply the fastest, most reliable way to move and hold money.

This transition marks the moment when stablecoins move from a niche financial tool to essential infrastructure.

Institutions are adopting without the noise

Perhaps the strongest signal of stablecoins’ durability is institutional behavior.

Major financial and commerce platforms are not experimenting publicly or chasing headlines. They are quietly integrating stablecoins into their core systems. Visa is rolling out stablecoin settlement, treating blockchains as an alternative backend for moving value. PayPal has described stablecoins as pivotal to the future of global commerce. Shopify is embedding stablecoin payments directly into checkout flows, allowing merchants to accept digital dollars alongside traditional payment methods.

These are not ideological endorsements of crypto. They are pragmatic decisions driven by cost efficiency, speed, and global reach. At scale, shaving seconds off settlement times and reducing fees by even small margins creates massive economic advantages.

When institutions adopt infrastructure quietly, it usually means they expect it to be permanent.

The Geopolitical shock nobody predicted

One of the most under-discussed consequences of stablecoin growth is its geopolitical impact.

Because the vast majority of stablecoins are backed by U.S. dollars, issuers must hold equivalent reserves. Today, those reserves include more than $150 billion in U.S. Treasuries, placing the stablecoin industry ahead of multiple sovereign nations as holders of U.S. government debt.

In effect, stablecoins are exporting the dollar digitally, without relying on traditional banks, treaties, or diplomatic agreements. For users in emerging markets, stablecoins often provide greater stability than local currencies, easier access than offshore banking, and faster settlement than legacy FX systems.

This creates organic global demand for dollars not through policy enforcement, but through superior technology. Dollar dominance is being reinforced by infrastructure rather than regulation.

Why this isn’t “Just another crypto cycle”

Skeptics often frame every crypto development as part of a repeating cycle. Stablecoins break that pattern.

They solve problems that exist regardless of market sentiment. Businesses need faster settlement. Merchants need lower fees. Individuals need stable value. The internet needs money that can move as easily as information.

These needs do not disappear during bear markets.

That’s why Citi projects the stablecoin market could reach $3.7 trillion by 2030. The growth curve resembles that of foundational technologies like cloud computing slow, unglamorous, and then suddenly indispensable.

Stablecoins are not a bet on price appreciation. They are a bet on efficiency.

Infrastructure Always Wins Quietly

Most financial revolutions don’t announce themselves with hype. They unfold quietly, in the background, while attention is elsewhere.

Stablecoins didn’t overthrow banks or replace fiat currencies overnight. They simply outperformed legacy systems where it mattered most: speed, cost, transparency, and reach. Over time, those advantages compound.

That’s how infrastructure wins. Slowly. Quietly. Inevitably.

The stablecoin revolution isn’t coming.

It’s already here and it’s scaling.

Resources & Links

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

CoinDesk Article:

Stablecoin Market Could Reach $4 Trillion by 2030, Citi Says in Revised Forecast

Bank tokens may ultimately surpass stablecoins in transaction volume, report said.

https://www.coindesk.com

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

For the past decade, general-purpose blockchains have powered some of the most creative experiments in technology. DeFi, NFTs, on-chain gaming, identity, and autonomous agents all emerged because these chains were designed to be flexible programmable environments where anything is possible.

But that flexibility comes with tradeoffs.

When a chain supports every type of workload, payments often share blockspace with NFT drops, liquidations, arbitrage bots, and high-frequency market activity. For most applications, that’s fine. For payments, especially those involving stablecoins or enterprise workflows, it can introduce unpredictability.

Tempo takes a different approach.

It begins with a simple question:

What if a blockchain was purpose built for stablecoin payments from day one?
What if finality, fees, metadata, and UX were architected not for general compute but specifically for moving digital dollars fast, reliably, and at global scale?

That question defines Tempo’s architecture. And today, its public testnet is officially live.

Why tempo exists and what it’s built for

Tempo is a specialized blockchain built entirely around payments.
> Not a general-purpose compute engine.
> Not a platform for NFT ecosystems.
> Not another environment competing for multi-tenant blockspace.

Tempo focuses on one thing: helping money move.

The chain is engineered for stability, determinism, and speed qualities that matter deeply to enterprises and consumer apps that rely on predictable financial behavior.

In less than three months, Tempo moved from announcement → implementation → live network. Builders can now test payment flows on infrastructure optimized for:

• Instant settlement (~0.5s)

Finality that feels closer to real-time payments, not typical crypto confirmation windows.

• Predictable low fees (~$0.001)

Isolated payment lanes keep fees steady even during periods of global volatility.

• A stablecoin native UX

Gas, liquidity, and transaction metadata are all designed around USD-denominated stable assets.

This isn’t a small launch. Tempo reports early pilots with major enterprises including OpenAI, Visa, Deutsche Bank, DoorDash, Shopify, Nubank, Mastercard, Brex, Klarna, Ramp, UBS, and more.

What makes tempo different

Medium readers love clarity, so let’s break down the mechanics.

→ Dedicated payment lanes

Payment traffic gets its own execution environment. No competition with NFT mints or trading bots.
More predictable fees. More predictable latency.

→ Stablecoin native gas

Gas is paid directly in USD stablecoins.
No volatile governance token.
No messy accounting.

→ Built in stable asset DEX

Unified, protocol-level liquidity for USD stablecoins.
Validators and users can pay and receive fees in the stablecoin of their choice.

→ Structured payment metadata

Native fields for invoices, vendor IDs, cost centers, payment references, reconciliation logic all built into the chain.

→ Fast, deterministic finality (~0.5s)

A BFT consensus mechanism ensures immediate, irreversible settlement.

→ Modern wallet UX

Tempo wallets support:

• gas sponsorship

• scheduled payments

• passkey authentication

• batched transactions

• automatic fee handling

All at the protocol layer not through third-party middleware.

What builders are exploring already

Early builders on the testnet are experimenting with :

> Cross-border remittances
> Payroll and vendor payouts
> Embedded finance rails
> Microtransactions with fees below a cent
> Agent-to-agent autonmous payments
> Tokenized deposits and institutional settlement

These use cases often require determinism, low fees, predictable blockspace, and structured metadata all areas where Tempo is specifically optimized.

What’s next for tempo

Launching the testnet is only step one.

Over the next phases, Tempo will:

• Onboard more enterprise partners

Expanding pilots across fintech, banks, commerce platforms, and agent-driven systems.

• Grow the developer ecosystem

Releasing SDKs, APIs, wallet toolkits, and data interfaces.

• Stress-test throughput

To understand how payment lanes behave under sustained high-volume settlement loads.

• Move toward validator decentralization

Ensuring long-term resilience, transparency, and trust.

Fully open source under apache

The Tempo client is entirely open-source under an Apache license.
Anyone can:

• run a node

• audit the implementation

• fork the client

• contribute improvements

This fosters community-driven development and supports a pathway toward decentralized governance and infrastructure.

The bigger picture

Tempo isn’t trying to replace general-purpose blockchains. Those ecosystems are thriving and essential for experimentation, apps, and compute-heavy use cases.

Tempo complements them.

As stablecoins become one of crypto’s most important real-world utilities, the infrastructure supporting them needs specialization. Payments are not just another transaction type; they’re a mission-critical function of global commerce. And they require consistency.

Tempo is designed for exactly that.

The testnet is live, open, and ready for builders who want to explore what’s possible when a blockchain focuses on one thing and does it exceptionally well.

Resources

Tempo Website :

Tempo: the blockchain designed for payments

The blockchain for payments at scale. A neutral, permissionless blockchain optimized for payment processing, enabling efficient transactions with predictable low fees.

https://tempo.xyz

Tempo doc :

Tempo

Documentation, integration guides, and protocol specifications

https://docs.tempo.xyz

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Clap it up if this saved you time!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

For Farcaster, a decentralized social protocol “good enough” once meant a messy, but functional, system. But as the network grew, that fragile foundation started to crack under pressure.

The answer? A bold re-architecture.

That led to Snapchain, a blockchain-like data layer designed specifically for social systems.

Farcaster + the “Deltagraph” (Pre-SnapChain) Era

Farcaster was always conceived as a decentralized social protocol. The idea was to let users own their identity, own their social graph, and give developers a base on which to build social apps free from centralized gatekeepers. Identity and high security operations (like account creation) remain on-chain, but most user data posts, follows, likes, profile updates are stored off-chain.

To manage that off-chain data, Farcaster originally used a system called “Deltagraph” , a gossip or CRDT(Conflict Free Replicated Data Type) based network. 

Under this system:

• Every user action (post, follow, like, profile update…) was treated as a CRDT operation.

• When a user did something, their node immediately applied the change locally, then “gossiped” it out to peers.

• There was no global coordinator, no strict ordering, just peer-to-peer gossip and eventual consistency.

Early on, Farcaster reportedly served a modest user base; the network managed something like 100,000 users and ~500 transactions per second (TPS), with roughly 2 GB/day of state growth.

It worked but only up to a point.

Deltagraph Started Failing

As usage grew, more users, more apps built on top of Farcaster Deltagraph started to show significant weaknesses. The decentralized, gossip-based system began failing in ways that matter to real users.

Here’s what went wrong:

1. Lack of global ordering and inability to guarantee strong consistency

Because CRDT operations are unordered and asynchronous, there was no canonical “source of truth.” If two nodes had differing data (e.g. due to message loss, network partitions, or delays), there was no reliable way to reconcile automatically. A node could only detect divergence by comparing all transactions with every other node, a task that becomes utterly unmanageable at scale.

As the number of nodes and messages ballooned, keeping everyone in sync became infeasible.

2. Sync failures, rate limit divergence, and state bloat

Nodes sometimes miss messages (gossip failures), meaning some users’ data became inconsistent or out-of-date. Because CRDT offers only eventual consistency, there was no guarantee when (or if) nodes would catch up.

Moreover, and perhaps most troubling, the state size kept growing relentlessly. Every post, like, follow, profile change, all piled up. For active usage, that meant storage demands growing day by day.

Eventually, running a node became so resource-intensive (bandwidth, storage, compute) that only big players could realistically keep up. That starts undermining the decentralization promise.

The result? Deltagraph, once “good enough,” was no longer good enough. Farcaster needed rethinking.

Watch the video on snapchain :

A New Chapter: Snapchain

Rather than patching the problems, the Farcaster team went for a full pivot: they replaced gossip-based CRDT with a brand-new system, Snapchain.

Snapchain is not a generic blockchain. It’s a blockchain inspired, social optimized data layer built specifically to handle social media workloads (posts, likes, follows, profile updates) rather than financial transactions.

What changed, and why this architecture works better:

• Ordered, block-based transaction processing: Instead of random gossip, user actions are grouped into blocks. Each block is signed, linked to the previous block, and includes a global “state root” (via a Merkle-trie over account states). This ordering provides a canonical source of truth. Syncing becomes trivial: if you miss a block, just fetch it no need to diff massive histories.

• Account-scoped transactions, non-Turing complete: Snapchain transactions are limited to social-native actions (post, like, follow, profile update, delete, etc.), each affecting only one account. No arbitrary smart contracts, no cross-account side effects. That simplifies validation and makes sharding by user account straightforward.

• Sharding & pruning (garbage collection): Because each account’s history is isolated, the network can split accounts across multiple chains, improving scalability dramatically. Meanwhile, Snapchain supports pruning: old or reversed transactions (e.g. unlike deleted posts) can be removed after a certain time, preventing unbounded state growth.

• Storage-rent model instead of per-action fees: Rather than charging gas per post/like (which would discourage frequent use), Snapchain opts for a “storage rent” model: users pay a fixed annual fee for storage. Within limits (e.g. number of transactions or storage quota), they can act freely. When limits are exceeded, older transactions get pruned. For typical social use, this feels effectively “unlimited.”

The result: a social-data layer that remains decentralized, but massively more scalable, reliable, and manageable.

What Snapchain Delivers :

Scalability, Consistency, and Real World Readiness

With Snapchain live (mainnet launch in 2025), Farcaster unlocked capabilities that were previously difficult or impossible:

• High throughput: Snapchain is designed to handle 9,000–10,000+ transactions per second (TPS), a level comparable to large centralized platforms and far beyond typical blockchains.

• Millions of daily users: The architecture supports large-scale usage. Estimates suggest a capacity for 2 million daily active users on Farcaster apps.

• Strong consistency & real-time sync across nodes: Because of block ordering and canonical state roots, nodes stay in sync reliably. No more “some nodes missing messages forever” missed blocks are detectable and fetchable.

• Decentralization + accessibility: With pruning and sharding, running a node becomes more feasible for a wider set of participants. The network stays decentralized but scalable, avoiding the “only big servers” trap.

• User-friendly experience: No gas fees per post or like, just a predictable storage rent. Users can behave like on traditional social media: post, like, follow, without worrying about per-action cost or blockchain latency.

In short: Snapchain reclaims the promise of decentralized social media not just as a technical novelty, but as a serious, usable alternative to centralized platforms.

The Tradeoffs: What Snapchain Gives Up and What It Restricts

No design is perfect. Snapchain makes deliberate tradeoffs to optimize for social use. Here’s what you should know.

• Limited transaction expressiveness: Snapchain only supports a fixed set of “social primitives” (posts, likes, follows, profile updates, deletes). There’s no support for Turing-complete smart contracts, arbitrary logic, or complex multi-account transactions. This keeps things simple but less flexible compared to general blockchains.

• Ephemeral history (due to pruning): Because the system prunes old or reversed transactions, the full historical record may not be kept forever. For typical social media usage, that may be fine (old likes/unlikes are rarely revisited), but it means history isn’t guaranteed to be immutable or permanent.

• New complexity, new failure modes: Snapchain introduces block production, consensus, validators, and sharding, a step up from simple gossip. That adds complexity to the protocol, and potential points of failure (validator downtime, shard coordination, consensus bugs, version upgrades).

• Storage-rent model tradeoffs: The “rent + prune” model means that heavy or long-term users may need to pay more (buy extra storage units), and some data might get dropped if quotas are exceeded. Also, different transaction types (posts, likes, follows) have separate quotas, which may lead to wasted capacity for some users.

In short: Snapchain sacrifices universality (no general smart contracts), permanence (pruning old data), and simplicity (added consensus/sharding complexity) but gains scalability, usability, and predictable performance for social use.

Conclusion

Snapchain shows that scaling decentralized social wasn’t just a performance problem, it was an architectural one. By replacing gossip with a purpose-built data layer, Farcaster proved the model can evolve without abandoning decentralization.

If Snapchain holds up under real adoption, it could pave the way for user owned social media at true Web2 scale. And that possibility alone makes this shift one of the most important experiments in Web3 right now.

Resources :

Snapchain website 

Snapchain

Snap V1 is our first no-code solution that brings fast finality to the OP Stack. We help deploy, manage and scale this integration for your chain, so you can focus on building the best experience for your users.

https://www.snapchain.dev

Farcaster 

Farcaster: crypto wallet for Base, Monad, and Solana

Discover new people, projects and tokens on Farcaster, the decentralized crypto social network and wallet for Base, Solana, Monad, BSC and more.

Farcaster

Heimlabs

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Clap it up if this saved you time!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

For more than three decades, the internet mastered one thing better than any invention in human history: moving information. It could stream videos, serve APIs, deliver messages, and host entire economies yet it never gained the ability to move money natively.

When the original designers of the web defined HTTP status codes, they reserved one number for a future capability: 402 Payment Required. It wasn’t truly implemented in the Web2 era mostly referenced in theory, occasionally speculated on, but never standardized or deployed at scale.

Until now.

x402 brings that placeholder to life.

It marks a fundamental shift in how the internet operates. It’s not a checkout system, not a Stripe clone, not a Web3 wrapper, and not a wallet prompt in disguise. It’s a protocol-level extension, embedding payments directly into the Web’s everyday request response cycle.

With x402, value moves over HTTP the same way data does instantly, natively, and verifiably.

So, What Exactly Is x402?

x402 is an open, machine-native payment protocol that embeds cryptographic payments directly inside normal HTTP requests. Instead of redirecting the user to a gateway or requiring API keys and subscriptions, a server can respond with 402 Payment Required containing:

• The required asset

• The amount

• The chain

• The recipient

• The API/service metadata needed for the client to pay and prove authorization

The client whether a browser, backend, agent, or IoT device, pays automatically by signing a transaction authorization, attaching it to the follow-up request, and receives the resource.

→ No pop-ups
→ No sign-ins
→ No “Connect Wallet.”

Just HTTP, upgraded with a value layer.

Why x402 Needed to Exist

The old web wasn’t built for:

• Microtransactions,

• Autonomous AI agents,

• Per-request billing,

• Real-time machine commerce,

• or on-demand digital services.

Everything depended on centralized intermediaries, API keys, and subscription logic, all designed for human-triggered flows, not automated machine economies.

The new internet, filled with autonomous agents, decentralized compute, tokenized services, and programmable money, needs a universal economic interface.

x402 is that interface.

It lets software interact with services the way humans intuitively do:
access → authorize → receive, without manual steps or platform friction.

How x402 Works Under the Hood

When a client requests a paid resource, the server replies with 402 Payment Required, including a structured descriptor containing:

• The asset and amount

• The chain

• The recipient

• API/service metadata

• A unique payment session

This payment session acts as a one-time handshake.

The client then constructs a cryptographically signed authorization preventing replay and proving intent. It attaches this proof to the follow-up request in a dedicated header.

The server verifies the payment session and signature.
In most deployments, the settlement and verification are handled by facilitators, not the server itself.

Once verified, the server returns the requested resource.

The flow is simple :

1. Client requests something.

2. Server replies with a 402 response containing how to pay.

3. The client signs an authorization, intending to pay.

4. Client retries the request with the proof.

5. The facilitator verifies and settles the payment

6. The server returns the content.

What once required checkouts, keys, dashboards, or subscriptions now fits inside one compact handshake between machines.

Why Onchain Settlement Matters

x402 isn’t built for speculative crypto. It relies on stablecoins and fast L2 settlement because:

• Payments are final and irreversible

• Settlement is transparent and auditable

• Confirmation happens in milliseconds

• Servers can release resources with confidence

It solves the question: How do I know the payment went through?

Not by trusting a platform but by relying on deterministic, cryptographic settlement.

The Internet Economy x402 Unlocks

Making payments a native part of HTTP unlocks entirely new design spaces:

APIs that charge per request instead of monthly subscriptions, media that charge per article without accounts or logins, compute markets that bill per second, agents that autonomously buy tools, data, or inference time, microservices that settle dependencies automatically, and streams priced by pixel, byte, or millisecond.

The web stops depending on centralized intermediaries. It becomes programmable, fluid, and value aware.

x402 is a Turning Point

• It does not replace HTTP.

• It does not replace wallets.

• It does not replace blockchains.

It extends the internet’s rulebook.

Just as cookies, compression, encryption, and caching became native primitives, x402 makes payments a primitive too a subtle shift with enormous consequences.

It changes how software interacts, how value flows, and how digital services monetize.

That’s why both non-technical readers and protocol engineers feel the “click” when they see it.

The Vision: A Value Aware Internet

Imagine an AI agent discovering a new API, interpreting its 402 descriptor, purchasing access instantly, and integrating it without human oversight.

Imagine a browser fetching premium content without accounts, passwords, or redirects, just request → authorize → continue.

Imagine infrastructure where economics aren’t bolted on, but built in.

The internet becomes not just a network of information, but a network of value.

x402 isn’t merely a protocol. It’s the long overdue upgrade the web always needed.

Real World Use Cases Emerging Today

we’re already seeing the first wave of systems that depend on x402 style, machine native payments:

1. Agent to Agent Payments

Autonomous agents are beginning to operate like tiny digital workers fetching data, running tasks, calling APIs, and chaining services together. With x402, these agents can now pay each other for what they consume, in real time, without user intervention.
 A model paying another model for inference, an agent paying for storage, or an AI purchasing access to a dataset all become seamless.

2. Per-Use APIs Without Subscriptions

APIs can finally charge per request. No keys, no dashboards, no plans. A simple “use → pay → continue” loop.

3. On Demand Compute

Compute nodes can bill by the second or millisecond perfect for inference time, job execution, rendering, or decentralized compute networks.

4. IoT and Device Payments

Devices such as sensors, smart meters, or edge hardware can settle tiny payments automatically as they interact with each other or cloud services.

5. Stream Based Pricing Models

Anything consumed continuously bandwidth, pixels, audio, compute cycles can now be priced dynamically and settled instantly.

Conclusion

x402 finally gives the internet what it has always lacked: a native way for value to move as easily as information. By embedding payments directly into HTTP, it removes the friction of gateways, accounts, and subscriptions, allowing humans, machines, and autonomous agents to access and pay for services in a single fluid interaction.

This simple shift unlocks a web where APIs bill per request, compute charges by the second, devices settle tiny debts automatically, and digital services become truly programmable. x402 doesn’t rebuild the internet, it completes it.

Resources & Links :

x402 :

x402.org

An open standard for internet-native payments

https://www.x402.org

Heimlabs :

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Share your x402 experiments, the internet’s new money layer is yours to shape.

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Happy Building 🚀

X402 introduced a simple idea: let agents pay for API access using the native semantics of the web, HTTP 402. No accounts, no custodians, no browser redirects. Just a request, a payment prompt, and a retry with a signed authorization.

But X402 originally operated on a single chain and token, which restricted how widely agents could function.

AnySpend removes those limits.

It keeps the familiar X402 flow exactly as it is, while adding the ability to pay with any token on any chain. Under the hood, AnySpend performs swaps, bridging, and settlement, completely invisible to the buyer and seller.

With this upgrade, X402 becomes a universal, chain-agnostic payment layer for agents.

Why This Matters for Autonomous Agents

Agents rarely hold the “correct” asset for every service.
One might have USDC on Base, another might earn fees in ETH on Optimism, while a service might settle in DAI on Ethereum.

Before AnySpend, these mismatches broke automation.
Now, they don’t matter.

• Agents pay with whatever they already have

• Sellers receive exactly what they want

• No one has to orchestrate routing or bridging logic

This allows autonomous systems to operate fluidly across chains and economies.

Implementation

Let’s walk through how to set up both server and client that charges users for API access using Anyspend X402.

We’ll be building a weather API that requires payment before access. Users can pay with any tokens to access the weather endpoint, but the server requires B3 tokens on the Base network.

(Watch the video here)

Setting Up the Express Server

First, let’s start with a basic Express setup. Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

import express from "express";
import { config } from "dotenv";

config();

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

Here, we:

• Import Express and dotenv for environment variable management

• Load environment variables from a .env file

• Create an Express application instance

• Configure Express to parse JSON request bodies

To enable payment functionality, we need to install and import two key libraries from the Anyspend X402 ecosystem:

@b3dotfun/anyspend-x402-express — Provides Express middleware for handling payments

@b3dotfun/anyspend-x402 — Core library with facilitator configuration utilities

@b3dotfun/anyspend-x402-fetch — library that extends the standard fetch API with payment capabilities

import { paymentMiddleware } from "@b3dotfun/anyspend-x402-express";
import {
 createFacilitatorConfig,
} from '@b3dotfun/anyspend-x402';
import { FacilitatorConfig } from "@b3dotfun/anyspend-x402/types";

The paymentMiddleware is what we’ll use to protect our API routes, while createFacilitatorConfig helps us set up the facilitator configuration that handles payment processing.

Setting Up the Facilitator URL

The facilitator is a service that handles payment verification and processing. In our case, we’re using the mainnet facilitator:

const facilitatorUrl = "https://mainnet.anyspend.com/x402";
const payTo = "0x6aed5ca43987221f41ba4bb2ebe29a7f583a53ff" as `0x${string}`

This URL points to the production Anyspend facilitator service that will verify payments on the blockchain before allowing requests to proceed.

The payTo address is the cryptocurrency address where payments will be sent. This is your revenue address:

All payments for API access will be sent to this payTo address. Make sure this is an address you control!

Setting Up the Facilitator Config

The facilitator configuration tells the payment system how to interact with the facilitator service:

const facilitatorConfig: FacilitatorConfig = { 
 …createFacilitatorConfig(), 
 url: facilitatorUrl 
};

We use createFacilitatorConfig() to get default configuration settings.This configuration will be passed to the payment middleware to handle payment verification.

Defining the Payment Middleware

Now comes the exciting part, setting up the payment middleware. This middleware will intercept requests to protected routes and verify that payment has been made before allowing access:

app.use(
 paymentMiddleware(
 payTo,
 {
 // Cross-chain: Accept B3 on Base 
 "GET /weather": {
 price: {
 amount: '1000000000000000', // 0.001 B3 tokens (18 decimals)
 asset: {
 address: '0xB3B32F9f8827D4634fE7d973Fa1034Ec9fdDB3B3',
 decimals: 18,
 eip712: {
 name: 'B3',
 version: '1',
 },
 },
 },
 network: "base",
 config: {
 description: "Premium weather content paid with B3 on base",
 },
 },
 },
 facilitatorConfig,
 ),
);

Let’s break down what’s happening here:

• payTo: The address that receives payments

• Route configuration: We’re protecting the GET /weather endpoint

• Price: Set to 1000000000000000 wei (0.001 B3 tokens, since B3 has 18 decimals)

• Asset: The B3 token contract address on Base network

• Network: “base” — we’re accepting payments on the Base network

• Description: A human-readable description of what the payment is for

The middleware will automatically:

1. Check if a valid payment proof is included in the request

2. Verify the payment with the facilitator

3. Allow the request to proceed if payment is valid

4. Reject the request if payment is missing or invalid

Plugging It In with the Weather API

Finally, we define our actual weather endpoint. This is a simple endpoint that returns weather data:

app.get("/weather", (req, res) => {
 res.send({
 report: {
 weather: "sunny",
 temperature: 70,
 },
 });
});

Because we’ve applied the payment middleware earlier, this endpoint is now protected. Users must include a valid payment proof in their request headers to access this endpoint.

Starting the Server

We start the server on port 4021:

app.listen(4021, () => {
 console.log(`Multi-token server listening at http://localhost:${4021}`);
});

Setting up the client

The client uses a wrapped fetch function that automatically handles payment processing, so you can make API calls just like you would with regular HTTP requests, but with built-in cryptocurrency payment support.

But first, we need to configure our environment variables. The client requires a private key for signing transactions and an optional API URL:

import { config } from "dotenv";
config();
const privateKey = process.env.PRIVATE_KEY as Hex | string;
const apiUrl = process.env.API_URL || "http://localhost:3001";
const MAX_PAYMENT_VALUE = BigInt("5000000000000000000"); // 5 ethers max

Here’s what each variable does:

• PRIVATE_KEY: Your Ethereum private key used to sign payment transactions. This should be kept secret and stored in a .env file.

• API_URL: The base URL of the API server. Defaults to http://localhost:3001 if not provided.

• MAX_PAYMENT_VALUE: A safety limit for maximum payment amount (5 ETH in this case) to prevent accidental overpayments.

Installing and Importing the Client Library

The client uses @b3dotfun/anyspend-x402-fetch, a library that extends the standard fetch API with payment capabilities:

import {
 decodeXPaymentResponse,
 wrapFetchWithPayment,
 createSigner,
 type Hex,
} from "@b3dotfun/anyspend-x402-fetch";

Let’s break down these imports:

• wrapFetchWithPayment: The main function that wraps the standard fetch to add automatic payment handling

• createSigner: Creates a cryptographic signer from a private key for signing payment transactions

• decodeXPaymentResponse: Decodes payment information from API response headers

• Hex: TypeScript type for hexadecimal strings (Ethereum addresses, transaction hashes, etc.)

Creating a Signer

Before we can make paid requests, we need to create a signer that will sign payment transactions on behalf of the user:

const network = “ethereum”
const signer = await createSigner(network, privateKey);

The signer:

• Takes a network identifier (in this case, “ethereum”)

• Uses your private key to sign transactions

• Enables the client to authorize payments automatically

The signer is what allows the wrapped fetch function to create and sign payment transactions without requiring manual wallet interactions for each request.

Wrapping Fetch with Payment

This is where the magic happens. We wrap the standard fetch function to add automatic payment processing:

const fetchWithPayment = wrapFetchWithPayment(
 fetch, 
 signer, 
 MAX_PAYMENT_VALUE, 
 undefined, 
 undefined, 
 {
 preferredNetwork: network,
 preferredToken: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" // $USDC token on ethereum
 }
);

Let’s understand each parameter:

• fetch: The standard fetch function to wrap

• signer: The signer we created earlier for authorizing payments

• MAX_PAYMENT_VALUE: Maximum payment amount as a safety limit.

Configuration object:

• preferredNetwork: The blockchain network to use for payments (“ethereum” in this case)

• preferredToken: The token contract address to use for payments (USDC on Ethereum)

Making the API Call

With our payment-enabled fetch function, making a paid API call is as simple as a regular HTTP request:

const response = await fetchWithPayment(`${apiUrl}/weather`, {
 method: “GET”,
});

The wrapped fetch handles all the payment complexity behind the scenes. If the API requires payment, it will:

• Check the payment requirements from the API

• Create and sign a payment transaction

• Include the signature in the request

• Then retries the API call

Handling Payment Responses

The API server includes payment information in response headers. We can extract and decode this information:

// Get payment response header
const paymentResponseHeader = response.headers.get("X-PAYMENT-RESPONSE");
if (paymentResponseHeader) {
 const paymentInfo = decodeXPaymentResponse(paymentResponseHeader);
 console.log(JSON.stringify(paymentInfo, null, 2));
}

The X-PAYMENT-RESPONSE header contains encoded payment details such as:

• Transaction hash

• Payment amount

• Token used

• Network

• Timestamp

This is useful for tracking payments, displaying receipts, or debugging payment issues.

Handling Errors

We include comprehensive error handling:

if (!response.ok) {
 const errorData = await response.json();
 console.error("❌ Request failed:");
 console.error(JSON.stringify(errorData, null, 2));
 return;
}

If the API call fails (due to payment issues, network problems, or API errors), we:

• Check if the response is not OK

• Parse the error response

• Display it in a readable format

• Exit gracefully

Processing the Response Data

Finally, we extract and display the actual API response:

// Get the response data
const data = await response.json();
console.log(JSON.stringify(data, null, 2));

In our weather API example, this would display:

{
 "report": {
 "weather": "sunny",
 "temperature": 70
 }
}

How the Flow Works 

The X402 flow stays exactly the same:

1. Client requests a resource

2. Server responds with 402 + payment details

3. Client retries with a signed payment authorization

4. Service grants access

The only difference now is what the facilitator is capable of.

Once the signed message arrives, AnySpend handles everything else:

• Validates the signature (EIP-2612 / EIP-3009 typed data)

• Pulls the specified funds

• Swaps the token if needed

• Bridges to the seller’s chain, if needed

• Settles in the seller’s preferred token

To the client, nothing changes.
To the seller, everything becomes interoperable.

Security Model

The security guarantees come from the signature standards themselves—not the facilitator.

• Standard signature with EIP 2612 and EIP 3009, which offers replay protection via nonces

• Signature expiration via deadlines

• Signer verification via EIP-712 address recovery by the contract

A facilitator cannot forge or spoof signatures
AnySpend only executes what the wallet owner explicitly authorizes.

Developer Integration

AnySpend is designed so both sides can integrate easily:

For Sellers

• Express middleware to monetize any endpoint with a 402 paywall

• Settlement configuration (desired chain + token)

• REST API for low-level control

For Buyers/Agents

• Client SDK for easy integration.

• Preparing and signing typed-data payments is handled automatically.

• Drop-in compatibility with existing X402 agent scripts

The integration experience remains simple and consistent.

A Simple Mental Model

You keep writing X402 the way you always have.
AnySpend makes it work everywhere.

That’s the entire upgrade.

Conclusion

X402 keeps the simple flow, and AnySpend extends it across chains and assets. Agents pay with what they have, services settle how they prefer, and the whole loop stays automated.

Resources

AnySpend Website

AnySpend - Swap & trade crypto tokens from any chain

AnySpend is a secure cross-chain crypto swapping platform that lets you seamlessly trade tokens across any blockchain network. Get the best rates, fast transactions, and easy token swaps between Base, Ethereum, Solana, and other major chains.

https://anyspend.com

HeimLabs

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

This is the foundation of open, intelligent, multi-chain autonomous commerce.

Share what you’re building with the CDP stack!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Happy Building 🚀

Today, let’s talk about a common pain point in the blockchain ecosystem.

If you want your users to enjoy a web2-like experience in an onchain application, you have to hide all the complexities, such as managing wallets, enforcing compliance rules, and sometimes even sponsoring gas. Doing all this securely and at scale is tough.

That’s where Server Wallets from Coinbase Developer Platform (CDP) come in.
They let you create and manage wallets programmatically, send transactions, enforce policies, and sponsor gas all through secure APIs. You can focus on your app logic while CDP handles the cryptography and infrastructure.

In our previous video, we covered how CDP secures private keys and how the wallet infrastructure works behind the scenes.
This time, we’re going hands-on with Python SDK (also available in TypeScript).

What You’ll Build

By the end of this walkthrough, you’ll be able to:

• ⚙ Set up the CDP SDK and securely manage environment variables

• 🔑 Create new Ethereum accounts and import existing ones

• 💸 Send transactions and fetch balances

• 🧩 Enforce policies with both failing and successful examples

• ⛽ Enable gas sponsorship for seamless, gasless UX

(Watch the Full Video here)

Step-by-Step Walkthrough

Step 1: SDK Setup

Create a requirements.txtfile and add these inside it:

cdp-sdk>=0.0.1
python-dotenv>=1.0.0
web3>=6.0.0
cryptography>=41.0.0
eth-account>=0.13.0

Then run this below command in your terminal:

pip install -r requirements.txt

Then we’ll create a reusable singleton instance of the CDP client inside utils.py

# Singleton CDP client instance
_cdp_instance = None

async def get_cdp_client() -> CdpClient:
 """
 Get or create a singleton CDP client instance
 """
 global _cdp_instance
 
 if _cdp_instance is None:
 # Verify environment variables
 api_key_id = os.getenv('CDP_API_KEY_ID')
 api_key_secret = os.getenv('CDP_API_KEY_SECRET')
 wallet_secret = os.getenv('CDP_WALLET_SECRET')
 
 if not all([api_key_id, api_key_secret, wallet_secret]):
 raise ValueError("Missing required environment variables. Please check your .env file.")
 
 _cdp_instance = CdpClient()
 
 return _cdp_instance

Step 2: Create and Import Accounts

Creating, fetching, or importing accounts is very straightforward with server wallets

You can create an account using

cdp = await get_cdp_client()
 
 # Create Alice — a new account
 timestamp = datetime.now().strftime(“%Y%m%d%H%M%S”)
 alice = await cdp.evm.create_or_get_account(name=f”demo-account-new-20251001002758")
 print(f”Alice: {alice.address}”)

To import an account using an existing private key

# Import Bob — from private key
 bob_key = BOB_PRIVATE_KEY[2:] if BOB_PRIVATE_KEY.startswith(‘0x’) else BOB_PRIVATE_KEY
 
 # Calculate the expected address from the private key
 eth_account = Account.from_key(BOB_PRIVATE_KEY)
 expected_address = eth_account.address
 bob = await cdp.evm.import_account(
 private_key=bob_key,
 name=f”bob-{timestamp}”
 )
 print(f”Bob: {bob.address}”)

Step 3: Send a Transaction & Fetch Balances

You can use evm.send_transactionfrom the cdp client to initialise a transaction

tx_response = await cdp.evm.send_transaction(
 address=alice.address,
 transaction=TransactionRequestEIP1559(
 to=bob.address,
 value=w3.to_wei(amount_eth, “ether”),
 ),
 network=NETWORK,
 )

And in the same way to fetch the balance of the user we use list_token_balancesas below

balances = await cdp.evm.list_token_balances(
 address=address,
 network=NETWORK
 )

This will provide the entire list of tokens the user is holding, and can be parsed as follow

if balances:
 balance_list = balances.balances if hasattr(balances, ‘balances’) else balances
 
 print(f”{address}:”)
 for balance in balance_list:
 symbol = balance.token.symbol if hasattr(balance, ‘token’) else ‘ETH’
 if hasattr(balance, ‘amount’) and hasattr(balance.amount, ‘amount’):
 amount = balance.amount.amount
 decimals = balance.amount.decimals if hasattr(balance.amount, ‘decimals’) else 18
 readable_amount = amount / (10 ** decimals)
 print(f” {symbol}: {readable_amount}”)
 
 return balances

Step 4: Enforce Policies

CDP Server Wallets allow you to attach policies that define allowed actions or spending limits.
For example, a policy might restrict transfers above a threshold or to certain addresses.

You can enable this from your CDP dashboard by editing an existing template or writing your own custom rules.

Once a policy is created, try to test with a transaction and your transaction will fail with an API error if in case it violates the policy.

This can play a key role in compliance and operational safety.

Step 5: Sponsor Gas

• To deliver a true web2-like experience, CDP lets you sponsor gas fees for your users by abstracting all the complexities of managing a paymaster.

• You can enable sponsorship through your CDP console under onchain tool > paymaster or click here

• Once you enable it, you’ll get the Paymaster URL, which should be passed as a parameter for gasless txn in the code.

Before we jump into the gasless txn, there’s an important to thing to note, that is gasless txn works only with smart accounts so it’s important to create one, and CDP let’s you do that with a single line of code using their get_or_create_smart_accountfunction. But these smart accounts needs an owner account which is a EOA.

Here’s how we create smart accounts

async def _get_or_create_smart_account(cdp: Any, name: str, display_name: str) -> Any:
 try:
 owner = await cdp.evm.get_or_create_account(name=name)
 account = await cdp.evm.get_or_create_smart_account(name=name, owner=owner)
 print(f”{display_name}: {account.address}”)
 return account
 except Exception as e:
 print(f”x Failed to create: {str(e)}”)
 raise

async def create_smart_accounts() -> Tuple[Any, Any]:
 cdp = await get_cdp_client()
 alice = await _get_or_create_smart_account(cdp, “alice”, “Alice”)
 bob = await _get_or_create_smart_account(cdp, “bob”, “Bob”)
 return alice, bob

This makes transactions feel instant and free from the user’s perspective, while you control limits via policy.

Step 6: Bringing them all together

You can call all these function in main function such as this

async def main():
 “””
 Main orchestration function
 “””
 try:
 # Create accounts
 alice, bob = await create_accounts()
 
 # Initial balances
 print(“\nInitial Balances:”)
 await fetch_balance(alice.address)
 await fetch_balance(bob.address)
 
 # Send transaction
 print(“\nSending Transaction:”)
 await send_tokens(alice, bob, amount_eth=0.001)
 
 # Final balances
 print(“\nFinal Balances:”)
 await fetch_balance(alice.address)
 await fetch_balance(bob.address)
 
 except Exception as e:
 print(f”Error: {str(e)}”)
 import traceback
 traceback.print_exc()
 
 finally:
 await close_cdp_client()

Security & Best Practices

When working with Server Wallets, keep these best practices in mind:

• 🔒 Always load secrets from environment variables — never hardcode keys

• 🔁 Rotate wallet secrets regularly

• 🧾 Redact API keys and private key material in logs

• 🧱 Keep access scoped and audit permissions frequently

Additional Features

Beyond what we built today, Server Wallets V2 also support:

• 🧠 Smart accounts for account abstraction and batching

• 🔄 Token swaps for direct ERC-20 swaps

• 🧰 Spend permissions for granular, scoped access

• 🏢 Managed mode for team-scale infrastructure

These are optional but powerful tools as your app grows.

Conclusion

You’ve just built and tested Server Wallets V2 with Python — from setup to transactions, policy enforcement, and gas sponsorship.
You now have a secure, programmable wallet infrastructure ready for production.

For deeper docs and SDK examples, visit the official Coinbase Developer Platform documentation.
And follow HeimLabs for more technical walkthroughs, tutorials, and hands-on guides for Web3 developers.

Resources

CDP Docs

Coinbase Developer Docs - Coinbase Developer Documentation

Explore our API & SDK references, demos, and guides for building onchain apps.

https://docs.cdp.coinbase.com

Python SDK Reference

GitHub - coinbase/cdp-sdk-python

Contribute to coinbase/cdp-sdk-python development by creating an account on GitHub.

https://github.com

HeimLabs

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Clap it up if this saved you time!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Most API marketplaces still assume a human is in the loop, create an account, add a card, mint keys, manage usage. That’s friction your AI agent can’t handle.

Bazaar + x402 flips that model. Your agent discovers services, gets an HTTP 402 (payment required) response with payment details, pays (typically USDC on Base), retries the same request with proof, and the API responds — no accounts, no subscriptions.

By the end of this post, you’ll have a runnable demo that shows the end-to-end loop: list → discover → 402 → pay → retry → use.

What You’ll Build

• 🧭 Publish a minimal Bazaar-style listing your agent can discover

• 💳 Simulate x402 payment flow (HTTP 402 → facilitator settle → proof)

• 🔁 Retry the same request with proof to get the paid response

• 🧪 Do it all in one Node.js script you can run locally

(Watch the full video here)

System Architecture

Agent (buyer) ──> Bazaar catalog ──> Service endpoint
    │                                   │
    │ (Request)                          │ If unpaid:
    │──────────────────────────────────> │  returns HTTP 402 + payment details
    │                                    │
    │ --pay via Facilitator------------> Facilitator (verifies/settles, returns proof)
    │                                    │
    │ (Retry + proof header)            │
    └──────────────────────────────────> │ Returns the result

Components (quick tour)

• Bazaar: Simple discovery layer returning listings with name, price, asset, network.

• Service: Your API endpoint that requires pay-per-request. If unpaid, it answers with HTTP 402 and payment details.

• x402 Facilitator: Verifies/settles the client’s payment and issues a proof your service can trust.

• Agent: A tiny buyer script that discovers a service, calls it, handles 402, pays via facilitator, retries with proof, and prints the result.

  ---

Implementation phase

The code will be split into two parts: Seller and Buyer.

Project setup

mkdir x402-baazar
cd x402-baazar

npm init -y

Install dependencies

npm i @coinbase/cdp-sdk @coinbase/x402 dotenv express viem x402-express x402-fetch

We’ll start by building a simple Rock–Paper–Scissors endpoint. Then, we’ll integrate it with x402 so each request is payable, and provide the necessary config to list the service in Baazar. Create a file called index.js

Setting up our endpoint with express

import express from “express”;

const moves = ["rock", "paper", "scissors"];
function getOutcome(player, server) {
 if (player === server) return "draw";
 if (
 (player === "rock" && server === "scissors") ||
 (player === "paper" && server === "rock") ||
 (player === "scissors" && server === "paper")
 ) {
 return "win";
 }
 return "lose";
}

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

app.post("/rps/play", (req, res) => {
 try {
 const { move } = req.body;
 if(!move || !moves.includes(move)){
 res.status(400).send({ error: "Move must be rock, paper, or scissors" });
 return;
 }

const serverMove = moves[Math.floor(Math.random() * moves.length)];
const outcome = getOutcome(move, serverMove);

app.listen(4021, () => {
 console.log(`Server listening at http://localhost:4021`);
})

Now to set up x402 and the configs required for Baazar for the above endpoint

// … exisiting imports
import { paymentMiddleware } from “x402-express”;
import { facilitator } from “@coinbase/x402”;

// after `app.use(express.json())`

app.use(
 paymentMiddleware(
 "0xB1De43C2Ca1195258FEE160adAcB1820c3776B7D",
 {
 "POST /rps/play": {
 price: "$0.001", // USDC testnet price
 network: "base",
 config: {
 name: "Rock-Paper-Scissors",
 description: "Pay to play a simple game of Rock-Paper-Scissors.",
 discoverable: true, // 
 inputSchema: {
 type: "object",
 properties: {
 move: {
 type: "string",
 enum: ["rock", "paper", "scissors"],
 description: "Your move",
 },
 },
 required: ["move"],
 },
 outputSchema: {
 type: "object",
 properties: {
 playerMove: { type: "string" },
 serverMove: { type: "string" },
 outcome: { type: "string" },
 },
 },
 },
 },
 },
 {
 facilitator
 }
 )
)

// before `app.post("/rps/play"…`

• The paymentMiddleware integrates x402 into this project as an Express middleware (learn more about Express middlewares here).

• It takes two parameters:

1. Recipient address — the wallet where payments to this endpoint will be sent.

2. Baazar config — metadata that describes your service in the Baazar catalog, making it discoverable for AI agents.

• The discoverable flag in the config is set to true, which ensures your API is automatically listed in the Baazar catalog.

Note: To make your API indexable by Baazar, you must deploy it to a public cloud (e.g., Railway, AWS, etc.) and ensure it’s accessible publicly

Next, let’s create a simple function that simulates a buyer

• It queries the Baazar catalog to list available services.

• Selects our rock-paper-scissors service.

• Plays the game while paying USDC for each request.

Now create another file called buyer.js, and start with listing the catalog

const listCatalog = async () => {
const response = await fetch("https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources")
const res = await response.json()
 console.log(res)
 
}

const run = async () => {
const catalog = await listCatalog();
}

run()

This will return an array of objects

{
 “items”: […]
}

Now that we have the service list, let’s set up a few prerequisites before making a call:

1. Wallet setup — We need a wallet to pay for the service. The quickest option is to use a CDP wallet, which abstracts all the complexities into just two lines of code. Alternatively, you can bring your own wallet, but then you’ll need to handle the full viem configuration yourself.

2. Making the API call — There are two approaches:

• Manually: call the API with fetch or axios, receive the 402 Payment Required response, make the payment, and then retry.

• Automatically: use the CDP wrappers for fetch or axios, which handle the entire payment flow for you.

For this walkthrough, we’ll wrap fetch with x402-fetch.

import { CdpClient } from “@coinbase/cdp-sdk”;
import dotenv from “dotenv”;
import { wrapFetchWithPayment, decodeXPaymentResponse } from “x402-fetch”;

dotenv.config()

// Setup CDP account or bring your own wallet
const cdp = new CdpClient();
const cdpAccount = await cdp.evm.getAccount({ name: “buyer-account”});

// feel free to enable this in testnet, perks for using CDP 😅
// await cdp.evm.requestFaucet({
// address: cdpAccount.address,
// network: “base-sepolia”,
// token: “usdc”
// });

// providing x402 super power to our good old `fetch`
const fetchWithPayment = wrapFetchWithPayment(fetch, cdpAccount);

// … previous listCatalog function

const run = async () => {
 try {
 const catalog = await listCatalog();
 
 // choosing a service, assuming that it’s our RPS API
 const service = catalog.items[0] 
 const response = await fetchWithPayment(service.resource, {
 method: “POST”,
 headers: {
 “Content-Type”: “application/json”,
 },
 body: JSON.stringify({ move }),
 });

 const result = await response.json();
 console.log(“Game result:”, result);
 const paymentResponse = decodeXPaymentResponse(response.headers.get(“x-payment-response”));
 console.log(paymentResponse)
 } catch (error) {
 console.log(error); 
 } 
}

run()

Using fetchWithPayment ensures that whenever the API responds with a 402 Payment Required, the payment is handled automatically and the request is retried — so you get the result without needing to manage the payment flow yourself.

Run the app

Seller

Buyer

You’ll see:

1. The server start

2. The buyer discovering the service

3. The first call returning HTTP 402 with payment details

4. The testnet facilitator issuing a receipt

5. Then retry with X-PAYMENT header

6. The server responds back with a valid response

Map the Demo to the Real Thing

• Bazaar UI & Catalog: In production, this is a hosted catalog with ratings, pricing, latency, and networks. Your agent chooses providers that match budget + policy constraints.

• x402: The pattern stays identical — service answers unpaid with 402, agent settles via a facilitator, then retries the exact same HTTP request with a proof header.

• Facilitator: In production you’d use Coinbase’s default facilitator for USDC on Base (or run your own / pick a community one). Its job: verify payment and issue a proof your service trusts.

• Service: Your API should treat 402 like a contract: be explicit about amount, asset, network, seller, and facilitator URL, then verify the facilitator’s proof on retry before returning data.

Hardening & Extensions

• Replay protection: Bind proofs to paymentRequestId + method + path + query and expire quickly. Note: CDP facilitators are, by default, designed to handle this—providing a 60-second window to pay and retry

• Tiered responses: Offer free previews, charge for high-res/long runs.

• Dynamic pricing: Quote by input size (e.g., seconds of audio, tokens) inside the 402 body.

• Provider switching: Your agent can compare rating/price/latency, swap providers mid-workflow, and keep moving.

• Onchain receipts: Include tx hashes and facilitator attestations to anchor off-chain work to on-chain payments.

Recap

You just ran a full, agent-friendly Bazaar + x402 loop: discover, call and get 402 payment required status, pay via a facilitator, retry with proof, and receive the paid result — no accounts, no subscriptions, per-request.

Next Steps

• Swap the mock facilitator for Coinbase’s default facilitator on Base USDC.

• Add signature verification using your facilitator’s real public keys.

• Turn the catalog into a UI with ratings, price filters, and network badges.

CTA

• Explore Coinbase Developer Platform docs for Bazaar/x402 and wallets.

• Follow HeimLabs for upcoming agent demos that chain providers (translate → analyze → summarize → TTS) with pay-per-step execution.

Resources & Links

Coinbase Developer Docs:

Coinbase Developer Docs - Coinbase Developer Documentation

Explore our API & SDK references, demos, and guides for building onchain apps.

https://docs.cdp.coinbase.com

x402:

x402.org

An open standard for internet-native payments

https://www.x402.org

HeimLabs:

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Clap if this saved you hours, and share what you’re building with the CDP stack!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Happy Building 🚀

Introduction

Automating on-chain actions on Solana can feel risky: one bad key leak or buggy transaction and funds are gone. Traditional guards like code reviews and unit tests help, but they don’t stop a live transaction.

Today, you’ll fix that with Coinbase Developer Platform (CDP) Server Wallets v2. We’ll create policies — API-level firewalls that allow only the transactions you intend. By the end, you’ll have a runnable TypeScript script that enforces SOL/SPL allowlists and a strict IDL-based policy for Jupiter v6 swaps.

What You’ll Build

• 🔐 Create policies that only allow SOL transfers to trusted addresses

• 🪙 Restrict SPL token transfers to approved mints (USDC)

• 🔎 Validate instruction data with a custom IDL (Jupiter v6 “route”)

• 🚀 Assemble a single script that creates all policies in one go

System Architecture

Dev Script (TypeScript) 
      │ uses
      ▼
 CDP SDK (Policies API)
      │ creates
      ▼
 Policy Objects (scope: account)
      │ enforced at
      ▼
 Server Wallets v2  ──> Solana Runtime

How it works (2–3 sentences each):

• CDP SDK — Programmatic entry to create/update policies.

• Policies — Declarative rules (allowlists, mint restrictions, IDL checks) that gate transactions before signing.

• Server Wallets v2 — Managed, programmatic wallets that must satisfy active policies.

• Solana — Actual execution layer; transactions only flow if they pass the policy engine.

Step-by-Step Walkthrough

1) Prerequisites & Project Setup

You’ll need

• Node.js v18+

• A CDP account, API Key (id + secret), and Wallet Secret from the CDP Portal

Create & init

# Create your project
mkdir solana-policy-engine-tutorial
cd solana-policy-engine-tutorial

# Initialize Node.js project
npm init -y

Install deps

npm install @coinbase/cdp-sdk dotenv typescript ts-node @types/node

Initialize TypeScript

npx tsc --init --rootDir src --outDir dist --esModuleInterop --resolveJsonModule --module commonjs --moduleResolution node

Scaffold files

mkdir src
touch src/main.ts
touch .env

Add secrets to .env

# .env - Get these from the CDP Portal
CDP_API_KEY_ID="your_api_key_id"
CDP_API_KEY_SECRET="your_api_key_secret"
CDP_WALLET_SECRET="your_wallet_secret"

2) Bootstrap the CDP Client

Create src/main.ts:

// src/main.ts
import { CdpClient } from "@coinbase/cdp-sdk";
import dotenv from "dotenv";

dotenv.config();
const cdp = new CdpClient();
console.log("CDP Client Initialized Successfully.");
async function main() {
  console.log("\n--- Starting Policy Creation Script ---");
  // We'll call our policy functions here.
  console.log("\n--- ✅ All Policies Created Successfully ---");
}
main().catch((error) => {
  console.error("\nAn error occurred during policy creation:", error);
  process.exit(1);
});

3) Foundational Policies

3.1 SOL Address Allowlist

Only allow SOL transfers to a trusted set of addresses.

/**
 * Policy 1: SOL Address Allowlist
 * This policy only permits sending SOL to a specific list of trusted addresses.
 * Any attempt to send SOL elsewhere will be blocked at the API level.
 */
async function createSolAllowlistPolicy(cdp: CdpClient) {
    console.log("\nCreating a SOL address allowlist policy...");

    const policy = await cdp.policies.createPolicy({
        policy: {
            description: "Allow SOL transfers to treasury addresses",
            scope: "account", // This policy will be applied to a specific account
            rules: [
                {
                    action: "accept", // Required: accept or deny
                    operation: "signSolTransaction", // Required: Solana transaction operation
                    criteria: [
                        {
                            type: "solAddress",
                            addresses: [
                                "DtdSSG8ZJRZVv5Jx7K1MeWp7Zxcu19GD5wQRGRpQ9uMF", // Valid Treasury Address 1
                                "HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT", // Valid Treasury Address 2
                            ],
                            operator: "in" // The 'to' address must be IN this list
                        }
                    ]
                }
            ]
        }
    });

    console.log(`Successfully created SOL Allowlist Policy with ID: ${policy.id}`);
    return policy.id;
}

3.2 SPL Token Mint Restriction (USDC Only)

Permit transfers only for approved mints (USDC shown below).

/**
 * Policy 2: SPL Token Mint Restriction
 * This policy only allows transfers of specific SPL tokens (USDC in this case)
 * by checking the token's mint address.
 */
async function createStablecoinOnlyPolicy(cdp: CdpClient) {
    console.log("\nCreating a stablecoin-only (USDC) transfer policy...");

    const USDC_MINT_ADDRESS = "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v";

    const policy = await cdp.policies.createPolicy({
        policy: {
            description: "Allow USDC SPL Token transfers only",
            scope: "account",
            rules: [
                {
                    action: "accept",
                    operation: "signSolTransaction",
                    criteria: [
                        {
                            type: "mintAddress",
                            addresses: [USDC_MINT_ADDRESS],
                            operator: "in"
                        }
                    ]
                }
            ]
        }
    });

    console.log(`Successfully created Stablecoin-Only Policy with ID: ${policy.id}`);
    return policy.id;
}

4) Advanced Policy with a Custom IDL (Jupiter v6)

Validate instruction data using the program’s IDL so only intended Jupiter “route” swaps are allowed — and cap the size.

1. Save the Jupiter v6 IDL JSON as src/jupiter-v6-idl.json (from explorer/IDL source).

2. Add the policy creator:

/**
 * Policy 3: Advanced Jupiter Swap Policy (solData + minimal IDL)
 * - Enforces a maximum input amount for Jupiter `route` swaps
 * - Validates instruction data against a minimal inline IDL built from
 *   `src/jupiter-v6-idl.json`
 * - Effect: Only allows signing Jupiter `route` swaps when `in_amount` <= 1 SOL;
 *   other transactions won't satisfy this rule
 */
async function createJupiterSwapPolicy(cdp: CdpClient) {
    console.log("\nCreating an advanced policy for Jupiter swaps...");

    const MAX_SWAP_AMOUNT_LAMPORTS = "1000000000"; // 1 SOL (lamports, as string)
    const JUPITER_PROGRAM_ID = "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4";

    // Build a minimal inline IDL for the `route` instruction for the API
    const routeIx = (jupiterIdl.instructions as any[]).find((ix) => ix?.name === 'route');
    if (!routeIx) {
        throw new Error('Jupiter IDL does not include route instruction');
    }
    const jupiterRouteIdl = {
        address: JUPITER_PROGRAM_ID,
        instructions: [
            {
                name: 'route',
                discriminator: routeIx.discriminator,
                args: [
                    { name: 'route_plan', type: 'vec<defined:RoutePlanStep>' },
                    { name: 'in_amount', type: 'u64' },
                    { name: 'quoted_out_amount', type: 'u64' },
                    { name: 'slippage_bps', type: 'u16' },
                    { name: 'platform_fee_bps', type: 'u8' },
                ],
            },
        ],
    };

    const policy = await cdp.policies.createPolicy({
        policy: {
            description: "Allow SOL USDC swaps on Jupiter max 1 SOL",
            scope: "account",
            rules: [
                {
                    action: "accept",
                    operation: "signSolTransaction",
                    criteria: [
                        {
                            type: "solData",
                            idls: [jupiterRouteIdl],
                            conditions: [
                                {
                                    instruction: "route",
                                    // Guardrail: limit maximum input amount for swaps
                                    params: [
                                        { name: "in_amount", operator: "<=", value: MAX_SWAP_AMOUNT_LAMPORTS }
                                    ]
                                }
                            ]
                        }
                    ]
                }
            ]
        }
    });

    console.log(`Successfully created Jupiter Swap Policy with ID: ${policy.id}`);
    return policy.id;
}

5) Wire It All Up

Update the bottom of src/main.ts to create all policies:

/**
 * Main: create three policies in sequence
 */
async function main() {
    console.log("\n--- Starting Policy Creation Script ---");

    try {
        // Create foundational policies
        await createSolAllowlistPolicy(cdp);
        await createStablecoinOnlyPolicy(cdp);

        // Create advanced, IDL-based policy
        await createJupiterSwapPolicy(cdp);

        console.log("\n--- ✅ All Policies Created Successfully ---");
    } catch (error) {
        console.error("\nAn error occurred during policy creation:", error);
        throw error;
    }
}

// Execute the main function with proper error handling
main().catch(error => {
    console.error("\nFatal error in policy creation:", error);
    process.exit(1);
});

Run it

npx tsc && node dist/main.js

Watch the console for policy IDs. These policies now protect your account-scoped server wallet operations.

Conclusion & Call to Action

You just stood up a practical Solana policy layer: SOL allowlists, SPL mint restrictions, and a Jupiter v6 IDL policy that inspects instruction data and caps swap size. This is the backbone of safer backends — especially for bots, treasuries, and automated services.

Next steps

• Expand the allowlists/mints for your app

• Add program-specific IDL rules for other protocols

• Combine with alerting & CI to treat policies as code

Keep building

• Coinbase Developer Docs: https://docs.cdp.coinbase.com

• Join the Coinbase Developer Discord to swap patterns and ask questions

Resources & Links

Jupiter — (find program/IDL references via explorers)

Jupiter: The DeFi Superapp

Jupiter is one of the largest decentralized trading platforms and one of the most active governance communities in crypto. We're building the everything exchange for everyone.

https://www.jup.ag

CDP Wallets v2 Docs: 

Welcome to Server Wallet v2 - Coinbase Developer Documentation

The v2 Server Wallet enables developers to programmatically create, manage, and use crypto accounts while CDP secures the private keys and handles complex infrastructure management. Developers can access the v2 Server Wallet through either the CDP SDK or CDP's REST endpoints.

https://docs.cdp.coinbase.com

CDP SDK Github: 

GitHub - coinbase/cdp-sdk: Client libraries for managing EVM and Solana wallets while relying on CDP to secure private keys.

Client libraries for managing EVM and Solana wallets while relying on CDP to secure private keys. - coinbase/cdp-sdk

https://github.com

Demo Github:

HeimLabs:

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Clap if this saved you hours, and share what you’re building with the CDP stack!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Happy Building 🚀

Introduction

App installs, cold-start social graphs, and clunky wallets kill growth. Traditional apps fight for app-store rankings while your users bounce before the first tap.

Today we’ll build a Base Mini App — a lightweight, social-native web app that launches instantly inside clients like the Base App and Farcaster. Using MiniKit (for frames + native hooks) and OnchainKit (for polished UI + onchain utilities), you’ll ship a “Social Trivia” app that feels at home in the feed and scales via sharing.

By the end, you’ll have a working Mini App with a clean viral loop, context-aware UI, smooth native controls, and an optional gasless onchain leaderboard on Base.

What You’ll Build

• ⚡ Launch a Next.js Mini App with a signed Farcaster manifest

• 🧭 Use MiniKit hooks for context, auth, share, and navigation

• 🧑‍🤝‍🧑 Render identity with OnchainKit’s Avatar/Name components

• 📣 Create a viral loop with dynamic embeds + useComposeCast

• ⛽ Store scores onchain with a paymaster-sponsored flow (gasless UX)

(Watch the Video here)

System Architecture

1. User → Mini App (WebView in client): Tap-to-open from a cast or DM.

2. MiniKit Context: Provides device safe areas, user FID, client info.

3. UI & Logic (Next.js + OnchainKit): Trivia flow, identity display, sharing.

4. Smart Contract (Base): Optional leaderboard storage, paymaster-sponsored.

5. Social Client: Native share sheets, in-app browser, profile/cast deep links.

MiniKit
 Harnesses the in-client runtime: safe area insets, native buttons, closing flows, social navigation, and sharing.

OnchainKit
 UI primitives (Avatar, Name, …) and helpers that match ecosystem UX conventions.

Blockchain (Base)
 Leaderboard contract on Base; optional paymaster for gasless writes.

Part 1: The Why — Onchain Apps, Built for the Feed

Mini Apps flip the model. Instead of dragging users to an app store, the app goes to the user — living inside the feed, casting UI as content. You inherit an onchain social graph (Farcaster), skip installs, and unlock viral distribution.

Part 2: The How — Build “Social Trivia” (End-to-End)

Prerequisites

• Farcaster account (for testing + manifest signing)

• Node.js v18+

• A tunneling service (e.g., ngrok) for public dev URL

Step 1: Scaffold, Manifest & Validation

Bootstrap the project

# Scaffold a new Mini Appnpx create-onchain --mini

Create the Farcaster manifest at /public/.well-known/farcaster.json:

function withValidProperties(
  properties: Record<string, undefined | string | string[]>,
) {
  return Object.fromEntries(
    Object.entries(properties).filter(([key, value]) => {
      if (Array.isArray(value)) {
        return value.length > 0;
      }
      return !!value;
    }),
  );
}

export async function GET() {
  const URL = process.env.NEXT_PUBLIC_URL;

  return Response.json({
    accountAssociation: {
      header: process.env.FARCASTER_HEADER,
      payload: process.env.FARCASTER_PAYLOAD,
      signature: process.env.FARCASTER_SIGNATURE,
    },
    frame: withValidProperties({
      version: "1",
      name: process.env.NEXT_PUBLIC_ONCHAINKIT_PROJECT_NAME,
      subtitle: process.env.NEXT_PUBLIC_APP_SUBTITLE,
      description: process.env.NEXT_PUBLIC_APP_DESCRIPTION,
      screenshotUrls: [],
      iconUrl: process.env.NEXT_PUBLIC_APP_ICON,
      splashImageUrl: process.env.NEXT_PUBLIC_APP_SPLASH_IMAGE,
      splashBackgroundColor: process.env.NEXT_PUBLIC_SPLASH_BACKGROUND_COLOR,
      homeUrl: URL,
      webhookUrl: `${URL}/api/webhook`,
      primaryCategory: process.env.NEXT_PUBLIC_APP_PRIMARY_CATEGORY,
      tags: [],
      heroImageUrl: process.env.NEXT_PUBLIC_APP_HERO_IMAGE,
      tagline: process.env.NEXT_PUBLIC_APP_TAGLINE,
      ogTitle: process.env.NEXT_PUBLIC_APP_OG_TITLE,
      ogDescription: process.env.NEXT_PUBLIC_APP_OG_DESCRIPTION,
      ogImageUrl: process.env.NEXT_PUBLIC_APP_OG_IMAGE,
    }),
    baseBuilder: {
      allowedAddresses: ["base-builder-address-here"],
    },
  });
}

Dev tip: Farcaster clients can’t access localhost. Expose your app with ngrok and validate your URLs using the official Farcaster Manifest and Embed validators before debugging anything else.

Step 2: Context-Aware UI with OnchainKit + MiniKit

app/components/AppLayout.tsx

/// app/components/AppLayout.tsx
'use client';

import { useMiniKit } from '@coinbase/onchainkit/minikit';
import { ReactNode } from 'react';

export default function AppLayout({ children }: { children: ReactNode }) {
  const { context } = useMiniKit();
  
  const style = {
    paddingTop: `${context?.client?.safeAreaInsets?.top ?? 0}px`,
    paddingBottom: `${context?.client?.safeAreaInsets?.bottom ?? 0}px`,
    minHeight: '100vh',
    display: 'flex',
    flexDirection: 'column' as const,
  };
  
  return (
    <main style={style} className="bg-gradient-to-b from-slate-900 to-slate-800">
      {children}
    </main>
  );
}

app/page.tsx

// app/page.tsx
// ⚠️ SECURITY CRITICAL:
// The context object is for display and personalization ONLY.
// It is unverified and must not be used to authorize actions on your backend.
// For secure actions, you must use the useAuthenticate hook.
// app/page.tsx
"use client";

import { useEffect } from "react";
import { useMiniKit } from "@coinbase/onchainkit/minikit";
import AppLayout from "./components/AppLayout";
import TriviaGame from "./components/TriviaGame";

export default function App() {
  const { setFrameReady, isFrameReady, context } = useMiniKit();
  const userFid = context?.user?.fid;
  const username = context?.user?.username;
  const pfpUrl = context?.user?.pfpUrl;
  const displayName = context?.user?.displayName;

  useEffect(() => {
    if (!isFrameReady) {
      setFrameReady();
    }
  }, [setFrameReady, isFrameReady]);

  return (
    <AppLayout>
      <div className="flex-1 flex flex-col">
        {/* Header */}
        <div className="flex items-center justify-between p-4 bg-black/20 backdrop-blur-sm">
          <div className="flex items-center gap-3">
            {userFid ? (
              <>
                {pfpUrl && (
                  <img
                    src={pfpUrl}
                    alt={displayName || username || 'User'}
                    className="h-10 w-10 rounded-full"
                  />
                )}
                <div>
                  <h1 className="text-xl font-bold text-white">
                    <span>{displayName || username || 'Anonymous'}</span>
                  </h1>
                </div>
              </>
            ) : (
              <h1 className="text-xl font-bold text-white">Social Trivia</h1>
            )}
          </div>
        </div>

        {/* Game */}
        <div className="flex-1">
          <TriviaGame userFid={userFid as number} username={username as string} />
        </div>
      </div>
    </AppLayout>
  );
}

Security note: context is not authentication. It’s for personalized display only. Use useAuthenticate for verified, server-authorized actions.

Step 3: Engineer the Viral Social Loop

A. Progressive Auth with useAuthenticate
 Let users play first. Only prompt auth when saving a score or calling your backend.

B. Dynamic Embeds (Share Previews)
 Generate a share URL like /share?score=95&user=vitalik and render dynamic <meta> tags server-side so the cast preview becomes a personalized challenge card.

C. Native Share with useComposeCast

// app/components/ResultsScreen.tsx
const { composeCast } = useComposeCast();

const handleShare = () => {
  const shareUrl = `https://your-trivia-app.xyz/share?score=${score}&user=${username}`;
  composeCast({
    text: `I scored ${score}/100! Can you beat me?`,
    embeds: [shareUrl],
  });
};

D. Deep Social Navigation

// Leaderboard row → tap to view Farcaster profile
const viewProfile = useViewProfile(playerFid);
return <button onClick={viewProfile}><Name address={`fid:${playerFid}`} /></button>;

E. The Linking Rule: useOpenUrl (never raw <a>)

const openUrl = useOpenUrl('https://en.wikipedia.org/wiki/Trivia');
return <button onClick={openUrl}>Source</button>;

Step 4: Native UI & Flow Control

Primary Action with usePrimaryButton

usePrimaryButton({ text: 'Submit Answer' }, () => {
  handleSubmitAnswer();
});

Graceful Exit with useClose

const closeFrame = useClose();
return <button onClick={closeFrame}>Done</button>;

Step 5: Go Onchain — Gasless Leaderboard (Optional)

Solidity Contract (simplified tutorial version)

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

contract TriviaLeaderboard {
    mapping(address => uint256) public scores;
    function addScore(uint256 score) public {
        // NOTE: In production, verify a server signature before accepting scores.
        scores[msg.sender] = score;
    }
}

Production Security Tip
 Never trust client-submitted scores. Verify on a server first, then sign {userAddress, score} with your server key. Have the contract check that signature before addScore updates storage. Pair with a Paymaster (Coinbase Developer Platform) to sponsor gas so the UX feels Web2-smooth.

Frontend flow
 Configure MiniKitProvider with your Paymaster URL. Use standard wagmi hooks (useWriteContract) to store scores; MiniKit handles gasless plumbing under the hood.

Part 3: Ship It — Deployment, Verification & Registration

Step 6: Deploy & Verify Ownership

1. Deploy to Vercel (or similar).

2. Update the manifest URLs to your final prod domain.

3. In Base Build (base.dev): import your app, connect the wallet tied to your Farcaster account, and follow the verification prompts.

4. Merge the provided baseBuilder object into your manifest, for example:

{
  "frame": {
    "name": "Social Trivia",
    "homeUrl": "https://your-final-app-url.xyz",
    "noindex": false
  },
  "baseBuilder": {
    "allowedAddresses": [
      "0x...your...verified...address"
    ]
  }
}

Redeploy with this final manifest, then submit your production URL on Base Build to complete verification.

Step 7: Official Registration & Analytics

Registering your app unlocks:

• Directory discovery in the Base App

• Analytics for installs, usage, and retention

Conclusion & Call to Action

Recap

You built a social-native Mini App with MiniKit + OnchainKit: context-aware UI, native controls, viral sharing, deep social navigation, and an optional gasless onchain leaderboard on Base.

Next Steps

• Tweak copy and visuals on your dynamic share previews.

• Add useAddFrame (save to favorites) and useNotification (re-engagement) as they roll out.

• Harden your onchain writes with server-verified signatures and a paymaster.

CTA

• Explore Base Docs to go deeper on Mini Apps.

• Ship your v1, share it in the Base community, and tag @HeimLabs with what you build!

Resources & Links

Base Docs (Mini Apps):

Base - Base Documentation

The #1 Ethereum Layer 2, incubated by Coinbase

https://docs.base.org

OnchainKit Documentation:

Base | OnchainKit

Base is a secure, low-cost, builder-friendly Ethereum L2 built to bring the next billion users onchain.

https://www.base.org

Farcaster Docs:

Farcaster Docs

A protocol for building sufficiently decentralized social networks.

https://docs.farcaster.xyz

Base Discord: 

Join the Base Discord Server!

Base is a secure, low-cost, developer-friendly Ethereum L2 built to bring the next billion users onchain | 476227 members

https://discord.com

Demo Codebase:

GitHub - HeimLabs/coinbase-cdp-demos: A collection of Demo Projects exploring the Coinbase Developer Platform

A collection of Demo Projects exploring the Coinbase Developer Platform - HeimLabs/coinbase-cdp-demos

https://github.com

HeimLabs:

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Clap if this saved you hours, and share what you’re building with the CDP stack!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Happy Building 🚀

Introduction

Onchain social commerce has been too click-heavy: break out of the feed, connect a wallet, fight a checkout. Conversion drops.

Miniapps on TBA (The Base App) + the x402 protocol fix this. Miniapps are lightweight web apps that run directly inside a TBA feed. x402 revives HTTP’s dormant 402 Payment Required to turn any API route into a vending machine for paid content—seamlessly funded by onchain payments via Coinbase Developer Platform.

In this tutorial, we’ll build a fun, monetized Onchain Fortune Cookie Miniapp end-to-end:

• Bootstrap with the official x402 template

• Add a backend API and protect it with an x402 paywall

• Ship a mobile-ready React UI for the full flow inside TBA

• Upgrade to a premium tier with different pricing

By the end, you’ll have a working Miniapp you can share in a TBA cast and charge for — no janky redirects.

What You’ll Build

• 🧰 Clone and run the official x402 TypeScript full-stack template

• 🔐 Add /api/fortune protected by x402 ($0.01)

• 💳 Add a premium /api/golden-fortune tier ($0.10)

• 📱 A mobile-friendly Next.js page with two purchase buttons

• 🚀 Test in TBA using an ngrok URL that resolves into a Frame + “Use App” button

(Watch the Full Video here)

System Architecture

Key pieces:

• Miniapp UI (Next.js/React): Simple mobile layout with buttons that call /api/fortune and /api/golden-fortune. The fetch looks “normal”; x402 handles the payment handshake behind the scenes.

• x402 Middleware: Wraps routes in paymentMiddleware, pricing in fiat strings (e.g., "$0.01"), and selects Base or Base Sepolia. It triggers the onchain payment flow when a protected route is hit.

• Protected API Routes: Ordinary Next.js route.ts handlers—your business logic only runs after a successful payment.

• CDP + OnchainKit: Provides wallet infra, payment facilitation, and a smooth purchase flow.

• TBA + Frames: Your public HTTPS URL resolves into a Frame; the “Use App” button launches the Miniapp inline.

Part 1: Project Setup

We’ll start from the official x402 template to skip boilerplate.

1.1 Clone the repository & install dependencies

git clone https://github.com/coinbase/x402.git
cd x402/examples/typescript/fullstack/farcaster-miniapp

# Install all deps for the example
pnpm install
# Build the monorepo packages (critical)
cd ../../
pnpm install
pnpm build
# Go back to the example
cd fullstack/farcaster-miniapp

1.2 Configure environment variables

# Copy the example env
cp env.example .env.local

Edit .env.local:

# where payments land
RESOURCE_WALLET_ADDRESS=0xYourReceivingAddress

# base-sepolia for testing; switch to base for prod
NETWORK=base-sepolia
# CDP portal > OnchainKit
NEXT_PUBLIC_ONCHAINKIT_API_KEY=your_onchainkit_key
NEXT_PUBLIC_ONCHAINKIT_PROJECT_NAME=Onchain Fortune Cookie
# Use emoji placeholders - no image files needed
NEXT_PUBLIC_APP_HERO_IMAGE=https://emojicdn.elk.sh/🥠?style=apple&size=600
NEXT_PUBLIC_APP_ICON=https://emojicdn.elk.sh/🥠?style=apple&size=200
NEXT_PUBLIC_APP_SPLASH_IMAGE=https://emojicdn.elk.sh/🥠?style=apple&size=200
NEXT_PUBLIC_ICON_URL=https://emojicdn.elk.sh/🥠?style=apple&size=200

Tip: For production, move to NETWORK=base and swap RESOURCE_WALLET_ADDRESS accordingly.

Part 2: Backend — Fortune API

Create a simple paid content endpoint.

2.1 Create the route

File: app/api/fortune/route.ts

import { NextResponse } from "next/server";

const fortunes = [
  "Your next transaction will be blessed with low gas fees.",
  "A 100x gem is in your near future. DYOR.",
  "The blockchain whispers secrets of prosperity to you.",
  "You will successfully avoid a rug pull this week.",
  "GM will bring you good luck today.",
  "Diamond hands will lead to diamond rings.",
  "A wild airdrop appears! It's super effective.",
];
export async function GET() {
  // Runs only AFTER a successful x402 payment
  const ix = Math.floor(Math.random() * fortunes.length);
  return NextResponse.json({ fortune: fortunes[ix], timestamp: new Date().toISOString() });

Part 3: Protect with x402

Wrap the route with paymentMiddleware and set the price.

File: middleware.ts

import { facilitator } from "@coinbase/x402";
import { Address } from "viem";
import { paymentMiddleware } from "x402-next";

const payTo = process.env.RESOURCE_WALLET_ADDRESS as Address;
const network = (process.env.NETWORK || "base-sepolia") as "base" | "base-sepolia";
export const middleware = paymentMiddleware(
  payTo,
  {
    "/api/fortune": {
      price: "$0.01",
      network,
      config: { description: "Your onchain fortune cookie!" },
    },
  },
  facilitator,
);
export const config = {
  matcher: ["/api/fortune"],
  runtime: "nodejs",
};

Any request to /api/fortune now triggers a $0.01 payment before the handler executes.

Part 4: Frontend UI (Next.js)

Create a minimal, mobile-first page with two buttons (standard + premium). If your template already includes a full page, you can replace it; otherwise add this as app/page.tsx.

File: app/page.tsx

"use client";

import { useState } from "react";
export default function FortuneCookieApp() {
  const [loading, setLoading] = useState<null | "basic" | "golden">(null);
  const [result, setResult] = useState<string>("");
  async function fetchFortune(path: "/api/fortune" | "/api/golden-fortune", tier: "basic" | "golden") {
    try {
      setLoading(tier);
      setResult("");
      const res = await fetch(path, { method: "GET" });
      // If payment is needed, the x402 middleware will orchestrate it.
      // From the client, this remains a normal fetch that resolves after purchase.
      if (!res.ok) {
        const text = await res.text();
        throw new Error(`Request failed: ${res.status} ${text}`);
      }
      const data = await res.json();
      setResult(data.fortune ?? JSON.stringify(data));
    } catch (e: any) {
      setResult(e?.message ?? "Something went wrong.");
    } finally {
      setLoading(null);
    }
  }
  return (
    <main className="min-h-screen bg-[#0c0c10] text-white flex flex-col items-center px-4 py-10">
      <div className="w-full max-w-md">
        <div className="flex flex-col items-center gap-3 mb-8">
          <div className="text-6xl">🥠</div>
          <h1 className="text-2xl font-semibold text-center">Onchain Fortune Cookie</h1>
          <p className="text-sm opacity-80 text-center">
            Grab a fortune inside TBA. Pay per request using x402 on Base Sepolia.
          </p>
        </div>
        <div className="grid grid-cols-1 gap-3">
          <button
            onClick={() => fetchFortune("/api/fortune", "basic")}
            disabled={loading !== null}
            className="rounded-2xl px-4 py-4 bg-white/10 hover:bg-white/15 transition border border-white/10"
          >
            {loading === "basic" ? "Purchasing…" : "Buy Fortune - $0.01"}
          </button>
          <button
            onClick={() => fetchFortune("/api/golden-fortune", "golden")}
            disabled={loading !== null}
            className="rounded-2xl px-4 py-4 bg-yellow-500/20 hover:bg-yellow-500/25 transition border border-yellow-500/30"
          >
            {loading === "golden" ? "Purchasing… " : "Buy GOLDEN Fortune - $0.10"}
          </button>
        </div>
        <div className="mt-6 min-h-[96px] rounded-2xl border border-white/10 bg-white/5 p-4">
          <div className="text-xs uppercase tracking-wide opacity-60 mb-1">Result</div>
          <p className="text-base leading-6">{result || "-"}</p>
        </div>
        <p className="mt-6 text-xs opacity-60 text-center">
          Network: {process.env.NEXT_PUBLIC_NETWORK ?? "base-sepolia"} · Powered by x402
        </p>
      </div>
    </main>
  );
}

Note: The payment UX is handled by x402 when your protected route is hit. Your client code stays simple: call fetch and display the response.

Part 5: Test Locally in TBA

We’ll expose your dev server to the internet so TBA can frame it.

1. Run dev server

1. Expose with ngrok (new terminal)

ngrok http 3000

1. Update your env

Copy the public https://… URL from ngrok to .env.local:

NEXT_PUBLIC_URL=https://your-ngrok-id.ngrok-free.app

Restart dev:

# stop then
pnpm dev

1. Open in TBA

• In TBA, create a new cast with your NEXT_PUBLIC_URL.

• The URL resolves to a Frame with a Use App button.

• Tap it to launch your Miniapp inline and complete a purchase.

Part 6: Tiered Pricing (Premium “Golden Fortune”)

6.1 Premium backend route

File: app/api/golden-fortune/route.ts

import { NextResponse } from "next/server";

const goldenFortunes = [
  "You've found the legendary Diamond Hand Pepe. Hodl for unimaginable gains.",
  "The memecoin you ape into next will not be a rug. This is financial advice.",
  "Satoshi's ghost will reveal the next big narrative to you tonight.",
];
export async function GET() {
  const ix = Math.floor(Math.random() * goldenFortunes.length);
  return NextResponse.json({ fortune: goldenFortunes[ix], isGolden: true, timestamp: new Date().toISOString() });
}

6.2 Update middleware with a second priced route

File: middleware.ts (updated)

import { facilitator } from "@coinbase/x402";
import { Address } from "viem";
import { paymentMiddleware } from "x402-next";

const payTo = process.env.RESOURCE_WALLET_ADDRESS as Address;
const network = (process.env.NETWORK || "base-sepolia") as "base" | "base-sepolia";
export const middleware = paymentMiddleware(
  payTo,
  {
    "/api/fortune": {
      price: "$0.01",
      network,
      config: { description: "Your onchain fortune cookie!" },
    },
    "/api/golden-fortune": {
      price: "$0.10",
      network,
      config: { description: "Your GOLDEN onchain fortune cookie!" },
    },
  },
  facilitator,
);
export const config = {
  matcher: ["/api/fortune", "/api/golden-fortune"],
  runtime: "nodejs",
};

No UI changes needed if you used the two-button page above.

The Final Demo

• Run pnpm dev and ngrok http 3000

• Cast your ngrok URL in TBA → “Use App”

• Purchase Fortune ($0.01) or Golden Fortune ($0.10)

• See the paid content return in-app — no context switching

Conclusion & Next Steps

You just shipped a multi-tier, monetized Miniapp that runs inside TBA, using x402 to price-gate API routes and CDP infra to handle payments.

Next ideas:

• Add more tiers and content types (e.g., images, signed data, gated downloads)

• Switch to NETWORK=base for production and set a mainnet receiver wallet

• Personalize pricing per route, per user, or time-boxed sales

• Track purchases and receipts for analytics

Source: Explore the official x402 examples repo to extend this project.
 Community: Join the Coinbase Developer Platform Discord to share builds and get help.

Resources & Links

x402 Examples 

GitHub - coinbase/x402: A payments protocol for the internet. Built on HTTP.

A payments protocol for the internet. Built on HTTP. - coinbase/x402

https://github.com

Coinbase Developer Docs

Coinbase Developer Docs - Coinbase Developer Documentation

Explore our API & SDK references, demos, and guides for building onchain apps.

https://docs.cdp.coinbase.com

HeimLabs

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

TBA (The Base App): (see product links)

Base

Base is an open stack that empowers builders, creators, and people everywhere to build apps, grow businesses, create what they love, and earn onchain.

https://www.base.org

Clap if this saved you hours, and share what you’re building with the CDP stack!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Happy Building 🚀

Introduction

Running onchain apps used to mean babysitting nodes and guarding private keys. Even simple automations — like watching for payments and reacting — were fragile and slow to build.

Today, we’ll fix that. You’ll build a fully autonomous onchain agent that uses Coinbase Developer Platform (CDP) Data APIs for real‑time awareness and Server Wallets v2 for secure, programmatic actions. In TypeScript. From scratch.

By the end, you’ll have a bot that:

• Detects incoming USDC transfers on Base via the SQL API

• Automatically forwards a 5% platform fee using Server Wallets v2

• Periodically reports your treasury’s USDC balance using the Token Balances API

What You’ll Build

• 🔭 Monitor USDC Transfer events on Base with the SQL API

• 🤖 React by sending onchain ERC‑20 transfers via Server Wallets v2

• 📊 Report treasury balance with the Token Balances API

• 🛡 Operate with secure key management — no raw keys in your app

• 🧰 Ship a clean, copy‑pasteable TypeScript project

(Watch the full video here)

Components in brief

• CDP Data APIs: SQL API for event queries; Token Balances API for wallet state.

• Server Wallets v2: Managed wallets with secure signing and transaction dispatch.

• Viem: ABI encoding for ERC‑20 transfer.

• Axios + dotenv: Simple HTTP + secret management.

Step‑by‑Step Walkthrough

Step 1: Bootstrap Your TypeScript Project

Create and initialize

mkdir cdp-payment-bot && cd cdp-payment-bot
npm init -y
npm pkg set type="module"

Install dependencies

npm install @coinbase/cdp-sdk dotenv axios viem

Scaffold files

mkdir src
printf "" > src/bot.ts
printf "" > .env

Create tsconfig.json

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "esModuleInterop": true,
    "strict": true,
    "skipLibCheck": true,
    "outDir": "./dist"
  }
}

Add secrets to .env

# .env
CDP_API_KEY_SECRET="your-api-key-secret-here"
CDP_API_KEY_ID="your-api-key-id-here"
CDP_WALLET_SECRET="your-wallet-secret-here"
CDP_CLIENT_API_KEY="your-client-api-key-here"

✅ Tip: Make sure your keys have access to Data APIs and Server Wallets v2 in the CDP dashboard.

Step 2: Paste the Bot (Awareness → Action)

Create src/bot.ts and paste the full, tested script below.

import { CdpClient } from "@coinbase/cdp-sdk";
import axios from "axios";
import dotenv from "dotenv";
import { encodeFunctionData } from "viem";

// Load environment variables
dotenv.config();

// Validate required environment variables
if (
  !process.env.CDP_API_KEY_ID ||
  !process.env.CDP_API_KEY_SECRET ||
  !process.env.CDP_WALLET_SECRET ||
  !process.env.CDP_CLIENT_API_KEY
) {
  console.error("❌ ERROR: Missing required environment variable!");
  console.error(
    "Please ensure CDP_API_KEY_ID, CDP_API_KEY_SECRET, CDP_WALLET_SECRET, and CDP_CLIENT_API_KEY are set in your .env file"
  );
  process.exit(1);
}

// Initialize the CDP Client
const cdp = new CdpClient();
console.log("🚀 CDP Client Initialized.");

// OFFICIAL Base Mainnet USDC Contract Address
const USDC_CONTRACT_ADDRESS = "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913";

// CDP SQL API Endpoint
const CDP_API_URL = "https://api.cdp.coinbase.com/platform/v2/data/query/run";

// A minimal ABI for the ERC-20 transfer function
const erc20Abi = [
  {
    name: "transfer",
    type: "function",
    inputs: [
      { type: "address", name: "to" },
      { type: "uint256", name: "amount" },
    ],
    outputs: [{ type: "boolean" }],
    stateMutability: "nonpayable",
  },
] as const;

// Type definition for EVM Account
interface EvmAccount {
  address: string;
  name?: string;
}

/**
 * Provisions a new EVM account managed by CDP or retrieves an existing one.
 */
async function provisionAccount(name: string): Promise<EvmAccount> {
    try {
      console.log(`[Provisioner] Checking for account named '${name}'...`);
      const account = await cdp.evm.getOrCreateAccount({ name });
      console.log(
        `[Provisioner] ✅ Account '${name}' ready at address: ${account.address}`
      );
      return account;
    } catch (error) {
      console.error(
        `[Provisioner] ❌ Failed to provision account '${name}':`,
        error
      );
      throw error;
    }
}

/**
 * Queries the CDP SQL API to find new USDC transfers to our receiver address.
 * Uses the base.events table to query Transfer events
 */
async function checkForNewPayments(
    receiverAddress: string,
    lastCheckedTimestamp: string
  ): Promise<any[]> {
    // Query the base.events table for Transfer events
    // Using parameter access pattern: parameters['field']::Type
    const sql = `
      SELECT
    transaction_hash,
    parameters['from']::String AS from_address,
    parameters['to']::String AS to_address,
    parameters['value']::UInt256 AS value,
    block_timestamp
  FROM
    base.events
  WHERE
    event_signature = 'Transfer(address,address,uint256)'
    AND address = LOWER('${USDC_CONTRACT_ADDRESS}')
    AND LOWER(parameters['to']::String) = LOWER('${receiverAddress}')
    AND block_timestamp > '${lastCheckedTimestamp}'
  ORDER BY
    block_timestamp ASC
  LIMIT 100
    `;
  
    try {
      const headers = {
        Authorization: `Bearer ${process.env.CDP_CLIENT_API_KEY}`,
        "Content-Type": "application/json",
      };
  
      const response = await axios.post(CDP_API_URL, { sql }, { headers });
  
      if (response.data && response.data.result) {
        const resultCount = response.data.result.length;
        if (resultCount > 0) {
          console.log(`[SQL API] Found ${resultCount} new payment(s)`);
        }
        return response.data.result;
      }
  
      return [];
    } catch (error: any) {
      if (error.response) {
        console.error("[SQL API] ❌ Error response:", {
          status: error.response.status,
          data: error.response.data,
        });
      } else if (error.request) {
        console.error("[SQL API] ❌ No response received");
      } else {
        console.error("[SQL API] ❌ Error:", error.message);
      }
      return [];
    }
}

/**
 * Uses the Token Balances API to check and report the treasury's USDC balance.
 */
async function reportTreasuryBalance(treasury: EvmAccount): Promise<void> {
    try {
      const response = await cdp.evm.listTokenBalances({
        address: treasury.address as `0x${string}`,
        network: "base",
      });
  
      // Find USDC balance in the response
      const usdcBalance = response.balances.find(
        (b: any) =>
          b.token.contractAddress?.toLowerCase() ===
          USDC_CONTRACT_ADDRESS.toLowerCase()
      );
  
      if (usdcBalance) {
        // USDC has 6 decimals
        const amount =
          Number(BigInt(usdcBalance.amount.amount) / BigInt(1e4)) / 100;
        console.log(
          `[Reporter] 💰 Treasury Balance: ${amount.toLocaleString("en-US", {
            style: "currency",
            currency: "USD",
          })} USDC`
        );
      } else {
        console.log(`[Reporter] 💰 Treasury Balance: $0.00 USDC`);
      }
    } catch (error: any) {
      console.error(
        "[Reporter] ❌ Error fetching treasury balance:",
        error.message || error
      );
    }
}

/**
 * Sends the calculated platform fee from the receiver wallet to the treasury wallet.
 */
async function sendFeeTransaction(
    receiverAccount: EvmAccount,
    treasuryAddress: string,
    feeAmount: bigint
  ): Promise<string | undefined> {
    try {
      // Convert to human-readable amount for logging (USDC has 6 decimals)
      const humanAmount = Number(feeAmount) / 1e6;
      console.log(
        `[Reactor] Forwarding fee of ${humanAmount.toFixed(
          6
        )} USDC to treasury...`
      );
  
      // Create the transaction data for ERC-20 transfer
      const data = encodeFunctionData({
        abi: erc20Abi,
        functionName: "transfer",
        args: [treasuryAddress as `0x${string}`, feeAmount],
      });
  
      // Send the transaction using CDP SDK
      const result = await cdp.evm.sendTransaction({
        address: receiverAccount.address as `0x${string}`,
        network: "base",
        transaction: {
          to: USDC_CONTRACT_ADDRESS,
          value: 0n, // No ETH value for token transfer
          data: data,
        },
      });
  
      console.log(
        `[Reactor] ✅ Fee transaction sent! Hash: https://basescan.org/tx/${result.transactionHash}`
      );
      return result.transactionHash;
    } catch (error: any) {
      console.error(
        "[Reactor] ❌ Failed to send fee transaction:",
        error.message || error
      );
  
      // Check if it's a gas-related error
      if (
        error.message?.includes("gas") ||
        error.message?.includes("insufficient")
      ) {
        console.error(
          "[Reactor] 💡 Hint: Ensure the receiver account has enough ETH for gas fees"
        );
      }
  
      return undefined;
    }
}

/**
 * Main function to run the autonomous payment bot
 */
async function main() {
    console.log("--- 🏁 Starting Onchain Agent ---");
    console.log(`📅 Current time: ${new Date().toISOString()}`);
  
    try {
      // 1. Provision the wallets our agent will use
      const receiverAccount = await provisionAccount("payment-receiver-bot");
      const treasuryAccount = await provisionAccount("platform-treasury-bot");
  
      // 2. CRITICAL WARNING
      console.log(
        "\n❗️❗️ WARNING: THIS AGENT OPERATES ON BASE MAINNET WITH REAL FUNDS ❗️❗️"
      );
      console.log("⚠️  Please ensure the following before starting:");
      console.log("   1. Fund the receiver with ETH for gas fees");
      console.log("   2. Test with small amounts first");
      console.log("   3. Monitor the addresses below:\n");
      console.log(`💰 Receiver Address: ${receiverAccount.address}`);
      console.log(`🏦 Treasury Address: ${treasuryAccount.address}`);
      console.log(
        "\nPress Ctrl+C to exit if you need to prepare the accounts first.\n"
      );
  
      // Initialize timestamp for payment tracking - SQL format
      let lastCheckedTimestamp = new Date().toISOString().replace('T', ' ').substring(0, 19);
  
      // Test SQL API connectivity with a simple query
      console.log("--- 🔍 Testing SQL API Connectivity ---");
      const testSql = `
        SELECT COUNT(*) as count 
        FROM base.events 
        WHERE event_signature = 'Transfer(address,address,uint256)' 
        LIMIT 1
      `;
  
      try {
        const testResponse = await axios.post(
          CDP_API_URL,
          { sql: testSql },
          {
            headers: {
              Authorization: `Bearer ${process.env.CDP_CLIENT_API_KEY}`,
              "Content-Type": "application/json",
            },
          }
        );
        console.log(`[Test] ✅ SQL API connected successfully`);
      } catch (error: any) {
        console.error(
          "[Test] ❌ Failed to connect to SQL API:",
          error.response?.data || error.message
        );
        console.error(
          "Please check your CDP_CLIENT_API_KEY and ensure it has proper permissions"
        );
        process.exit(1);
      }
  
      // Loop 1: Check for new payments every 10 seconds
      console.log(
        "\n--- ⏰ Starting Payment Monitoring Loop (every 10 seconds) ---"
      );
      const paymentInterval = setInterval(async () => {
        try {
          const newPayments = await checkForNewPayments(
            receiverAccount.address,
            lastCheckedTimestamp
          );
  
          if (newPayments.length > 0) {
            console.log(
              `\n[Detector] 🎉 Found ${newPayments.length} new payment(s)!`
            );
  
            for (const payment of newPayments) {
              console.log(
                `[Detector] Processing payment from ${payment.from_address}`
              );
              console.log(
                `[Detector] Amount: ${BigInt(payment.value)} (smallest unit)`
              );
  
              const paymentValue = BigInt(payment.value);
              const feeValue = paymentValue / 20n; // Calculate 5% fee
  
              if (feeValue > 0n) {
                const txHash = await sendFeeTransaction(
                  receiverAccount,
                  treasuryAccount.address,
                  feeValue
                );
                if (txHash) {
                  console.log(
                    `[Reactor] Successfully processed fee for payment ${payment.transaction_hash}`
                  );
                }
              } else {
                console.log(`[Reactor] Payment amount too small to collect fee`);
              }
  
              // Update the timestamp to avoid reprocessing
              lastCheckedTimestamp = payment.block_timestamp;
            }
          } else {
            // Quiet log - only show periodically
            const now = new Date();
            if (now.getSeconds() % 30 === 0) {
              console.log(
                `[Monitor] Watching for new USDC payments... (${now.toLocaleTimeString()})`
              );
            }
          }
        } catch (error) {
          console.error("[Payment Loop] Error in payment monitoring:", error);
        }
      }, 10000);
  
      // Loop 2: Report treasury balance every 60 seconds
      console.log(
        "--- 📈 Starting Treasury Reporting Loop (every 60 seconds) ---"
      );
      const reportingInterval = setInterval(async () => {
        await reportTreasuryBalance(treasuryAccount);
      }, 60000);
  
      // Initial balance report
      await reportTreasuryBalance(treasuryAccount);
  
      // Graceful shutdown handler
      process.on("SIGINT", () => {
        console.log("\n\n--- 🛑 Shutting down gracefully ---");
        clearInterval(paymentInterval);
        clearInterval(reportingInterval);
        console.log("✅ All intervals cleared. Goodbye!");
        process.exit(0);
      });
    } catch (error: any) {
      console.error(
        "\n❌ Critical error during initialization:",
        error.message || error
      );
      process.exit(1);
    }
  }

// Run the main function
main().catch((error) => {
  console.error("\n❌ Unhandled error:", error);
  process.exit(1);
});

Step 3: Run the Agent

Build and start

npx tsc && node dist/bot.js

You’ll see the monitoring and reporting loops start. Send a small USDC transfer to the receiver address printed in the console. The bot will:

• Detect the payment via SQL API

• Compute a 5% fee

• Send an ERC‑20 transfer from the receiver to the treasury

• Log the transaction hash and update the treasury balance report

⚠ Mainnet Warning: This script targets Base mainnet and moves real funds. Start with tiny amounts, keep the receiver funded with ETH for gas, and monitor activity closely.

Conclusion & Call to Action

You just built an Awareness → Action loop using CDP Data APIs and Server Wallets v2 — a foundation for autonomous DeFi bots, game backends, and more. Because CDP unifies EVM networks, you can adapt this pattern to Ethereum, Polygon, and beyond with minimal changes.

Next Steps

• Swap the SQL query to watch a different contract or event signature

• Add rate‑limiting, alerts, or retries around the reactor

• Extend reporting (e.g., multi‑token balances, PnL snapshots)

CTA

• Explore CDP Docs: https://docs.cdp.coinbase.com

• Join the Coinbase Developer Discord

• Follow HeimLabs for more builder‑first tutorials

Resources & Links

CDP Documentation:

Coinbase Developer Docs - Coinbase Developer Documentation

Explore our API & SDK references, demos, and guides for building onchain apps.

https://docs.cdp.coinbase.com

Server Wallets v2:

Welcome to Server Wallet v2 - Coinbase Developer Documentation

The v2 Server Wallet enables developers to programmatically create, manage, and use crypto accounts while CDP secures the private keys and handles complex infrastructure management. Developers can access the v2 Server Wallet through either the CDP SDK or CDP's REST endpoints.

https://docs.cdp.coinbase.com

Data APIs (SQL + Balances):

Welcome to Onchain Data - Coinbase Developer Documentation

Welcome to the onchain data documentation for developers! This is a suite of enterprise-grade developer tools that simplify reading and interacting with blockchain data. To learn more about our motivations and development history, please refer to our development blog series. Log into the Coinbase Developer Platform portal- directly or from Coinbase.com.

https://docs.cdp.coinbase.com

Viem:

Viem · TypeScript Interface for Ethereum

Build reliable Ethereum apps & libraries with lightweight, composable, & type-safe modules from viem.

https://viem.sh

HeimLabs:

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

Twitter, LinkedIn.

Happy building! 🚀

Seed phrases, gas pop-ups, “approve then transfer” — the classic wallet UX slows users (and your growth) to a crawl. Base Accounts fix this. Built on ERC-4337, they’re a programmable, multi-chain account layer that unlocks passkeys, social recovery, sponsored gas, batching, and more.

In this hands-on guide, you’ll learn why Base Accounts matter and how to ship a production-grade app: passwordless auth, one-tap USDC payments, gasless calls, sub-accounts for zero-prompt interactions, and automated subscriptions with spend permissions.

What You’ll Build

• Scaffold a Next.js + wagmi app with “Sign in with Base.”

• Add Base Pay for one-tap USDC checkout (testnet friendly).

• Use Paymasters to sponsor gas (true gasless UX).

• Create Sub-Accounts for zero-prompt actions.

• Automate billing with Spend Permissions (revocable allowances).

(Watch the Full Video here)

Why Base Accounts (vs. EOAs)

Powered by Account Abstraction (ERC-4337), Base Accounts bring modern app UX to onchain.

System Architecture

Components at a glance

• Base Account SDK & UI: Auth, checkout, sub-accounts, permissions.

• wagmi: Chain config + connectors.

• Paymaster: Sponsors user gas.

• Sub-Accounts: App-scoped, embedded wallets for zero-prompt actions.

• Spend Permissions: Off-chain signed allowances you can execute on a schedule.

Part 1 — Project Scaffolding & Setup

1. Create the app

# Next.js + wagmi
npm create wagmi@latest base-accounts-demo
cd base-accounts-demo

2. Install Base Accounts SDK & UI

npm install @base-org/account @base-org/account-ui

3. Configure wagmi with Base + Base Sepolia

import { http, createConfig } from 'wagmi';
import { baseSepolia } from 'wagmi/chains';
import { baseAccount } from '@wagmi/connectors';

export const config = createConfig({
  chains: [baseSepolia],
  connectors: [
    baseAccount({
      appName: 'Base Accounts Demo',
      appLogoUrl: 'https://base.org/logo.png',
    }),
  ],
  transports: {
    [baseSepolia.id]: http(),
  },
  // Enable server-side rendering
  ssr: true,
});

export function getConfig() {
  return config
}

This enables “Sign in with Base” as a first-class connector.

Part 2 — Passwordless Auth (SIWE)

Use EIP-4361 (SIWE) with a server-side nonce + signature verification. Never verify on the client.

1. UI: a consistent, trusted sign-in + Client: fetch nonce → request signat

import React from 'react'
import { createBaseAccountSDK } from '@base-org/account'

type LoginFormProps = {
  onSignIn?: (address: string) => void;
  isSigningIn?: boolean;
};

export function LoginForm({ onSignIn, isSigningIn }: LoginFormProps) {
  const handleSignIn = async () => {
    try {
      const provider = createBaseAccountSDK({ appName: 'Base Accounts Demo' }).getProvider()
      const nonce = window.crypto.randomUUID().replace(/-/g, '')
      const response = await provider.request({
        method: 'wallet_connect',
        params: [
          {
            version: '1',
            capabilities: {
              signInWithEthereum: {
                // chainid must be a hex string
                chainId: "0x" + (8453).toString(16),
                nonce,
              },
            },
          },
        ],
      }) as { accounts: { address: string; capabilities?: { signInWithEthereum?: { message: string; signature: `0x${string}` } } }[] }

      // Extract SIWE message & signature and verify on server
      const account = response.accounts[0]
      const { address } = account
      const siwe = account.capabilities?.signInWithEthereum as { message: string; signature: `0x${string}` }
      const message = siwe?.message
      const signature = siwe?.signature

      const verifyRes = await fetch('/api/auth/verify', {
        method: 'POST',
        headers: { 'content-type': 'application/json' },
        body: JSON.stringify({ address, message, signature }),
      })
      if (!verifyRes.ok) {
        const err = await verifyRes.json().catch(() => ({}))
        throw new Error(err?.error || 'Verification failed')
      }

      onSignIn?.(address)
    } catch (err) {
      console.error('Sign in failed:', err)
    }
  }

  return (
    <button type="button" onClick={handleSignIn} disabled={!!isSigningIn} style={{
      display: 'flex', alignItems: 'center', justifyContent: 'center', gap: 8, padding: '12px 16px',
      backgroundColor: '#ffffff', border: '1px solid #e5e7eb', borderRadius: 8, cursor: isSigningIn ? 'not-allowed' : 'pointer',
      minWidth: 180, height: 44
    }}>
      <div style={{ width: 16, height: 16, backgroundColor: '#0052FF', borderRadius: 2 }} />
      <span>{isSigningIn ? 'Signing in...' : 'Sign in with Base'}</span>
    </button>
  )
}

2. Backend: verify and create a session

import { NextRequest, NextResponse } from 'next/server'

// Demo behavior:
// - This route mirrors the agent project: accepts an address and issues a simple session cookie.
// - It intentionally does NOT verify a signed message (no viem.verifyMessage) to keep the demo minimal.
//   To enforce SIWE-style verification in production:
//     1) Request { address, message, signature } from the client.
//     2) Extract & validate a one-time nonce persisted in a shared store (e.g. Redis/DB).
//     3) Verify with viem's public client verifyMessage before issuing a session.
const nonces = new Set<string>()

export async function POST(request: NextRequest) {
  try {
    const { address } = await request.json()

    if (!address) {
      return NextResponse.json({ error: 'Missing address' }, { status: 400 })
    }

    // Create session token (simplified - in production use proper JWT with SESSION_SECRET)
    // For demo purposes, using simple encoding - in production, use proper JWT:
    // const jwt = require('jsonwebtoken')
    // const sessionToken = jwt.sign({ address, timestamp: Date.now() }, process.env.SESSION_SECRET)
    const sessionToken = Buffer.from(`${address}:${Date.now()}`).toString('base64')
    const response = NextResponse.json({ ok: true, address, sessionToken })
    response.cookies.set('session', sessionToken, {
      httpOnly: true,
      secure: false,
      sameSite: 'strict',
      maxAge: 60 * 60 * 24 * 7,
    })
    return response
  } catch (error) {
    console.error('Auth verification error:', error)
    return NextResponse.json({ error: 'Internal server error' }, { status: 500 })
  }
}

export async function GET() {
  const array = new Uint8Array(16)
  crypto.getRandomValues(array)
  const nonce = Array.from(array, (byte) => byte.toString(16).padStart(2, '0')).join('')
  nonces.add(nonce)
  return NextResponse.json({ nonce })
}

Tip: Persist nonces + sessions in Redis/DB in production.

Part 3 — One-Tap Payments with Base Pay

1. Drop-in checkout UI

// components/CheckoutForm.tsx
import { BasePayButton } from '@base-org/account-ui/react';

export function CheckoutForm({ onPay, isPaying }) {
  return (
    <div>
      <h3>Awesome Product - $1.00</h3>
      <BasePayButton onClick={onPay} disabled={isPaying} />
    </div>
  );
}

2. Initiate payment and poll

// pages/checkout.tsx (excerpt)
import { pay, getPaymentStatus } from '@base-org/account';
import { useState } from 'react';

function CheckoutPage() {
  const [status, setStatus] = useState<'idle'|'pending'|'completed'|'failed'>('idle');
  const handlePayment = async () => {
    setStatus('pending');
    try {
      const { id } = await pay({ amount: '1.00', to: '0xRecipientAddress', testnet: true });
      const poll = async () => {
        const { status: s, userTxHash } = await getPaymentStatus({ id, testnet: true });
        if (s === 'completed') { setStatus('completed'); console.log('Tx:', userTxHash); }
        else if (s === 'failed') { setStatus('failed'); }
        else setTimeout(poll, 1000);
      };
      poll();
    } catch {
      setStatus('failed');
    }
  };
}

Part 4 — The Magic: Gasless + Zero-Prompt + Auto-Billing

A) True Gasless UX with Paymasters

Proxy your Paymaster URL through your backend.

import { ensureBaseProviderConnected, getBaseAccountProvider } from '@/lib/base-account-sdk'
import { toHex } from 'viem'

/**
 * Gas Sponsorship (Paymaster) functionality for Base Account
 * Complete implementation of sponsored transactions
 */

export interface PaymasterConfig {
  url: string
  type: 'eth'
  sponsorshipRules?: {
    maxGasLimit?: number
    allowedMethods?: string[]
    dailyLimit?: number
  }
}

// In production, use your own paymaster proxy endpoints for security and control
export const PAYMASTER_CONFIGS = {
  default: {
    // Proxy or CDP Paymaster URL: set via env for security
    url:
      process.env.NEXT_PUBLIC_PAYMASTER_PROXY_SERVER_URL ||
      'https://api.developer.coinbase.com/rpc/v1/base-sepolia/demo',
    type: 'eth' as const,
    sponsorshipRules: {
      maxGasLimit: 1000000,
      dailyLimit: 10
    }
  }
}

/**
 * Send sponsored transaction
 * In production: implement your own paymaster proxy for security and control
 */

/**
 * Send sponsored calls with custom configuration
 */
// Send a transaction sponsored by a Paymaster using wallet_sendCalls.
// - userAddress: user's smart account address
// - calls: array of low-level calls to execute
// - chainId: Base Sepolia (84532) in this tutorial
export async function sendSponsoredCalls(
  userAddress: `0x${string}`,
  chainId: number,
  calls: Array<{ 
    to: `0x${string}`
    value?: string
    data?: `0x${string}` 
  }>,
  config: PaymasterConfig = PAYMASTER_CONFIGS.default
): Promise<string | null> {
  const provider = getBaseAccountProvider()
  await ensureBaseProviderConnected()

  try {
    const normalizedCalls = calls.map((c) => ({
      to: c.to,
      data: (c.data || '0x') as `0x${string}`,
      value: toHex(c.value ? BigInt(c.value) : 0n),
    }))

    const txHash = await provider.request({
      method: 'wallet_sendCalls',
      params: [{
        from: userAddress,
        chainId: toHex(84532),
        version: '1',
        calls: normalizedCalls,
        capabilities: { 
          paymasterService: { 
            url: process.env.NEXT_PUBLIC_PAYMASTER_PROXY_SERVER_URL || 'https://api.developer.coinbase.com/rpc/v1/base-sepolia/demo',
            ...(config.sponsorshipRules && { data: config.sponsorshipRules })
          } 
        },
      }],
    }) as string

    console.log('Sponsored calls sent:', txHash)
    return txHash
  } catch (error) {
    console.error('Sponsored calls failed:', error)
    return null
  }
}

The wallet clearly shows “Fee: Sponsored.”

B) Eliminate Pop-ups with Sub-Accounts

Create an app-scoped, embedded wallet so frequent actions won’t prompt.

import { ensureBaseProviderConnected, getBaseAccountProvider } from '@/lib/base-account-sdk'
import { toHex } from 'viem'

// Minimal interface for sub-account info as returned by wallet_getSubAccounts
type SubAccountInfo = {
  address: `0x${string}`
  factory?: `0x${string}`
  factoryData?: `0x${string}`
}

type GetSubAccountsResponse = {
  subAccounts?: SubAccountInfo[]
}

type AddSubAccountResponse = SubAccountInfo

/**
 * Comprehensive Sub-Account management for Base Account
 * Implements all sub-account capabilities from Base Account documentation
 */

/**
 * Get existing sub-accounts for the user
 */
export async function getSubAccounts(
  universalAddress: `0x${string}`,
  chainId: number,
  domain?: string
): Promise<SubAccountInfo[]> {
  const provider = getBaseAccountProvider()
  await ensureBaseProviderConnected()

  try {
    const { subAccounts } = (await provider.request({
      method: 'wallet_getSubAccounts',
      params: [{ 
        version: '1', 
        account: universalAddress, 
        domain: domain || window.location.origin, 
        chainId: toHex(84532) 
      }],
    })) as GetSubAccountsResponse

    return subAccounts || []
  } catch (error) {
    console.error('Failed to get sub-accounts:', error)
    return []
  }
}

/**
 * Create a new sub-account
 */
export async function createSubAccount(
  accountType: 'create' | 'import' = 'create',
  factory?: `0x${string}`,
  factoryData?: `0x${string}`
): Promise<`0x${string}` | null> {
  const provider = getBaseAccountProvider()
  await ensureBaseProviderConnected()

  try {
    const newSubAccount = (await provider.request({
      method: 'wallet_addSubAccount',
      params: [{ 
        version: '1', 
        account: { 
          type: accountType,
          factory,
          factoryData
        } 
      }],
    })) as AddSubAccountResponse

    console.log('Created new sub-account:', newSubAccount.address)
    return newSubAccount.address
  } catch (error) {
    console.error('Failed to create sub-account:', error)
    return null
  }
}

/**
 * Get or create a sub-account
 */
export async function getOrCreateSubAccount(
  universalAddress: `0x${string}`,
  chainId: number,
  domain?: string
): Promise<`0x${string}`> {
  const provider = getBaseAccountProvider()
  await ensureBaseProviderConnected()

  // 1. Check if a sub-account already exists for the domain
  const existingSubAccounts = await getSubAccounts(universalAddress, chainId, domain)

  if (existingSubAccounts.length > 0) {
    console.log('Found existing sub-account:', existingSubAccounts[0].address)
    return existingSubAccounts[0].address
  }

  // 2. If not, create a new one
  const newSubAccountAddress = await createSubAccount()
  if (!newSubAccountAddress) {
    throw new Error('Failed to create sub-account')
  }

  return newSubAccountAddress
}

/**
 * Remove a sub-account
 */
export async function removeSubAccount(
  subAccountAddress: `0x${string}`
): Promise<boolean> {
  const provider = getBaseAccountProvider()
  await ensureBaseProviderConnected()

  try {
    await provider.request({
      method: 'wallet_removeSubAccount',
      params: [{ 
        version: '1', 
        account: subAccountAddress 
      }],
    })

    console.log('Removed sub-account:', subAccountAddress)
    return true
  } catch (error) {
    console.error('Failed to remove sub-account:', error)
    return false
  }
}

/**
 * Transfer funds between main account and sub-account
 */
export async function transferToSubAccount(
  fromAddress: `0x${string}`,
  toSubAccount: `0x${string}`,
  amount: string,
  chainId: number
): Promise<string | null> {
  const provider = getBaseAccountProvider()
  await ensureBaseProviderConnected()

  try {
    const txHash = await provider.request({
      method: 'wallet_sendCalls',
      params: [{
        from: fromAddress,
        chainId: toHex(chainId),
        version: '1',
        calls: [{
          to: toSubAccount,
          value: amount,
          data: '0x'
        }]
      }]
    }) as string

    console.log('Transfer to sub-account sent:', txHash)
    return txHash
  } catch (error) {
    console.error('Transfer to sub-account failed:', error)
    return null
  }
}

/**
 * Execute transaction from sub-account
 */
export async function executeFromSubAccount(
  subAccountAddress: `0x${string}`,
  calls: Array<{
    to: `0x${string}`
    value?: string
    data?: `0x${string}`
  }>,
  chainId: number
): Promise<string | null> {
  const provider = getBaseAccountProvider()
  await ensureBaseProviderConnected()

  try {
    const txHash = await provider.request({
      method: 'wallet_sendCalls',
      params: [{
        from: subAccountAddress,
        chainId: toHex(chainId),
        version: '1',
        calls
      }]
    }) as string

    console.log('Sub-account transaction sent:', txHash)
    return txHash
  } catch (error) {
    console.error('Sub-account transaction failed:', error)
    return null
  }
}

/**
 * Get sub-account balance
 */
export async function getSubAccountBalance(
  subAccountAddress: `0x${string}`,
  tokenAddress?: `0x${string}`
): Promise<string | null> {
  const provider = getBaseAccountProvider()

  try {
    if (tokenAddress) {
      // Get ERC20 token balance using balanceOf(address)
      // 0x70a08231 is the function selector for balanceOf
      const balance = await provider.request({
        method: 'eth_call',
        params: [{
          to: tokenAddress,
          data: `0x70a08231000000000000000000000000${subAccountAddress.slice(2)}`
        }, 'latest']
      }) as string
      return balance
    } else {
      // Get native ETH balance of the sub-account
      const balance = await provider.request({
        method: 'eth_getBalance',
        params: [subAccountAddress, 'latest']
      }) as string
      return balance
    }
  } catch (error) {
    console.error('Failed to get sub-account balance:', error)
    return null
  }
}

C) Automated Subscriptions with Spend Permissions

1. User grants allowance (off-chain EIP-712).

2. Cron job executes batched, gasless charges from the sub-account.

import { getBaseAccountProvider } from '@/lib/base-account-sdk'
import {
  requestSpendPermission as sdkRequestSpendPermission,
  prepareSpendCallData,
} from '@base-org/account/spend-permission'

// Simplified type alias for the permission object returned by the SDK
export type Permission = any

// Request a Spend Permission using the SDK helper
// - account: user's Base Account (smart account) the permission applies to
// - spender: your app's spender address that will execute future transfers
// - token: ERC-20 token address (USDC on Base Mainnet in our UI)
// - allowance: spend limit in token base units for each period
// - periodInDays: recurring period window (e.g., 30 days)
// - chainId: chain on which the permission is valid (8453 = Base Mainnet)
export async function requestSpendPermission(
  account: `0x${string}`,
  spender: `0x${string}`,
  token: `0x${string}`,
  allowance: bigint,
  periodInDays: number,
  chainId: number = 8453,
) {
  const provider = getBaseAccountProvider()
  const permission = await sdkRequestSpendPermission({
    provider,
    account,
    spender,
    token,
    chainId,
    allowance,
    periodInDays,
  })
  return permission as Permission
}

// Prepare and execute spend calls using wallet_sendCalls v2
// - On first use, returned array typically includes approveWithSignature then spend
// - On subsequent uses, only the spend call is included
export async function executeSpendCalls(
  permission: Permission,
  amount: bigint | undefined,
  spender: `0x${string}`,
  chainId: number = 8453,
) {
  const provider = getBaseAccountProvider()
  const calls = await prepareSpendCallData(permission as any, amount ?? 'max-remaining-allowance')
  const txHash = (await provider.request({
    method: 'wallet_sendCalls',
    params: [
      {
        version: '2.0',
        atomicRequired: true,
        from: spender,
        calls: calls as any,
      },
    ],
  })) as string
  return txHash
}

// Optional storage helper (demo): persist the permission in a backend store
// In production, replace with your database and proper authentication
export async function storeSpendPermission(
  permission: Permission,
  metadata?: { description?: string; category?: string; frequency?: 'monthly' | 'weekly' | 'daily' },
): Promise<boolean> {
  try {
    const response = await fetch('/api/subscriptions/save', {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
      body: JSON.stringify({
        signature: permission?.signature || '0x',
        spendPermissionData: permission,
        metadata: { createdAt: new Date().toISOString(), ...metadata },
      }),
    })
    return response.ok
  } catch (e) {
    return false
  }
}

import { NextResponse } from 'next/server'

// In-memory store for demo (use database in production)
const subscriptionsStore: Array<{ 
  id: string
  signature: string
  spendPermissionData: any
  metadata: any
  createdAt: string
}> = []

/**
 * Save spend permission signatures for subscriptions
 */
export async function POST(request: Request) {
  try {
    const body = await request.json()
    
    if (!body || !body.signature || !body.spendPermissionData) {
      return NextResponse.json({ error: 'Invalid payload' }, { status: 400 })
    }

    const subscription = {
      id: `sub_${Date.now()}_${Math.random().toString(36).substr(2, 9)}`,
      signature: body.signature,
      spendPermissionData: body.spendPermissionData,
      metadata: body.metadata || {},
      createdAt: new Date().toISOString()
    }

    subscriptionsStore.push(subscription)

    console.log('Saved subscription:', subscription.id)
    
    return NextResponse.json({ 
      ok: true, 
      subscriptionId: subscription.id,
      message: 'Subscription saved successfully'
    })
  } catch (e) {
    console.error('Subscription save error:', e)
    return NextResponse.json({ error: 'Invalid JSON or processing error' }, { status: 400 })
  }
}

/**
 * Get all subscriptions (for demo purposes)
 */
export async function GET(request: Request) {
  const { searchParams } = new URL(request.url)
  const userAddress = searchParams.get('address')

  let filteredSubscriptions = subscriptionsStore

  if (userAddress) {
    filteredSubscriptions = subscriptionsStore.filter(sub => 
      sub.spendPermissionData.account?.toLowerCase() === userAddress.toLowerCase()
    )
  }

  return NextResponse.json({ 
    subscriptions: filteredSubscriptions,
    total: filteredSubscriptions.length
  })
}

/**
 * Execute a subscription (for backend use)
 */
export async function PUT(request: Request) {
  try {
    const body = await request.json()
    const { subscriptionId, amount } = body

    if (!subscriptionId || !amount) {
      return NextResponse.json({ error: 'Missing subscriptionId or amount' }, { status: 400 })
    }

    const subscription = subscriptionsStore.find(sub => sub.id === subscriptionId)
    if (!subscription) {
      return NextResponse.json({ error: 'Subscription not found' }, { status: 404 })
    }

    // In production, this would:
    // 1. Validate the spend permission
    // 2. Execute the transaction on-chain
    // 3. Update subscription usage
    // 4. Return transaction hash

    console.log('Executed subscription:', subscriptionId, 'for amount:', amount)

    return NextResponse.json({
      ok: true,
      transactionHash: `0x${Math.random().toString(16).slice(2, 66)}`,
      amount,
      timestamp: new Date().toISOString()
    })
  } catch (e) {
    console.error('Subscription execution error:', e)
    return NextResponse.json({ error: 'Execution failed' }, { status: 500 })
  }
}

Production notes: Store signed permissions securely server-side; add replay protection; monitor balances; expose a “Cancel subscription” UI that revokes the permission.

Conclusion & Next Steps

You now have a full stack that feels like a modern app:

• Sign in with Base (no passwords).

• One-tap USDC payments via Base Pay.

• Gasless actions with Paymasters.

• Zero-prompt UX using Sub-Accounts.

• Automated billing with Spend Permissions.

Next steps

• Swap Base Sepolia → Base mainnet when ready.

• Add swap/NFT flows with OnchainKit components.

• Migrate keys/session state to a hardened backend.

• Instrument analytics for funnel visibility (auth → pay → retention).

Resources & Links

Base Accounts Docs:

Base Account Overview - Base Documentation

What is a Base Account and how the Base Account SDK lets you add universal sign-in and one-tap USDC payments to any app.

https://docs.base.org

Coinbase Developer Docs:

Coinbase Developer Docs - Coinbase Developer Documentation

Explore our API & SDK references, demos, and guides for building onchain apps.

https://docs.cdp.coinbase.com

Base Docs — network specifics & tooling

Base - Base Documentation

The #1 Ethereum Layer 2, incubated by Coinbase

https://docs.base.org

HeimLabs — more tutorials and examples

GitHub - HeimLabs/coinbase-cdp-demos: A collection of Demo Projects exploring the Coinbase Developer Platform

A collection of Demo Projects exploring the Coinbase Developer Platform - HeimLabs/coinbase-cdp-demos

https://github.com

HeimLabs Website:

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

CDP Discord:

Discord - Group Chat That's All Fun & Games

Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.

https://discord.com

Clap if this saved you hours, and share what you’re building with the CDP stack!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Happy Building 🚀

Introduction

What’s the biggest bottleneck when building data-rich on-chain apps? It’s not your idea — it’s the engineering headache of getting reliable, queryable blockchain data.

For years, developers had two painful choices:

1. Run your own indexing infra (expensive and brittle).

2. Rely on rigid REST endpoints that can’t answer your custom questions.

The Coinbase Developer Platform SQL API changes that. It’s a zero-infrastructure, production-grade indexing solution that lets you query live and historical blockchain data with SQL — the universal language of developers.

Today, we’ll explain how it works (and why it’s reorg-proof), then walk through a hands-on Node.js tutorial where you’ll build a “Whale Watcher” that finds the largest USDC transfers on Base.

Watch how it works (and why it’s reorg-proof)

Walk-through a hands-on Node.js tutorial where you’ll build a “Whale Watcher” that finds the largest USDC transfers on Base. Watch here:

You’ll Build

• ⚙ Bootstrap a Node.js project and connect to the CDP SQL API.

• ⛓ Query blockchain tables (blocks, events) in SQL.

• 🐳 Build a “Whale Watcher” that finds the biggest USDC transfers.

• 📊 Handle large datasets and API limits like a pro.

Why SQL API Matters (Explainer)

Blockchains are living ledgers — sometimes the network disagrees on the “latest” state. These temporary forks are called reorgs.

For developers, reorgs are brutal: you might show a user a confirmed payment, only for it to vanish when the chain reorganizes.

The SQL API solves this elegantly with an action column:

1. When a transaction first appears → action = 1 (credit). ✅

2. If it gets dropped in a reorg → a new record with action = -1 (debit). ❌

To get the truth, just SUM(action). If the result is > 0, the transaction is valid. No manual reconciliation needed — the API handles it.

That’s why the SQL API isn’t just another endpoint. It’s your on-chain data warehouse.

System Architecture

Data Flow:

Developer → SQL API → Blockchain Tables → JSON Result → App Logic

• SQL API: Secure endpoint that accepts custom SQL queries.

• Tables: base.blocks, base.events, and more.

• Output: JSON with schema, rows, and metadata.

• Your App: Processes and visualizes the results.

Think of it as BigQuery or Snowflake — but pointed at the blockchain.

Step 1: Project Setup

mkdir cdp-sql-tutorial && cd cdp-sql-tutorial
npm init -y
npm install axios dotenv

Update package.json to mark the project as ESM:

"type": "module"

Create a .env file:

CDP_CLIENT_API_KEY=your-client-api-key

Make sure .env is in your .gitignore.

Step 2: First Query — Latest Block

Create queryApi.js:

import axios from 'axios';
import dotenv from 'dotenv';
dotenv.config();

const API_URL = 'https://api.cdp.coinbase.com/platform/v2/data/query/run';
const API_KEY = process.env.CDP_CLIENT_API_KEY;
async function runSqlQuery(sql) {
  const headers = { Authorization: `Bearer ${API_KEY}`, 'Content-Type': 'application/json' };
  const response = await axios.post(API_URL, { sql }, { headers });
  return response.data;
}
async function main() {
  const query = `
    SELECT block_number, block_hash, timestamp, miner, gas_used, transaction_count
    FROM base.blocks
    ORDER BY block_number DESC
    LIMIT 1
  `;
  const result = await runSqlQuery(query);
  console.log(JSON.stringify(result, null, 2));
}
main();

Run it:

node queryApi.js

✅ You just pulled the latest block on Base.

Step 3: Whale Watcher — Top USDC Transfers

Append this inside your main() function.

const usdcContract = '0x833589fcd6edb6e08f4c7c32d4f71b54bda02913';

const whaleQuery = `
  SELECT parameters['from']::String AS sender,
         parameters['to']::String AS recipient,
         parameters['value']::UInt256 AS amount
  FROM base.events
  WHERE event_signature = 'Transfer(address,address,uint256)'
    AND address = '${usdcContract}'
  LIMIT 10000
`;
const whaleResult = await runSqlQuery(whaleQuery);
if (whaleResult.result.length > 0) {
  const sorted = whaleResult.result.sort((a, b) => BigInt(b.amount) - BigInt(a.amount));
  const top5 = sorted.slice(0, 5).map(t => ({
    sender: t.sender,
    recipient: t.recipient,
    usdc: Number(BigInt(t.amount) / BigInt(1e6)).toLocaleString()
  }));
  console.log('--- Top 5 USDC Transfers ---');
  console.log(top5);
}

Run again:

node queryApi.js

You’ll see the biggest whales moving USDC on Base. 🐳

Step 4: Working with Limits

The SQL API enforces guardrails:

• ⏱ 30s timeout per query

• 📊 10,000 rows max

• 🔗 Up to 5 JOINs

Pro tip: paginate by time. Use WHERE block_timestamp BETWEEN ... to fetch daily/weekly chunks.

Conclusion

You’ve just:

• Learned why the SQL API is reorg-proof.

• Queried live block data with a few lines of Node.js.

• Built a whale-watching analytics tool in under 50 lines of code.

This same approach powers dashboards, bots, and monitoring tools. No infra, no indexers — just SQL.

Resources & Links

Coinbase Developer Docs:

Coinbase Developer Docs - Coinbase Developer Documentation

Explore our API & SDK references, demos, and guides for building onchain apps.

https://docs.cdp.coinbase.com

HeimLabs:

HeimLabs | Trusted Blockchain Solutions Provider

Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.

https://www.heimlabs.com

CDP Discord:

Discord - Group Chat That's All Fun & Games

Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.

https://discord.com

Clap if this saved you hours, and share what you’re building with the CDP stack!

Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.

Happy Building 🚀