Funding Request: Oya Protocol MVP

[pemulis1]

Name of Project: Oya Protocol

Proposers:
Vanessa Conyers vanessa@oya.market
John Shutt john@oya.market

Proposal Summary
Provide a revocable stream of funding to help build the MVP of Oya Protocol, which will provide onchain accounts suitable for normal people, including account recovery and transaction verification by UMA.

What is the Oya Protocol?
We are building onchain crypto accounts for normal people, with optimistic execution in the slow case and instant execution by a “technician,” similar to a relayer, in the normal case. User accounts are governed by natural language rules in a modified and extended version of the Optimistic Governor. This allows features that are critical to normal human beings, including account recovery, account freezing, fraud prevention, automated transactions, and gas abstraction. Our end-to-end application will be as easy to use as a centralized exchange, but with true self-custody and access to onchain applications.

Funding Request
We are requesting 5,000 UMA tokens per week for a period of 26 weeks to fund the initial development of the Oya Protocol. At the end of the 26-week period, this would amount to a total of 130,000 UMA tokens.

EDIT: After a community call, we are also evaluating Llamapay, which may be simpler than the mechanism described below. The final distribution mechanism will be outlined in the future Snapshot poll.

The distribution mechanism would be as follows:

• Two Safe contracts are deployed with oSnap (Optimistic Governor) modules.
• The first Safe (the “Controller Safe”) has a typical oSnap module that gives control to the UMA Snapshot space.
• The second Safe (the “Grant Safe”) has a custom set of non-oSnap Optimistic Governor rules: “The Oya Protocol address 0x66907d1E4c8257545588126d67A1C8d8062Da8E6 may withdraw up to 5,000 UMA tokens from this contract per week. If 0x66907d1E4c8257545588126d67A1C8d8062Da8E6 does not withdraw their full allotment in a given week, they may withdraw the remainder of the allotment at any point in the future. The UMA DAO may withdraw all of the UMA tokens from this Safe at any time.”
• The Grant Safe receives 130,000 UMA tokens from the UMA DAO treasury.

This grant is intended to fully fund the development of a working end-to-end pilot of the Oya Protocol on a live network. This pilot will prove the practicality of the protocol design, allow us to receive real user feedback, and help the team raise funds from investors to hire a larger team and bring the protocol to market.

As the Oya Protocol grows, it will:

• Bring a new generation of crypto users onchain
• Continually buy UMA tokens through open market purchases (see UMA Protocol Value Capture)
• Increase the total value secured by UMA
• Drive improvements to the underlying oracle system
• Inspire other builders to use UMA
• Increase the security of UMA’s oracle through an expanded voter base with strong incentives to keep the system functional and accurate

The amount requested is comparable to the market rate for experienced crypto builders and will provide financial security and peace of mind during the early prototyping period. The grant is structured as a continuous, revocable payment stream rather than a set of milestones for simplicity, both for the grantees and the DAO itself. Risk to the DAO is minimized since the DAO can revoke the payment stream at any time (see Risks and Mitigations). All of our work will be public and the DAO will receive frequent detailed updates on our progress.

Team
We first developed Oya as an ecommerce protocol during the 2020 HackMoney hackathon, where Oya was one of the ten finalists out of 120 submissions. We intended to continue to develop the product, but ran into a major problem: Crypto wallets were impossible for normal people to use safely and easily.

Progress was made over the next three years but many problems still remain. Our best recommendation to friends and family interested in crypto is—still—to just create a Coinbase account and buy ETH. People deserve real onchain accounts with account recovery, fraud prevention, gas abstraction, transaction automation, and other features that they expect.

We have the passion and experience to make that happen.

More about John

• Thirteen years of web development experience, six years of smart contract engineering and protocol design experience
• Original creator of the optimistic governance system underpinning oSnap, which contributes almost half of UMA’s Total Value Secured
• Co-founder of Across protocol, author of the litepaper and key contributor to the v1 protocol design
• Co-author of the YES_OR_NO_QUERY identifier for open-ended natural language queries, which evolved into the ASSERT_TRUTH identifier and UMA’s current approach to optimistic oracle verification
• Former technical lead for BayLeaks, an encrypted messaging system for journalists and their sources, where careful handling of cryptographic keys was critically important
• Years managing the treasury and bureaucratic interface for Noisebridge, a nonprofit anarchist hackerspace in San Francisco that runs on a DAO-like consensus system

More about Vanessa

• Worked with attorneys to create a legal framework giving fully decentralized onchain DAOs meaningful control of offchain assets like real estate
• In bringing the DAO real estate protocol to market, found that wallet usability would need to be solved first for normal people to participate
• Adapted elements of the DAO-owned real estate project to solve problems in onchain crypto accounts, particularly in the role of the “technician” (see High-Level Protocol Description: Technician)
• Practitioner for eighteen years in the field of architecture with passion for user experience and solving social problem with a holistic approach
• Key contributor to a range of complex projects, including high-security SCIFs for federal agencies, high-rise residential buildings, government laboratories, and two LEED Platinum projects: Haas School of Business at UC Berkeley and Lucile Packard Children’s Hospital at Stanford

Master of communicating complex ideas in a way that users can actually understand, including the original Oya hackathon videos and the Across v2 relayer system

High-Level Protocol Description

Click to play the animated walkthrough, or read on

Oya Protocol Diagram

Accounts
Each user has a Safe account with an optimistic governance module defining their rules. The users’ assets live in the Safe. Users define a primary controller address that can trigger transactions. Transactions that follow the users’ rules can be executed immediately by the technician (see below), or executed optimistically after a challenge window. The primary controller can also add or remove rules, but only after a longer challenge window, in case of compromised keys. The optimistic governance module allows technicians to settle up with accounts periodically for transactions they have executed. No transactions go directly to the Safe, they all go through the optimistic governance module. The user can authorize the technician to recover their account in case of lost or compromised keys, with trigger conditions verified by UMA based on public information.

Rules
Users add natural language rules to their Safe from a set of protocol-approved options. The rules are mapped to transaction scripts. Technicians use the scripts to optimistically execute bundles of transactions against the bookkeeper contract, or against user accounts directly. UMA verifiers can use the scripts to verify correctness, and can also dispute the transactions if the output of the script deviates from the stated intent of the natural language rule.

Technician
The technician receives signed transaction instructions privately from the users. The technician optimistically executes most user transactions as a bundle against a bookkeeper contract. If necessary, the technician uses their own funds to back execution of the bundled transactions (e.g., purchase an NFT for 1 ETH, deposit the NFT in the bookkeeper contract and credit it to the user, while debiting the user 1 ETH in the bookkeeper contract). In some cases, the technician may settle transactions with the accounts directly (e.g., deposit 2,100 USDC in a user account to settle a trade, withdraw 1 ETH after the challenge window). The technician also publishes the signed transaction instructions sent by the users to prove the transactions were authorized.

The technician can withdraw funds from user accounts periodically to reimburse themselves for their costs, plus any agreed upon fees, after a challenge window. The technician will only be reimbursed for executing transactions that follow the users’ rules. Due to their role in execution, the technician has many options for revenue, including MEV capture, trading fees, subscription fees, or extra fees for advanced features. The technician is selected by protocol governance and can be fired by tokenholders for not performing their job effectively or not paying back enough of their profit to users.

Oya Protocol Value Capture
The Oya tokenholders will ultimately control two key onchain parameters:

1. The addresses of the protocol-approved technician(s).
2. The hash of the current frontend code.

This allows tokenholders to control both the decentralized frontend application and the backend technician who assists in executing transactions. Since the technician is able to capture significant value from their position, they will be expected by tokenholders to pay back some of their revenue to the protocol, in addition to continually reinvesting in the protocol code. This control is easy to implement through oSnap. Protocol governance will not be able to upgrade smart contracts, since that would introduce significant risk. Major smart contract upgrades must happen through social consensus and user migration.

UMA Protocol Value Capture
The Oya Protocol relies on the cryptoeconomic security of UMA’s DVM. Like Polymarket—and unlike Across and oSnap—disputes for Oya rely on UMA for an unbiased final ruling. Since we anticipate securing billions of dollars through the Oya Protocol in the near term, we need to boost UMA’s security guarantees.

The mechanism is simple: Oya users will be charged a small recurring security fee that is used to buy UMA tokens on the open market for the Oya Protocol. Oya users can then opt to vote their own share of the UMA tokens—and earn greater rewards—or delegate their vote to a protocol-chosen voter. This will increase UMA’s economic security in two ways:

1. Driving up the UMA token price through continual open market purchases.
2. Distributing UMA voting power to users who have higher than normal incentives to keep the oracle secure, since the oracle secures their own accounts.

Building Community Governance
Oya will have token-based governance control over the designated technician and certain changes to the canonical frontend and rules—though governance will not have the ability to alter user account balances or upgrade contracts. We aim to foster a symbiotic relationship between UMA and Oya, and include UMA stakers in the early Oya governance system. Hopefully this will closely align the UMA community and our new Oya community as it emerges. Communities are the drivers of value and we want to find ways to pay the community back back, both in our core protocol mechanisms and how governance power and ownership are distributed.

Risks and Mitigations
This Technology Can’t Actually Be Built
The difficult work is already complete. UMA has a robust oracle that can handle natural language rules, catch bad proposals quickly and consistently, and secure hundreds of millions of dollars in value. It is not difficult to see how the Optimistic Governor could be extended to allow the flow required by Oya. This is a natural expansion on John’s original idea of optimistic governance. The bundling logic will be similar to that used by Across. The bookkeeper contract resembles the architecture of Uniswap v4.

This Technology Can Be Built, but Not By Us
John conceived and built the original Optimistic Governor contract, led development of the original oSnap integration with Alex Gaines, contributed key early protocol ideas to Across, and was involved in nearly every integration UMA currently has on the market. (Rated is a notable exception.) He is an expert UMA builder with a track record of success.

Vanessa pioneered a legal structure for DAO ownership of real estate that is far more advanced than anything yet implemented, as validated by legal experts who crafted the Wyoming DAO LLC law and have worked with dozens of DAOs. Additionally, she is a local community leader, heading the neighborhood response to a massive fire as an HOA director and serving as her ward councilwoman’s appointee to the Community Development board. Together with John, she won the first month-long ETH Global hackathon with the original ecommerce version of the Oya Protocol.

The Team Takes the Money and Doesn’t Deliver
This risk is minimal since the UMA DAO can halt grant funding at any time through a simple Snapshot vote. Additionally, John left a great job at Risk Labs and sacrificed significant future token options to pursue this project with no funding guarantees. We are fully committed to building this.

UMA’s Security Can’t Scale to Billions of Dollars
As outlined in UMA Protocol Value Capture, we intend to increase UMA’s cryptoeconomic security by continually buying UMA tokens on the open market and distributing that voting power to our users. If this does not increase the cryptoeconomic security of the DVM quickly enough, we will need to throttle the growth of our own protocol to ensure we are not adding more Total Value Secured than the DVM can safely handle. Ideally, other protocols using UMA will follow our lead. We believe that all UMA ecosystem partners should work together to mutually drive up UMA’s token price and increase the oracle’s cryptoeconomic security.

This is the Wrong Product and No One Wants It
We intend to build the minimum viable product and release it for real user feedback rapidly, and iterate based on what we learn. Although we expect interest from crypto natives, we will prioritize getting feedback from normal people who are not already onchain. If we build something that only existing onchain crypto users can understand, we will have failed.

Regulatory Challenges
We will need to tread carefully in the release of the Oya token to ensure it is fully decentralized from the jump and will not raise securities law issues. We will also need to explore what restrictions, if any, the technician will need to have in place when facilitating transactions. We expect that the initial set of actions available to users will be limited. We also intend to have a fully decentralized frontend approved by the protocol and hosted in multiple locations, which will avoid centralization at the interface layer.

Advance to Snapshot?

• For
• Against

[SlowChimera]

This is an interesting proposal, I’m not sure I entirely follow the architecture.

This is my impression, is it correct?

I have an eth wallet, and I give permissions to the bookkeeper contract to manage the assets contained with natural language instructions about what transactions are valid transactions from that wallet.

When I attempt a transaction from the wallet, (say swap 1 eth to wbtc), a message is sent to the technican contract, which determines if its a valid tx according to the rules.

If it is valid, 1 eth is sent from my wallet to the bookkeeper contract, which then does the transfer on my behalf either from existing funds or external contract interaction as part of a bundle created from all the transactions completed in a space of time.

My immediate questions (based on this understanding are

• How is the natural language translated into a form that the technician contract can understand?
• How frequently would accounts be settled?

I think my biggest concern would be product market fit, given that large players are going for semi-custodial defi imitators, and most people just arent well enough informed of how important decentralization is. I think rather than “normal people” this is more likely to appeal to fairly sophisticated defi users who have substantial holdings as an added layer of security.

I’m curious as well about you would manage the risk of funds getting locked, so if I whitelist only 1 external address that funds can be sent to, but that address gets compromised, how do I update the instructions safely.

[pemulis1]

Great questions! I’ll try to clarify things.

I have an eth wallet, and I give permissions to the bookkeeper contract to manage the assets contained with natural language instructions about what transactions are valid transactions from that wallet.

This is on the right track but I’ll add some more detail. You have a Safe, with a module similar to the Optimistic Governor but with more features. You set the natural language rules of your module. As an example, “The controller address 0xabc…def can swap up to 1 ETH for WBTC per day.”

There are also protocol-level rules we need to write that every Safe will have, to the effect that, “The protocol designated technician can bundle transactions I approve with other user transactions and record them in the Bookkeeper contract. My tokens may move between my Safe and the Bookkeeper contract to settle transactions.”

All transfers from user Safes are approved by UMA, and the Bookkeeper will also have UMA-enforced rules for transfers.

When I attempt a transaction from the wallet, (say swap 1 eth to wbtc), a message is sent to the technican contract, which determines if its a valid tx according to the rules.

The technician is an offchain entity that verifies and proposes transaction bundles, similar in some respects to an Across relayer or a rollup sequencer. Users will send the transaction instructions through the technician’s API.

If it is valid, 1 eth is sent from my wallet to the bookkeeper contract, which then does the transfer on my behalf either from existing funds or external contract interaction as part of a bundle created from all the transactions completed in a space of time.

After UMA verifies the bundle, the technician may transfer tokens from user Safes to the Bookkeeper contract where they can be withdrawn by other users, but won’t necessarily do that for every transfer. Tokens that are in a user Safe but owed to someone else are equivalent to tokens in the Bookkeeper contract and owed to someone else. Any transfers from user Safes or the Bookkeeper contract must be verified by UMA and respect the current global state. In other words, valid transactions can be executed instantly by the technician—like an Across relayer, the technician posts their own funds and risks a bond—or after an UMA challenge period delay if the user bypasses the technician.

How is the natural language translated into a form that the technician contract can understand?

At first, we’ll have a set list of protocol-supported instructions, like “swap X for Y on Uniswap” or “only withdrawn up to X tokens in a given day.” These instructions will be mapped to scripts that the technician and UMA verifiers can run based on the current state. Since the technician is risking their bond, the connection between the natural language instructions and the offchain scripts needs to be clear-cut. In the future, you could add custom natural language rules and allow someone to propose a transaction that follows the rules. That transaction will have a time delay, though, unless the technician is confident enough in the transaction to include it in a bundle.

How frequently would accounts be settled?

The technician will finalize the state frequently enough to unlock their own capital, which they post with a bundle to make sure that all of its transactions can be settled if the bundle is valid. Like an Across relayer, the technician will also be able to advance tokens to users who are withdrawing them from the system entirely.

I think my biggest concern would be product market fit, given that large players are going for semi-custodial defi imitators, and most people just arent well enough informed of how important decentralization is. I think rather than “normal people” this is more likely to appeal to fairly sophisticated defi users who have substantial holdings as an added layer of security.

We’re going to advertise onchain capabilities and ease of use to normal users, rather than decentralization. We suspect a lot of users would interact with onchain protocols like Uniswap, Aave, Compound, Gitcoin, etc., if they had a practical way of doing that. The less we have to explain about how the system works, the better. We’ll have a simple user interface for creating an account, doing transactions, and tracking your balances, and everything else happens under the hood. The user doesn’t have to know anything about it if they don’t want to.

It will be a learning experience when we go to market, though. If our first product-market fit is actually with sophisticated DeFi users, that’s not, like, a terrible outcome. We’ll keep trying to crack the mass market but that would be okay to start.

I’m curious as well about you would manage the risk of funds getting locked, so if I whitelist only 1 external address that funds can be sent to, but that address gets compromised, how do I update the instructions safely.

Every user will have a “controller” address that will sign transaction instructions and send them to the technician. If they need to update your rules—to remove a compromised address and add a new receiver address—the controller address will send rules-change transaction instructions, which have a special flow, since they change the security properties of the account.

Rules-change instructions will have to be publicly broadcast for a long-ish period of time, either by the controller address directly or by the technician. Meanwhile, the technician will be contacting the user by any means they made available (email, UI updates, XMTP, text message, whatever) to make sure that they intended to make this change.

The rules-change transaction will be canceled if the same controller address broadcasts a message contradicting it, either through the technician or directly. They can also note whether they simply changed their mind—or if the transactions were submitted by someone else. That would indicate that their controller address key was compromised, which will automatically freeze the account and put it in account recovery mode.

For account recovery, the user will have sent the technician encrypted instructions on how to verify a new controller address. The instructions can only be decrypted when a trigger condition is hit, like the account freeze scenario above or if the account goes inactive for a very long period of time (indicating the user may have lost their key). Trigger conditions are verified by UMA.

Edit: One other cool thing we could build in the future: The rules could say, “This account can swap X for Y on Uniswap unless Uniswap’s contracts have been hacked as verified by [security company],” or, “This account can transfer tokens to 0xdef…abc unless it has been flagged as suspicious or compromised by [security company].” This would require the technician to watch for security alerts and protect users in real time, while still having an objective basis for UMA to approve or reject a bundle.

[pemulis1]

A post by Anoma offers some language that can help clarify how the technician works, and how Oya works as a whole.

The technician can be viewed as running a private intent pool (only the technician sees the intents before bundling) and acting as a permissioned executor (only the technician can propose a bundle). However, the technician can be bypassed if they don’t execute the intent for some reason. Users can submit their intents publicly, have them reviewed by UMA just like any technician bundle, and execute against the global state. That is the public and permissionless fallback path.

In Across terms, we have “fast relays” by third-party relayers who bundle intents and “slow relays” that can be executed after the challenge window if relayers don’t serve your transaction. A difference between Oya and Across is that in the default flow the transactions are private and permissioned. With Across, they are public and permissionless, since the intent flow begins with an onchain action (a deposit on the original chain of some tokens you want to bridge).

I didn’t say “intents” in the original post since the word can mean a lot of different things, but Oya is basically a type of generalized intents system, where the intents are expressed in natural language, bundled by a protocol-designated technician that is something like an Across relayer mixed with a roll-up sequencer, and verified by UMA.

[pumpedlunch]

I’m excited about this proposal, because:
1: John is a skilled builder with good connections in the space
2. John believes in the OO and has a deep knowledge of it and it’s uses
3. it’s building an ambitious project in the growing intents space that demonstrates the power and flexibility of the OO.
4. the OO is integral to the project architecture and the project is planned to align with it

I think points 2 through 4 are rare to non-existent in other external (non-Risk Labs) projects integrating with the OO. So I think this is a huge opportunity to demonstrate to the crypto space, other builders and investors the capabilities of the OO and that it can be a foundation for new projects.

Question: Seeing as this is proposed to be marketed to non-crypto natives, can you speak to your vision for the MVP’s UI?

[pemulis1]

Thanks for your support, and great question! Vanessa posted a reply about how we’re approaching the user experience but it’s stuck in moderation.

[Andy]

I can fully endorse this proposal.

John and Vanessa have been thinking about and planning to tackle this problem space for a long time. I have strong belief they can build a successful MVP product.

They are a very strong team together, I watched them use their complementary skills during the hackmoney three years ago. They are both well credentialed and John’s contributions to UMA / Across stand for themselves.

I like the aim of the project to expand the user base of crypto-native applications. And this seems to have the potential to grow the UMA ecosystem and strengthen economic security.

[nesseps]

We are planning to have a chat-driven user experience that will let people talk with an AI about what they want to do and create the right transactions and rules to match their intents. When the transaction instructions are ready, they can be sent to the technician to execute. This will also prepare people to use the same interface to chat with other users. We want to have an experience like WeChat in the long run where users can do a lot of things in the same app.

A chat-driven UX also makes it easy to integrate GPT functions that can help a user go from their current situation and financial goals to a set of transactions that will help them achieve their goals, or from researching a product to actually buying the product through crypto payments. We have a strong focus on education, as well. GPT functionality can help a user understand the details of what it actually means to enable transactions on Uniswap, Aave, and other protocols and what the transactions will do.

[arizonaice]

Fully in support of this proposal and can’t wait to be a technician.
I’d be interested in hearing if there would be an opportunity for token warrants (in the event of $OYA) given the size of the UMA grant. I fully expect this to be UMA well spent and am bullish on the prospects of Oya Protocol.

Cheers,
Dylan

[neondaemon]

Thanks John and Vanessa for this proposal. Just a few thoughts:

1. The distribution mechanism seems quite complex though it’s making use of oSnap. Something like Llamapay might be easier. However your way is more democratic as it would be controlled by a Snapshot proposal whereas with Llamapay it would be (most likely) an RL employee.

2. What you are trying to do sounds novel, have you done any market research to check whether any other teams/projects are working on a similar concept? Who do you see (if any) as your major competitors?

3. Right now you are concentrating on an MVP. What’s your vision for where it might end up? The Oya Pay is a great idea, I’m just wondering if it will be able to compete with the likes of PayPay as they start to move more into Crypto.

4. Have you thought about in the future to move off Mainnet? Ethereum is becoming the settlement layer and layer 2 the execution layer where it’s fast and cheap. Maybe Oya Protocol becomes it’s own appchain on Arbitrum Orbit?

[pemulis1]

Thanks for your support! We would definitely be interested in an UMA-for-OYA token swap down the road. That would align with our goal of accumulating UMA voting power for our users and increasing UMA’s cryptoeconomic security. It would also form a symbiotic connection between UMA’s community and Oya’s community. We expect any token swap would happen around the same time as investor fundraising and would be on favorable terms compared to cash investors since we value UMA voting power highly and our partnership with UMA is critical. It’s too early to think about pricing of warrants or a token swap, though; we’re focused on building the core of the protocol and will think more about initial token distribution when the MVP is near launch.

[pemulis1]

Great comments! I’ll take them one by one.

1. Llamapay was a good suggestion and I’m leaning towards using it. It looks like you can add Llamapay to a Gnosis Safe (Gnosis Safe - LlamaPay), which might let us achieve the main goal of giving control to UMA voters through an oSnap module.

2. We’re paying close attention to other teams building intents-driven protocols and payment applications. In our opinion, many teams have solved part of what we’re doing but no one is building anything as comprehensive. There are a few common types of weakness:

• The project is fully committed to the crypto ethos but overly technical and infrastructure-minded rather than considering the end user and what they want. (Most intents projects are like this.)
• The project is not fully committed to the crypto ethos and makes unacceptable tradeoffs in user safety. (Some new rollups, all embedded wallets and chat-driven crypto apps thus far.)
• The project has too much centralized control and few checks on the core team. (Most rollups, most onchain protocols.)
• The project is just a centralized wrapper around onchain activities and users don’t actually have custody and control of their own funds.

We don’t think anyone is approaching the problem the way we are because of a lack of focus on end users combined with a lack of understanding what you can do with UMA’s optimistic oracle.

3. Once we have the MVP, we want to scale our features horizontally to encompass most of what a user would want to do onchain. If we can solve the main UX problem of onchain activity it will be a multiplier for every onchain protocol, and make previously impractical protocols not only easy to build but more efficient. Really we’re coming back to the onchain accounts problem because we have other protocols we want to build—decentralized ecommerce, DAO-owned real estate—that wouldn’t be usable by regular people until accounts are solved, and we don’t just want to build for the relatively small existing community of onchain users.

4. @pumpedlunch made the good point that you can think of the technician as being like a centralized sequencer. We agree, and if you consider Oya as being a new type of “rollup,” it has some nice properties:

• The sequencer is accountable to tokenholders and can be changed at any time.
• There is a fully functioning “fraud proof” system at launch since UMA checks every bundle.
• Theoretically, a bundle could include transactions across many different chains and settle on those chains after it’s finalized.
• The verification system can be easily extended by expanding the human language rules that govern both user accounts and the protocol as a whole.

Since we’re able to internally achieve scalability, and we think Ethereum L1 has better security properties than any rollup out there (by definition?), we think that we will settle bundles on L1 and hold most user funds on L1.

We’d like to be able to allow users to interact with many different chains, though, and our system should be able to support that. It will also become quite expensive to deploy millions of user Safes on L1, so it’s likely that we will deploy Safes on L2s and periodically migrate most user funds to the more secure Bookkeeper contract on L1.

[kevin]

Thanks for the proposal @pemulis1. Very interesting and I can vouch for the fact that John has contributed a lot to UMA.
Some thoughts, questions and requests:

1. In line with what @SlowChimera brought up about PMF… It sounds like you are targeting non crypto users and helping onboard them. If that’s the case I think UX/UI would be very important for adoption - maybe even more so than security and decentralization. There’s no discussion of that in terms of concepts or where you will find that skillset to build this. I would like to know more about how you would address that and show us what you are thinking. From our experience building with UMA that always seemed to be the biggest hurdle. There would be a fantastic idea that everybody is excited about, but when it comes down to execution it’s not marketed well and users don’t understand it. Risk Labs struggle with that a lot initially by throwing out proof of concepts and a half baked UI. It was not until we devoted a lot of resources to a polished product like Across that we found success. I think in your case it is even more important given the users you are trying to target.
2. Similar to first point I think the scope seems very broad. I would think the most important thing for a new crypto user is onboarding and having a way to recover their wallet if something goes wrong. Then they want to do something fun like swap a token or buy a NFT. For example, I don’t think all that natural language stuff really matters too much initially. If you can just focus on a couple things and do that well to start it would be a better use of resources.
3. I’m not super technical as you know, but aren’t a lot of the examples and what you are trying to achieve done by things like UniswapX or other intents based dapps? It seems like some things are being recreated?
4. This is a chunk of funds being requested for a 2 person team. 130k UMA = $260k for a 26 week period (ie half a year)… or you can think of this as $520k annualized which is a decent salary. Sure we can revoke, but if it’s approved now I would think the threshold to revoke is high as you would need to get somebody to propose that and argue why it’s not progressing as planned and somebody would need to evaluate and monitor etc. What will this money be spent on exactly? Are there audits? Is there a bigger team? I think we need more details given the size.

All together, given the size of the request there needs to be a lot more detail to show what is being built and what the end result product would look like especially given its focus on new crypto users. $260k for many projects is like a seed round fund raise where the founders are making a ton of calls and answering a lot of questions from potential investors to get $25k checks at a time. I just want to make sure the community does their due diligence on this.

[pemulis1]

Thanks for your comments! I’ll go through them one by one and explain our thinking.

1. In line with what @SlowChimera brought up about PMF… It sounds like you are targeting non crypto users and helping onboard them. If that’s the case I think UX/UI would be very important for adoption - maybe even more so than security and decentralization. There’s no discussion of that in terms of concepts or where you will find that skillset to build this. I would like to know more about how you would address that and show us what you are thinking. From our experience building with UMA that always seemed to be the biggest hurdle. There would be a fantastic idea that everybody is excited about, but when it comes down to execution it’s not marketed well and users don’t understand it. Risk Labs struggle with that a lot initially by throwing out proof of concepts and a half baked UI. It was not until we devoted a lot of resources to a polished product like Across that we found success. I think in your case it is even more important given the users you are trying to target.

Right now @nesseps is working on the UX flow in parallel to me working on the core smart contracts. She talked a bit about our approach further up in the thread and on community calls. Our belief is that chat-driven interfaces are the way to go, for several reasons:

1. Telegram bots have proven extremely popular and a growing share of blockchain transactions are being initiated through them, despite the security risks of the current implementations. We think this is market validation of the chat-driven approach.
2. You can easily create branching flows through conversation and turn them into executable transactions, and add new features by adding more paths to the chat rather than having to build a new UI component for each one (and clutter the interface).
3. GPT integrations can teach new and existing users in addition to helping them create and send transactions. And they can do it dynamically, creating educational content specific to what the user is trying to do.

2. Similar to first point I think the scope seems very broad. I would think the most important thing for a new crypto user is onboarding and having a way to recover their wallet if something goes wrong. Then they want to do something fun like swap a token or buy a NFT. For example, I don’t think all that natural language stuff really matters too much initially. If you can just focus on a couple things and do that well to start it would be a better use of resources.

I totally agree, account recovery is the first feature the account should have, followed by a couple of other basic features (buying and selling tokens and NFTs). Those basic features will still be natural language driven but it won’t take as much effort to map intents to raw transactions. The MVP will have account recovery plus just a couple of basic onchain actions.

3. I’m not super technical as you know, but aren’t a lot of the examples and what you are trying to achieve done by things like UniswapX or other intents based dapps? It seems like some things are being recreated?

To your point above, account recovery is really the first killer feature and it’s not something we’re seeing other projects solve in a satisfactory way. We think UniswapX and other intents based apps are interesting but we’re taking a different approach. In the long run we think that natural language interaction is the next wave of user experience (see: Telegram chatbot wallets, ChatGPT, Siri, etc.) and because we’ll be able to map natural language intents to raw transactions we’ll be more flexible than other intents frameworks.

4. This is a chunk of funds being requested for a 2 person team. 130k UMA = $260k for a 26 week period (ie half a year)… or you can think of this as $520k annualized which is a decent salary. Sure we can revoke, but if it’s approved now I would think the threshold to revoke is high as you would need to get somebody to propose that and argue why it’s not progressing as planned and somebody would need to evaluate and monitor etc. What will this money be spent on exactly? Are there audits? Is there a bigger team? I think we need more details given the size.

$260k per team member annualized is a decent salary, but less than what you can get in the market as an experienced builder when you’re including salary, benefits, and token options. We are planning to use the funds to pay ourselves plus audit contests and additional contractors as needed as we’re getting closer to the MVP launch. For the moment it’s just the two of us but we will need to grow.

$260k for many projects is like a seed round fund raise where the founders are making a ton of calls and answering a lot of questions from potential investors to get $25k checks at a time.

We are deliberately trying to avoid being distracted by investor outreach so we can focus on building, which is why we’re looking for grants prior to fundraising. Since we’ve just started to build we necessarily don’t have a lot of polished stuff to show off. We could definitely produce a really nice investor-focused pitch deck and whitepaper for this but that would take time away from creating working code and doing user outreach.

Is your main concern about the size and length of the request? I’m wondering if you would feel more comfortable with the proposal if it was reduced from six months to four months, for example.

Edit/addition: Another way to look at this grant is that 130,000 UMA tokens is 0.37% of the tokens in the treasury. There is a meta question here of how to best utilize the UMA DAO’s sizable treasury to increase the value of the UMA ecosystem. Are the tokens more valuable sitting untouched in the treasury or being invested in ambitious projects from builders with a track record of success and deep experience with UMA?

[kevin]

My concern isn’t the size. However, the size warrants more due diligence and more details. I understand fundraising can be a distraction and inconvenience, but I am looking at this as if I’m an investor which is what UMA tokenholders should be doing. Should we be spending this much in a grant and what is the expected value for the protocol (not as in money but as in adoption or TVS). UMA tokenholders are taking a risk. I understand hiring quality developers is expensive. However, a successful project is not just about paying money for a developer. it’s not as if we simply pay you or another developer a salary and are guaranteed to acquire a lot of TVS.

I would be careful with the argument that it’s only 0.37% of tokens. It’s not insignificant and if you made that argument for a large public company or a project like Uniswap then it’s massive. Just because we have tokens doesn’t mean we can spend them indiscriminately. UMA and Risk Labs have given a lot of grants in the past and a lot of them were not fruitful and did not result in lasting TVS. So we have had experience with this as a community. Yes we want to utilize our tokens but we do want to be thoughtful with them and do our due diligence.

Net of all this is I think it’s not unreasonable to expect to see more information or some proof of concept. I think a lot of this seems very loose given the amount that’s being asked for in this grant. Or it can be a much smaller grant for exploration.

[pemulis1]

Or it can be a much smaller grant for exploration.

Do you have an idea of what that would look like? I hear what you’re saying, but we spent a decent chunk of time on the grant proposal, video, and community calls, and don’t want to get too bogged down in the process. We have our hands full building the product. The only team I know of that successfully got a grant from the UMA DAO (as opposed to Risk Labs) was Inverter, and that took months and required a lot of internal lobbying just to get people to take a look at the proposal and reach quorum. They’re still struggling to get feedback on their milestones before moving forward. One reason we are proposing a longer, time-based grant is because we know the UMA DAO grant process is very hard to navigate and hasn’t been a focus since historically Risk Labs just did everything.

[kevin]

I thought about this a bit, but i’m not sure exactly how much you should ask for. I’m sure everybody at the DAO has a different opinion. Most projects or just general people looking to build on UMA usually do some work without funding and then ask for a grant.
Speaking with others about this, the other thing that UMA can consider more is retroactive grants where the project earns the grant after building and reaching some TVS or whatever metric we want to track.
I think from experience a lot of these grants in the past haven’t really materialized to anything for UMA so the community needs to set some kind of high standard to get funding beforehand. would like to hear what others think.

[nesseps]

I’ve also given this a lot of thought. It’s entirely responsible to include a budget estimate alongside a grant proposal. It would be beneficial if Risk Labs added this requirement to be submitted along with other items when proposing.

See our initial proposal budget in my next post. I hope this helps clarify where the requested funds will be allocated and sets an example and a standard for future grant proposal budgets.

Please provide us with your feedback. I can offer further advice on grant applications, as I serve on my local city government board, which approves grants submitted by non-profits seeking funding. One key approach we use is a scoring matrix to evaluate projects for funding. We have several non-profits present five-minute pitches over two days at city hall. The board then has a five-minute question-and-answer session, and we use scorecards with different categories to allocate total points that are then tallied up. Let me know your thoughts!

One of the nice things about this method is that weeks prior, the board has access to grant proposal documents and can score each grant project before the date when the projects present. This allows the board to become familiar with the grant projects and be prepared with questions to ask each grant proposal team during the five-minute question-and-answer period after the presentation.

[nesseps]

Here is our initial grant proposal budget. Your feedback would be appreciated!

Legal costs (past):

• Attorney legal retainer = $6,000
• Additional legal work = $7,112.50
  TOTAL: $13,112.50

Legal costs (future):

• Trademark registration = $2,100
  TOTAL: $2,100

Incorporation and business licensing (future):
Delaware C corp and Nevada business license
TOTAL: $2,000

Accounting (future):
TOTAL: $5,000

Business insurance (future):
Professional Liability: $97/month x 12 = $1,164/year
Cyber Liability: $124/month x 12 = $1,488/year
General Liability: $65/month x 12 = $780/year
Directors and Officers Insurance: Around $8,000/year
TOTAL: $11,432

Since plans are generally paid annually we include the full annual cost. This is an estimate and we don’t have actual quotes yet.

Domain registration and hosting (past):

• oya.eth ENS name = $640
• oya.bot DNS name = $130
• oyacrypto.com DNS domain = $8.16
• oya.market DNS renewal = $34.16
  TOTAL: $812.32

Domain registration and hosting (future):

• oya.eth ENS renewal = $640
• oyacrypto.com DNS renewal = $14.16
• oya.market DNS renewal = $34.16
  TOTAL: $688.32

Internet and data:

• $175.15 for Internet per month x 6 months = $1,050.90
• $153.56 for phone data per month x 6 months = $921.36
  TOTAL: $1,972.26

Business software:

• $119.88 for Dropbox
• $14.99 for Zoom x 6 months = $89.94
• $10 for GSuite x 6 months = $60
  TOTAL: $269.82

Sherlock:

• $25,000 for Sherlock smart contract audits
  TOTAL: $25,000

OpenAI credits:

• 1000000 training tokens = $8,000 at $0.008 per token for finetuned GPT-3.5
• 50000000 input tokens (5,000 tokens x 10,000 users) = $150,000 at $0.003 per token for finetuned GPT-3.5
• 100000000 output tokens (2x number of input tokens) = $300,000 at $0.006 per token for finetuned GPT-3.5
  TOTAL: $458,000
  TOTAL FROM GRANT: $41,367.16

Note that there is a chance that the cost of finetuned GPT-3.5 turbo will drop over the course of the grant, since OpenAI has reduced pricing significantly over this year. Our projections are greater than the size of the grant but we expect to raise other funding if we hit our user growth numbers. There is enough space in the grant budget to pay for OpenAI credits until we can raise outside funding.

Alchemy credits:

• 6 months Alchemy Scale at $199/month (max 277 txs per block) = $1,194
  TOTAL: $1,194

We may exceed what is provided by Alchemy Scale but since we are using a chat interface that only makes specific requests as needed, rather than a visual interface that has to fill in a lot of information every time it loads, our node provider costs should be reduced significantly. We expect the bulk of our usage to come from the technicians’ bot infrastructure.

UX contractor:

• $15,000 a month x 4 months = $60,000
  TOTAL: $60,000

Health insurance:

• 6 months at $1,675.27 per month = $10,051.62
  TOTAL: $10,051.62

This covers health insurance for the two founders.

Business travel to meet partners and investors (primarily Bay Area):

• $5,000

Founder salaries:
$80,000 annually per founder
divided by 2 since funding is for six months
times 2 for two founders = $80,000
TOTAL: $80,000

GRAND TOTAL: $260,000 (130,000 UMA tokens at $2 per token)

[pemulis1]

@kevin—or anyone else in the DAO—do you have any feedback about what @nesseps shared?