RFC #1: DFK Chain Allowlist Removal

Problem Statement****

Due to the nature of DFK Chain, it’s very cheap (in terms of gas costs) to write data to the chain. When data is written to the chain, if we make no changes to the subnet EVM, we must store and potentially be open to process that data for as long as DFK Chain exists. This is fine as long as there are no malicious contracts that allow arbitrary data storage. If we fully remove the allowlist, there are no protections in place to prevent a malicious actor from writing several gigabytes of data to the chain, forcing the useless data to be stored on DFK Chain (and by extension all validators and RPC nodes) in perpetuity.

Potential Solutions

1. Keep the chain as-is with allowlist in place

Pros:

• Chain stays performant and protected
• Gas fees remain lower

Cons:

• Reduces network effects
• Reduces community engagement
• Higher friction for infrastructure partners to deploy on our chain
• Still the potential for abuse from allowlisted parties

---

2. Remove the allowlist, raise gas fees to increase the cost of storage in order to protect the chain

Pros:

• Chain is open, decentralized
• Reduces the regulatory risk

Cons:

• Players must pay higher gas fees
• On-chain volume could slow as a result of higher fees

---

3. Remove the allowlist, keeping gas fees at current levels. Deal with the fallout in the case of malicious behavior

Pros:

• Chain is open for contract deployment
• Decentralized
• Gas fees stay at current levels

Cons:

• Opens us up to risk of slowing down chain
• No non-centralized solution to removing the data
• Delay in response could put the chain operation and access to funds at risk

---

4. Implement a precompile that puts restrictions on what contracts can be deployed

Pros:

• Very fine-grained control over what types of contracts can be deployed

Cons:

• Technical resources need to implement and maintain going forward
• Significant internal management overhead by team
• Could be misinterpreted as KS team auditing the code or declaring it vetted or safe, as we cannot provide security guarantees for these contracts

---

5. Keep the allowlist but have a way to automatically become whitelisted if a user signs a transaction saying they have read the terms and conditions, which include terms about not maliciously storing useless data and being responsible with data cleanup. Then use a Precompile that lets a Governor contract, which uses on-chain governance via c/sJEWEL, remove malicious contracts and data from the chain.

Pros:

• An open and decentralized chain.
• Recourse in case of bad actors.
• Enforcement of policy is decentralized

Cons:

• Complex to set up and requires a precompile to be maintained
• Not quite as “lawless” as other blockchains due to the policy

---

6. Community-Driven Allowlist - A group of elected community representatives would decide what addresses are allowed to deploy contracts on chain

Pros:

• Decentralized
• Allows for recourse in case of bad actors

Cons:

• Slower to respond to requests due to the need to allow the community to vote
• Requires significant development resources to implement
• Higher friction for infrastructure partners to deploy on our chain
• Still the potential for abuse from allowlisted parties