 is a powerful authentication and key management platform to securely onboard, activate, and manage your users at scale. 

With just nine minutes of setup, Privy gives you out-of-the-box support for:

A variety of login methods, including email, phone, wallets, and social

Customizable UIs to progressively onboard your users

Self-custodial embedded wallets and powerful connectors for external wallets

native funding and bridging, full customization, account abstraction, delegated actions

 wallets are self-custodial wallets provisioned for a wallet experience that is directly embedded in your application. Embedded wallets do not require a separate wallet client, like a browser extension or a mobile app, and can be accessed directly from your product. Privy embedded wallets are fully self-custodial, so neither Privy nor integrating applications ever access embedded wallet private keys.

 wallets are managed by a third-party client, such as MetaMask or Rainbow. All browser extension wallets, hardware wallets, and mobile app wallets fall into this category.

Onboarding users with Privy

From there, you can get API keys and start your integration in the dashboard. You can choose which login methods, chains, wallet types, and plugins to enable!

Create an account

Privy offers multiple SDKs to easily onboard users to web3, including

 for managing your application. We find that starting with the React Auth SDK is easiest!

pnpm install @privy-io/react-auth@latest


 by selecting your app and then clicking Login Methods in the side bar. Select the account types you'd like users to be able to login with. By default, Privy enables wallet and email logins for new apps; you can update this setting now or later. For more information on how to enable social logins, check out the 

 for select your desired app, navigate to the 

 tab, find the API keys section. Get your 

The app ID serves as an API key used to initialize the Privy React SDK. This value can be safely exposed in a client-side environment, and you can 

 component and wrap your app with it. Set the 

 field to the app ID you got from the Dashboard in step 3.

 component or page that will use the Privy React SDK. It is generally recommended to render it as close to the root of your application as possible.

you can now use the Privy SDK throughout your components and pages via the 

Install the Privy SDK

With Privy, your app can prompt users for permission to take certain actions on their behalf. In this setup, your users can delegate permissions for your app to take allowlisted actions on their behalf, such as signing certain messages or sending certain transactions. These are 

Just request access to this feature in the Dashboard under plugins! 

Delegated actions enable you to build certain automated workflows, for instance:

buying a collectible when it becomes available on an open marketplace

triggering recurring onchain transactions for subscriptions and 

At a high-level, setting up delegated actions for your app involves two steps:

 within the Privy Dashboard, when enabling delegated actions, generate a P-256 asymmetric keypair to ensure that the TEE only ever executes requests originating from your app's servers. This step is optional, but 

: within your client (web or native mobile app), prompt the user to delegate certain permissions over their wallet to your app.

To generate an authorization keypair, in the 

 setting. This will enable delegated actions for your app.

From here, you can generate a P-256 authorization keypair. Your server will use this private key to sign request payloads to Privy's delegated actions API.

Copy the private key from the console and save it securely in a secrets manager or similar. Privy never sees this private key and cannot help you recover it. 

This means rotating the private key for your app in the case of key loss will require all users to consent to wallet delegation again.

To use delegated actions, your user must first grant consent to your app to take actions on their behalf. 

To prompt users to grant consent, follow 

Once a user has consented to delegated actions for their wallet, your app can take certain actions with the user's wallet. Follow 

If you have any feedback on this feature, reach out to us! You can read more about the TEE architecture we used to build delegated actions 

Use Delegated Actions

You can now use Privy to create a simple and smooth onboarding experience for your app! Once you’re able to log users in, you can start requesting signatures and transactions from wallets. Don’t forget to upgrade your application to Production when you’re ready!

 are programmable, onchain accounts that incorporate the features of 

. With just a few lines of code, you can create smart wallets for your users to sponsor gas payments, send batched transactions, and more.

 their wallets with a variety of assets, including a network's native currency (e.g. ETH), USDC, and other ERC20 tokens. 

If the external wallet does not have sufficient funds on the configured chain, but has funds on other networks, Privy will prompt the user to instead 

Cross-app wallets enable teams to bring one of crypto's most powerful features—interoperability—to mainstream audiences. 

 can easily integrate your cross-app wallet into an existing Rainbowkit or wagmi-based connector library with just a few lines of code.

If there are any features you need access to, just request access in the Dashboard or email us at 

If you ever have questions, you can reach us in 

Additional Resources

Intro to Privy

Privy 

Jamie Hinz

Kinode is a decentralized operating system, peer-to-peer app framework, and node network designed to simplify the development and deployment of decentralized applications. It is also a 

, in that Kinode can be deployed anywhere and act as a server controlled by anyone. Ultimately, Kinode facilitates the writing and distribution of software that runs on privately-held, personal server nodes or node clusters.

You are reading the Kinode Book, which is a technical document targeted at developers.

Learn how to boot a Kinode locally in the 

1. Getting Started

Run two fake Kinodes and chat between them

# Get Rust and `kit` Kinode development tools
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo install --git https://github.com/kinode-dao/kit --locked

# Start two fake nodes, each in a new terminal on ports 8080 and 8081:
## First new terminal:
kit boot-fake-node

## Second new terminal:
kit boot-fake-node --home /tmp/kinode-fake-node-2 --port 8081 --fake-node-name fake2

# Back in the original terminal that is not running a fake node:
## Create and build a chat app from a template:
kit new my_chat_app
kit build my_chat_app

## Load the chat app into each node & start it:
kit start-package my_chat_app
kit start-package my_chat_app --port 8081

## Chat between the nodes:
kit inject-message my_chat_app:my_chat_app:template.os '{"Send": {"target": "fake2.dev", "message": "hello from the outside world"}}'
kit inject-message my_chat_app:my_chat_app:template.os '{"Send": {"target": "fake.dev", "message": "replying from fake2.dev using first method..."}}' --node fake2.dev
kit inject-message my_chat_app:my_chat_app:template.os '{"Send": {"target": "fake.dev", "message": "and second!"}}' -p 8081

# Or, from the terminal running one of the fake nodes:
## First fake node terminal:
m our@my_chat_app:my_chat_app:template.os '{"Send": {"target": "fake2.dev", "message": "hello world"}}'

## Second fake node terminal:
m our@my_chat_app:my_chat_app:template.os '{"Send": {"target": "fake.dev", "message": "wow, it works!"}}'


 tutorial is a more detailed version of this Quick Start. Alternatively, you can learn more about 

If instead, you want to learn more about high-level concepts, start with the 

 and work your way through the book in-order.

1.1 Quick Start

The Kinode Book describes the Kinode operating system, both in conceptual and practical terms.

Kinode eliminates boilerplate and reduces the complexity of p2p software development by providing four basic and necessary primitives:

The focus of this book is how to build and deploy applications on Kinode.

Applications are composed of processes, which hold state and pass messages. Kinode's kernel handles the startup and teardown of processes, as well as message-passing between processes, both locally and across the network. Processes are programs compiled to Wasm, which export a single 

 function. They can be started once and complete immediately, or they can run "forever".

Peers in Kinode are identified by their onchain username in the "KNS": Kinode Name System, which is modeled after ENS. The modular architecture of the KNS allows for any Ethereum NFT, including ENS names themselves, to generate a unique Kinode identity once it is linked to a KNS entry.

Data persistence and blockchain access, as fundamental primitives for p2p apps, are built directly into the kernel. The filesystem is abstracted away from the developer, and data is automatically persisted across an arbitrary number of encrypted remote backups as configured at the user-system-level. Accessing global state in the form of the Ethereum blockchain is now trivial, with chain reads and writes handled by built-in system runtime modules.

Several other I/O primitives also come with the kernel: an HTTP server and client framework, as well as a simple key-value store. Together, these tools can be used to build performant and self-custodied full-stack applications.

Finally, by the end of this book, you will learn how to deploy applications to the Kinode network, where they will be discoverable and installable by any user with a Kinode.

1.2 Introduction

Kimap is an onchain namespace for the Kinode operating system. It serves as the base-level shared global state that all nodes use to share critical signaling data with the entire network. Kimap is organized as a hierarchical path system and has mutable and immutable keys.

 has been a major barrier for peer-to-peer developers. Discoverability can present both social barriers (finding a new user on a game or chat) and technical obstacles (automatically acquiring networking information for a particular username). Many solutions have been designed to address this problem, but so far, the "devex'' (developer experience) of deploying centralized services has continued to outcompete the p2p discoverability options available. Kimap aims to change this by providing a single, shared, onchain namespace that can be used to resolve to arbitrary elements of the Kinode network.

All keys are strings containing exclusively characters 0-9, a-z (lowercase), - (hyphen).

A key may be one of two types, a name-key or a data-key.

Every name-key may create sub-entries directly beneath it.

 NFT (non-fungible token), with a connected token-bound account (

The implementation of the token-bound account may be set when a name-key is created.

If the parent entry of a name-key has a token-bound account implementation set (a "gene"), then the name-key will automatically inherit this implementation.

Every name-key may inscribe data in data-keys directly beneath it.

A data-key may be mutable (a "note", prepended with 

) or immutable (a "fact", prepended with 

See the Kinode whitepaper for a full specification which goes into detail regarding token-bound accounts, sub-entry management, the use of data keys, and protocol extensibility.

Kimap is tightly integrated into the operating system. At the runtime level, networking id entities are verified against the kimap namespace. In userspace, programs such as the App Store make use of kimap by storing and reading data from it to define global state, such as apps available for download.

One of the most important features of a peer-to-peer network is the ability to maintain a unique and persistent identity. This identity must be self-sovereign, unforgeable, and easy to discover by peers. Kinode uses a PKI (public-key infrastructure) that runs 

 kimap to achieve this. It should be noted that, in our system, the concepts of 

Also important to understanding KNS identities is that other onchain identity protocols can be absorbed and supported by KNS. The KNS is not an attempt at replacing or competing with existing onchain identity primitives such as ENS and Lens. This has already been done for ENS protocol.

Kinode names are registered by a wallet and owned in the form of an NFT like any other kimap namespace entry. They contain metadata necessary to cover both:

 - to demonstrate that the NFT owner has provenance of a given Kinode identity.

 - to be able to route messages to a given identity on the Kinode network.

It's easy enough to check for provenance of a given Kinode identity. If you have a Kinode domain, you can prove ownership by signing a message with the wallet that owns the domain. However, to effectively use your Kinode identity as a domain name for your personal server, KNS domains have routing information, similar to a DNS record, that points to an IP address.

. When users first boot a node, they may decide between these two types as they create their initial identity. Direct nodes share their literal IP address and port in their metadata, allowing other nodes to message them directly. Again, this is similar to registering a WWW domain name and pointing it at your web server. However, running a direct node is both technically demanding (you must maintain the ability of your machine to be accessed remotely) and a security risk (you must open ports on the server to the public internet). Therefore, indirect nodes are the best choice for the majority of users that choose to run their own node.

Instead of sharing their IP and port, indirect nodes simply post a list of 

 nodes that have agreed to forward messages to indirect nodes. When a node wants to send a message to an indirect node, it first finds the node onchain, and then sends the message to one of the routers listed in the node's metadata. The router is responsible for forwarding the message to the indirect node and similarly forwarding messages from that node back to the network at large.

The definition of a node identity in the KNS protocol is any kimap entry that has:

 and one or more of the port notes. Indirect nodes are those that publish 

 must be 32 bytes corresponding to an Ed25519 public key. This is a node's signing key which is used across a variety of domains to verify ownership, including in the end-to-end encrypted networking protocol between nodes. The owner of a namespace entry/node identity may rotate this key at any time by posting a transaction to kimap mutating the data stored at 

 entry must parse to an array of UTF-8 strings. These strings should be node identities. Each node in the array is treated by other participants in the networking protocol as a router for the parent entry. Routers should themselves be direct nodes. If a string in the array is not a valid node identity, or it is a valid node identity but not a direct one, that router will not be used by the networking protocol. Further discussion of the networking protocol specification can be found 

 entry must be either 4 or 16 big-endian bytes. A 4-byte entry represents a 32-bit unsigned integer and is interpreted as an IPv4 address. A 16-byte entry represents a 128-bit unsigned integer and is interpreted as an IPv6 address.

Lastly, the bytes at any of the following port entries must be 2 big-endian bytes corresponding to a 16-bit unsigned integer:

These integers are translated to port numbers. In practice, port numbers used are between 9000 and 65535. Ports between 8000-8999 are usually saved for HTTP server use.

1.3 Kimap and KNS

The following is a high-level overview of Kinode's design philosophy, along with the rationale for fundamental design choices.

Decentralized Software Requires a Shared Computing Environment

A single shared computing environment enables software to coordinate directly between users, services, and other pieces of software in a common language. Therefore, the best way to enable decentralized software is to provide an easy-to-use, general purpose node (that can run on anything from laptops to data centers) that runs the same operating system as all other nodes on the network. This environment must integrate with existing protocols, blockchains, and services to create a new set of protocols that operate peer-to-peer within the node network.

A wide array of companies and services benefit from some amount of decentralized infrastructure, even those operating in a largely centralized context. Additionally, central authority and centralized data are often essential to the proper function of a particular service, including those with decentralized properties. The Kinode environment must be flexible enough to serve the vast majority of the decentralization spectrum.

To use blockchains as mere databases would negate their unique value. Blockchains are consensus tools, and exist in a spectrum alongside other consensus strategies such as Raft, lockstep protocols, CRDTs, and simple gossip. All of these are valid consensus schemes, and peer-to-peer software, such as that built on Kinode, must choose the correct strategy for a particular task, program, or application.

Decentralized Software Outcompetes Centralized Software through Permissionlessness and Composability

Therefore, any serious decentralized network must identify and prioritize the features that guarantee permissionless and composable development. Those features include:

a persistent software environment (software can run forever once deployed)

client diversity (more actors means fewer monopolies)

a robust node network that ensures individual ownership of software and data

Decentralized Software Requires Decentralized Governance

The above properties are achieved by governance. Successful protocols launched on Kinode will be ones that decentralize their governance in order to maintain these properties. Kinode believes that systems that don't proactively specify their point of control will eventually centralize, even if unintentionally. The governance of Kinode itself must be designed to encourage decentralization, playing a role in the publication and distribution of userspace software protocols. In practice, this looks like an on-chain permissionless App Store.

Kinode is a novel combination of existing technologies, protocols, and ideas. Our goal is not to create a new programming language or consensus algorithm, but to build a new execution environment that integrates the best of existing tools. Our current architecture relies on the following systems:

Rust: a performant, expressive, and popular programming language

Wasm: a portable, powerful binary format for executable programs

 and their vision for secure, efficient, and modular software. Kinode makes extensive use of their tools and standards. 

1.4 Design Philosophy

This section will teach you how to get the Kinode core software, required to run a live node. After acquiring the software, you can learn how to run it and 

If you are just interested in starting development as fast as possible, skip to 

If you want to run a Kinode without managing it yourself, use the 

If you want to make edits to the Kinode core software, see 

Kinode core distributes pre-compiled binaries for MacOS and Linux Debian derivatives, like Ubuntu.

First, get the software itself by downloading a 

. Choose the correct binary for your particular computer architecture and OS. There is no need to download the 

 binary — it is used behind the scenes by 

Note that some operating systems, particularly Apple, may flag the download as suspicious.

First, attempt to run the binary, which Apple will block. Then, go to 

Kinode can also be run using Docker. MacOS and Debian derivatives of Linux, like Ubuntu, are supported. Windows may work but is not officially supported.

First, install Docker. Instructions will be different depending on your OS, but it is recommended to follow 

If you are using Linux, make sure to perform any post-install necessary afterwards. 

. This volume may be empty or may contain another Kinode's data. It will be used as the home directory of your Kinode. Each volume is unique to each Kinode. If you want to run multiple Kinodes, create multiple volumes.

The image includes EXPOSE directives for TCP port 

 is used for serving the Kinode web dashboard over HTTP, and it may be mapped to a different port on the host. Port 

 is optional and is only required for a direct node.

 to the same port on the host and on your router. Otherwise, your Kinode will not be able to connect to the rest of the network as connection info is written to the chain, and this information is based on the view from inside the Docker container.

Run the following command to create a volume:

Then run the following command to create the container. Replace 

 with a unique name. To map the port to a different port (for example, 

docker run -d -p 127.0.0.1:8080:8080 -it --name my-kinode \
    --mount type=volume,source=kinode-volume,destination=/kinode-home \
    0xlynett/kinode

Check the status of your Docker processes with 

As long as the volume is not deleted, your data remains intact upon removal or stop. If you need further help with Docker, 

You can compile the binary from source using the following instructions. This is only recommended if:

 don't work on your system and you can't use 

You need to make changes to the Kinode core source.

 tools, by running the following in your terminal:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo install wasm-tools
rustup install nightly
rustup target add wasm32-wasi
rustup target add wasm32-wasi --toolchain nightly
cargo install cargo-wasi

For more information, or debugging, see the 

 build of Rust. You will want to run the command 

 on a regular basis to keep your version of the language current, especially if you run into issues compiling the runtime down the line.

git clone https://github.com/kinode-dao/kinode.git

# OPTIONAL: --release flag cargo +nightly build -p kinode

. (Note that this is the binary crate inside the 

 will produce the binary significantly faster, as it does not perform any optimizations during compilation, but the node will run much more slowly after compiling. The release binary will be at path 

1.5 Installation

This page discusses joining the network with a locally-run Kinode. To instead join with a hosted node, see 

These directions are particular to the Kinode beta release. Kinode is in active development on Optimism.

Start a Kinode using the binary acquired in the 

. Locate the binary on your system (e.g., if you built source yourself, the binary will be in the repository at 

). Print out the arguments expected by the binary:

$ ./kinode --help
A General Purpose Sovereign Cloud Computing Platform

Usage: kinode [OPTIONS] <home>

Arguments:
  <home>  Path to home directory

Options:
      --port <PORT>            Port to bind [default: first unbound at or above 8080]
      --ws-port <PORT>         Kinode internal WebSockets protocol port [default: first unbound at or above 9000]
      --tcp-port <PORT>        Kinode internal TCP protocol port [default: first unbound at or above 10000]
      --verbosity <VERBOSITY>  Verbosity level: higher is more verbose [default: 0]
      --reveal-ip              If set to false, as an indirect node, always use routers to connect to other nodes.
      --detached               Run in detached mode (don't accept input)
      --rpc <RPC>              Add a WebSockets RPC URL at boot
      --password <PASSWORD>    Node password (in double quotes)
  -h, --help                   Print help
  -V, --version                Print version


A home directory must be supplied — where the node will store its files. The 

 WebSocket link to an Ethereum RPC, allowing the Kinode to send and receive Ethereum transactions — used in the 

. If this is not supplied, the node will use a set of default RPC providers served by other nodes on the network. If the 

 flag is supplied, Kinode will attempt to bind that port for serving HTTP and will exit if that port is already taken. If no 

 if it is available, or the first port above 

Copy the WebSocket API key from the API Key button:

As an alternative to using Alchemy's RPC API key, 

 endpoints may be used. Upon creating an Infura account, the first key is already created and titled 'My First Key'. Click on the title to edit the key.

Next, check the box next to Optimism "MAINNET". After one is chosen, click "SAVE CHANGES". Then, at the top, click "Active Endpoints".

On the "Active Endpoints" tab, there are tabs for "HTTPS" and "WebSockets". Select the WebSockets tab. Copy this endpoint and use it in place of the Alchemy endpoint in the following step, "Running the Binary".

A new browser tab should open, but if not, look in the terminal for this line:

login or register at http://localhost:8080

Next, register an identity. If the page looks like:

the browser already has a supported wallet installed. Click 

To register an identity, Kinode must send an Ethereum transaction, which requires ETH and a cryptocurrency wallet. While many wallets will work, the examples below use Metamask. Install Metamask 

After clicking 'Register Kinode Name', click 

. Many exchanges also allow sending ETH directly to Optimism wallets.

Setting Up Networking (Direct vs. Routed Nodes)

When registering on Kinode, you may choose between running a direct or indirect (routed) node. Most users should use an indirect node. To do this, simply leave the box below name registration unchecked.

An indirect node connects to the network through a router, which is a direct node that serves as an intermediary, passing packets from sender to receiver. Routers make connecting to the network convenient, and so are the default. If you are connecting from a laptop that isn't always on, or that changes WiFi networks, use an indirect node.

A direct node connects directly, without intermediary, to other nodes (though they may, themselves, be using a router). Direct nodes may have better performance, since they remove middlemen from connections. Direct nodes also reduces the number of third parties that know about the connection between your node and your peer's node (if both you and your peer use direct nodes, there will be no third party involved).

Use an indirect node unless you are familiar with running servers. A direct node must be served from a static IP and port, since these are registered on the Ethereum network and are how other nodes will attempt to contact you.

Regardless, all packets, passed directly or via a router, are end-to-end encrypted. Only you and the recipient can read messages.

As a direct node, your IP is published on the blockchain. As an indirect node, only your router knows your IP.

, click through the wallet prompts to send the transaction:

The password encrypts the node's networking key. The networking key is how your node communicates securely with other nodes, and how other nodes can be certain that you are who you say you are.

1.6 Join the Network

This section describes the various components of the system, including the processes, networking protocol, public key infrastructure, HTTP server and client, files, databases, and terminal.

2 System Components

Processes are independent pieces of Wasm code running on Kinode. They can either be persistent, in which case they have in-memory state, or temporary, completing some specific task and returning. They have access to long-term storage, like the filesystem or databases. They can communicate locally and over the Kinode network. They can access the internet via HTTP or WebSockets. And these abilities can be controlled using a capabilities security model.

2.1 Processes

On Kinode OS, processes are the building blocks for peer-to-peer applications. The Kinode runtime handles message-passing between processes, plus the startup and teardown of said processes. This section describes the message design as it relates to processes.

Each process instance has a globally unique identifier, or 

the process name. This may be a developer-selected string or a randomly-generated number as string.

the node the process is running on (your node).

Guides

Interested in contributing? Ping us at [email protected]

Intro to Privy

Intro to Kinode

How to Integrate Reown AppKit on EVM

Building with 1inch

Introduction to VRF with Gelato

Introduction to Relay with Gelato

Introduction to Automation/Web3 functions with Gelato

Simplify Onchain Data with Goldsky

Building dApps for Cars

Intro to The Graph and Querying Subgraphs

Introduction to Hedera

Introduction to Zircuit

Efficient Data Indexing Using SubQuery Network

Intro to MultiBaas

A Complete Guide to Oracles

All You Need To Know About Our Hackathons!

Intro to Celo

Intro to Cartesi

Building a Superfluid Super App

Introduction to Unlock Protocol

Creating ERC20 Token on Polygon

Intro to Sequence Smart Contract Wallet

Introduction to MetaMask Snaps

Introduction to Optimism

Introduction to Livepeer

Verifying Storage on Filecoin

Introduction to libp2p

Smart Contract Development Guidelines

Bridging Tokens & Data

Intro to Push Protocol

Intro to Ethereum Name Service

Money Streaming with Solidity 101

Getting started with Metamask