There's a version of dog-fooding that means using your own product for low-stakes internal workflows — a Slack bot that nobody relies on, a read-only dashboard that surfaces data you could find elsewhere. It's useful for catching obvious bugs, but it doesn't actually build confidence in your infrastructure, and it doesn't build credibility with the customers you're asking to trust it with their money.
Then there's the version that actually matters: running real capital through the infrastructure you're asking others to trust. Proco's treasury operations run through Proco. Not a demo environment, not testnet tokens, not a simulated policy engine. Actual operational capital — supplier payments, recurring API costs, inter-account rebalancing, contractor settlements — flowing through the same wallet infrastructure and payment policy engine that our customers use.
This post is an account of what that looks like in practice, what we've learned, and why we think it's a commitment that the financial infrastructure space needs more of.
The credibility problem in financial infrastructure
Financial infrastructure companies have a fundamental trust problem. They ask enterprises — often with significant institutional credibility, risk committees, and fiduciary obligations — to route real money through software written by a startup. The standard pitch involves compliance certifications, security audits, and testimonials from early customers. All of that matters. None of it is the same as saying: "We run our own treasury through this."
When we started building Proco, we made a deliberate decision: before we asked a corporate treasury team to route their agents' capital through our infrastructure, we would route our own. Not because it was required, not because it was particularly convenient, but because we couldn't in good conscience ask others to accept a risk we weren't willing to accept ourselves.
The decision also had a practical dimension. There is no substitute for operational experience with your own infrastructure. You can write tests, run security audits, and simulate scenarios — but the way you discover that your policy engine has an unexpected interaction between velocity controls and multi-step approval flows is by running a real treasury operation through it under real operational pressure.
What "real" means — the scope of Proco on Proco
To be specific about what we mean: Proco's operational capital — the money we use to run the company — flows through Proco's agent wallet infrastructure. This includes:
- Supplier payments: SaaS subscriptions, cloud infrastructure, professional services
- Recurring API costs: infrastructure services that bill on usage, paid via automated agent
- Inter-account rebalancing: moving capital between treasury accounts as operational needs change
- Contractor settlements: payments to individuals and entities for specific work, processed through the same compliance layer we surface to customers
Each of these payment types exercises a different part of the infrastructure. Recurring API costs test our policy engine's handling of high-frequency, small-value transactions. Contractor settlements test the KYA compliance layer. Inter-account rebalancing tests our treasury management tooling. Supplier payments test the counterparty whitelist system and approval flows.
We are not running through a shadow environment or a special internal configuration. The policy engine evaluating our transactions is the same one evaluating our customers' transactions. If we find a bug, we fix it — and the fix ships to everyone. If we find an edge case, it becomes a test case. Our operational reality becomes our test suite.
What we've discovered by running real money through Proco
The most honest thing we can say about dog-fooding financial infrastructure is that the learning isn't symmetric. When things work as expected, you learn that the specific scenario you tested works. When something unexpected happens, you learn something genuinely new — about the infrastructure, about your assumptions, or about the operational context you hadn't modelled correctly.
We've had three meaningful edge cases surface through our own operational use that became product improvements:
Policy boundary ambiguity. Our initial policy configuration had a gap: transactions that fell exactly on a threshold amount (not above, not below) weren't matched by either the auto-approve rule or the approval-required rule. They fell into a default-block path silently. We discovered this when a supplier payment for exactly $500 was blocked without notification. The fix: explicit handling of boundary cases and mandatory notification on any block. That fix is now in production for all customers.
Velocity control interaction with batching. We use batch payment processing for some recurring costs. Our velocity controls, designed to catch runaway agent behaviour, were triggering on our own legitimate batch operations. The interaction between velocity windows and batch timing required a configuration option we hadn't built yet. We built it. It's now a standard feature of the policy engine.
Audit log reconstruction speed. Our requirement was to be able to reconstruct any payment decision in under a minute. In practice, our log query interface was taking 3–4 minutes for complex reconstructions involving multiple policy evaluations. We optimised the query path. All customers benefit from the improved audit log performance.
The audit trail in practice
One of the things we claim in our documentation is that every movement of funds through Proco produces a complete, queryable audit trail: transaction ID, policy decision log, agent attribution, counterparty, timestamp, and network confirmation. The claim is easy to make. What does it actually look like when you need to use it?
We've reconstructed our own payment decisions under two scenarios that approximate what customers would face in practice: a supplier querying why a payment wasn't received, and an internal audit of a spending category over a specific time period.
In both cases, the reconstruction was complete and fast. The supplier query was resolved in under two minutes: payment status, confirmation hash, network, timestamp, and the policy decision that approved the transaction. The internal audit produced a structured export with full policy audit trails for every transaction in the category.
The experience validated the documentation — and gave us specific user interface improvements that make the audit workflow faster. Those improvements are in production.
The operational metrics we track and will publish
Financial infrastructure earns trust through consistent behaviour over time, not through claims. We've committed to publishing our own operational metrics on a regular cadence. The metrics we track internally and will publish:
- Transaction success rate (target: 99.9%+)
- Policy evaluation latency (target: under 50ms at p99)
- Audit reconstruction time (target: under 60 seconds for any transaction)
- Payment settlement time (network-dependent, tracked per network)
- Policy engine edge cases discovered and time-to-fix
This isn't a marketing exercise. It's accountability infrastructure. If our metrics slip, that's information — for us, and for our customers who deserve to make informed decisions about the infrastructure they depend on.
The ongoing commitment
Proco on Proco isn't a launch event. It's a permanent operating commitment. As we add capabilities to the platform, we use them ourselves first. When we ship a new feature to customers, we've already run real operations through it. When we ask enterprise customers to trust us with their treasury operations, we can say: our treasury operations run on this too.
The financial infrastructure space has a tendency toward claims that outrun operational reality. We think the answer to that tendency isn't better marketing — it's accountability. Running your own money through your own infrastructure is one form of accountability. Publishing the metrics is another. Being willing to discuss edge cases publicly, as we've done in this post, is a third.
Proco on Proco is a promise: we'll never ask you to run on infrastructure we're not willing to run ourselves. That's the bar. We intend to keep it.
Further reading: What Your Agent Needs Before Its First Live Transaction · Building a Payment Policy Engine