Tameion

The problem. Businesses hold cash across multiple accounts and chains, often earning zero yield while missing the right moment to spend. How does an AI manage a treasury to maximize yield, forecast cash needs, and allocate funds across the company?

• Cash-flow forecasting, and what the forecast implies about runway
• Fund allocation across accounts and legal entities
• Working capital: when to deploy cash and when to preserve it
• Yield: move idle funds into USYC, redeem when cash is needed
• Budget warnings by department or project
• Timing for large expenditures

• Multichain treasury dashboards with a unified balance view
• Cash-flow forecasting models with runway alerts
• Automated yield optimization with USYC
• Budget monitoring and departmental allocation tools

• TreasuryAI: manages cash across accounts, forecasts runway, flags a change in burn rate, moves funds between operating and reserve, and earns yield on the reserve via USYC

• Businesses using the application · total funds under management
• Cash-flow forecast accuracy
• Treasury operations automated per week

The problem. Accounts payable and receivable mean manual invoice processing, payment-timing decisions, and collections follow-ups. It is tedious, error-prone, and a standing invitation to fraud. How does an AI run the full AP/AR cycle while improving cash flow?

• Reads invoices, emails, and contracts to work out what is actually owed
• Optimizes vendor payment timing: an early-pay discount against preserving cash
• Prioritizes collections based on how each customer has behaved before
• Detects duplicate invoices and probable fraud
• Screens a vendor's wallet address before paying it
• Matches payments to invoices without a human doing the matching

• Invoice ingestion and parsing from email, PDF, or API
• Payment-timing optimization engines
• Payment workflows with address screening built into the path
• Receivables collection with follow-ups timed to the customer

• PayablesAI: reads incoming invoices from email, validates each against the contract, screens the vendor address, schedules the payment for the right day, and executes it. Chases overdue receivables on its own schedule.

• Invoices processed · total payment volume
• Days payable and days receivable outstanding, before and after
• Duplicate invoices caught

The problem. Businesses work with dozens of contractors and vendors but have no systematic way to track performance, manage payment, or build reputation data. How does an AI manage those relationships, release milestone payments, and surface the right contractor for the next job?

• Payment scheduling against milestone completion
• Reputation scoring from delivery and quality, not from a testimonial
• Compliance screening at onboarding, before the first payment clears
• Rate negotiation informed by what the market is actually paying
• Vendor discovery and matching for a given need
• Credit limits set by payment history

• Vendor onboarding flows with screening in the path
• Milestone escrow and release systems
• Reputation scoring and vendor ranking
• Vendor discovery and matching marketplaces

• VendorAI: manages a network of contractors, screens each wallet at onboarding, releases milestone payments once work is verified, builds a reputation score from what happened, and suggests new vendors from the pattern

• Contractors and vendors managed · total payment volume
• On-time payment rate
• Vendor satisfaction

The problem. Build an AI agent that operates the financial side of a business end to end: it receives and holds USDC, watches cash against upcoming obligations, decides when to pay a vendor or buy a service, moves funds when it needs to, and stays inside predefined budgets and approval limits. How does an AI run a business's money as a continuous operation, and know which decisions are not its to make?

• Whether there is enough liquidity to cover what is due, and what is due next
• Which obligations to pay now, which to hold, and which are worth paying early for the discount
• When a service is worth buying, and at what price
• When to move funds between operating, reserve, and yield, and how much
• Which decisions fall inside its budget and approval limits, and which go to a human
• What to write down, so every action has a reason attached

• An agent wallet that holds USDC, with budgets and approval limits enforced in the contract rather than the prompt
• Liquidity monitoring that reads balances and upcoming obligations together
• Payment and purchasing workflows the agent runs without a person in the loop
• A decision log that records what was done, why, and what it cost
• Escalation paths that reach a human only when a policy threshold is hit

At least one complete business workflow, run by the agent from start to finish. For example: receive revenue → assess available liquidity → purchase a service or pay an obligation → record the decision and the transaction → escalate to a human only when a policy threshold is reached.

• OperatorAI: takes revenue into a USDC wallet, checks what is due in the next thirty days against what is on hand, pays the invoices that clear policy, buys the API credits the product is about to run out of, moves the surplus to reserve, logs each decision with its reasoning, and pings a human only when a payment exceeds its approval limit
• PolicyWallet: a smart-contract wallet with per-category budgets and per-transaction approval limits, so the agent's authority is enforced on-chain and cannot be talked past

• Businesses operated · total USDC received and paid out
• Obligations settled on time without a human touching them
• Decisions made vs. decisions escalated, and how often the human agreed

The problem. Compliance screening is typically binary and point-in-time: block or allow, checked once, at the transaction. Businesses need continuous monitoring, risk-tiered responses, and some visibility into indirect exposure. How does an AI make compliance an ongoing judgment rather than a gate?

• Transaction limits scaled to risk, rather than a single allow-or-block
• When enhanced due diligence is warranted: PEP exposure, high-risk industry
• How often an existing counterparty should be screened again
• Which indirect exposures matter, when your vendor's vendor is the sanctioned one
• Payment terms priced to the counterparty's risk profile

• Continuous counterparty monitoring
• Risk-tiered transaction limit systems
• Indirect exposure visualization across a vendor network
• Audit-ready compliance reporting

• ComplianceAI: monitors every counterparty, alerts when a risk profile changes, adjusts credit limits against exposure, and generates reports a regulator would accept
• RiskTier: dynamic transaction limits from live screening. Low risk gets full access, medium gets reduced limits, high requires a human
• ExposureMap: second-degree sanctions exposure across your vendor and customer network, surfaced before it becomes your problem

• Addresses monitored · alerts generated and resolved
• Risk events caught before the transaction
• Compliance reports generated

Whatever you want. The field is open, and the five RFBs and prior-art ideas are prompts, not tracks. What we're looking for comes down to three things, and they matter in this order:

• It runs on Arc, with payments actually flowing in USDC, testnet or mainnet, on the Circle Agent Stack.
• It's something you genuinely care about and intend to keep building after the three weeks are up, not a demo you'll abandon the day after the deadline.
• It's already in front of a business that uses it, solving a problem they actually have.

We weigh agency and traction equally. Genuine usage matters even on a testnet. We want to see both.

No. The RFBs and the prior-art section exist to get you started, not to box you in. There's no favored RFB this round: treasury, AP/AR, vendors, spend, and compliance are all equally open, and a build that cuts across several of them is closer to what a real finance function looks like anyway. If you surprise us with something better, that wins. As the judging note says, judges have the final say and the best projects tend to break the rules.

You need someone with real money problems, and they don't have to be large. A freelancer chasing three invoices, a two-person agency paying contractors abroad, a small studio with an unused seat on six SaaS tools: all of these are the traction we mean. Your own company counts, and so does the open-source project you maintain that has never had a way to take money in.

What doesn't count is a synthetic dataset. If nobody's actual money is on the other side of the decision, the agent isn't being tested.

This is the interesting design question of the whole event, and we don't have a fixed answer. An agent that asks permission for every payment is a form with extra steps. An agent that can move the entire treasury on its own judgment is not something anyone will run.

The good answers so far put the limit somewhere the agent cannot reach: a contract that enforces the budget rather than a prompt that requests it, a threshold above which a human signs, a complete record it must produce afterwards. Delegated authority has always worked this way: the person trusted with the money spends it freely, and every transaction is reviewed afterwards. The same rule works for an AI agent.

Unlike most hackathons, the prize isn't the finish line for us. If you're serious about building a real thing after the deadline, we commit for the long run alongside you. We have follow-on support for teams that keep going:

• Funding to take the project beyond the prototype.
• Grant support to keep building while you find traction.
• Partnership support across Canteen, Circle, and the Arc ecosystem: distribution, introductions, and a path to real users.

The three weeks are how we meet you. What we're really looking for is the small handful of teams we'll still be backing a year from now. If that's you, tell us in your submission and find us in the Canteen Discord.

Yes. If you've already started something (at a prior hackathon, as a side project, or as an open-source accounting tool you've maintained for years), you're welcome to carry it forward here. That's exactly the kind of long-run building we're after. But we judge the delta, not the whole project: what you shipped and who you reached during Tameion. Where was the product and how many users did it have when Tameion began, and where are both at the end?

That gap is what's eligible for prizes, on both fronts equally: product and traction. New features built and new businesses onboarded during the program count; work that already existed when you started doesn't. So tell us where you left off, and show us how much further you've taken it.