This is a proposal is a collaborative effort between Picasso x AADAO (Atom Accelerator DAO) to explore Picasso network as an opt-in consumer chain.
Opt-in consumer chains are intended to be launched permissionlessly, but in this version of ICS, a permissionless launch is not yet possible for technical reasons involving the chain_id. If you are interested, read more here.
This proposal is NOT intended to judge whether the chain is worthwhile to use or validate. Since it is an opt-in consumer chain, no validator is obligated to run it, and any validator can opt in or out its validator set at any time. Validators who do not feel that the chain is worthwhile are encouraged simply not to run it.
Vote
YES if you believe that this consumer chain is being started by Picasso’s real development team, is not squatting on a chain_id commonly recognized as belonging to another chain, and is not launching a large number of consumer chain proposals to spam governance.
NO has no purpose. Voters who feel that this chain is impersonating another chain or that this proposal is part of a spam attack should vote NO WITH VETO.
NO WITH VETO if this consumer chain is impersonating another chain, is “squatting” on an existing chain’s chain_id, or is part of a spam attack.
ABSTAIN if you are not sure. However, the criteria above are quite clear, and in most cases, it should be easy to decide whether to veto a consumer chain launch because of impersonation or spam.
About Picasso
Picasso is a DeFi infrastructure-focused Layer 1 protocol designed to build a trust-minimized interoperability solution called Cross-Ecosystem IBC. It aims to facilitate seamless and secure interactions between different blockchain ecosystems.
Interoperability Hub: Built using the Cosmos SDK framework, Picasso acts as an Inter-Blockchain Communication (IBC) Protocol hub between IBC-enabled chains. This infrastructure supports native protocol-level security and permissionless interoperability for DeFi users across various networks.
Security & Consensus: Picasso secures its network through PICA token staking, a Generalized Restaking Layer.
Cross-Ecosystem IBC: Picasso extends the IBC protocol to connect multiple blockchain networks, including Solana, Ethereum, Polkadot, and Kusama, upholding IBC standards and values. This extension involves significant development to achieve trust-minimized bridging and state proof without relying on centralized intermediaries.
Generalized Restaking Layer: Picasso is developing the first Generalized Restaking Layer, initially deployed on Solana, expanding to support all IBC-connected ecosystems. This innovation allows users to leverage the economic value of their liquid staked tokens and yield-bearing assets for enhanced security and validation services.
Revenue Sharing and Fees: Revenue from bridging fees generated by IBC connections is allocated to stakers of PICA, with a mechanism to buy back PICA from the market and distribute rewards to stakers. This system ensures that fees collected in the form of bridged tokens benefit the ecosystem, enhancing the economic value for participants.
Vision: Picasso network is dedicated to advancing interoperability in DeFi by expanding IBC connectivity across various ecosystems. By reducing fungibility issues and increasing IBC traffic, Picasso aims to realize the Cosmos Hub’s vision of becoming the central hub for cross-ecosystem IBC, driving liquidity and user growth.
Proposed Chain Parameters
Type - OptIn
AllowList - N/A
DenyList - Exchange validators
NumberCap - 10 validators
PowerCap - 10% voting power
Picasso Incentive Structure
ATOM as Gas: ATOM will be used as the gas fee and as AEZ capital/liquidity token.
AEZ DeFi x Picasso/Hub revenue sharing deals (similar to Nomic x Osmosis structure) to be split between Picasso & Cosmos Hub 50/50
Token Allocation: 20% of PICA staking rewards will be allocated to the Cosmos Hub validators (and their delegators) who opt-in to securing the Picasso chain.
Reduced IBC Fees: Reduced IBC fees for ATOM-related bridging to encourage usage and liquidity flow.
Revenue Sharing: 20% of IBC fees generated on Picasso will be shared with the Cosmos Hub opt-in validators.
Hello, why limit the number of validators to 10? I don’t understand why you would want to limit your market to such an extent when, in the current Picasso network, 48 validators are validating the network. I think you should let the opt in market do its work and significantly increase the validator cap, as well as estimate the chain’s revenue to convince validators to opt in.
I’m not very well versed in this but I got a question : I see how this benefits atom and how it lowers the cost of running a chain for composable but how does it benefit pica stakers for example, I see less rev share for them
Also by not using pica as gas, it lowers it’s utility…
I fail to see how this benefits pica holders and stakers
I agree. I’m sure we can make this work, and we definitely need to show that we can if we want the consumer chain thesis to gain traction, but there has to be a way to incentivize pica stakers to vote for it. Maybe the answer would be to show data on how this will increase long-term revenue for pica stakers? Or data on why not becoming a consumer chain is worse for pica stakers?
Hey - the validators capped at 10 isn’t something finalized. If we go this route, a reduction in validator set is possible. But would mostly boil down to which would prefer to continue as Picasso specific validators
Picasso has been built as an infrastructure chain extending one of the core technical pieces of the Cosmos ecosystem (IBC). This should make a minimal impact to holders/stakers as the revenue split to PICA remains the same - we are simply looking to explore alternatives to secure the chain.
Picasso is a network that migrated to Cosmos from the Kusama ecosystem, and as such, we do not have built in token inflation as many (mostly all) Cosmos chains do. This is an attempt to secure Picasso chain into the future, and have IBC volume outside of Cosmos (Ethereum, Solana, Polkadot/Kusama) flow back to the hub for security.
From our vantage point - nothing significant is changing here for PICA other than the source of security. Revenue is still going to flow to PICA stakers the same as previously, there are potentially some options we could explore to increase the current split to PICA stakers.
In that case, I recommend ensuring that’s spelled out and explicit in the proposal when it goes on-chain. Pica stakers will want to know they aren’t losing their investment and preferably they’ll want to see in writing why we think this will make Pica an even better investment. I think the way it was written above doesn’t make that clear.
After thorough review, we are delighted to back your proposal. Your grasp of PSS economics is evident in the revenue-sharing approach, which aligns with our recommended financial strategies (ICS 2.0 Economics : Partial Set Security (PSS) Financial Model). The decision to limit validators to ten, until more stable revenues are established, seems prudent. This should cover operational costs and potentially yield profits for delegators.
Your suggestion of a 10% VotePowerCap is noteworthy, ensuring all opt-in validators receive rewards equitably, irrespective of their delegated stake (10 validators at 10%cap means every validator receives 1/10th). This method promotes a fair start for a chain with a limited validator set, providing assured revenue for basic operations and discouraging strategic maneuvers among validators, as rewards will be evenly distributed.
In summary, your proposal is well-considered, demonstrating economic acumen and a realistic appraisal of your value proposition. On behalf of the PRO Delegators’ validator, we will meticulously examine the finalized details and lean towards a positive vote to operate the chain.
Definitely understood, and appreciate the note. We will take this discussion period very seriously to answer as many outstanding questions as possible before a revised copy makes it on chain.
