Fiat DAOs: A bridge between DAO Treasuries and fiat debit cards

...to pay for IRL stuff, SaaS, plane tickets, pizza and more.

tl;dr

This essay is a proposal for how to give DAOs access to shared, fiat debit cards that can be used to pay for expenses. This will avoid reimbursements, and individual members needing to front cash for the DAO. It also builds a needed bridge between USDC and the banking system. If this is a topic that interests you, no matter your role in the ecosystem, please add your info here for updates. A second essay on technical specifics will be next, if there is enough interest.

The Proposal

DAOs are in the kingdom of possibilities phase right now. It’s intoxicating, with new ideas and theories and developments emerging practically daily.

For this essay, though, we’d like to cover one highly specific and targeted issue: fiat expenses. We realized there were real parallels between DAOs and the groups that use Braid every day: community groups, co-ops, food funds, HOAs, creative projects, shared houses, classrooms, professional organizations, podcasts, extended families, and more.

The details below outline a proposed solution, and a straightforward way to create a lightweight expense pool for a DAO.

What We Want to Build

We are considering adding USDC functionality to Braid. The funding process would be three steps:

  1. A DAO sends USDC from their treasury to a DAO-managed USDC wallet at Braid. We would only support USDC to start, due to our bank partnerships and compliance obligations.
  2. The USDC would be instantly off-ramped, converted to fiat via an exchange and sent via wire/ACH into a shared money pool. The DAO would determine who has access to the pool and what that access looks like.
  3. The DAO could use the pool’s debit card to pay for expenses without any need for reimbursements, and would have a record of all transactions in a shared space (this already exists, this is Braid’s core product).

This would allow for multi-user access, transparency, and accountability. Additionally, it would take away the burden and liability of the fiat spend from sitting on one person’s shoulders. Reimbursements are arduous and messy, and access to a shared pool for expenses can avoid a lot of administrative work around reimbursements.

It’s a solution designed for this:

Other Options

When thinking about this problem, we looked at the other available options. It appears that the only current options are to incorporate the DAO and get a business bank account, or to route expenses through an individual (whether they are using a regular fiat account or a crypto-funded card like BlockFi or Coinbase). If we’re missing any, please let us know.

Building a Bridge

For us, what’s special about Braid is that money pools are a useful tool for a very diverse set of people. We host money pools for church breakfasts, Alcoholics Anonymous, public art, classroom funds, intentional communities and more.

The challenge in bridge building here, though, is how to embrace principles of decentralization while maintaining the compliance necessary to operate in a highly regulated industry. There is an opportunity to combine the promise and idealism of blockchain technologies with the ubiquity and ease of use of fiat.

Our goal is to create a pool that is dead simple, accessible for anyone to use and super easy to fund with any payment method. We want to abstract away the regulatory complexities and the clunky quirks of our payments system to massively expand access and solve a real problem.

Put another way, what do you call 6 people who meet monthly to buy food and deep dive on vintage cars? They buy car parts and rehab cars together on weekends, maybe go to shows and maintain a collection. In the future, maybe we’ll call that a DAO. For now, no one really knows.

KYC and Regulatory Matters

This would not be a proper payments essay if we did not talk about KYC. The way that the U.S. financial system is structured requires anyone with access to money to go through a KYC (“Know Your Customer”) process. This is a requirement and the regulations that outline this are clear and comprehensive. Keep in mind that KYC is not the same thing as a credit check (many people make this mistake). KYC is verifying that you are who you say you are, a credit check actually runs your credit history.

This is no doubt an enormous topic throughout web3. It’s important to discuss it in relation to DAOs though, because the necessity of KYC conflicts directly with a DAO and its ability to support an open, decentralized, and pseudonymous membership.

For the purposes of this proposal, we will leave this as an open question. Our banking relationship requires us to KYC anyone with access to money, that is non-negotiable. Does that make the offering less appealing? Probably, yes. But compliance and the importance of maintaining our right to exist in the world of traditional payments is crucial.

The Origin Story

Like all good internet stories, this one starts with a tweet:

Seeing this tweet made it clear that the pain point is identical: when you have a group doing anything related to money, the burden of dealing with that money often falls to one person or a small group. They have a paltry set of single-user tools to act on behalf of the group. One person “footing the bill and submitting a proposal for reimbursement” mirrors the same behavior. And you have to wonder, is that really the best way?

The promise of DAOs is one of truly shared economics, in the best and worst sense. But that means that better tools to manage these shared economics are desperately needed. It’s the same problem for DAOs and any other multiplayer financial group out there: the selection of multiplayer fiat accounts are crap.

There are really only two kinds:

  • Joint Accounts, normally limited to 2 signers, generally for couples and families
  • Business Accounts, only available to incorporated entities

Banks, and even modern payment apps make multiplayer really hard unless you’re a business.

Issues with Incorporation and Business Banking

While there are great tools available in business banking, incorporating as a C-Corp or LLC forces unnecessary operational overhead. Besides that, leaning on business tooling betrays the spirit of DAOs as a decidedly new concept. This tweet from Arianna Simpson touches on the downside of creating an LLC:

David Kerr and Miles Jennings released an incredible paper on entity structures for DAOs recently.  Specifically, they said:

“The incongruity of many DAOs intended purpose with an incorporated business structure is evident.”

And then:

“…declaring a fictional business purpose is incongruent to the purpose of a DAO and the formality required to operate an incorporated business entity could negatively affect the development of the underlying technology.”

There are entities that aren’t businesses, and shoehorning them into corporate entities is not the right answer. The paper continues:

“They are analogous to partnerships, and yet not partnerships; analogous to corporations; and yet not corporations; analogous to joint tenancies, and yet not joint tenancies; analogous to mutual agencies; and yet not mutual agencies.”

The whole paper is worth reading. Another notable essay from Mario Gabriele at The Generalist, makes the comparison to cooperatives:

“DAOs differ from companies in significant aspects, particularly with regard to ownership. For this reason, cooperatives may be a more apt comparison. Coops are owned and controlled by the workers that contribute to it. This is similar to DAOs in which stakeholders receive tokens which grant governance power and assign ownership. It’s not a million miles away from your neighborhood grocery coop brought into the digital realm.”

If we want to live in a world where three friends can start a DAO on a Thursday night, have it live and funded by Friday morning, work on it for 2 months and then walk away, C-Corps and LLCs are not the answer.

The Workaround

This has been a problem for decades in non-web3 situations. The workaround has become common practice and entrenched: one person organizes and fronts the money, and then asks to get repaid. Expenses get entered, tracked and reimbursed.

This creates all sorts of problems and friction. A short list of them:

  • Someone fronts the money and doesn’t get fully paid back.
  • Someone fronts the money and the group doesn’t approve of it in some way.
  • Someone fronts the money and overcharges people, effectively skimming from the group.
  • The Treasurer must commingle personal and non-personal funds, creating an annoying administrative burden (as a lifelong Treasurer, I hate this part of it)
  • Anytime there are more than, say, 4 expenses, some sort of tracking mechanism needs to happen (spreadsheet, Splitwise, receipt apps, etc.)
  • One person is shouldering the financial burden for the entire group. All liability and responsibility rests with that person, and the burden is not distributed to the rest of the group.
  • There is sometimes a lag between when an expense happens and when a person gets paid back, meaning individuals are effectively making personal loans to the group.
  • Money is collected up front and then the expense comes in as higher or lower than the amount collected, and you have to do a second collection or pay people back.

These pain points are as true for a 4th grade classroom as they are for a DAO. Defaulting to the single-player workaround would be unfortunate, as DAOs present an opportunity to move completely away from established behavioral paradigms. Yes, it would be super easy for a single member of a DAO to use a crypto-native debit card and get reimbursed, but the issues will be the same. When all the fiat responsibility is delegated to one person, transparency and collective action are lost.

Groups and Financial Entities

In an essay in Crypto Tonight, Ian Kar says, “Web 3 isn’t that complicated--it’s simply attaching a wallet (therefore, a verified identity and a funding source) natively to any application or piece of software.”

Think about that in the context of ad-hoc groups. It’s an expansive proposal. When it becomes easy and straightforward to attach a wallet of any kind to a group project or a comedy troupe or a classroom, the potential is enormous.

But They Are Going to Steal All the Money

One interesting data point on pooling money that I’ll leave with you before we wrap. The knee-jerk reaction from most people when they hear about sharing money is one of fear. If everyone has access to the money, someone will steal it, is the commonly held belief. We have processed tens of millions of dollars through Braid, and the thing that has shocked me the most is how rare this actually is. Every pool has a set of controls and permissions to regulate access to funds and spend, but even in cases where those aren’t used, there are seldom issues with theft.

I know incidents have happened both in the real and the web3 worlds, but what we’re massively under-valuing here is the importance of social contracts and trust. When everything happens out in the open, the social consequences of screwing around are so enormous as to dissuade most people. The group mechanics provide their own sort of security. This was not immediately obvious to us when we started working on this, so we thought we’d share it here.

Squad Wealth articulates the case that groups are financial entities better than any other essay out there. Specifically, they lay out a case that:

The group is the basic user class for the tools we need today as a society, yet few pieces of software allow the squad as a whole to produce cooperatively and generate wealth together.

Groups are financial entities, period. The line between “business” and “personal” is blurring so much as to become unrecognizable, and while that is exciting, a new toolset is needed. We cannot contort groups into entities that fit our existing legal paradigms that were designed decades ago, we must create new ones. In that same sense, we cannot expect the old fiat toolset to adapt either.

The Follow-Up

If there is enough interest in piloting this, we will follow-up with a second essay about treasury specifics. It will include:

  • Exact details of off-ramping as we plan to implement it
  • How KYC will work, the many questions there, and why it’s necessary
  • Any questions that have come up and other ideas (one-time use cards for example)

As a fintech company, we are well-versed in the payment regulatory landscape, and have experience there. More specifically, our knowledge around shared accounts that exist outside of business banking gives us a relevant vantage point to examine this exact problem. We’re posting this publicly with the hope of gathering feedback and criticism.

Specifically, we’d like to know:

  • Is this product something that’s needed?
  • Would you use this product if it existed?
  • What are the flaws in what is being presented? (Don’t hold back)

Are you part of a DAO that would like to try out this product? Get in touch with us here. 

Thanks for reading.

Special thanks to those who read this in advance and provided feedback, we really appreciate it.

Subscribe to Braid
Receive the latest updates directly to your inbox.
Verification
This entry has been permanently stored onchain and signed by its creator.