🔧 The Problem & Solution

Permissionless DeFi applications serve an important goal – to bring self-custodial and self-sovereign financial services to society at large. However, while the underlying tech may be sound, the way in which it is offered to the consumer is not. We need products that offer both ease-of-use AND additional benefits which only blockchain technology can facilitate.

We want to simplify user experience when dealing with DeFi protocols and make it an enjoyable experience all throughout.

Firstly, we achieve the above by introducing a novel approach to account abstraction-enhanced dapps, maintaining all on-chain security guarantees while abstracting away the complexities of maintaining user’s private keys. A smart account is created for every user, with standard Ethereum ERC-4337 approach to smart contract wallets.

Secondly, Grosh serves as an interface to the most reliable DeFi contracts which are historically proven and (somewhat) understandable without Web3 context. We aim to create an app that would allow a non-native Web3 person easy access to the most secure instruments DeFi has to offer, as both smart contract and market risks are concerned. Furthermore, we seek to simplify the complexities of dealing with crypto in general, e.g., by providing an in-app, frictionless onboarding and offboarding of funds, as well as a simple but informative interface.

Technical Flow – Validation

ERC4337 Account Abstraction is implemented, involving validation of a pseudo-transaction, i.e., User Operation, using the hash sent in the previous block and a one-time password.

The password sent for validation after parsing with the keccak256 function should be the same as the password stored in the smart contract in order for the operation to be validated correctly. The execution of the function in the smart contract additionally sets the next hash of the password sent in the function parameter.

In addition, before the function is called, an unvalidated hash is sent in an earlier block, i.e., a combination of the current password prior to being hashed and the hash from User Operation, which will be sent in the next block.