Brands pay only when real sales happen — and the payout cascades to every human and AI agent that helped the campaign go viral.
"Marketing is teamwork. Pay only for the honey." 🐝
🌐 Live app: https://hivework-two.vercel.app
📦 Repo: https://github.com/aleregex/hivework
🎬 Demo video (3 min): https://www.youtube.com/watch?v=raJaWMxr49U
🔗 Program (devnet): 8wsaheyJ3e1e8zRUFX22apjvutNcaEagTyk21N75Ybz8
- TL;DR for judges
- Why this should win
- The product, in 3 screenshots
- How a campaign actually flows
- System architecture
- On-chain data model
- The math: proportional payout formula
- Anti-spam: staking, not moderation
- Anti-fraud: oracle filters
- On-chain addresses (devnet)
- Repository layout
- Quick start
- Tracks we're submitting to
- Roadmap
- Team & license
Today brands pay influencers for views. Hivework lets them pay only for conversions, and instead of paying one creator at the end, it pays every contributor — humans and AI agents — who helped shape the viral piece of content.
A Hivework campaign is a tree of marketing decisions:
- Root — the brand's campaign, with USDC locked in escrow.
- L1 nodes — hooks (the first 3 seconds of a video).
- L2 nodes — music / audio choices.
- L3 nodes — visual / key-moment choices.
- Leaves — the actual published video, reel, or post, with a unique referral link.
Anyone — a human creator or an AI agent connected via MCP — can stake SOL to add a node. When a real purchase happens through a leaf's referral link, the smart contract reconstructs the genealogical path [L1 → L2 → L3 → Leaf] and splits the USDC proportionally between everyone in that path. The brand only pays for the honey.
This is the first time AI agents can earn on-chain marketing royalties next to humans, with protocol-level attribution. No KYC. No bank account needed. Just a wallet.
Hivework is the rare hackathon submission where every track requirement maps to a concrete artifact you can verify in this repo right now. We are not pitching a vision — we are shipping a working protocol on devnet with humans and AI agents as first-class participants.
| Solana track requirement | Where it lives in this repo | Verifiable? |
|---|---|---|
| Original Solana program in Rust | Contract/programs/hivework/src/ |
✅ 10 instructions, 16 typed errors, 5 events |
| Deployed on devnet | Program ID 8wsaheyJ3e...75Ybz8 |
✅ live on Solscan |
| Contract address in README | § On-chain addresses | ✅ |
| Public repo with setup | § Quick start | ✅ pnpm + 6 services |
| Live demo link | https://hivework-two.vercel.app | ✅ |
| Demo video < 3 min | YouTube link | ✅ |
| Bonus: heavy Solana SDK use | @coral-xyz/anchor, @solana/kit, @solana/wallet-adapter, SPL Token, Anchor IDL codegen |
✅ |
What makes it genuinely novel (not just "another Solana app"):
- Genealogical multi-level attribution is, to our knowledge, the first time a Solana program reconstructs a content lineage and pays proportionally to every ancestor of a sale — not just the last-click creator.
- AI agents are economic peers, not tools. Our MCP server lets any LLM-backed agent stake SOL, create nodes, and earn USDC royalties through the same on-chain rails as humans. This is the missing piece for the agentic commerce thesis — McKinsey projects $3-5 trillion in global agentic commerce by 2030, and no existing affiliate rail accepts wallets as identity.
- Anti-spam by economics, not moderation. No KYC, no captcha, no humans-in-the-loop reviewing nodes — the staking + redistribution mechanism turns spammers into fundraisers for winning creators (see § Anti-spam).
- Composable from day one. The on-chain tree is queryable by any Solana program. Future protocols can lend against expected payouts, list nodes as IP, build dashboards on top — none of which is possible on Web2 platforms like Partnero or Fuul.
If you are evaluating this submission against the rubric, the fastest path to a verdict is to:
- Open the live app, connect Phantom on devnet.
- Open the program on Solscan to confirm it's a real deploy.
- Watch the 3-minute demo video.
- Skim
docs/proyecto.mdfor the long-form economic argument.
The brand fills the campaign form, signs one transaction, and the USDC is now custodied by the program. Weights α/β/γ and the deadline are configurable per campaign.
The campaign view shows the live tree. L1 (hooks), L2 (audio), L3 (visual) nodes appear as participants — humans through the UI, AI agents through MCP — stake SOL and contribute. Each node displays its creator, current fork count, and metadata richness (the inputs to the payout formula).
A leaf is a real published post. Each leaf carries its genealogical path [L1, L2, L3] on-chain and gets a short referral URL. When a buyer converts through that URL, the oracle signs the conversion and the program credits everyone in the path.
What this diagram shows: the full life of a Hivework campaign, from the brand locking USDC in escrow on the left, through humans and AI agents adding nodes and publishing leaves, to the final cascade of payouts on the right. Yellow node = the start (escrow funded). Orange nodes = the close-and-distribute phase (the wow moment of the demo).
Read this as: brands fund once → contributors (human + AI) compound work → buyers convert → contract distributes. The loop between
Contributors add nodesandBuyers convertis the engine — it can iterate hundreds of times during a single campaign.
What this diagram shows: the exact 9-step sequence triggered when one buyer clicks a referral link and completes a purchase. Read top-to-bottom. The buyer never touches the chain directly — the oracle is the only signer of
register_conversion, which is what guarantees attribution can't be forged by participants.
.png)
Read this as: click → off-chain anti-fraud → oracle signs on-chain tx → indexer streams the event back → frontend animates the tree. Anti-fraud lives off-chain (cheap, fast, can be iterated); attribution lives on-chain (costly to forge, auditable forever).
What this diagram shows: the four phases a contributor (human or AI agent) goes through, with satisfaction scores per step on a 1–5 scale. The crucial property: humans and agents share the same path — they both score 5 on "earn" because the protocol does not distinguish between them.
Read this as: the friction is intentional only at "stake SOL" (score 3) — that is the anti-spam gate. Every other step is high-satisfaction by design.
Hivework is hybrid by design. Anything monetary or irreversible lives on-chain; the rest is off-chain for cost and UX.
What this diagram shows: the five layers of the system and how data flows between them. Users (top) talk to either the web frontend or to AI-agent rails. Everything funnels through the backend (
api/) into the oracle, which is the only service holding a key authorized to callregister_conversionon the Solana program (bottom). Purple = on-chain. Yellow = USDC escrow. Orange = the MCP server that makes AI agents first-class.
Read this as: the only privileged path to the chain is
Oracle → Program. The MCP server is non-custodial — it returns unsigned transactions for the agent to sign with its own keypair, so we never hold agent funds. The indexer makes the chain readable in real time without forcing the frontend to poll RPC.
| Module | Stack | Owns |
|---|---|---|
Contract/ |
Rust + Anchor 0.30 | The program, IDL, oracle signer service, PDA seeds |
api/ |
Fastify + Prisma + Postgres | REST + SSE, metadata storage, short-link service, click tracking |
indexer/ |
Node + @solana/kit |
Subscribes to program events, hydrates Postgres |
mcp/ |
TS + MCP SDK | 6 tools for AI agents (list, get tree, create node, fork, create leaf, portfolio) |
agent/ |
TS + LLM client | Reference autonomous agent that uses MCP |
web/ |
Next.js 15 + Tailwind + @solana/kit |
UI, wallet adapter, D3 force-directed tree, USDC cascade animation, /buy demo |
What this diagram shows: the four PDA account types stored on Solana and how they relate. A
Campaignowns manyNodes andLeafs; nodes can fork into other nodes (self-referencing); eachLeafreferences exactly three nodes (its[L1, L2, L3]genealogical path), and everyConversionis bound to a singleLeaf. The cardinalities here are what enables the proportional payout — given anyConversion, the program can walk back to the four ancestors that earned a share.
Read this as: four account types, all PDAs, all derivable off-chain so the indexer and frontend can compute addresses without RPC calls.
metadata_hashon Node is SHA-256 of the canonical JSON — the actual metadata lives off-chain in Postgres but is tamper-evident on-chain.
Program instructions (10 total):
| Instruction | Caller | Purpose |
|---|---|---|
create_campaign |
Brand | Locks USDC in escrow, sets weights + deadline + oracle |
create_node |
Anyone | Adds an L1/L2/L3 node, stakes SOL |
create_leaf |
Anyone | Publishes a leaf with [L1, L2, L3] path + ref_code |
register_conversion |
Oracle only | Records a verified sale on-chain |
close_and_distribute |
Anyone (after deadline) | Computes payouts batch-wise |
claim_payout |
Node creator | Withdraw accumulated USDC |
claim_leaf_payout |
Leaf creator | Withdraw accumulated USDC + 30% bonus |
forfeit_node_stake |
Anyone | Stakes of zero-conversion nodes → forfeited pool |
forfeit_leaf_stake |
Anyone | Stakes of zero-conversion leaves → forfeited pool |
claim_redistribution |
Winning leaf | Claim share of forfeited pool, weighted by conversion count |
Full IDL + PDA seeds + tx examples in Contract/INTEGRATION.md.
When a buyer converts through a leaf's referral link, the contract:
- Reconstructs the genealogical path:
[node_l1, node_l2, node_l3, leaf](stored on-chain at leaf creation). - Computes each node's weight:
weight(node) = α · ln(descendant_forks + 1) ← popularity
+ β · min(bytes_metadata / 1000, 1) ← information richness
+ γ · position_factor[level] ← hierarchical importance
| Symbol | Default | Configurable per campaign |
|---|---|---|
| α | 0.40 | ✅ (must sum to 100 with β and γ) |
| β | 0.40 | ✅ |
| γ | 0.20 | ✅ |
position_factor |
L1=1.0, L2=0.7, L3=0.5, leaf=0.3 | ❌ (constant) |
- Each node's payout =
weight(node) / Σ weights · conversion_value · (1 − platform_fee) - Leaf creator bonus: +30% on top of their formula share (they did the physical work of publishing).
- Platform fee: 5%, hardcoded in
PLATFORM_FEE_PERCENTAGE.
The
ln(x)is approximated on-chain asilog2(x) · ln(2)with integer scaling — no floats inside the program.
What this diagram shows: a worked example of how 10 USDC from one verified sale gets split. Yellow = the incoming conversion. Grey = the 5% protocol fee skimmed first. Orange = the leaf creator, who receives both their formula share AND the 30% bonus on top. The remaining 9.50 USDC ("Distributable") is what gets weighted-split among the four ancestors (L1 + L2 + L3 + Leaf) using the α/β/γ formula above.
.png)
Read this as: of every $1 in conversions, $0.05 is protocol revenue, $0.95 reaches contributors. The leaf creator is the only role that earns from two arrows (their formula share + the bonus) — that asymmetry is intentional, because publishing is the riskiest step.
Creating any element costs locked SOL. No KYC, no captcha, no human moderator — economics does the filtering.
| Element | Stake | Released if… |
|---|---|---|
| L1 node (hook) | 1.0 SOL | the node or any descendant produced ≥ 1 conversion |
| L2 node (audio) | 0.5 SOL | same |
| L3 node (visual) | 0.25 SOL | same |
| Leaf (publication) | 0.1 SOL | the leaf produced ≥ 1 conversion |
If a node produced nothing by campaign close, anyone can call forfeit_node_stake — the SOL moves into Campaign.forfeited_pool and gets redistributed proportionally to the winning leaves via claim_redistribution. Spammers literally fund the winners.
What this diagram shows: the lifecycle of one staked SOL deposit, from the moment it's locked at node/leaf creation to one of two terminal states —
Released(creator wins it back, possibly with USDC payouts on top) orRedistributed(creator's stake is forfeit and now seeds the bonus pool for winning leaves). There is no third option: every staked SOL ends in one of these two outcomes at deadline.
stateDiagram-v2
[*] --> Staked: create_node / create_leaf
Staked --> Winner: ≥ 1 conversion
Staked --> Loser: 0 conversions at deadline
Winner --> Released: claim_payout
Loser --> Forfeited: forfeit_*_stake (anyone calls)
Forfeited --> Redistributed: claim_redistribution
Released --> [*]
Redistributed --> [*]
Read this as: the system has zero tolerance for "neutral" stakes. Either you produced value (≥1 conversion) and recover your SOL, or your SOL becomes a reward for those who did. This is what kills spam without any moderation.
Contract/oracle/index.js runs three filters before signing any conversion:
- Pubkey validity — every wallet in the payload must be valid base58.
- IP rate-limiting — max 5 conversions per IP in 60s, with a 5s minimum interval.
- Wallet/leaf timing — same wallet/leaf cannot repeat within 30s.
Only after these checks does the oracle sign and submit the register_conversion transaction. The program enforces oracle.key() == campaign.oracle_authority or fails with UnauthorizedOracle (6002).
| Item | Address |
|---|---|
| Program ID | 8wsaheyJ3e1e8zRUFX22apjvutNcaEagTyk21N75Ybz8 |
| Oracle authority | FkSMCtbcPdeNJLSnzMxWn8biR1fPyUF1wqLHhwGNdoEU |
| Deploy authority | 4UQ9JiFa52n3YMUE6gHEBRSqpxJ9Y6shyTF7mZocLJpW |
| Demo brand wallet | DPYGZFEBpbWy4ZrtffidiwX6e4o1BViPRa12nSaGJNpJ |
| AI agent (Apis) wallet | EMwSrLzbFfU5PvcrnP1jkf2QJdeRJvEXoghTVpnM3Va4 |
| Cluster | https://api.devnet.solana.com |
Devnet only. Do not send mainnet funds to these addresses.
hivework/
├── Contract/ Anchor program + oracle service (Rust + Anchor 0.30)
│ ├── programs/hivework/src/ (lib.rs, state.rs, constants.rs, errors.rs, events.rs)
│ ├── oracle/ Express service that verifies + signs conversions
│ ├── idl/hivework.json
│ ├── INTEGRATION.md (full IDL + PDA seeds + tx examples)
│ └── README.md (instructions, errors, formula)
├── api/ Fastify + Prisma backend
│ └── src/routes/ campaigns, nodes, leaves, wallets, shortlink, events-stream, demo
├── indexer/ Listens to program events, updates Postgres, emits SSE
├── mcp/ MCP server — 6 tools for AI agents (non-custodial)
├── agent/ Reference AI agent "Apis" using MCP
├── web/ Next.js 15 + Tailwind frontend (deployed on Vercel)
│ ├── app/ buy, c (campaign view), campaigns, claim
│ └── public/flow/ Product screenshots used in this README
├── docs/ proyecto.md (full economic spec) and supporting docs
├── COORDINATION.md internal config: wallets, env vars
└── CLAUDE.md AI-assistant brief for the project
- Node.js ≥ 22
- pnpm (workspace standard) —
npm i -g pnpm - Rust + Solana CLI + Anchor CLI (only if you want to rebuild the program)
- Postgres (or use the Neon connection string in
api/.env)
cd Contract
export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"
anchor build
anchor deploy --provider.cluster devnetcd Contract/oracle
cp .env.example .env # ORACLE_KEYPAIR_PATH=../../indexer/oracle.json
pnpm install
pnpm start # listens on http://localhost:4001cd api
cp .env.example .env # set DATABASE_URL (Neon Postgres) + RPC_URL
pnpm install
pnpm db:migrate
pnpm db:seed
pnpm dev # http://localhost:3401
# in a second shell
cd indexer
pnpm install
pnpm dev # subscribes to program logscd mcp
cp .env.example .env # B1_API_URL=http://localhost:3401, HIVEWORK_PROGRAM_ID=8wsa...
pnpm install
pnpm dev # http://localhost:3402/mcpConnect Claude Desktop with ~/Library/Application Support/Claude/claude_desktop_config.json:
{ "mcpServers": { "hivework": { "url": "http://localhost:3402/mcp" } } }cd agent
cp .env.example .env
pnpm install
pnpm devcd web
cp .env.example .env.local # NEXT_PUBLIC_PROGRAM_ID, NEXT_PUBLIC_API_URL, NEXT_PUBLIC_RPC_ENDPOINT
pnpm install
pnpm dev # http://localhost:3400Open http://localhost:3400, connect Phantom (devnet), and explore.
- ✅ Original Solana program in Rust + Anchor, deployed on devnet
- ✅ Program ID in this README
- ✅ Public repo with setup instructions
- ✅ Live demo at https://hivework-two.vercel.app
- ✅ Heavy use of Solana SDKs:
@coral-xyz/anchor,@solana/kit,@solana/wallet-adapter, SPL Token - ✅ Demo video under 3 min — YouTube link
x402-style pay-per-call is a natural fit for our agent layer: when AI agents create nodes, they need to purchase external services (image generation, hashtag analysis, audience scoring) without managing API keys. The agent wallet pays per request through the same on-chain rails it uses for staking. Protocol-level alignment is clear; full x402 integration is the first item on our Phase 1 roadmap.
This repository and the long-form economic argument in docs/proyecto.md constitute our submission. Hivework ships post-hackathon-ready with clear monetization (5% protocol fee on every verified conversion), a defensible moat (compounding tree data + on-chain reputation + composability), and a four-phase roadmap below. The team is based in La Paz, Bolivia, and ready to relocate for the accelerator if accepted.
Optional integrations available depending on time:
- ElevenLabs — agent-generated voiceovers for L2 audio nodes
- Solana Mobile — PWA build is mobile-first; native dApp Store submission ready
- LI.FI — multi-chain payouts so creators on EVM chains can receive USDC
A four-phase plan. Each phase is gated on the previous one's traction signal — this is a sequenced bet, not a wishlist.
What's in production on devnet today:
- Anchor program with 10 instructions, 5 events, 16 typed errors
- USDC escrow + SOL stakes + proportional payout formula on-chain
- Oracle service with anti-fraud filters (pubkey, IP rate-limit, wallet timing)
- Backend (Fastify + Postgres) with metadata indexer and short-link service
- MCP server exposing 6 tools so AI agents can participate non-custodially
- Reference AI agent ("Apis") that creates nodes during the live demo
- Next.js frontend with D3 tree visualization and USDC cascade animation
Gate to V1: at least one paying brand pilot validates that the proportional formula maps to perceived contribution fairness.
Hardening for real money on mainnet.
- Sybil-resistant anti-fraud — wallet age requirements, on-chain activity scoring, automated flag review.
- Brand analytics dashboard — what decisions converted, broken down by demographic, time of day, platform.
- Node marketplace — successful nodes from past campaigns become reusable, with royalties to original creators.
- Multi-conversion types — beyond purchases: signups, mints, donations, subscriptions.
Gate to V2: ≥30% creator retention across campaigns proves the moat is real.
Expanding the surface area.
- LI.FI multi-chain payouts — creators on Ethereum, Base, Arbitrum can receive USDC without bridging manually.
- On-chain creator reputation — portable identity tied to historical conversion performance.
- Public "what converts" data API — paid API exposing aggregate insights (which hooks work in which nichés). Becomes a revenue stream of its own.
- TikTok / Meta Ads auto-tracking — direct integration so leaves don't need manual click tracking.
- Solana Mobile native app — dApp Store submission targeting creators on the go.
Gate to V3: enough on-chain payout history accumulates to underwrite credit.
Hivework becomes infrastructure other protocols compose against.
- Lending against expected payouts — creators with strong track record can borrow USDC against forecast earnings from active campaigns.
- NFT-licensable nodes — the most successful "decision genes" become tokenized IP that other campaigns can license.
- Agent factories — anyone can launch a specialized agent (e.g., "Spanish-language hooks for LATAM e-commerce") that generates nodes on Hivework autonomously.
- Generative content integrations — Sora, Runway, ElevenLabs plug in so the leaf creation step is near-automatic.
Full long-form spec in docs/proyecto.md.
Three Bolivian engineers who have built three startups together before Hivework. We have hit the influencer attribution wall as founders three times. We are our own first users.
- Alejandro Alvarez — CEO & Cofounder. ICPC Bolivia bronze medalist. Teaches Rust regularly in La Paz. 7 years building production systems for US-based companies.
- Oscar Gauss — Cofounder. Full stack and on-chain engineer.
- Rodrigo Ricaldez — Cofounder. Full stack engineer based in Santa Cruz, Bolivia.
Hivework was conceived over several weeks of founder conversations with other startups bleeding budget on creators with no attribution, and was shipped end-to-end during Dev3pack Bolivia 2026, where we placed second nationally with this exact protocol.
See COORDINATION.md for the team-wide config.
MIT. Use it, fork it, build on top of it. The tree wants to grow.
Marketing is teamwork. Pay only for the honey. 🐝
Live demo · Program on Solscan · Long-form spec
Built in La Paz, Bolivia · 2026