Introducing Low-Level Intents, a Summary of Our Talk at EthCC[6]

In this post, we’ll unpack the key takeaways from our EthCC[6] talk about frontends for smart contracts, addressing the unique challenges in frontend development and introducing a new interaction specification: Low-level intents.

Introduction

At present, when we interact with smart contracts, we typically engage with a Decentralized Application (dApp) designed by the same team who built the contract. For instance, if you want to play a game in TheSandbox, you’ll navigate to their homepage, find the game event, and follow the minting instructions to get your NFT avatar or game assets. A similar process applies if you want to provide liquidity on Uniswap, trade perpetuals on GMX, or borrow assets on Compound Finance.

Uniswap has developed widgets as Software Development Kits (SDKs) that can be embedded in other sites. But this SDK is uniquely built to interact with Uniswap smart contracts. What if we could generalize this process for all contracts?

That’s where the beauty of smart contracts comes into play — they’re permissionless. In the Web 2.0 era, integrating with a startup required communication, possibly with a sales team, and acquiring an API key. With smart contracts, you can directly build a frontend using the deployed contract address, the method, the ABI, and an SDK if you choose to do the programming yourself.

Challenges

Yet, smart contracts’ frontends are not always straightforward. The implementation of a single function call, like Uniswap V2’s AddLiquidity, can be incredibly complex. It requires multiple SDKs like ethers.js, Uniswap’s SDK core, web3 react, and React. Developers need to write hundreds of lines of code for each method of the contract and even more for managing various other aspects like wallet changes, balances, and approvals. This complexity is amplified if the contract involves non-fungible tokens (NFTs) with off-chain data.

We asked ourselves at OKcontract: Could there be a simpler solution? Could we identify the exact problem that needs solving and apply a more streamlined, computer science approach?

OKcontract Solution

Our solution revolves around three key areas:

1. Creating a standard way to specify the smart contract interaction.

2. Automatically generating a transactional interface from that specification.

3. Making it easy to embed that automated interface into any web page or web app.

To specify the smart contract interaction, we introduced a new language called Lambda script. This purely functional programming language enables automated reasoning and static analysis, offering a high-level transaction or low-level intent depending on the level of specification required.

After specifying the interaction, we automatically create a transactional interface from that specification. This way, the interface can be generated for any contract and method without repeated manual input.

Finally, we’ve made it easy to embed the interface into any web page or web app, just as Uniswap did with their widgets, but applicable to any contract or method. This runtime architecture can interact directly with the wallet, support IPFS, and connect to APIs, all while running within our graphical editor.

As we move forward, our goal is to increase the number of frontends available for smart contracts. To that end, we’ve initiated a private beta to work with projects like Alchemix and Compound III in DeFi, and TheSandbox in gaming. Our public release is on the horizon, and we’re excited to bring more users into the smart contract world. We’re diligently working to ensure our product is stable, effective, and beneficial for all who use it.

Be sure to follow us on Twitter for updates, as we’ll be releasing batches of invites to the platform before public release. By doing so, you’ll get an inside look at how OKcontract widgets work and an opportunity to test them with your contracts.

Here’s a full video of the talk: https://www.youtube.com/watch?v=3kQQHgIjE2Q