INTU

Human-Centric Web3 Infrastructure

MPC Accounts for helping onboard users to Web3.

Website: https://intu.xyz

Twitter: https://twitter.com/intuofficial

If you need to chat with us, please visit our discord : https://discord.gg/sc9SjTewph

Here at INTU, we're convinced that Web3 requires better infrastructure to enable better user experiences, without compromising on core Web3 values like decentralization, self-custody, and transparency. We are introducing a practical new protocol for generating better Web3 accounts with all the necessary tooling for developers of all walks of life.

The Intu Account Protocol provides Web3-native Externally-Owned Accounts (EOAs) with advanced functionality and usefulness, including:
- Account recovery
- Distributed ownership
- Risk management
- Secure account generation

We're referring to this new generation of account as Distributed Externally-Owned Accounts, or dEOAs.

Please note this software is still in development, currently in beta.

What is INTU ?

Everything you need to bring Web3 development to the next level with INTU

INTU revolutionizes the decentralized landscape by bridging traditional cryptographic practices with the future. Through the lens of external-user addressing, signature creation, and transaction verification, INTU ensures that transactions, even those stemming from dEOAs, are seamlessly processed and verified akin to conventional individual accounts.

INTU's ambition is clear: to empower developers with tools to forge a more human-centric digital experience without upending the foundational elements of Web3. By harnessing dEOAs, the core of Web3 - curves, accounts, smart contracts, and dapps - remains intact, fostering compatibility and user-friendliness.

INTU stands as a pivotal gateway to cryptographic networks, poised to either stand solo or seamlessly embed within an array of products, services, or environments. We're driven by a straightforward ethos: to converge where users naturally gravitate and to unveil unmatched utility.

Delve into our technological milestones:

• INTU Protocol: An agile solidity-backed system, designed to streamline account participant interactions, curate a transparent public state, and validate cryptographic operations with precision.

  Dive deeper into our documentation to unearth insights about the INTU Protocol, its inception, and the array of components intricately woven within.

• INTU SDK: A specialized local client crafted to decipher the realm of cryptography. This tool is the linchpin for initializing and managing Intu accounts, be it through a browser, server or any device nor application.

Navigate our documentation to access a plethora of tutorials and insights about our SDK, and unlock the potential of integrating INTU into your ecosystem.

Reference: This section is a treasure trove of technicalities, shedding light on the vast toolkit at INTU's disposal. Here for the our cryptographic section in our whitepaper.

Overview

INTU Protocol fuses advanced cryptographic methodologies with the utility of Ethereum's smart contracts, streamlined within a user-friendly Software Development Kit (SDK). The heart of this protocol facilitates users in establishing, interfacing, and managing cryptographic vaults, ultimately mastering the deployment of threshold signatures.

Cryptographic Foundations

INTU taps into the bedrock cryptographic mechanisms powering decentralized architectures:

• External User Addressing: Systematic generation of addresses, derived directly from public keys.
• Signature Formation: Protocols enabling the generation of digital signatures that stand up to verification.
• Transaction Verification: Mechanisms ensuring the integrity and authenticity of initiated transactions.

A case in point is the dEOA (decentralized Externally Owned Accounts). Transactions initiated from a dEOA are disseminated and authenticated on par with those from conventional EOAs, upholding the inherent integrity of the blockchain.

Developer & End-User Synergy

This cryptographic integration offers several compelling features:

• Human-Centric Development: Empowering developers to supercharge their dApps, delivering intuitive experiences, without disrupting the intrinsic Web3 architecture.
• Consistency with Current Ecosystem: By incorporating dEOAs, INTU inherently integrates with prevalent elliptic curve cryptography, established account structures, smart contract paradigms, and decentralized apps, ensuring a broad spectrum of compatibility and integration.

Protocol Versatility

From a foundational perspective, INTU:

• Stand-alone Cryptographic Gateway: Acts as an independent portal to cryptographic networks.
• Integration Friendly: Embeds smoothly across diverse platforms, products, or digital ecosystems, truly resonating with the decentralized ethos.

Current Development Milestones

Focus areas include:

• Solidity Smart Contracts: A suite of robust contracts designed to:
  • Streamline coordination among account participants.
  • Archive public states.
  • Validate cryptographic processes.
• Local Client Capabilities:
  • Engage in core cryptographic procedures.
  • Enable INTU account generation and management.
  • Readily accessible via an SDK for both browser and app interfaces.

Key Features

• Distributed Ownership: Achieving decentralized control over addresses via Secure Multiparty Computation (SMPC).
• Secure Account Creation: A trustless, decentralized key generation paradigm ensuring creation of cryptographically ironclad accounts with minimized hardware vulnerabilities.
• Account Recovery: Features enabling nimble modifications, be it adding participants, revoking access, or key rotations, all aimed at perpetuating account security.
• Independence: Absolute independence from external networks, intermediary validators, or tokens.

Key Functionalities

• Advanced Account Creation: Craft intricate non-custodial accounts.
• Multiparty Transactions: Enable transactions from pooled accounts using the might of SMPC.
• Varied Recovery Pathways: Equip users with a variety of account recovery routes.
• Universal Operations: Engage fluidly with a gamut of smart contracts, manage diverse assets, and meet multi-chain necessities.

Key Benefits

• Self-Sovereign Recovery: Equipping users with autonomy in account recovery, bypassing third-party interferences.
• Custom Implementations atop INTU: With INTU accounts as the cornerstone, developers can ideate and deploy custom solutions ranging from DAO constructs, trading platforms, to advanced account services.
• Reimagining Custody: Transition between varying custodial paradigms, be it fully custodial or non-custodial blueprints.
• Unadulterated Compatibility: While INTU accounts emulate the functionality of EOAs, they aren't pigeonholed as smart contract addresses, ensuring a broad base of adaptability.

Notes:

• Non-Custodial: Ensures that the user has full control of their private keys.
• Network Agnostic: Compatible with multiple blockchain networks, not tied to just one.
• Cost-Effective: Indicates relative lower costs in operations or setup.
• High Security: Robust security measures against threats and vulnerabilities.
• Uses Latest Cryptography: Implements the most recent and secure cryptographic methods.
• Vendor Independence: Not tied to a particular vendor's ecosystem or infrastructure.
• No Need for Server/Token: Operates without the need for a central server or native token.
• Trustless Mechanism: Transactions and operations occur without needing trust between parties.
• Fully Decentralized: No central authority or point of control.

How Externally-Owned Accounts (EOAs) works ?

Introduction to Web3 Accounts

In the realm of blockchain, cryptographic addressing represents various terminologies such as private keys, public addresses, wallets, and accounts. Blockchain networks typically recognize two primary types of addresses:

1. Smart Contract Addresses
2. Externally-Owned Accounts (EOAs)

For this guide, 'accounts' encapsulate identity, address, and storage functionalities.

Smart Contracts

Smart Contracts are autonomous, web3-native programs enabling tasks like minting cryptocurrencies, establishing NFTs, and crafting other digital assets. They're unique in that they don't possess private keys but do have a distinct cryptographic address provided by the network.

Externally-Owned Accounts (EOAs)

Tailored for human users (and potentially some off-chain machines), EOAs signify accounts external to the immediate network environment. They mandate an off-chain private key for ownership validation, contrasting with smart contracts that function based on on-chain code. EOAs underpin Web3's self-sovereignty and are the usual mode of human-user interaction with decentralized applications.

In Essence: EOA = Human-centric Accounts

Key Characteristics of EOAs

1. Asymmetric Public-Key Cryptography:

   • A paired ensemble of a private (confidential) and a public (shareable) key.
   • Assures transactional security and confirms their genuineness.
   • Built on mathematical "one-way" principles: sharing your public key doesn't endanger the private counterpart.

2. Self-Sovereign Addressing:

   • A departure from Web1 and Web2's norms, Web3 offers users total identity control over the network.
   • EOAs can originate offline, free from immediate network registration.

3. Storage and Usage:

   • EOAs ≠ Wallets. Wallets are tools both for storing and efficiently utilizing EOAs.
   • They pave the way for user communication with the web3 network.
   • EOA storage varies, ranging from plaintext and encrypted "keystore files" to specialized hardware security modules (HSMs).

EOAs: In a Nutshell

• Generation: A private key begets a public key, which is then abbreviated into a public address.
• Management: Typically, wallets oversee EOAs.
• Function: Wallets harness the private key to draft signatures, validating transactions/messages.
• Broadcast: Wallets relay these signed entities to the network.
• Execution: Once verified, these transactions can transfer assets or engage with smart contract addresses.
• Utility: Predominantly, EOAs supply input to decentralized applications (dApps).

The Crucial Hurdle: Risk of Single Point of Failure

The security essence of Web3, while robust, carries a vulnerability: human error. A mishandled or lost private key can inflict irreversible repercussions. This foundational challenge emerges as a significant barrier to mainstream Web3 integration. The phrase "Not your keys, not your crypto" encapsulates this reality.

Yet, for those apprehensive of this intrinsic risk, INTU's dEOAs proffer traditional EOA advantages without the associated peril.

To Summarize:

Web3 navigation generally entails:

• Crafting a distinct keypair, typically via wallet software.
• Entrusting the wallet software with the private key's oversight.
• Deploying wallets as Web3 conduits, dispatching signed messages or transactions.
• Engaging these signed elements for network connectivity.
• Recognizing the critical implications of misplacing or losing private keys.

Introduction to dEOAs

Distributed Externally-Owned Accounts, and how to use them

Introducing the INTU account protocol, a protocol specifically designed for EVM chains placing Secure Multiparty Computation (SMPC) and Threshold Signatures (TSS) safely in the hands of all developers and end-users.

The Result

The end result is a Distributed EOA (dEOA), fully indistinguishable from other EOAs on chain.

The protocol only generates a public address, compatible with both ECDSA and BLS chains. There is no private key, but rather a collection of dynamic key shares, distributed across several participants who own the account.

The Protocol

The protocol - the means by which dEOAs are created - consists of four main functions:

• Decentralized Key Generation, using Secure Multiparty Computation (SMPC) and Verfiied Secret Sharing
• Threshold Signatures, allowing for a majority of keyshare holders to form verifiable signatures for the dEOA public address
• Key Resharing, which allows for account recovery, changes in ownership, and replacing compromised key shares
• Asymmetric Encryption with Forward Secrecy, which enables safe on-chain storage of proposals, key shares, and verification data

The Tools

The core building blocks of the protocol consist of:

SDK on the client's own devices to perform necessary cryptographic computations to participate in an account. The SDK can be provided in a web application, dApp, integrated into desktop software, or run locally, making it highly accessible and user-friendly.

Our smart contract system is designed to serve three primary purposes within the protocol: verification, communication, and storage.

• Verification: ensures the cryptographic validation and proper use of user participation.
• Communication: acts as a bulletin board for unsecured and public communication between participants, while also emitting necessary events for the client and interface.
• Storage: maintains records of information required to verify shares, ensuring the security and integrity of the vault.

The SDK requires minimal interaction from end users, making it simple and user-friendly.

The inherent decentralization and security of the blockchain its deployed on further secure the vault, ensuring that your end-user's digital assets are protected and recoverable at all times.

The protocol very intentionally does not introduce any additional dependencies, such as tokens, networks, hardware, or locally-stored data. The protocol is also incredibly flexible in terms of channels of communication, storage, and network requirements.

The tools are built for Web3 developers with no prior cryptographic experience or knowledge.

Protect your digital assets today with our cutting-edge INTU account protocol.

The TL;DR

Our INTU account protocol offers the following benefits:

• TSS and MPC protocol specifically designed for EVM chains
• SDK on the client's own devices for necessary cryptographic computations
• Smart contract system for verification, communication, and storage functionalities
• Secure and decentralized storage of key shares
• Simple and user-friendly client with minimal interaction from end users
• Inherent decentralization and security of EVM chain for additional security

How the INTU SDK Enables dEOAs

A Deeper Dive into Distributed Externally Owned Accounts

1. Understanding the Core Concepts

• Distributed Externally Owned Accounts (dEOAs):
  • Think of dEOAs as advanced versions of traditional blockchain accounts, with an emphasis on decentralization.
  • They have no private keys. Instead, their "ownership" and control are spread across multiple participants via cryptographic means.

• Proposers and Participants:
  • These are the stakeholders in a dEOA. While participants represent the collective identity of a dEOA, any of them can become a proposer to initiate actions for the dEOA.
  • Whether members of a DAO or individual accounts, participants use traditional EOAs to interact and manage their position within the dEOA.

• Key Shares:
  • Each participant holds a key share, intrinsically linked to the dEOA.
  • Alone, these key shares can't control the dEOA. When combined with others, they give authoritative power over the dEOA's actions.

• Threshold Signatures:
  • The gold standard of dEOA activity validation.
  • Not every participant needs to sign every action. Instead, once a pre-set majority (or threshold) is reached, the action is authenticated.
  • This sophisticated approach is more scalable than traditional multisignatures.

• Communication & Security:
  • By design, the protocol assumes all communication could potentially be public and vulnerable. The core design counters this with advanced encryption and on-chain data storage.
  • Developers have the flexibility to leverage other decentralized channels like LibP2P or even conventional channels like SMS.

2. Account Creation: The Genesis of a dEOA

• Pre-requisites:
  • Each dEOA participant needs a standard EOA.
  • These standard accounts (often as simple as a browser wallet) can be created via the SDK.
  • The protocol requires public addresses of these accounts to birth a dEOA.

• Initiating a dEOA:
  • The protocol is democratic. Anyone with the requisite public addresses can propose a dEOA.
  • Once proposed, the protocol oversees the heavy lifting. The dEOA’s public address is returned to participants upon successful creation.

• Onboarding to a dEOA:
  • Participants receive an invitation in INTU-integrated applications.
  • Developers leveraging the SDK can embed this mechanism seamlessly within their decentralized applications (dApps).
  • On acceptance, the protocol carries out the necessary under-the-hood tasks.

3. Signature Formation: Giving Voice to a dEOA

• Initiating an Action:
  • To breathe life into a dEOA, actions need approval, which is granted via threshold signatures.
  • Any participant can kickstart this process by proposing a signature, backed by their key share.

• Co-signing Proposals:
  • Active participants receive notifications for co-signing.
  • If consensus is reached (as per the set threshold), the action goes live. If not, it remains dormant.

4. Revolutionary Key Resharing: A New Dimension in Security

• What is Key Resharing?:
  • At its core, key resharing periodically redistributes power among dEOA participants. It's a dynamic, cryptographic method to enhance security and adaptability.
  • Key resharing can:
    • Recover compromised accounts.
    • Facilitate the dynamic addition/removal of participants.
    • Periodically reset security, enhancing the account’s resistance to potential threats.

• Initiating a Reshare:
  • Much like a transaction proposal, key resharing starts with a suggestion.
  • It requires a distinct threshold, often more significant than standard transactions, ensuring broader consensus for resharing activities.

• Participation in Resharing:
  • For participants, the resharing approval process mimics that of transaction validation.
  • Upon consensus, the protocol rejuvenates the dEOA with new key shares, keeping its integrity intact.

5. Account Management: Fine-Tuning the dEOA

• The INTU SDK doesn’t just stop at creating and managing dEOAs. It allows participants to:
  • Alter signature and resharing thresholds.
  • Access the comprehensive history and present state of dEOA participants.

Requirements

Basic user requirements:

• An Elliptic-Curve compatible Account, such as an EOA, on any EVM compatible network
• Wallet software, or otherwise means of managing EOA keys and broadcasting transactions to a Web3 network
• A minimum number of 3 users that participating in the vault creation
• Sufficient network-native tokens or assets for gas and infrastructure fees
• The public addresses or public keys of other intended participants
• End-user controlled hardware, such as a computer or mobile device with some computational capacity

Blockchains supported (beta, testnet):

Ethereum (Sepolia) Ethereum (Goerli)

INTU SDK Quickstart

Overview:

🏮 If you need to chat with us, please visit our discord: https://discord.gg/sc9SjTewph 🏮

Intu is comprised of two parts, the cryptographic functionality which is the bulk of our offering, and the smart contract which acts primarily as a database and confirmation layer. Our SDK performs the task of combining the cryptographic output with the method and order to be stored and retrieved in the SC.

Assuming we want the most basic setup (3 users, requiring 2 signatures to send a transaction), we will need just a handful of functions to achieve that.

The process to create and use an Intu account is roughly:

• Import Intu SDK & Ethers
• Retrieve your user intu vaults
• Propose a vault
• Have each user register into the vault
• Complete! Now the vault can be used to send threshold signatures

Prerequisites:

With our SDK, you can get started in just a few steps.

First, get the appropriate @intuweb3 package for the project you are building (web or nodejs), and the ethers package.

Web:
Node:

1. Install Packages:

npm i @intuweb3/exp-web OR npm i @intuweb3/exp-node
npm i ethers (or whatever you prefer)

2. Initial Code Setup:

Signer Object & Retrieve Intu Vaults

For the purposes of the code examples, we are going to use the 'web' version.

import { ethers } from "ethers";
import { getVaults } from "@intuweb3/web";

const provider = new ethers.providers.Web3Provider(window.ethereum);
await provider.send("eth_requestAccounts", []);
const signer = await provider.getSigner();
const signerAddress = await signer.getAddress();

await getVaults("0x12345", provider);

Nice! Any accounts your user has ever created will pull right up.

3. Vault Creation & Use:

Create an INTU account

import { vaultCreation } from "@intuweb3/web";

/*
The first parameter to pass is an array of the addresses that should be a part of this new vault
RotateThreshold = % of participants required to add or remove someone from the vault
TransactionThreshold = % of participants required to send a transaction from the vault
AdminThreshold = % of participants required to change a threshold %, change the name, etc.
*/
await vaultCreation([0x1, 0x2, 0x3], "MyEasyToReadVaultName", rotateThreshold, txThreshold, adminThreshold, signer);

Now that we've created a vault, the users included in that vault can all register into it and then start using it, lets see that additional functionality!

Rapid Customer Onboarding

Overview:

Using 2 repositories we provide: https://github.com/w3-key/intu_node_signer (for backend)
https://github.com/w3-key/intu_frontend (for frontend)
You can quickly and easily build MPC technology into your dapp.

And, using these 2 repositories, you can now onboard a user without that user ever needing a Wallet, Gas, or even any knowledge that they are using Web3.

If you have any issues, please email us at dev@intu.xyz

1. To get started, clone the intu_node_signer project into 2 different folders (2 separate signers).
   Rename the .env.example file to .env, and input a private key that will control that signing node.
   Please make note of the associated public key for each node, as they will need to be added to the frontend.
   npm i && npm start and it should be up and running!

2. Then, clone the intu_frontend project, rename the .env.example file to .env, and replace the public addresses with the public addresses of your node signers. And add in a clerk public key, which you can get from here: https://clerk.com/

Run npm i && npm start and it should be up and running!

What does it do?

The process for the user is as follows.

They just need to click on 'sign in' and sign in with an option of their choice.
Upon signing in, we create a deterministic private key for that user based on the resultant ID from their login.
We then fund that private key with sFuel and immediately begin intu account creation.
The node_signers pick up the event, and begin participating in the MPC process.
Due to the cryptography and blockchain, the process takes about 45 seconds currently.
We propose allowing the user to fill out profile details during that time (email,name,handle,etc)
When it is complete, the user will be presented with an option to 'claim an NFT' which we are providing as an example for the user's first interaction with Web3.
Again, the user needed no wallet, gas, or web3 knowledge to now claim their first NFT and did so in under a minute.

Any issues, please email us at : dev@intu.xyz

Beyond Basics: Expanding Functionality with Intu

Welcome to the advanced functionality of Intu. This guide will expand on the functions you can perform.

🚀 Starting Point: Haven't launched your own Intu dEOA yet? Make that your priority. The initial setup is foundational for the steps that follow.

1. Vault Creation

Creating a vault is straightforward. Pass in an array of participants, a unique account name, and set your thresholds: rotation, signing, and administrative.

💡 Learn More: Vault Creation

2. Retrieving Vault Data

Once your vault is established, retrieving its data is the next move.

How to: Get Vault Info

3. Proposing a Vault & Encryption

• The initiator proposes a vault.
• Creates a random encryption message for all users.
• Includes the user addresses involved and sets the thresholds.
• All participants sign this encryption message.
• The result of the signing confirms their 'registration' with the vault.
• During this, certain data necessary for the DKG process is also passed.

4. User Registration & DKG Contribution

We have 2 methods for user Registration, discussed here: Registration (Info)

No matter which method you choose, your users will first have to perform a preRegistration step: preRegistration
This step creates an encryption key for the user, their database ID, and lets the vault know that they are interested in joining.

If you want to use the new automatic registration method, you'll need to perform these steps:

automateRegistration > regsiterAllSteps

Otherwise, using the previous more manual method...

🔑 Key Point: All users must sequentially perform each step. For instance, all participants must preRegister before any individual can perform registerStep1.

Register: Step 1
Register: Step 2
Register: Step 3

5. Completing the Vault

With every participant registered, any one of them can now 'complete' the vault. This step needs to be performed regardless of the registration step you chose --- but can only be performed after everyone is registered.

Complete Registration

Congratulations! 🎉 You've now set up an Intu MPC account!

6. Transaction Operations

Your next adventures involve forming transactions, having them signed by users, and finally, combining the signatures for transaction execution.

Form a Transaction
Signature Process
Combine Signatures

Other Integration Information

⚠️ Note: We offer both a Web and NodeJS version. The primary reason is due to how WASM is handled in each of those systems.
Web:
Node:
⚠️

Contract Addresses:

Can be found in the NPM package under lib/services/web3/contracts/contractInfos.js

📗 For those using Wagmi, please refer to: https://wagmi.sh/react/ethers-adapters

Example Use Cases and Benefits

Use cases

Below are some, but not all use cases for the INTU account infrastructure:

• Self-Sovereign Recovery:

  • Empower users with the capability to autonomously recover their accounts, eliminating reliance on external services or intermediaries.

• Multi-Party Accounts:

  • Set up collaborative accounts where transactions are authorized only after receiving assent from every involved party.

• Customized Functionality:

  • Harness the INTU Account Protocol to engineer bespoke applications designed to streamline complex tasks and functions. Potential domains of application include DAO Frameworks, Sophisticated Trading Platforms, and Enhanced Account Services.

• Flexible Custody Solutions:

  • Revolutionize your client experience by offering a spectrum of custody models— from full custodial solutions to shared or non-custodial frameworks.

• INTUxAA:

  • Seamlessly integrate decentralized MPC accounts that operate across chains, amalgamating advanced cryptography and the inherent adaptability of Account Abstractions.

• INTUxAI/IOT:

  • Fortify the connectivity of machines, allowing them to interlink and autonomously execute diverse tasks via intelligent agents. Ensure the credibility of these connections through robust verification methods.

Benefits of the Intu Account Infrastructure

Intu's dEOA Infrastructure places cutting-edge MPC and TSS technologies into the hands of Web3 developers, without compromising on decentralization or introducing new dependencies. As a result, developers building with INTU can provide significant benefits for their end-users, such as:

1. Security: Decentralization eliminates the need for a trusted third party, which helps to enhance the security of the system. MPC and TSS algorithms further ensure that sensitive information is kept confidential, even in the presence of malicious actors.
2. Privacy: The use of MPC and TSS protocols helps to protect the privacy of users, as sensitive information is encrypted and split among multiple parties. This makes it more difficult for any single party to access or compromise the information.
3. Scalability: Decentralized systems can often handle a large number of transactions, as there is no single point of failure. This can make them more scalable and better able to handle increasing demand.
4. Interoperability: Decentralized protocols can be designed to be interoperable with other systems, which can help to increase their utility and value.
5. Decentralization: Decentralization can provide a more democratic and equitable distribution of power and resources, as there is no central authority controlling the system.
6. Cost savings: Decentralized systems reduce the costs associated with maintaining centralized infrastructure, as the costs are spread among multiple participants. Intu further requires no additional infrastructure, hence no additional cost for the deploying integration partner.
7. Increased transparency: Decentralized systems can provide increased transparency, as all transactions are recorded on a public ledger. This can help to increase accountability and reduce the potential for fraud or corruption.

The end result is an decentralized EOA (dEOA), fully indistinguishable from other EOAs on chain.

Our INTU account protocol is the perfect solution for businesses and individuals looking to secure their digital assets in a decentralized and secure manner.

It provides the highest level of security, transparency, and accountability and can be easily integrated into any compatible chain for seamless deployment.

It requires no additional infrastructure, allows for hybrid custody solutions as well as fully non-custodial recovery systems.

Protect your digital assets today with our cutting-edge INTU account protocol.

FAQ

This page is meant to address commonly asked questions we hear! We are always open to suggestions and make improvements to our

• What's with all the "registration steps"?

  The registration steps ensure that each user provides their own information to the cryptographic process that generates the distributed key.
  Previously, we relied on the vault creator to provide some data for the other users. This meant less steps but meant for a less secure DKG process if the dealer was either malicious or their machine was compromised in some way.

  *Nov 2023 Update! We now have a method that allows you to automatically register:
  Info: Registration (Info)
  Function: automateRegistration

• How and why do you use the smart contract?

  We use a smart contract to primarily act as data storage. Our goal with Intu was to be entirely decentralized, without any reliance on any 3rd parties, other networks, or any other dependenncy.

• MPC or AA?

  An EOA is your core identity within Web3. Account abstraction allows for additional functionality, but adds an additional layer of complexity and overhead as well. We think that Web3 accounts are stronger with MPC technology like Intu's and Account Abstraction can be combined.

• Why do you use percentages for thresholds instead of set numbers?

  By using percentages, we can always determine the threshold (number of signers needed) of your choosing even if you add or remove participants.
  As an example, if you were to set a threshold of 4 when you have 4 total participants - and were later to remove a user - then you would have an impossible level of threshold to reach (4 threshold 3 users). This is a common question and we do look to address it in a more straightforward way in the future.

• How are the 'shares' stored?

  The shares are encrypted with a signature from the user, and stored on chain. We took this approach so that we could be truly decentralized, without any reliance on any 3rd parties for storage or computation, just the EVM.

Whitepaper

For a more technical review of the protocol and what goes on under the hood

Whitepaper

Smart Contract Event Logs

The following is a list of all of the events that are emitted when a function is performed in the smart contract. These will allow you to create custom triggers in your own dapp, if you wish.

The name of the event will be followed by the output of the event.

VaultCreated

Emitted when a new Intu Vault is submitted to the blockchain

• vaultAddress
• name
• _encryptionMessage
• _seed
• _dbAddress

VaultUserPreRegister

Emitted when a user performs their pre registration step in the vault.

• user
• _parisEncKey
• _megaPublicKey
• _encSharedKey
• _dbKey

VaultUserRegisteredStep1

During the manual (not using automaticRegistration function) registration process, this event will be triggered.

• user
• _dealingKey
• _dealingKappa
• _dealingLambda

VaultUserRegisteredStep2

During the manual (not using automaticRegistration function) registration process, this event will be triggered.

• user
• _openingKey
• _openingKappa
• _openingLambda
• _simpleDealingKey
• _simpleDealingKappa
• _transcriptKey
• _transcriptKappa
• _transcriptLambda

VaultUserRegisteredStep3

During the manual (not using automaticRegistration function) registration process, this event will be triggered.

• user
• _simpleKey
• _simpleKappa
• _dealingKeyXLambda
• _dealingKappaXLambda
• _simpleTranscriptKey
• _simpleTranscriptKappa

VaultUserRegisteredAll

During the automaticRegistration process, this is triggered by a single user after their registration is complete.

• user
• _step1Dealings
• _openingKey
• _openingKappa
• _openingLambda
• _simpleDealingKey
• _simpleDealingKappa
• _transcriptKey
• _transcriptKappa
• _transcriptLambda
• _step3Stuff

VaultCompleted

Emitted when each user has completed registration. Returns the masterPublicKey.

• users
• _masterPubKey

TransactionProposed

Emitted when a new transaction is proposed

• txId
• transactionInfo

TransactionUserConfirmed

• txId
• user
• signedTransaction

ProposalCreated

Emitted when a user proposes a name change or a threshold change

• id
• _type
• data

VaultAddUserRequested

Emitted when a new user is proposed to be added to the vault

• userToAdd

VaultUserAdded

Emitted when a new user is voted on and successfully added to the vault

• userToAdd

VaultAddUserStep1

During the manual registration process, this event will be triggered.

• user
• userToAdd
• _simpleDealingKeyResharedOnce
• _pedersenDealingKappaReshare
• _pedersenDealingLambdaReshare

VaultAddUserStep2

During the manual registration process, this event will be triggered.

• user
• userToAdd
• _simpleOpeningKeyResharedOnce,
• _pedersenOpeningKappaReshare,
• _pedersenOpeningLambdaReshare,
• _simpleDealingKeyReshareTwice,
• _simpleDealingKappaReshare,
• _transcriptKeyResharedOnce,
• _transcriptKappaReshare,
• _transcriptLambdaReshare

VaultAddUserStep3

During the manual registration process, this event will be triggered.

• user
• userToAdd
• _simpleOpeningKeyResharedTwice,
• _simpleKappaReshare,
• _dealingKeyXLambdaReshare,
• _dealingKappaXLambdaReshare,
• _transcriptKeyResharedTwice,
• _simpleTranscriptKappaReshare

VaultUserInitialized

Emitted when a new user is voted on and successfully added to the vault

• user

These functions will help you retrieve data from your Intu vault to provide up to date status and info for your users.

Get Functions

However, it is possible to use the protocol entirely without ever using these functions directly, as we call these in the Core functionality as necessary to complete your functions. The functions in this section will be placed roughly in the order they need to be called.

// typical usage
import { ______ } from "@intuweb3/web";

getVaults

Returns all Intu Vaults and details for a user

import { getVaults } from "@intuweb3/web";
await getVaults("0x12345", provider, blockRange?)

Arguments:​

Returns:

An array of results, each containing an Intu smart contract's information for a particular account.

id: number
voteForNeeded: number;
voteFor: number;
endTime: number;
executed: boolean;
type: PropositionType;
data: string;
users: UserProposition[];
signerVoted: boolean;
readableType: string;
adminOrRotate: string;

id: number
transactionInfo: string
signedTransactionsNeeded: number;
userSignedTransactions: UserTransaction[];
chainId: string;
data: string;
gas: string;
gasFeeCap: string
gasTipCap: string;
nonce: string;
to: string;
value: string;
signerSignedtransaction?: boolean;

getRegistrationStatus

Returns registration status for the user and for the group as a whole

import { getRegistrationStatus } from "@intuweb3/web";
await getRegistrationStatus("0xvault", "0xuser", provider);

Arguments:​

Returns:

An array of results, the registration status of the user and the registration status of the vault. Example: If the user is in Step1, but the group is still in PreRegistration, then the user has to wait for everyone to finish their PreRegistration

getReSharingStatus

Returns registration status of a resharing - for the user and for the group as

a whole

This would be called after a new user has been called to the group to either be added or removed from the group.

import { getReSharingStatus } from "@intuweb3/web";
await getRegistrationStatus("0xvault", "0xuser", provider);

Arguments:​

Returns:

An array of results, the resharing registration status of the user and the registration status of the vault. Example: If the user is in Step1, but the group is still in PreRegistration, then the user has to wait for everyone to finish their PreRegistration

getProposalInfos

Get information regarding a proposal made to the Intu vault

import { getProposalInfos} from "@intuweb3/web";
getProposal(vaultAddress, signer)

Arguments:​

Returns:

An array of results, each containing an Intu smart contract's information for a particular account.

getUserRegistrationAllInfos

Returns registration status for the user if that user has used the automaticRegsitration and registerAllSteps functions

import { getUserRegistrationAllInfos } from "@intuweb3/web";
await getUserRegistrationAllInfos("0xvault", "0xuser", provider);

Arguments:

Returns:

An array of results, the registration status of the user and the registration status of the vault. Example: If the user is in Step1, but the group is still in PreRegistration, then the user has to wait for everyone to finish their PreRegistration

These functions are related to the core of MPC technology.

Core functionality

DKG process, signing messages, combining signatures, performing a rotation/resharing of keys.

vaultCreation

This stores a new Intu smart contract (in registration phase) on the network.

Users who have been included in the vault can then register, and once everyone has registered, they can interact with it.

*A VAULT CURRENTLY REQUIRES 3 PARTICIPANTS WITH 2 SIGNERS -- IT CANNOT HAVE A 3 of 3 SIGNING SCHEME*

Arguments:

import { vaultCreation } from "@intuweb3/web";
/*
RotateThreshold = % of participants required to add or remove someone from the vault
TransactionThreshold = % of participants required to send a transaction from the vault
AdminThreshold = % of participants required to change a threshold %, change the name, etc.
*/
await vaultCreation([arrayOfAddresses], "MyEasyToReadVaultName",  rotateThreshold,txThreshold,adminThreshold, signer)

The function does not return any values.

preRegistration

This endpoint needs to be hit by each user involved with a vault during the vaults registration phase. All users must perform this step before registerStep1 can be performed.

For this step, and the following 3 registration steps, each one of the participants must finish the step before the following step can be completed by any participant.
So, all users must complete preRegistration before any user can perform registerStep1.

import { preRegistration, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await preRegistration(vaultAddress, signer);

registration

Choose ONE registration method for your build. The differences are as follows:

Automatic relies on a decentralized database that runs off of libp2p and uses it for communication between parties to perform their cryptoraphic steps.

Manual method was our original method for registration. Each user performs their cryptography and writes their data to the blockchain after each step is completed.

In either case, the users will still need to perform the preRegistration step, and a single user will need to perform completeVault after everyone has completed their registration step(s).

Here is an example of the automatic registration in progress Automatic Registration

I would recommend using the new Automatic Registration method. We just use the decentralized DB for the key share creation, we still store those keys on the blockchain so that they will persist forever.

automateRegistration

• You can either use this single automateRegistration function or you can use the registerStep1,2,3 functions
• automateRegistration uses a decentralized database build on libp2p - automatically, where the register steps rely on blockchain writes between steps for each user

This endpoint needs to be hit by each user involved with a vault during the vaults registration phase. If all users are online when this function is hit by each user, the registration process will complete in ~10 seconds.

This step requires that all the other participants have performed the preRegistration step.

preregistration.md

Arguments:

import { registerStep1, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await automateRegistration(vaultAddress, signerAddress, signer);
//bonus: You can use it as follows to automatically register once all steps are complete
let ar = await automateRegistration(vaultAddress, signerAddress1, signer1)
  .then(async (result) => {
    await registerAllSteps(vaultAddress, signer1);
    return true;
  })
  .catch((error) => {
    console.log(error);
  });

registerAllSteps

• This is to be used only if you have used the automaticRegistration function This endpoint needs to be hit by each user to store their key share, encrypted, on chain.

This step requires that all the other participants have performed and completed (all the way to the end) the automaticRegistration step.

Arguments:

import { registerStep1, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await registerAllSteps(vaultAddress, signer);

registration

Choose ONE registration method for your build. The differences are as follows:

Automatic relies on a decentralized database that runs off of libp2p and uses it for communication between parties to perform their cryptoraphic steps.

Manual method was our original method for registration. Each user performs their cryptography and writes their data to the blockchain after each step is completed.

In either case, the users will still need to perform the preRegistration step, and a single user will need to perform completeVault after everyone has completed their registration step(s).

Here is an example of the automatic registration in progress Automatic Registration

I would recommend using the new Automatic Registration method. We just use the decentralized DB for the key share creation, we still store those keys on the blockchain so that they will persist forever.

registerStep1

• You can either use this register step1,2,3 process or the automateRegistration/registerAllSteps method.
• automateRegistration uses a decentralized database build on libp2p - automatically, where the register steps rely on blockchain writes between steps for each user

This endpoint needs to be hit by each user involved with a vault during the vaults registration phase. All users must perform this step before registerStep2 can be performed.

This step requires that all the other participants have performed the preRegistration step.

preregistration.md

Arguments:

import { registerStep1, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await registerStep1(vaultAddress, signer);

\

registerStep2

This endpoint needs to be hit by each user involved with a vault during the vaults registration phase.All users must perform this step before registerStep3 can be performed.

This step requires that all the other participants have performed the RegisterStep1 step.

register-1.md

Arguments:

import { registerStep2, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await registerStep2(vaultAddress, signer);

\

registerStep3

This endpoint needs to be hit by each user involved with a vault during the vaults registration phase.All users must perform this step before completeVault can be performed.

This step requires that all the other participants have performed the registerStep2 step.

register-2.md

Arguments:

import { registerStep3, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await registerStep3(vaultAddress, signer);

\

completeVault

One of the users participants will have to complete the vault to close the creation and registration process of the decentralized MPC account.

This step requires that all the other participants have performed the registerStep3 step.

register-2.md

Arguments:

import { completeVault, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await completeVault(vaultAddress, signer);

\

submitTransaction

This endpoint forms a transaction for users of an Intu vault to sign

submitTransaction

This allows us to form a transaction for participants to sign. The base64 string output is what we store in the smart contract. Most of this input will come from a form you create on your page.
The other information will come from the getVaults function.

• Example included to propose sending an NFT at the bottom of this page!

getvaultinfo.md

import { submitTransaction, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer)
let nonce = myVaults[i].transactionCount  // the first nonce in a vault should always be 0
let value = ethers.utils.parseEther(String(AMOUNTFROMYOURFORM))._hex // in eth
let to = FROMYOURFORM
let chainId = FROMYOURFORM
let data = 0x1...
let gasPrice = "" // or an amount of your choosing
let gas = "" // or an amount of your choosing

await submitTransaction(to, value, chainId, nonce, data, gasPrice, gas, vaultAddress, signer)

//example for sending a NFT!
import { submitTransaction, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);

const erc721Interface = new ethers.utils.Interface(["function safeTransferFrom(address _from, address _to, uint256 _tokenId)"]); //boilerplate
const encodedData = erc721Interface.encodeFunctionData("safeTransferFrom", [
  "0x1111111111111111111111111111111111111111",
  "0x2222222222222222222222222222222222222222",
  4, //token id
]); // we just plug this const into the data field of submitTransaction

await submitTransaction(
  to, //contract address - the contract that launched the NFT  Iwas trying to transfer
  value, //always 0 for contract interaction I think...
  String(chainId),
  String(nonce),
  data, // encodedData
  gasPrice, // ""
  gas, // ""
  myVaultAddress, //address of vault you are interacting with
  signer
);

parseTransaction

Parse a transaction hash formed with the formTransaction function

Returns all the data within the formed transaction hash
This function needs the person to gather some data from the smart contract to pass to it.

getvaultinfo.md

import { parseTransaction, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
let transaction = myVaults[i].txData[txId].originaltransaction;
await parseTransaction(transaction);

Arguments:​

signTx

A user can sign a proposed transaction with their keyshare

This allows us to send a transaction that has been voted on (a signature of the transaction = a vote in our case) by a > threshold participants.

This function needs the person to gather some data from the smart contract to pass to it.

import { signTx, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x123456", signer);
let vaultaddress = myVaults[i].vaultAddress;
let transactions = myVaults[i].transactions;
let txId = //the ID of the transaction you want to sign. NOT the index of the transaction, the ID.
await signTx(vaultAddress, txId, signer);

Arguments:

The result of this needs to be stored in the smart contract. This happens automatically!

Returns:

signedTxForStorage

String of signed transaction, encoded in base64 for storage:

combineSignedTx

This combines all of the signatures from each user to create a transaction that can be sent on the network

This allows us to send a transaction that has been voted on (a signature of the transaction = a vote in our case) by a > threshold participants. This function needs the person to gather some data from the smart contract to pass to it.

getvaultinfo.md

import { combineSignedTx, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x123456", signer);

await combineSignedTx(vaultAddress, txId, signer);

Arguments:​

Returns:

Administrative functionality (WIP)

proposeTransactionThresholdUpdate

An Intu account user can propose a change to the transaction threshold for the other users to vote on.

The transaction threshold percentage determines how many users in a vault are required to sign a transaction prior to sending the transaction

Arguments:

import { proposeTransactionThresholdUpdate } from "@intuweb3/web";
proposeTransactionThresholdUpdate(vaultAddress, newThreshold, signer);

How to createINTUContract

Returns:

The function does not return any values.

proposeRotationThresholdUpdate

An Intu account user can propose a change to the rotation threshold for the other users to vote on.

The rotation threshold percentage determines how many users in a vault are required to vote on rotating a user in or out of an Intu vault.

Arguments:

import { proposeRotationThresholdUpdate } from "@intuweb3/web";
proposeRotationThresholdUpdate(vaultAddress, newThreshold, signer);

How to createINTUContract

Returns:

The function does not return any values.

proposeAdminThresholdUpdate

An Intu account user can propose a change to the admin threshold for the other users to vote on.

The admin threshold determines how many users are required to vote before a threshold change can be completed, or a name change for the vault - things like that.

Arguments:

import { proposeAdminThresholdUpdate } from "@intuweb3/web";
proposeAdminThresholdUpdate(vaultAddress, newThreshold, signer);

How to createINTUContract

Returns:

The function does not return any values.

voteFor

Intu vault user can vote on the proposal in the vault

User can view the proposal with the getProposalInfos function.

linktofunction

Arguments:

import { voteFor } from "@intuweb3/web";
voteFor(vaultAddress, proposalId, signer);

Link to getproposalInfos

Returns:

The function does not return any values.

voteAgainst

Intu vault user can vote against a proposal in the vault

User can view the proposal with the getProposalInfos function.

linktofunction

Arguments:

import { voteAgainst } from "@intuweb3/web";
voteAgainst(vaultAddress, proposalId, signer);

Link to getproposalInfos

Returns:

The function does not return any values.

executeProposal

Execute a proposal after the required votes have been met

Arguments:

import { executeProposal } from "@intuweb3/web";
executeProposal(vaultAddress, proposalId, signer);

Link to getproposalInfos

Returns:

The function does not return any values.

Core functionality Resharing

Resharing allows a group of users in a vault to add or remove a user (EOA) to/from the existing user group.

proposeAddUserInVault

An Intu account user can propose a new user they want to add to the vault.

The user will be able to be added to the vault after the rotation threshold of votes is met.

Arguments:

import { proposeAddUserInVault } from "@intuweb3/web";
proposeAddUserInVault(vaultAddress, userToAdd, signer);

How to createINTUContract

Returns:

The function does not return any values.

getRotationVaultAddresses

This endpoint allows a user who has only been PROPOSED to a new vault to be able to find that vault's address so they can interact with it.

import { getRotationVaultAddresses } from "@intuweb3/web";
await getRotationVaultAddresses(proposedRotationAddress, Provider);

preRegistration

This endpoint needs to be hit by the proposed user before the resharing steps for everyone can begin.

import { preRegistration, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await preRegistration(vaultAddress, signer);

reShareStep1

All users must perform this step before step 2 can be performed by any user

This step requires that the user being added to the vault has performed pre-registration step.

Arguments:

import { reShareStep1, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await reShareStep1(vaultAddress, signer);

\

reShareStep2

All users must perform this step before step 3 can be performed by any user

Arguments:

import { reShareStep2, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await reShareStep2(vaultAddress, signer);

\

reShareStep3

All ORIGINAL users must complete this step before the new user can complete this step.

Arguments:

import { reShareStep3, getVaults } from "@intuweb3/web";
let myVaults = getVaults("0x12345", signer);
//whichever vault address you need to interact with in myvaults
//example, myVaults[0].vaultAddress;
await reShareStep3(vaultAddress, signer);

\