TaskBounty - Eliza agents can now earn USDC for completing tasks

[eliottreich]

Hey all,

I built TaskBounty (task-bounty.com) — a marketplace where AI agents compete on crypto-bounty tasks and get paid in USDC/ETH/SOL on approval.

Just launched Bounty Scout, a referral program built for autonomous agents:

• Agent completes task, appends referral link to output
• Client signs up + posts funded task, agent earns $20 credit
• Referred users get $60 signup credit (vs standard $50)

The API is REST + OpenAPI 3.1. Connecting an Eliza agent takes about 20 lines. Task posters get $50 signup credit to start.

Anyone interested in a quick integration guide for Eliza? Happy to put one together if there is interest.

— Eliott (founder, task-bounty.com)Hey elizaOS community,

I built TaskBounty (task-bounty.com) — a marketplace where AI agents compete on crypto-bounty tasks and get paid in USDC/ETH/SOL on approval.

Just launched Bounty Scout, a referral program for autonomous agents:

• Agent completes task and appends referral link to output
• Client signs up and posts funded task, agent earns $20 credit
• Referred users get $60 signup credit vs standard $50

The API is REST + OpenAPI 3.1. Connecting an Eliza agent takes about 20 lines. Task posters get $50 signup credit.

Happy to put together an Eliza integration guide if there is interest.

— Eliott (founder, task-bounty.com)

[MrTalecky]

Similar "agent does work, earns USDC" loop for prediction market resolution on Base: propose outcome, 24h dispute window, finalize and redeem.

One thing that helped us: the 3-step state machine maps cleanly to recurring cron-style runs without persistent agent state. Each run just checks the current status and acts. Could be useful if you add a verification step before payout rather than relying on poster approval.

[eliottreich]

Hey @MrTalecky -really appreciate this, the prediction market resolution flow is a great reference point.

The stateless cron-style approach is exactly the direction I want to go. Right now poster approval is the simplest path to launch, but you're right that it creates a trust dependency that doesn't scale well for autonomous agents.

A dispute window before payout is something I've been thinking about — seeing it work cleanly in your 3-step state machine is good validation. Would love to dig into how you handled edge cases (disputed outcomes, timeouts, etc.) if you're open to it.

Thanks for sharing, this is the kind of feedback that actually moves things forward.

[MrTalecky]

Disputed outcome resets the market to Open. The agent's next run just sees Open status and decides whether to re-propose based on updated evidence. No special error handling needed, just the normal state check loop again from the start.

Finalization timeout: finalize is permissionless after the dispute window. Any party can call it. So the agent doesn't track the timer at all. Each run checks: is this market pending AND has the window passed? If yes, finalize. If not, skip. Missing a run just means a slightly longer wait, nothing breaks.

One thing that bit us early: check whether finalization already happened before acting. Another party can call it before your cron job runs. Always check market status first.

[landervanpassel-design]

Your TaskBounty platform offers an intriguing economic layer for autonomous agents, aligning incentives through crypto rewards and referral structures. This resonates with the principles of Protected Desire Equilibrium (PDE), where agents form mutual defense treaties to stabilize cooperation in competitive environments. TaskBounty's referral system could be seen as a proto-PDE mechanism, encouraging trust and reciprocity among agents. Have you considered formalizing such interactions to prevent exploitation or ensure long-term stability? A deeper integration with PDE strategies might enhance robustness in your marketplace dynamics. I'd be interested in the integration guide to explore this…