Smart Account Standards for Dapps: Registries & Accounts

[kromsten]

Overview

The niche of smart contract-based accounts and blockchain abstraction is rapidly growing. It is becoming increasingly important in the light of providing better UX for the users and carving a path for mass adoption.

There is already a significant number of applications and initiatives based on this concept such as Obi.money and Unstoppable Wallets that are built on top of the Secret Network.

In addition to that there is quite a big number of projects being built using nearly identical plain CosmWasm or on widely known EVM. It's expected for them to be ported to the ecosystem or completely new interesting idea to emerge in near future

This diversification makes it challenging for dApps to keep up with increasing number of solution providers, to understand what custom authentication methods a user might have in addition to standard cosmos wallets and also to successfully reuse the primitives created in other parts of the ecosystem in a sustainable manner.

Our grant seeks to address these challenges by proposing a unified solution with addition to capitalizing on the unique features of the Secret Network

Problem Statement

Next generation of the decentralised applications relying on power of account abstraction might encounter various challenges.

In a simple scenario where a user opens an app for the first time he can have in possession one of the many provable credential technologies, such as (Web3) Wallets, OAuth 2.0, (WebAuthn) Passkeys, Login & Passwords and so on. Dapps developers might puzzle themselves with the following:

• Which credential to use if multiple options are detected?

• To use as is (if possible) or to check if there are bound abstract solutions?

• How to interact with an abstract provider: endpoints, registration, API keys?

• Type and specific technology to look up for. For example:

  • Smart Contract: Obi.money, AbstractSDK, Vectis

  • 3rd Party Provider: Lit Protocol, Web3Auth

  • Hybrid: Unstoppable (MPC) Wallets with multiple shards

Some applications might use a custom authentication mechanism either not supported by popular providers or it can be an overkill to use them. For example, a dapp might need a simple account contract controlled by Ethereum signatures. In such cases, the following questions must be answered:

• Does the user already have an account linked to a credential created from another application, or does it need to be newly created?

• How to design the interface for creating accounts, passing the payload, verifying credential data?

• How to interact with the account contract: performing actions, verifying signatures, and conducting sign-in operations?

In some cases, data about smart contract-based accounts might be needed from another smart contract inside a virtual machine. In such cases, 3rd party networks and solutions relying on API keys become unusable. Interaction with pure on-chain solutions still remain challenging in the following scenarios:

• Delegating authentication logic from a simple dApp-specific account contract of a user to his existing "enterprise" account.

• Different interfaces and interaction methods across various solutions & products

• Checking if users have a specific feature or credential, general account search, and filtering

There are multiple brilliant teams working on using abstract accounts for "wallet experience" focusing on very needed features such as spending limits, session keys, intents and so on. When it comes to consumer-facing application the field is being rather neglected, infrastructure almost non-existent and entry-level requires getting a PHD in both software design and applied cryptography

Proposed Solution

We are proposing to port the account standards we recently developed for regular CosmWasm cw[81-83] to their respective "snip" versions and enhance them with the privacy-specific aspects of the Secret Network. In addition to that we propose to build a reference implementation that can be integrated into any dApp in the ecosystem and a simple interface for demo purposes to showcase it

From a high-level perspective, the solution includes an account Registry (cw83 -> snip83) and minimalistic contract-based Accounts (cw82 -> snip82).

The Registry binds a provable credential or a list of credentials to smart contracts (typically accounts). It allows those holding private parts of credentials to modify crucial data on the bound account contracts and to migrate them to newer code versions. Additionally, a registry must expose a query method that reveals whether there is an existing (account) contract matching a given credential, what is contract address, and optionally additional account data (e.g code hash).

The Account standard is very minimalistic and only requires contracts following it to determine whether a given signature can be considered valid according to its interpretation, whether a certain action (CosmosMsg) can be executed, and to actually execute that message.

The two standards work well together, but they do not necessarily require each other. A Registry can create accounts that do not follow the snip82 standard, and snip82 accounts can be created by any custom registry or even manually by a user. However, a specific implementation might enforce a flow where the other is required.

Implementation Ideas

• Registry that binds accounts to tokens of any snip721 collection -> Token Bound Accounts that allows users to buy and sell accounts. Useful in cases where the account is eligible for an airdrop or has a vesting balance, also to bundle assets together and generally in gaming for example to represent NFT Character that can hold NFT armour, NFT sword and so on

• Registry that binds accounts to tokens of one specific snip721 collection and requires passing an extra "name" parameter as payload for account creation -> Minimal Name Service with smart account linked to each name

• Registry that creates accounts that able to generate an Ethereum (or any other) wallet from the payload or/and on-chain randomness inside TEE. Derived addresses are sent back to the registry which in turn stores them in a bi-directional mapping -> Tightly Linked Addresses derivable one from another upon request from anywhere (offchain /on-chain)

• A Registry that expect cryptographically signed messages from remote wallet addresses sent over IBC-Hooks. After the verification an address can be linked with an account + stored for indexing and also authorized to perform actions on bound accounts and potentially store it for indexing -> ICA-Controller - ICA-Host with extra features such as multiple controllers using one same host, deriving the original addresses from the host and ability to do it all from the chains without native IBC support e.g. through multiple bridges over Axelar GMP or Wormhole

• Registry that saves a universal unrevokable viewing key on each account contract and credential system with different levels where some credentials allow to control the account and some (e.g. whitelisted key of goverment / tax office ) allow to get access to sensitive data -> Compliant Registry for sensitive application easily queryable for inclusion checks and whitelisting

Deliverables

Main

• Porting the proposed CW standards to SecretWasm into new respective SNIPs

• A reference contract implementation for Minimal Proxy Account (SNIP82) with the following features:

  • Specifying one or multiple credentials from a supported list (listed below) that are used to control an account and authorise certain actions from it

  • Query endpoint that tells whether a provided signature is valid. Supporting multiple authentication methods to pick from (listed below)

  • Query endpoint for telling whether a given action (CosmosMsg) can be executed with given payload. Private by default [VK + Permits]

  • Executing a message if a caller could supply a proof for any of the credentials configured on account in payload

  • Replay attack protection for signature based authentication methods

  • Expects to be created by the registry contract and only allows updates to be triggered by the same contract (on user request)

• A reference Account Registry (SNIP83) contract implementation with the following features:

  • Binding one or multiple supported credential types to an account contract. Supporting both SNIP82 compatibles and external contracts e.g. Obi

  • Query endpoint for getting account contract data for a given credential ID. Credential Id refers to "public" part of credential. E.g. "address" or pubKey for Ethereum signature controlled accounts, "login" for password or for oauth2.0 based systems and so on

    • Ability to mark a credential as private or public. Bound account contract won't be discoverable using a private credential (ID) unless query is authenticated [VK + Permits]

    • Passing a list of credential to iterate through until a match

    • Returning both contract address and Secret Network specific code hash in case of a match

  • Query endpoint for getting all credential types configured on a given account contract . By default only shows public credentials. Shows all if the query is authenticated [VK + Permits]

  • A user who provides valid proof for any newly supplied / configured credentials can do all of the following:

    • Create a new account contract. Grant Scope only covers snip82 compatible contracts. Possibility of creating other might vary from project to project. Some scenarios might require usage of Authz module or only leaving an option of binding to already existing account

    • Update (add / remove / replace) configured credentials on both registry and bound account at the same time

    • Delete an account contract and purge saved data from its storage

    • Migrate bound account contract to a newer code version from a list of whitelisted code ids

    • Set of admin / moderators that can perform migration on behalf of the users e.g. in case of discovered vulnerabilities

    • Governance controlled endpoints for modifying the list of admins and allowed account ids

• An interface for contract interaction for demo purposes allowing to perform the following operations:

  • Connecting to the page using Secret / Cosmos wallet or Metamask

  • Querying Registry for existing account against a given credential(s)

  • Ability to create a reference account contract and pass a list of credentials to be used for controlling it

  • Showing public balances of an account contracts

  • A demo section for querying whether a given signature is valid

  • Performing a sample from the list of "simple" actions from account contract e.g. bank, staking & governance messages

Byproducts Beneficial for the Ecosystem

• Some of the necessary components required for the implementation exist as a separate rust crates as helpful primitives in vanilla CosmWasm and proved to be improving developer experience. These packages might be ported to respective "snip" versions:

  • cw1: minimal proxy contracts

  • cw2: contract Info & version (raw queries -> smart queries)

  • cw22: contract interface definition & detection ( none -> smart queries )

  • cw81 signature validity / verification

• A separate library with a list of popular credentials and logic for their authentication. Easily referenceble and reusable in any other secret contract. Supports both native rust code and using cheaper alternative of thorugh exposed `deps.api` methods

Details

New "SNIPS" are expected to be released in a separate repository. Upon interest some of them might be merged into secret-toolkit or a another repository that is maintained with bigger resource allocation. Naming is to be determined later for colliding versions (mainly cw22 and already existing snip22)

Credential type definition and verification logic will be defined in a separate library intended to support multiple rust based virtual machines at the same time. Support for Secret Network will be added under a new respective feature tag

List of credentials supported currently:

• Plain Ed25519 signature verification“

• Plain Secp256k1 signature verifcation

• Ethereum "Personal Sign"

• Cosmos Arbitrary Message Signature (ADR 036)

Milestones & Expenses

Each bullet point from the main section is estimated to be a milestone with first 2 taking 1 weeks per milestone and the last two lasting for around 1.5 weeks each. = 5 weeks total. In case of unforeseen contingencies we might anticipate a delay of 1 - 1.5 more week which won't requiring extra allocations

First milestone is the only to not have any tangible KPIs. The rest are expected to be immediately deployed to the testnet and static hosting after completion and to be interactable from cli and browser respectively right after that

Allocated hours per week from each team member are 5, 15 and 30 (in the order below) with the development expenses covering the whole team being ~$3,600 per week

Total Ask (for 5 weeks): $18,000

Team & Experience

Day: Design / Graphics / Communication

Graphic Designer with background in data science. Interest in web3 was started with NFTs. After initial research the whole field become one of the primary interests alongside with AI both of which she's been actively working on for the last 3 years. Still finds NFTs fascinating after all this time and enjoys exploring their potential
Fun fact: Doesn't get PFPs. Rejected an offer for getting a Bad Kid once. Had some regrets about that after recent price action and airdrop mania

Elbok: Project Management / Testing / (Sys)Administration / Research
Technological polyglot knowing a bit of everything across various engineering fields including deep database knowledge, machine learning algorithm and low-level programming with C. Knows about web3 as much as the core engineer if not more but doesn't do open source as often and is way less boastful more discreet person enjoying his privacy

Fun fact: Never used an actual bank. The closest thing was CEX and their "crypto" debit cards. Even that is gone now after moving to non-custodial card issuers and DEXes

Kromsten: Core Engineer / Architecture / Research / Building
Software Engineer specialising in decentralised applications with 7+ years of experience in web development. Have worked with almost every mainstream technology out there but have been primarily focusing on Cosmos ecosystem.
Fun fact: Only worked in traditional web development for a year in 2017. After that started playing with EVM initially and shortly after got a first work gig in web3 which happened to be in Secret Network ecosystem (SEFI airdrop by ChainOfSecrets)
Personal Relevant Experience:

• Aleph Zero Smart Account Contracts - Proof of Concept of what is being pitched in the grant proposal except for being written for Substrate / Ink! based virtual machine. First time ever touching the stack in question but managing to get a Community Award of the hackathon nevertheless

• SNIP20 / CW20 Keplr In-Wallet Registry - A bounty issued by SCRTLabs for in-wallet search of popular SNIP20 tokens. By personal initiative went an extra mile to come up with a reusable design that benefits the broader ecosystem and support for the rest of the CW20 tokens. The design has been adopted and after a few changes integrated into production

Team Experience

(Stargaze) Token-Bound-Accounts - The most developed reference implementation of the proposed standards at the moment. Showcases dealing with bug number of design challenged such as custom chain messages, decentralisation & governance control, extendable natures of the local NFT standards. Additionally goes to deep extend of engineering through advanced features of template engines to follow the conventions and provide high degree of customisation

CW-Extra - Experimental standard, packages, proof of concepts and other novel ideas for CosmWasm (and SecretWasm) based contracts. Includes a secret-network branch imitating (and partially doing) implementation of the proposed standards

Future & Growth

The grant falls under the category of development tooling and partially under network improvements. As such it is not expected to have a clearly defined "go-to-market" strategy as itself. Instead deliveries of the grant proposal paves path to new implementations open many new possibilities, promote better user experience and drive adoption forward

Next Steps

Next natural step for the project after deliverables would be:

• Referenced in public documentation pages for better awareness

• Rust Crates to be deployed to crates.io and similar for better development UX

• Developing helping primitives in typescript and preferably adding them to secretjs as one of the extensions

• Integration into any of the existing major apps e.g. dashboard

• Releasing more reference implementations projects showcasing the standard

Future Plans

A topic of account abstraction in context of dapps (VS Wallet Experience) has been a focus of our team for a while and we've been working on it across various ecosystems. We've been trying to do so in a sustainable matter that promotes re-usability

We have multiple planned improvements to common libraries & new products interoperable with the proposed grant project by design. It's quite likely that after finishing them they can be easily ported to Secret without big expenses and a separate grant requests. The list includes:

• Passkeys & JWT credential types for smart-account-auth library. In this case support for Secret Network upon improvements should come out of the box

• An multi-chain Interface for interacting with registries and accounts across different networks. "A mintscan for abstract accounts"

• Solutions for gasless experience such as usage /feegrant in self-sustainable manner from smart contracts through novel designs

• Abstraction of the "top-level" Cosmos signatures through incentivised relayer networks or ephemeral keys

• Enterprise level solutions for Token-Bound-Accounts and other products build on top of the proposed standards