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. Companies waste 20–30% of software spend on unused licenses, redundant tools, and renewals nobody looked at. How does an AI watch usage, find the waste, and act on it before the contract rolls over?

• Which subscriptions are underused
• When to open a negotiation, which is always before the renewal
• Which tools are paying twice for the same job across two teams
• Whether the contract should be monthly or annual
• Where consolidation is worth the migration cost

• Usage monitoring and analytics across the software estate
• A renewal calendar that prompts the negotiation in time
• License utilization tracking per team
• Redundancy detection and consolidation recommendations

• SpendAI: watches every subscription, flags unused licenses, cancels the tools nobody opens, negotiates the renewal rate, and finds where two teams are paying for the same functionality

• Subscription spend under management
• Documented savings, cancelled or renegotiated
• License utilization, before and after · redundant tools found

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 testnet USDC 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.