The Final Summoning Rites, Part 2 - Mainnet Phase 0

If you are reading this, Penumbra exists.

The following post will go over what is needed in order to interact with the network as it moves through it’s initial phases, as well as explaining the structure of genesis.

Summary:

Part 1: Token Allocations
  • Token distribution and reasoning
  • Token lockups
    • Investor responsibilities and limitations
    • Contributor lockups
    • Lockup liberties
  • The role of the Institute for Applied Numogrammatics (IAN)
  • The role of the Community Pool (in contrast to the IAN)
  • Additional Distributions
Part 2: Token Economics
  • UM Resource usage
  • Penumbra Transaction qualities
  • Staking
  • Decentralized Exchange - the Penumbra DEX

Phased Launch

The initial genesis event is only the first step in Penumbra’s decentralized launch.

Phase 0

Radiant Commons organized an airdrop claim that collected community sentiment about their preferred validators, allowing decentralized selection of a genesis validator set. This initial validator set has produced an initial block proposed as the basis for the Penumbra chain, which is subject to approval by governance in Phases 1 and 2, with allocations described below. In phase 0, IBC, IBC transfers and the DEX are all disabled, so the chain has no functionality beyond transfers and governance.

As of this post, this is the current phase.

New validators can join the network and users can delegate to them, further decentralizing the network. Note that unlike Cosmos-SDK chains, Penumbra processes stake updates only at epoch boundaries, so the validator set will update gradually over the coming days.

At this time, there is no official RPC and no official frontend, to ensure network decentralization. Interested community members can consult the Penumbra Guide for details on how to run a node or host a frontend and share resources on the forum or in the Discord. It is with a community-produced front-end that airdrop claimants can check their balances and stake to validators on the network.

Phase 1

After an initial shakeout period in phase 0 to establish community RPC endpoints, ensure network stability, and so on, the network is proposed to enter phase 1 via a governance vote that would enable Penumbra’s IBC module. This would not enable transfers, but merely allow IBC connections to be created between Penumbra and the rest of the interchain, ratifying the Phase 0 genesis.

It is at this point that the Phase 0 genesis would become the Penumbra mainnet.

At this stage, relayers can be configured and tested, though transfer packets will be rejected by the Penumbra chain. This allows propagating channel IDs and token metadata through the ecosystem in advance of transfers and trading being enabled.

Full Functionality

After IBC connections have successfully been created to other chains, full functionality could be enabled via a governance vote to enable the Penumbra DEX and IBC transfers, potentially allowing price discovery of the Penumbra token.


Token Allocations

The genesis supply of Penumbra’s 100,000,000 UM tokens are broken down along the below lines. Note that all investor tokens and team tokens are locked:

Categories

Airdrop

The Penumbra UM airdrop was a proposed drop comprising 16% of the protocol’s genesis supply. This amount was allocated to two eligible groups - active Cosmos DeFi wallet addresses and developers who have either contributed to repositories that supported Penumbra’s creation or to repositories critical to crypto at large. Each of these categories was respectively allocated 8% of the total supply, then offered an in-category multiplier if the claimant elected to stake their claim to a validator aiming to be a part of the genesis set.

Institute for Applied Numogrammatics (IAN)

IAN is a Cayman foundation dedicated to supporting the Penumbra protocol and ecosystem through grant-making activities to parties demonstrating credible intention and results in growing the Penumbra ecosystem and blockchain. While IAN should be responsive to the community, it is not controlled through on-chain governance and is an independent entity with its own decision-making process. It is allocated 20% of the genesis supply.

Community Pool

Penumbra’s community pool is modeled on the design of the Cosmos SDK, and holds 25% of the token supply. Of this 25%, it is suggested that

  • 10% is earmarked for future distribution to the community, as approved by governance;
  • 15% is for future use by the community, as approved by governance;

At genesis, tokens in the community pool are frozen via a chain parameter. This is intended as an conservative risk mitigation against the possibility of governance-related exploits. The community can decide if and when to enable community pool spends via a parameter change.

Radiant Commons

Radiant Commons is a not-for-profit entity established to support the Penumbra protocol and ecosystem. 4.5% of tokens are allocated to Radiant Commons.

Penumbra Labs

Penumbra Labs was the original developer of the core Penumbra protocol. Penumbra Labs develops the Prax Wallet and contributes to open-source development of the Penumbra software. 3.65% of tokens are allocated to Penumbra Labs.

Contributors

12.5% of tokens are allocated to pre-launch contributors to the development of the Penumbra protocol over the last three years. All contributor tokens are subject to at least a one-year lockup plus vesting, described in more detail below.

Investors

Seed Investors are allocated 12.1% of the genesis supply, whereas Strategic Investors are allocated 5.1% of the genesis supply. All investors are subject to a 2 year lockup, with a 1 year cliff and monthly unlock thereafter.


Token Lockups

All investor and team tokens are locked for a minimum of one year post genesis, with unlock schedules described below. Penumbra records all tokens in the same shielded pool, and does not have transparent accounts or programmability. Lockups were not encoded into the ZK proof circuits to minimize their complexity and reduce the risk of critical bugs. Instead, to ensure transparency of locked tokens, the Full Viewing Keys (FVKs) of all wallets holding locked tokens will be published, disclosing all past and future activity of each wallet.

Schedules for lockups are roughly as follows:

  • Investor tokens are locked in a 2-year linear lockup schedule with a 1 year cliff;
  • Team-distributed tokens are vested on a 3 or 4 year schedule with a 1 year cliff;

The exact lockup terms are encoded directly into the genesis allocations, for public auditability.

One unique feature of Penumbra is that each wallet has many numbered accounts all viewed with a single full viewing key, rather than a single account per key. This allows lockup schedules to be precisely encoded in the genesis allocations as follows: account number N holds the tranche of tokens unlocking at N months following genesis. Locked tokens can be staked or used to participate in governance. The act of delegation exchanges UM for a validator’s delegation token, so a lockup account may have less UM if it stakes tokens after genesis, but at all times prior to the unlock date, the lockup account must maintain the UM-equivalent value of its original balance, whether in UM or delegation tokens.


Part 2: UM Token Economics (Tokenomics)

Penumbra’s token economics are designed around a principle of creating the best possible environment for crypto-economic settlement - efficient price discovery for tokens, batch ordering, and multi-dimensional gas fees, (among other features), all while guaranteeing privacy in all transactions that take place within and through Penumbra.

A decentralized protocol must internalize an economic model for the resources required for its operation — computation, bandwidth, economic security, or otherwise. To this end, there are three aspects of the protocol design that create or burn UM tokens: resource-usage based fees, staking and decentralized exchange.

Resource usage

  • Penumbra implements multidimensional gas pricing to allow separate pricing of four different resources used in processing transactions:
    • Block space, as a proxy for synchronization costs between full nodes
    • Compact block space, as a proxy for synchronization costs of wallets running ultralight nodes
    • Verification, as a proxy for CPU-intensive work like proof verification
    • Execution, as a proxy for IO-intensive work like state updates
  • Each transaction has a gas vector, representing the amount of each type of resource it uses. This gas vector is multiplied by a vector of gas prices (one for each resource) to determine the transaction’s required base fee.
  • The base fee for a transaction is always burned, to represent the cost each transaction incurs to every other user of the network.
  • Transactions include a fee amount which must be larger than the base fee. The difference between the base fee and the actual fee is intended to be a proposer tip paid to the validator who proposed the block. However, in the initial version of the Penumbra software, this tip is also burned, for implementation simplicity. This could be changed in a network upgrade subject to community approval.
  • Gas prices are initially set by governance. A future network upgrade could implement automatic resource pricing based on the dynamically measured usage of each resource, as described in this research paper: https://baincapitalcrypto.com/multi-dimensional-on-chain-resource-pricing/
  • Transaction fees can also be paid in non-native tokens other than UM. Currently, these prices are independently set by governance.
    • This is suboptimal but simple and resilient; in a future with dynamic resource pricing and confidence in the DEX as its own on-chain price oracle, this could be done automatically.
    • Non-native fees are swapped into UM and then treated the same way as native-token fees. Using non-native fee tokens harms privacy, so it should be discouraged by having a higher price. This also avoids a need to rely on the DEX as a price oracle in the initial phase of the network.
  • In the future, multidimensional resource pricing together with the DEX as a reliable price oracle would enable governance minimization for fees.

Staking

Staking on Penumbra is fully private - allowing users to hold a liquid-staking token specific to a validator rather than demonstrating preference publicly.

  • Delegation tokens on Penumbra allow users to stake tokens with validators while maintaining privacy by using protocol-native, validator-specific tokens, ensuring validators can be held accountable without compromising user confidentiality. You can learn more about them here or in more detail here.
  • Staking issuance on Penumbra is currently fixed, rather than a dynamic rate as in the Cosmos SDK. This parameter is chosen by governance. The initially proposed staking rate issuance is low, targeting approximately 2% per year, but this could be adjusted by the community via governance.
    • A low initial staking rate is intended to minimize concerns about excessive and disproportionate staking rewards to locked holders seen on other Cosmos chains.
  • The unbonding period for staked tokens is 21 days, which determines the trusting period for IBC clients.
  • Staking is entirely non-custodial. Users have sole custody of their delegation tokens at all times, and validators do not take control of any staked assets.

Decentralized Exchange (DEX)

  • Penumbra minimizes MEV by having no economically meaningful transaction ordering. This is because all trades are submitted as part of the same block and executed in a single batch with a common price averaged by the protocol.
  • However, this presents problems with intra-chain arbitrage, which is necessary for the chain to report consistent prices between trading pairs. To address this, the DEX programmatically and autonomously performs arbitrage at the end of each block by attempting to trade UM to UM through any mis-priced positions. Any arbitrage proceeds are programmatically burned, as this is the most credibly neutral way to handle the tokens.
  • This allows users to reliably execute trades on the market-maker side as well as the market-taker side, as they can expect that if a position is mispriced it will be filled.
4 Likes

⊤⊥ has set up penumbra’s first public GRPC instance at:

https://void.s9.gay

This can be configured under the RPC setting in Prax to use with the hosted frontend at https://void.s9.gay/app/

There is also a public CometBFT RPC service which other operators can use to start their own mainnet full nodes by following the instructions in https://guide.penumbra.zone/node/pd/join-network.html and using http://void.s9.gay:26657 in place of NODE_URL in the pd network join step.

Example:
pd network join --moniker MY_NODE_NAME --external-address IP_ADDRESS:26656 http://void.s9.gay:26657

Super cool operators can even setup their own public GRPC instances (and minifront hosted frontend!) by pointing a DNS record to their host, and modifying the service example located at https://github.com/penumbra-zone/penumbra/blob/main/deployments/systemd/penumbra.service to use an ExecStart line like:

ExecStart=/usr/local/bin/pd start --grpc-auto-https www.example.com

Together we will make penumbra as decentralized as possible :heart_on_fire: :pray: :new_moon:

Please consider staking to our validator to support our decentralization efforts :heart_hands:
penumbravalid1qttzflwwf76qsredmcmqdny3z2v35a3kklrzram6l7x9l69v7szslkuzy0

1 Like

Silent Validator have set up the public rpc and frontend.

Feel free to use
Frontend: https://grpc.penumbra.silentvalidator.com/app/
GRPC: https://grpc.penumbra.silentvalidator.com/
Tendermint RPC https://rpc.penumbra.silentvalidator.com/

For use in pcli
pcli init --grpc-url https://grpc.penumbra.silentvalidator.com:443 soft-kms import-phrase

Our Mainnet Identity
penumbravalid19jqf35xytm4ht9f8awtad9wxmfky0tjygug8390cewyqjwmyucqqkkrc9r

If you want to set up one public GRPC and frontend, contributing to the decentralization together

You can run a full node
https://guide.penumbra.zone/tutorials/running-node.html
set a DNS record, and add your DNS domain after --grpc-auto-https in the service file. (Just download pre-compiled pd for now, building from source will met issue about frontend)

Let’s make penumbra decentralized together.

1 Like

Polkachu has set up penumbra’s node operation services.

https://polkachu.com/networks/penumbra

I especially want to highlight our customized instruction on how to process Penumbra node snapshot: https://polkachu.com/tendermint_snapshots/penumbra

3 Likes

wrote up a little script to help other operators get full nodes up quickly (and if you point a DNS name at your host first, it will auto setup HTTPS / GRPC too :heart_on_fire: )

single liner:
curl --proto '=https' --tlsv1.2 -LsSf https://raw.githubusercontent.com/22a435/void-sh/main/init.sh | bash

repo with source:

2 Likes

A wild Penumbra node appears! Feel free to use the following endpoints:

1 Like

Congrats everyone!

“AM Solutions” endpoints and snapshot service:
RPC : https://rpc-penumbra.theamsolutions.info
gRPC : https://grpc-penumbra.theamsolutions.info
FRONT APP : https://grpc-penumbra.theamsolutions.info/app/#
Data snapshots : https://www.theamsolutions.info/penumbra

Starling Cybernetics has configured an always up to date frontend for Penumbra, built and deployed every six hours based on the latest release of minifront, the minimal static frontend bundled with and served by pd.

This continuously updated edge deployment of the frontend may be found at:

stake.with.starlingcyber.net

If you want to support further infrastructure development like this frontend, our dashboard at https://penumbra.today, and more, the frontend URL tells you how to help out: stake.with.starlingcyber.net using praxwallet.com or the command line pcli wallet. Further instructions for staking on Penumbra can be found at our website: Stake | Starling Cybernetics.

Good evening to all!

:waning_crescent_moon: