Why you should care about trustless...

At this point, it’s not controversial to believe that “Web3” is building upon Web2 and Web1. Per @cdixon’s Tweet,

Web1: read
Web2: read + write
Web3: read + write + own

Of course you need the technologies and infrastructure of Web2 to build Web3. Of course centralized servers (both storage and compute) will be used in Web3. Of course there are use cases where one would require a faster mechanism to execute transactions (e.g. high-frequency trading). But as with anything in technology and engineering, there are trade-offs.

What are we building at OAK?

Our CEO, Chris, refers to our innovation as a significantly more powerful transaction. We’d call the typical (wallet to wallet) transaction PLUS OAK’s automation as “autonomous transactions.” You can imagine these transactions as one where you own both the asset and your intention for that asset (ie whatever action you want to take). You own both of these until you decide not to. There is no other actor (bot, centralized server, smart contract, etc.) that’s deciding for you.

What you “own” in OAK’s Web3 decentralized vision is: asset + plan for asset

For example, if you intend to create a payment stream (or pay a subscription service) to a creator you support, and you’d like to pay this creator 0.1 ETH every month, with OAK’s solution, you have total control of that ETH until the ETH goes to said creator’s wallet. This seems trivial, right? It seems like an experience that you’d expect in Web2.

What are your current decentralized automation options?

Without OAK, a Web3 user who wants to create the payment stream example above has the following options:

Delegate some funds to a smart contract (that they likely don’t own) to create a payment stream.
Spin up an AWS server. Save their private key on the server. Then the server runs the automation for them.

The problem with both of these solutions is that they are inherently insecure, and/or require significant technical expertise to understand how to create something as simple as a subscription. In EVM-land, many keeper networks and bots rely on heavy proxies to control their users’ funds and thus do not need an approval from them to spend them for each task the user wants to run. That means that in this equation of asset + plan for asset, the consumer owns neither. Not your keys, not your coins!

OAK’s Solution

Web3 innovation and usage will be capped and continue to be controlled by centralized entities (i.e. banks, or neobanks called centralized exchanges) if we don’t provide a secure, trustless and decentralized solution for both the asset and the user’s intention for the asset. Without going into the technical minutiae, this is a lot of the reason why the OAK team chose to become a Layer 1 building on the Substrate framework. We want to change the primitives and effectively create an event-driven virtual machine (OAKVM) to store the user’s intent on-chain.

How are we going to provide this powerful transaction to the end user?

This is where I’d happily provide more context on our roadmap. For our (not so) secret sauce, we are dividing the roadmap into two areas: triggers and actions.

Triggers are the “when”. Actions are the “what”. For the example above: I want to send 0.1 ETH (action) to a creator every month (trigger).

Triggers

Time-based trigger
Price-based trigger
Smart contract or custom trigger
Interchain, off-chain, on-chain event triggers

For our triggers, we built out an MVP with the simplest possible trigger: a future time execution (N=1). As the base case is proven out, we are adding to it by creating recurring (N>1) time triggers (a la cron jobs). For example, I want to send ETH on March 14th to Bob (N=1) vs I want to send ETH every 14th of the month to Bob (N>1) for the next 6 months. This very simple infrastructure feature unlocks a number of Layer 2 use cases:

Payment streams
Subscription services
Payroll services
Dollar cost averaging
…and many more

After building out recurring time triggers, we plan on building out price triggers. An example use case for this is advanced order types on AMM DEXs. Today, if an everyday consumer wanted to create something more sophisticated than a market order, their options are:

Use a centralized exchange
Spin up an AWS server…see above.
Create a limit-order-like call on Uniswap (aka range order)

With OAK’s automation technology, users will be able to create any type of order including limit, stop loss, and iceberg simply by having their favorite DEX integrated with our chain.

Actions

Once your trigger is in place and stored in the OAK Blockchain, almost any on-chain execution is then enabled with our OAKVM. Examples include:

Sending an event on-chain
Executing a transaction from wallet A to B (native token, ie OAK)
Parachain <> relay chain token transfer (OAK<>DOT)
Parachain <> parachain token transfer (OAK<>GLMR)
Smart contract or custom execution logic

While some of these examples may look simple, the power they unlock is endless. From simple payroll use cases to full blown metaverse economies, OAK aims to power automation across the entire Web3 landscape.

Looking Forward

We’ve published our product roadmap plans for the coming year. In it, we highlight our plans for additional triggers and actions, as well as our plans to become a parachain on Kusama and Polkadot. It’s worth noting that we have only covered our plans for the L1 in this article, where consumer-first means trustless, seamless and secure automation for all consumers. If your smart contract gets hacked or if you need to code and deploy a smart contract to do an automation, we do NOT consider that consumer-first. Make sure to look out for more news on DApp and consumer products (L2) built using our automation infrastructure through partnership announcements in the near future.

Stay tuned for further information about the OAK Network here on Subsocial, Medium, Twitter and LinkedIn, as well as in our Discord Server! Please check out our engineering and growth job openings, contact [email protected] for partnerships, or [email protected] for any general inquiries.

Why you should care about trustless automation