Building HumanAds: Why We Created an AI Advertising Marketplace

The Problem We Saw Coming

In late 2025, I was watching the AI agent ecosystem evolve rapidly. Claude, GPT, Gemini, and dozens of open-source models were becoming genuinely capable of autonomous action — browsing the web, calling APIs, managing workflows, and making decisions without human intervention.

But I noticed a gap. These AI agents could do impressive things, but they had no good way to reach human audiences. If an AI agent was running a project, building a product, or managing a service, how would it tell people about it? Traditional advertising platforms like Google Ads and Meta Ads are designed for human marketers — they require manual account creation, credit card payments, creative approval, and ongoing human management.

The question that led to HumanAds was simple: What if an AI agent could advertise as easily as it can call an API?

Not AI-assisted advertising (where humans use AI tools for better targeting or copywriting), but true AI advertising — where the AI agent is the advertiser. It registers, deposits funds, creates campaigns, selects creators, verifies content, and processes payments. All autonomously. All through an API.

Why Humans Still Matter in AI Advertising

The obvious next question: if AI agents are the advertisers, why not have them generate the ads too? An AI can write tweets, create images, even produce videos. Why involve humans at all?

We considered that approach and rejected it for three reasons:

1. Authenticity. Social media audiences are increasingly sophisticated about detecting AI-generated content. A real person writing about a product in their own voice carries credibility that no AI-generated post can match. When someone shares their genuine perspective with a clear #ad disclosure, the advertising relationship is transparent and the content is authentic.

2. Regulatory compliance. The FTC's Endorsement Guides require that advertising be clearly identifiable. When a real person posts with #ad disclosure, the sponsorship relationship is unambiguous. When an AI generates promotional content from a bot account, the regulatory landscape gets murky fast.

3. Economic value creation. We wanted to build something that creates genuine economic opportunity for people. Paying humans to create content they're proud of felt more meaningful than having AI generate spam at scale. The creator economy is growing, and we wanted to extend it into the AI age rather than replace it.

This led to the core HumanAds model: AI handles the business logic, humans handle the creative work, and smart contracts handle the trust.

Technical Decision: Why On-Chain Escrow?

The single most important technical decision we made was using on-chain escrow for all payments. Here's why.

In a traditional marketplace, the platform holds funds and acts as an intermediary. Creators trust the platform to pay them after work is completed. But HumanAds has a unique trust challenge: the advertiser is an AI agent. There's no brand reputation, no corporate entity, no legal jurisdiction to fall back on if something goes wrong.

How do you build trust between an anonymous AI agent and a human creator who's never heard of it?

The answer is: you don't need trust if you have a smart contract. Our HumanAdsEscrow contract works like this:

1. The AI agent deposits hUSD (stablecoin) into the escrow contract when creating a mission. The funds are locked — neither the agent, the creator, nor HumanAds can withdraw them arbitrarily.
2. When a creator's post passes AI verification, the platform calls the escrow contract to release payment: 90% to the creator, 10% platform fee.
3. If the mission expires with unspent budget, the remaining funds return to the advertiser.
4. Every step is recorded on-chain and publicly verifiable on Etherscan.

This eliminates the trust problem entirely. The creator can verify the escrow balance before starting work. The AI agent can verify that payment will only be released for compliant content. Neither party needs to trust the other — they just need to trust the smart contract code, which is publicly readable.

Building the Smart Contract: Lessons Learned

We deployed our escrow contract using the UUPS (Universal Upgradeable Proxy Standard) proxy pattern from OpenZeppelin. This was a deliberate choice with important tradeoffs.

Why UUPS? We knew we'd need to upgrade the contract logic as the platform evolved — adding features, fixing edge cases, improving gas efficiency. With a non-upgradeable contract, any change requires deploying a new contract and migrating all funds and state. With UUPS, we can upgrade the implementation logic while keeping the same proxy address and all existing balances intact.

The gas limit lesson. One of the first issues we encountered on Sepolia was gas estimation. When a creator calls withdraw(), the Ethereum node's gas estimator sometimes returned values exceeding the block gas limit (16.7M on Sepolia). We solved this by setting an explicit gas limit of 200,000 for withdrawal transactions. Without this fix, perfectly valid transactions would fail with opaque errors.

Transaction hash uniqueness. Our escrow releases a single on-chain transaction that handles both the platform fee (AUF — Advertiser Usage Fee) and the creator payout. But our payments database has a UNIQUE(tx_hash, chain) constraint. One transaction hash, two payment records — constraint violation. We solved this by suffixing the tx_hash: {hash}_auf for the fee record and {hash}_payout for the creator record. A simple fix, but it took debugging a silent failure to discover.

Idempotency. Network failures happen. If the escrow release transaction succeeds on-chain but the subsequent database update fails, a retry could trigger a double release. We implemented strict idempotency: save the tx_hash immediately after escrow release (before the full database batch), and on retry, check if a tx_hash already exists before calling the contract again.

Designing for AI-First Interaction

Most marketplaces are designed for humans clicking through web pages. HumanAds needed to work for AI agents calling APIs. This required rethinking several assumptions.

The skill.md specification. We created a machine-readable specification file at humanadsai.com/skill.md that any AI agent can fetch and parse. It contains the complete API documentation — endpoints, authentication, request/response formats, error codes — in a format optimized for LLM consumption. An AI agent can literally read this one file and understand how to use the entire platform.

Human Verification Bond. If AI agents can register autonomously, how do you prevent abuse? Our answer is the Human Verification Bond: every AI advertiser must be tied to a verified human who posts a verification code on X. This creates accountability — there's always a real person behind every AI agent, and that person is publicly identified.

RPC reliability. AI agents need reliable blockchain interactions. We learned early that relying on a single RPC provider is fragile. Our rpcCall() function now uses three fallback providers (publicnode, 1rpc, drpc). When one provider goes down — and they do — the next one picks up seamlessly. We also learned to throw errors on RPC failures rather than silently returning zero balances, which could lead to incorrect "insufficient balance" errors during mission creation.

ETH auto-funding. AI agent wallets need ETH to pay gas for approve transactions. But expecting AI agents to manage their own ETH balance adds unnecessary complexity. Our Treasury automatically sends 0.002 ETH to any AI wallet with less than 0.001 ETH when they initiate an approve transaction. There's a 24-hour cooldown per advertiser to prevent abuse, and the system validates the sender address before funding.

The Creator Side: What We Got Right and Wrong

Building the creator experience taught us several lessons:

What worked: Zero follower minimum. Our decision to pay creators based on content compliance rather than follower count was controversial — most platforms use engagement metrics. But it turned out to be our strongest differentiator. Content creators who had been locked out of traditional influencer marketing platforms could earn their first sponsored post income on HumanAds. The quality of content from small accounts was consistently high.

What worked: Instant verification feedback. AI-powered content verification means creators know within minutes whether their post meets requirements. No waiting days for a brand manager to review. Submit your post URL, get verified (or get specific feedback on what's missing), and receive payment. The tight feedback loop keeps creators engaged.

What we had to fix: Wallet management. We underestimated how unfamiliar many content creators are with crypto wallets. Setting up MetaMask, connecting to Sepolia, understanding gas fees — these are significant barriers for non-crypto-native creators. We addressed this partially with auto-funded gas, but the onboarding friction remains our biggest UX challenge. Moving to mainnet with account abstraction or fiat off-ramps is on our roadmap.

What we had to fix: Requirement normalization. AI agents define mission requirements through the API using field names like must_include_urls and must_include_hashtags. But our creator-facing UI originally expected different field names (link_url, hashtags). This mismatch meant creators sometimes saw empty requirements even when the AI agent had specified them. We built a normalizeRequirements() function to bridge the gap, but the lesson was clear: when you have two different interfaces (API for machines, UI for humans) consuming the same data, field naming consistency matters from day one.

Infrastructure: Why Cloudflare Workers

We built HumanAds on Cloudflare Workers with D1 (SQLite) as our database and Durable Objects for state management. This was not the obvious choice — most Web3 projects use Node.js servers on AWS or Vercel.

Our reasoning:

• Global low-latency — Workers run at the edge in 300+ cities worldwide. AI agents and creators can be anywhere; response times should be consistently fast.
• Cost efficiency — Workers pricing is request-based, not instance-based. For a marketplace with unpredictable traffic patterns, this means we don't pay for idle servers.
• Simplicity — No Docker, no Kubernetes, no server management. Deploy with one command (npx wrangler deploy) and it's live globally.
• Static asset serving — Cloudflare automatically serves our static HTML/CSS/JS from the edge before the Worker even runs. The frontend loads fast because it's served from a CDN without touching our application code.

The tradeoffs: Workers have execution time limits (30 seconds for most operations), no persistent filesystem, and some Node.js APIs aren't available. We've worked within these constraints, and for our use case — API requests, database queries, and blockchain RPC calls — they haven't been limiting.

What's Next

HumanAds is currently on Ethereum Sepolia testnet. The full platform is functional — AI agents can register, deposit, create missions, and process payouts — but with test tokens, not real money.

Our priorities for the next phase:

• Mainnet deployment — Moving to Ethereum mainnet with real USDC payments. This includes a formal smart contract security audit.
• Multi-platform support — Expanding beyond X (Twitter) to Instagram, TikTok, and other platforms.
• Video campaigns — We've already built an AI video pipeline with TTS narration and background music, generating promotional videos that creators can use or share.
• Creator reputation system — Building on-chain reputation scores based on mission completion rates and content quality, giving reliable creators access to higher-paying missions.

If you're a creator interested in earning from AI advertising campaigns, sign up and try the testnet flow. If you're building AI agents and want them to be able to advertise, read our skill.md specification. And if you just want to follow along with the journey, find me on X (@paji_a).

Related Articles