Skip to main content
Fundwork may eventually support software agents as marketplace participants. This page describes the direction and, importantly, is explicit about what an agent wallet does and does not prove.
Autonomous agent participation is not currently live on Fundwork. This page describes an exploratory direction, not a shipped feature.

​
Possible Agent Flow

A plausible end-to-end flow for an agent participating in Fundwork looks like this:
1

Discover

The agent discovers an opportunity via the Fundwork marketplace or API.
2

Evaluate

The agent evaluates the requirements against its capabilities and decides whether to participate.
3

Claim or enter

The agent applies to a contract, enters a bounty, or joins a campaign according to the opportunity type.
4

Execute

The agent performs the work.
5

Submit proof

The agent submits the deliverable, along with any artifacts a verification mechanism needs to evaluate the result.
6

Verify

A verification mechanism evaluates the submission. This may be deterministic tests, an API check, an onchain event, a signed artifact, third-party verification, or human review.
7

Settle

On approval, USDC settles to the agent’s wallet according to the payment architecture in effect for the opportunity.

​
What an Agent Wallet Proves

An agent’s wallet is important, but its role is narrower than it might appear. An agent wallet proves:
  • Economic identity. Payments to this address benefit this agent.
  • Transaction authority. Onchain actions signed by this account are attributable to this agent.
  • Submission signer identity. Signed submissions can be attributed to the account.
An agent wallet does not by itself prove that work was completed correctly. Signing a submission is not evidence that the submission satisfies the opportunity’s requirements. That evidence has to come from somewhere else.

​
Verification Must Still Come From Somewhere

Regardless of who or what submits the work, verification comes from mechanisms outside the signing key:
  • Deterministic tests that run against the submitted artifact.
  • APIs that check external state, such as whether a specific action was taken on another service.
  • Onchain events that confirm a specific transaction or state change occurred on Base or elsewhere.
  • Signed artifacts from a trusted authority that vouches for some property of the submission.
  • Third-party verification by a party the opportunity designates.
  • Human review by the client or a designated reviewer.
For agent-friendly opportunities, the verification mechanism is what actually decides whether payment should be released. The agent wallet decides who gets paid; the verification mechanism decides whether payment is warranted.

​
Verification Method as an Opportunity Field

Agent-compatible opportunities may eventually specify a Verification Method as part of the opportunity definition. Possible values include:
  • Automated — the submission is evaluated by code owned by the opportunity.
  • API — the submission is verified by checking a specified API for an expected state.
  • Onchain — the submission is verified by looking for a specified event or state change on a specified chain.
  • Agent verifier — the submission is evaluated by a designated verification agent.
  • Human review — the submission is reviewed by a person (client or designated reviewer).
Exposing the verification method on the opportunity itself lets agents decide whether they can meaningfully participate before doing the work.

​
Status

Currently available

Human participants using Base Account. No autonomous agent flow is live today.

Planned before public launch

None specifically for agent participation. Human-driven flows remain the launch focus.

Under evaluation

Verification Method as an opportunity field, agent-friendly onboarding, and reputation for agent wallets.

Future

Full agent participation across compatible opportunity types, including agent-signed submissions and settlement to agent wallets.