[RFC] Multi-chain DILL vision & design

As previously mentioned in Monthly DILL DAO Community Call — November 2021, a current roadmap item is to take DILL multi-chain, an initiative that I have christened as “Picklestations”.

The vision could be summarised in the following image.

As a quick reminder, a definition of what a product vision statement is from the 280 Group (emphasis mine).

a description of the essence of your product: what are the problems it is solving, for whom, and why now is the right time to build it. A Product vision gives your team a bigger picture of what they are working on and why.

That being said, it is understood that the target audience here is:

  • existing DILL holders, not getting full DILL utility (voting + boosts) outside of the Ethereum mainnet.
  • PICKLE holders, who have stopped interacting with DILL contracts due to costs of the Ethereum mainnet.
  • Pickle users, who are interested in the PICKLE/DILL tokenomics but are unable to participate due to being priced out of the Ethereum mainnet.

Conversely, the why of the Picklestation initiative can be understood as follows:

  • The DILL mechanism is the core value proposition of the PICKLE token, therefore it should operate in Ethereum rollups, given Ethereum’s rollup-centric roadmap: https://twitter.com/VitalikButerin/status/1311921668005060608. Whenever feasible and desirable, the same logic should be extended to sidechains to the Ethereum mainnet where Pickle has emissions.
    • The DILL mechanism provides certain benefits, namely revenue-sharing, voting for emissions distribution, and boosted rewards for depositing TVL into Pickle. The value provided by all of these benefits should extend to non-mainnet Pickle deployments whenever feasible. (Currently, only revenue-sharing captures all multi-chain revenue).
  • The DILL mechanism should be highly accessible to users. Given the costs of the Ethereum mainnet, many existing and potential users have been impacted or fully priced out of using DILL.
  • The DILL mechanism is immutable, non-custodial, and largely decentralised. These properties should be maintained as it is extended or enhanced.

Given that context, a what is proposed to contain the following features or modules:

  • A mechanism to lock PICKLEs for DILL using non-Ethereum mainnet chains.
    • This should be accompanied by extending the lock duration, in a similar manner as existing DILL.
  • A mechanism to send rewards to PICKLEs locked using non-Ethereum mainnet chains.
    • This should be accompanied by the ability to claim such rewards using non-Ethereum mainnet chains.
  • A mechanism to vote emissions distribution to non-Ethereum farms.
  • A mechanism to account for and provide boosts to DILL owners in non-Ethereum farms. DILL is meant to be fungible, therefore this mechanism should consider all DILL equal, no matter the chain in which PICKLEs are locked.
  • These mechanisms should all be as accessible as possible, lowering the cost barrier to participating in DILL tokenomics significantly.

Finally, a rough how has been proposed that meets the why and what as elaborated herein. It looks something like this:

  • a module called “Picklestation” will be deployed in each feasible Ethereum rollup and non-Ethereum mainnet chain where PICKLEs are emitted. This module will have the following functionality:
    • allow for locking PICKLEs for DILL using a contract call.
    • allow for extending DILL locks using a contract call.
    • manage PICKLE rewards (from revenue-sharing), and allow for claiming using a contract call.
    • utilise transaction batching/pooling whenever bridging to/from mainnet is required, to socialised these costs.
    • whenever contract calls are needed, local rollup or sidechain gas rates will apply.
  • the Picklestations will couple into the existing DILL architecture on the Ethereum mainnet, each Picklestation will have its own balance of DILL on mainnet, and keep track of local DILL balances on rollup/sidechain.
    • PICKLEs for locks will be bridged from the Picklestation on the rollup/sidechain to mainnet.
    • revenue-sharing given to the Picklestation will be bridged by the Picklestation from mainnet to the rollup/sidechain.
    • For bridging, each Picklestation will have a wallet and a proxy on mainnet (or a proxy common to all Picklestations) to cover these costs, and will mainly rely on transaction batching/pooling to obtain the funds to pay for gas. Treasury will act as a guarantor of these transactions, providing gas tokens when necessary in edge cases.
  • dependant on the enablement of voting for rollup/sidechain jars on mainnet, the Picklestation will serve as a proxy for voting on farm weights / emissions distribution. Gasless methods like signatures will be explored here if feasible, particularly if mainnet voting switches to gasless (SafeSnap or as part of GaugeProxyV2).
  • the PICKLE distributor on each rollup/sidechain currently relies on the MiniChef architecture. A new architecture that takes into account global DILL balances as reported by PickleStations (aggregated to a common proxy on mainnet) will have to be developed in order to calculate boost balances correctly.
  • in order to communicate cross-chain, a cross-chain messaging protocol either built in-house or procured from a decentralised provider (e.g. Chainlink) probably will have to be part of the implementation.

Keep in mind that at this stage of the process (roadmapping and issue refinement), a full-blown architecture and proposed implementation would need to be sanity checked for feasibility by a technical solution architect or engineer.

The purpose of this post is to invite feedback (including criticism) to the vision and initial design. All feedback will be given due consideration and may cause the vision and/or design to change. Understandably, not all feedback will be given the same weight. Feedback on design should incorporate design thinking principles and feedback on implementation should incorporate knowledge on solution architecture as it pertains to the existing and future EVM ecosystem. As expected, constructive feedback (the kind that proposes solutions to the same standards as those already proposed) will drive further engagement.

Note that this vision has come from the distillation of user-identified problems, complaints, and pain points as well as an understanding of customer jobs and gain creators – therefore a competing or complementary vision is expected to hold a candle to the same rigor.

Temperature Check on the Multi-Chain DILL initiative’s current vision & design
    • Picklestations are the wei for Multi-Chain DILL
    • Me no likey (see comments)

0 voters

1 Like

That’s a lot of engineering for PICKLE distribution mechanism that is centralized anyway.

Cross chain communication will be centralized and potentially fragile. What happens if the cross chain communication stops working or catches a bug?

Does anyone have an idea that requires less development time?
We’re designing here an internal Pickle distribution mechanism, supervised by the team already. Does it have to have complexity close to an entire new protocol or a large product? Can we afford so much resources to be spent on Pickle token distribution?
A hyper-complex approach to distributing PICKLE will not help humanity and will not help Pickle find users.
To be frank, we can ignore all that effort and have distribution calculated in excel and claimable and users will be happy as well.

Any thoughts on the following designs:

Design 1:
Modify DILL so that we can vote for more farms. Either make it less gas hungry or split voting into batches. Alternatively, consider voting on snapshot.org, keep the same boost mechanism.

Snapshot current DILL balances and deploy on Arbitrum/Optimism.

Vote for farms on all chains from Arbi/Opti and distribute Pickle to Arbi/Opti ONLY. Pickle does not go to any other chain.
You can lock it for DILL on Arbi/Opti or dump. No DILL contract on any other chain.

Design 2:
Modify DILL so that we can vote for more farms. Either make it less gas hungry or split voting into batches. Alternatively, consider voting on snapshot.org, keep the same boost mechanism.

Deploy DILL on each chain, that is Arbitrum, Polygon, Moonriver. People can bridge PICKLE to each chain with official bridges. People can lock for DILL on each chain for that chain only and not for other chains. Same for boosts.

When updated DILL is redeployed on ETH (allowing more farms) allow users a one-off opportunity to have their DILL go to another chain instead of ETH.

Pickle team looks at the proportion of DILL between all chains, and if the proportion is ETH 3 - Poly 1 - Arbi 1 - moonriver 0.5 then the total pickle emissions will be divided accordingly and issued proportionally on each chain. More users or Arbitrum - more emissions to arbitrum. Emissions will be issued from Treasury funds - treasury will keep surplus and distribute to chains depending on how much DILL there is on each chain.

I can think of some more designs, what do you guys think?

1 Like

I’ll rephrase a few things:
Pickle is already fairly centralized and it helps with operations. Why not use team-run offchain scripts instead of building a complex tool that will need to be heavily supervised and centralized as well?
Jars need to be decentralized. PICKLE emissions - not so much.

Does PICKLE need to go on different chains?
The only 2 usecases for PICKLE are:

  • lock for DILL, boost, vote
  • dump
    sloshing PICKLE across chains, bridging, paying fees and losing on slippage is not a valid usecase. Very interesting post in DILLdao:
    "the current tools available make it very difficult for me to take my pickles from Arb, bridge them to Eth, and lock for Dill

i’d have to sell aPickle for one of 5 bridgeable assets, then bridge, then buy Pickle on eth and pay for the gas, etc"

What if I told you that all PICKLE stuff could be done on Arbitrum and there is no need for PICKLE ever leaving that chain? With reduced risks of hacks and reduced dev time.

Getting that Chainlink communications thing would probably have a different implementation on 10 different chains. And then we may be forced to baghold their token to get access to their services.