Govern

Informal Proposals

Below is a list of informal proposals subject to discussions among community members that are suitable for voting via DAO Governance:

  • To limit outflow of liquidity, the use of LN Channel Rewards should be restricted. Lightning Nodes should not be able to withdraw free rewards coming from outbound capacity without having used the capacity market. Instead, they should be encouraged to use their balance via the Lightning Ocean. Effectively, this enhancement would work like an entry bonus that prompts Lightning Nodes to spend PL2 as Liquidity Takers when licensing inbound capacity from Liquidity Makers.
  • Provide a Software Development Kit (SDK) to enable Chainlink node operators joining the DON. The proposed tool should allow these Ethereum oracle providers to install a Bitcoin Lightning Node on their system so they can connect with Plenny and run Lightning Oracles.
  • Adjust the Plenny DLSP module for integration with Bitcoin Improvement Proposals BIP340 (i.e. Schnorr signatures), BIP341 (i.e. Taproot), BIP342 (i.e. Tapscript) to benefit from Bitcoin’s multi-sig-transactions, smart contracts, and enhanced privacy.
  • Support liquidity contracts for PL2/WBTC via Sushi/Arbitrum.
  • To mitigate currency risk, support decentralized stablecoins DAI via Sushi/Arbitrum and the capacity market.
  • Integrate Plenny with sidechains of the Bitcoin protocol (e.g. RSK SmartBitcoin, RBTC).
  • Integrated Plenny with Gnosis Chain using xDai (i.e. Ethereum low-cost sidechain).
  • Integrate Plenny with Fantom Opera (Ethereum-compatible super low-cost blockchain network) using Lachesis, a DAG-based (acyclic directed graph) Asynchronous Byzantine Fault Tolerance (aBFT) consensus algorithm.
  • Introduce a separate Plenny-chain enabling Lightning Nodes to validate transactions.
  • Convert channel capacity into non-fungible tokens (NFT) to mirror sat liquidity positions on the LN via Ethereum and reduce the regulatory risk of the transactional data licensing model.
  • Adding further payment utility to PL2 by incorporating Optimism Layer 2.
  • Add ZK-Sync Ethereum L2 scaling solution using Zero-Knowledge-Proofs (ZKP).
  • Adding more currency pairs for liquidity providing over decentralized exchanges.
  • Adding Atomic Swaps to Plenny to support cross-chain interoperability.
  • Integrate Perpetual Protocol into the capacity market enabling Lightning Nodes to use virtual AMM on decentralized derivative exchanges.
  • Improve interconnection with decentralized markets: Integrations for Compound and Aave to support use cases related to lending and borrowing liquidity.
  • Introducing a decentralized money market (i.e. “Channel Credit”) for allowing Lightning Nodes to borrow liquidity through cross-chain atomic swaps and enabling miners to lend cryptocurrency to Lightning Nodes on a non-custodial basis. This envisioned service feature targets use cases related to the Internet of Things (IoT), enabling decentralized loans based on machine-to-machine (M2M) transactions.
  • Add feature enabling streaming of money for Makers and Takers (e.g. Sablier/Superfluid).
  • Plenny shall provide tools to Lightning Nodes enabling them to operate non-custodial channel factories using discovery tools for optimized pathfinding to route transactions and rebalancing payment channels for outbound and inbound capacity at profitable margin. The idea is to provide best-in-breed routing suggestions based on data science and prevent payment failure. For the implementation to work, the discovery tool of Plenny should collect and publish node data for making better commercial decisions. Basically, it should function like a search engine that crawls through the LN. Counteract inflation by introducing deflationary functionality: Reducing supply by burning newly minted token rewards given to LTs for logging outbound capacity (i.e. NCCR-mechanism) when the relevant payment channel is closed.
  • Adjust the inflation model from the generally assumed optimal number (2.5%) to an elastic Mirror-Universe-Function (MUF). The idea is to base inflation on the Plenny’s real cash flow and not on the fixed percentage as suggested by financial economic theory. Change the numbers as follows:

    Replace the current inflation model with a multiplier of the turnover in sat on the Bitcoin Lightning Network which is facilitated by Plenny (e.g. x 100), as well as with another factor X (e.g. 100) relative to turnover in PL2 via decentralized markets. Underlying crypto values could be derived from the volume of Non-Custodial Channel Rewards (NCCR) as well as the burning and buyback volume in PL2 in the Ethereum ecosystem. The purpose of this change is to expand the token supply dynamically based on the activity taking place within the non-financial digital economy via the LN and the activity of PL2 in the decentralized financial economy via Ethereum. The new inflation formula is supposed to keep the different sizes and growth rates of the different types of economies more proportionate to each other. The MUF aims to strengthen the influence of the smaller real economy by giving it more weight in controlling inflationary and deflationary tendencies than the much larger financial economy. With this model, the costs and demand for lightning services, as well as the revenues and expenses of Lightning Nodes, could influence the token price more effectively, resulting in more efficient compensation for the core users of Plenny without being unduly affected by price fluctuations caused by speculative market behavior of traders. Technically, this adjustment could be implemented by changing the smart contract that controls the community-driven “Replenishment Trigger.” This way, the additional token gets minted through the current functionality and distributed via the existing decentralized cash management operations.