Inspiration

We have been working in the fields of self-sovereign identity and blockchain for some time, and noticed that there is a clear gap in the space, in that it is impossible to operate on-chain as an identity. Identities on-chain are usually limited to public keys. By adding a richer identity layer to the blockchain, we can tap into a rich vein of possibilities for the next generation of wallet services, from third-party key recovery and custody, multiple devices, key rotation, spending limits, as well as gaining access to services on-chain that require KYC.

What it does

Cryptid establishes an on-chain proxy for your Solana wallet. A Cryptid account allows you to configure one or more access keys, giving you more control over your funds, tokens, NFTs and other assets. You can also establish relationships of control between identities, to allow you to execute transactions on behalf of other entities, e.g. a company or dependent.

Cryptid consists of 4 components:

  • The Cryptid Solana program
  • A client library
  • A wallet user interface
  • A command line client

Some of the features currently available in Cryptid:

  • Create a Cryptid account from your existing Solana wallet
  • Access your funds across multiple devices without sharing key material or relying on off-chain infrastructure
  • Cryptid allows you to rotate your key if it becomes compromised, ensuring you can keep control of your identity even if your wallet is breached. Even your initial wallet key can be rotated!
  • Interact with dApps
  • Through the "controller" feature, Cryptid accounts can be connected together. This allows:
    • fully on-chain and secure trust accounts
    • individuals can control assets belonging to dependents
    • corporate wallets - company executives can share control of a company wallet without sharing keys

How we built it

We first developed an on-chain Solana Cryptid program. Transactions signed by a Cryptid account are, in fact, wrapped in a meta-transaction. The meta-transaction is signed by a private key and then sent to the Cryptid program The Cryptid program validates that the private key has the permissions to sign the transaction from the Cryptid account, according to the associated identity stored on chain.

We then developed a Javascript client library to interact with the on-chain Cryptid program. This client can be used directly, or with the Cryptid Wallet UI or CLI tool.

Challenges we ran into

  • Size-efficiency of our meta-transaction solution: Due to the 1232-byte transaction size limit on Solana, we soon realized that we needed to optimize for every last byte in the payload to make the Cryptid vision a reality.
  • TX fee payers must be signer: With Cryptid, users' wallet addresses are PDAs. Since PDAs cannot be tx fee payers, that currenly means that Cryptid users generally have to keep two addresses funded, which harms usability. We would love to work with Solana to be able to establish advanced mechanisms to allow a PDA to directly pay for the transaction fees.

Accomplishments that we're proud of

Cryptid is a novel Solana wallet solution that goes far beyond what traditional wallets can do. In order to properly demonstrate that vision we need to make Cryptid work transparently with any existing dApp. Since Cryptid wraps transactions from dApps into a metastructure we needed to understand how to common apps are currently building and executing transactions and how we could optimize (or split) those instructions to make them work with Cryptid. In that way we not only be came experts in Solana wallet implementations, but also in a lot Solana apps.

What we learned

We learned that working at the edges of what is currently possible within a space throws up many challenges that need to be overcome. We’ve learned that at many stages in the project there could have been a “game over” argument that could have stopped us from realizing the vision. We are praying that this moment never comes!

As a wallet itself and by depending on other third party wallets (in a passthrough model for signatures), we learned that wallet integration on Solana can still contain some pitfalls for the user (and the developer) in order to make the experience transparent, easy and secure.

What's next for Cryptid

This hackathon submission is really just the beginning! We plan to build a "middleware" layer, that can be composed around a cryptid account, enabling a number of very exciting use-cases.

M-of-N Multisig

Cryptid currently supports 1-of-N multisig. We plan to expand this to support threshold-multisig.

Spending limits and restrictions

An important part of the Cryptid model is the ability to add restrictions to a Cryptid account. We plan to support:

  • Spending limits
  • Recipient whitelists (all fully non-custodial and on-chain)

This will allow use-cases such as:

  • "savings accounts" protected by cold-storage keys, with a "current account" balance on a hot wallet, all under the same account
  • non-custodial account recovery, either social or via a third-party
  • subscriptions - secure and non-custodial standing orders for periodic payments on-chain.

Self-Sovereign Identities

DIDs (Decentralized Identifiers) are the standard identifier for self-sovereign identity. It is a globally unique identifier and independent of any central authority.

Cryptid use the did:sol did method on Solana. The use of DIDs in Cryptid means that we can tie it to up to verifiable credentials, and add claims on your Cryptid account.

As an example. We can have a verifiable way that an NFT creator that has created an NFT under key X is a particular artists. We can add a verifiable credential to that identity, have it discoverable on-chain (either directly on-chain, or via a link that's discoverable on-chain) - that attests to who they are.

Built With

+ 19 more
Share this project:

Updates