From 05e4b5d57b2e58bbd022344fa99bcdeed718ff60 Mon Sep 17 00:00:00 2001 From: emduc Date: Tue, 15 Jul 2025 15:35:09 +0200 Subject: [PATCH] remove defiscan blog posts --- .../blog/deFiscan-community-review-program.md | 101 ------- content/english/blog/defiscan-bounties.md | 46 --- .../defiscan-update-methodology-batch-2.md | 100 ------- .../blog/defiscan-update-methodology.md | 101 ------- content/english/blog/ef-grants.md | 51 ---- .../blog/make-defi-decentralized-again.md | 81 ----- .../blog/software-licenses-for-defi.md | 283 ------------------ content/english/blog/the-great-unmasking.md | 71 ----- 8 files changed, 834 deletions(-) delete mode 100644 content/english/blog/deFiscan-community-review-program.md delete mode 100644 content/english/blog/defiscan-bounties.md delete mode 100644 content/english/blog/defiscan-update-methodology-batch-2.md delete mode 100644 content/english/blog/defiscan-update-methodology.md delete mode 100644 content/english/blog/ef-grants.md delete mode 100644 content/english/blog/make-defi-decentralized-again.md delete mode 100644 content/english/blog/software-licenses-for-defi.md delete mode 100644 content/english/blog/the-great-unmasking.md diff --git a/content/english/blog/deFiscan-community-review-program.md b/content/english/blog/deFiscan-community-review-program.md deleted file mode 100644 index 42345c1..0000000 --- a/content/english/blog/deFiscan-community-review-program.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: "DeFiScan Community Review Program" -meta_title: "" -description: "How much De is in my Fi? Help the crowds figure it out, and earn LUSD for it!" -date: 2024-11-19T05:00:00Z -image: "/images/defiscan-community-review-program-cover.png" -categories: ["Campaign"] -author: "nils" -tags: ["DeFiScan", "Community Review Program"] -draft: false ---- - -Are you deep in the trenches, knowing the protocols you use in and out? It’s time to put that knowledge to work, doing a service for the whole industry and getting paid for it! - -After the successful release of [DeFiScan](https://www.defiscan.info/) and the “How much De is in my Fi” competition last week during Devcon, we will now shift gears and focus on increasing coverage of the reviewed DeFi protocols. And how better to do this than through an incentivized community program with a total **prize pool of 10,000 LUSD!** - -This article outlines the details of the program. - -**This program has been replaced by [the DeFiScan Bounty Program](https://deficollective.org/blog/defiscan-bounties/)**. - - -### Key Information - - - -* The total payout for community submitted protocol reviews is LUSD 10,000 -* Anyone can submit reviews through a PR on the DeFiScan GitHub -* DeFi Collective members review and verify submissions -* Only PRs containing a complete and accurate review are merged and earn the prize of 500 LUSD -* Payouts are made in LUSD on Optimism -* Participants can submit more than one review -* The program ends as soon as LUSD 10,000 are paid out to community reviewers - - -### Scope - -At this stage, and although all submissions are welcome, only the reviews of the following protocols (on the chains indicated in brackets) are eligible for the prize payout: - - - -1. Lido (Ethereum) -2. Aave v3 (Ethereum, Arbitrum, Avalanche, Polygon, Base, Optimism, Scroll, BSC, Gnosis) -3. Aave v2 (Ethereum, Polygon) -4. EigenLayer (Ethereum) -5. Ether.Fi Stake (Ethereum) -6. Ether.fi Vaults (Ethereum) -7. Ether.fi Liquid (Ethereum) -8. Maker / Sky (Ethereum) -9. Uniswap v3 (Ethereum, Arbitrum, Polygon, Base) -10. Uniswap v2 (Ethereum, Base) -11. Binance Staked ETH (Ethereum, BSC) -12. Rocket Pool (Ethereum) -13. Ethena (Ethereum) -14. Spark (Ethereum) -15. Pendle (Ethereum) -16. Compound v3 (Ethereum, Arbitrum) -17. Compound V2 (Ethereum) -18. Symbiotic (Ethereum) -19. Zircuit (Ethereum) -20. Venus (BSC, Ethereum) -21. PancakeSwap AMM (BSC) -22. PancakeSwap AMM v3 (BSC) -23. Morpho Blue (Ethereum, Base) -24. Renzo (Ethereum) -25. Curve DEX (Ethereum, Arbitrum) -26. Curve crvUSD (Ethereum) - - -### Getting Started - -The following steps outline the process of registering for and conducting a successful protocol review. Make sure you understand and follow this process: - - - -1. Read the defiscan methodology and existing reviews to familiarize yourself with the expected submission process -2. Clone the permission-scanner repository from our GitHub -3. Fork the defiscan repository from our GitHub -4. Copy the review template and complete the information in the frontmatter with the details of the targeted DeFi protocol -5. Register your participation for the specific protocol by creating a draft PR with the review template on the defiscan repository -6. Complete the review within 2 weeks of registration (through step 5) by updating your PR with the full information -7. Ping the team in the DeFiScan channel on our GitHub -8. Assist the team in finalizing the review if any information is missing or incomplete -9. Once verified the team will merge your PR and coordinate for the payout - thank you! - - -### Successful Reviews - -A review is considered successful if it follows the process outlined above and is ultimately merged to the main repository. In particular, this requires that: - - - -* Registration of a protocol/chain, that is **not yet in review**, by submitting a draft PR -* Completion and submission of final PR with complete and accurate review **within 2 weeks** after registration -* Assisting the DeFi Collective team with final corrections and cleanups and merge or PR **within 1 week** after submission of final PR - -The prize of 500 LUSD is only awarded to successful reviews and paid out in LUSD on Optimism. - - -### Final Notes - -DeFiScan is an open source initiative driven by the DeFi Collective, a non-profit organization, and the broader DeFi community. We are very grateful for your participation in this initiative and support of the DeFi ecosystem. If you cannot participate in the DeFiScan Community Review Program but still want to support us, please consider donating to the DeFi Collective or spreading the word! diff --git a/content/english/blog/defiscan-bounties.md b/content/english/blog/defiscan-bounties.md deleted file mode 100644 index b778798..0000000 --- a/content/english/blog/defiscan-bounties.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "DeFiScan Bounty Reward Program" -meta_title: "" -description: "Introducing DeFiScan’s revamped incentivized review program: join us in our mission to achieve 90% DeFi TVL coverage by November 2025!" -date: 2025-04-23T05:00:00Z -image: "/images/defiscan-bounties-cover.png" -categories: ["Campaign"] -author: "nils" -tags: ["DeFiScan", "Community Review Program"] -draft: false ---- - -We're thrilled to announce a new streamlined and consolidated all-in-one DeFiScan community review reward program, increased payouts, and clearer access to up-to-date protocol review bounties and availability. - -We have run several incentivized review programs with various formats and payouts so far, and “users”—protocol reviewers—have reported that the multiplicity of the programs can be confusing, and we agree. - -Introducing DeFiScan’s revamped incentivized review program: join us in our mission to achieve 90% DeFi TVL coverage by November 2025! - -## Payout size - -* The first Community Review program allowed to earn 500 LUSD per review. Community reviewers can now earn up to 2,000 LUSD, paid in stablecoins: [LUSD, on Optimism](https://optimistic.etherscan.io/token/0xc40f949f8a4e094d1b49a23ea9241d289b7b2819). -* Payouts range from 1,000 to 2,000 LUSD, depending on the protocol's complexity. A long codebase, a large number of permissions, or a large number of external dependencies mean higher payouts. - -## Protocols Available for Bounties - -**Find available bounties directly on GitHub!** Any available protocol (not already worked on by someone else) is tagged “Available,” along with the bounty payout amount ranging from 1,000 LUSD to 2,000. - -Explore the up-to-date list of available protocols and payouts on the DeFiScan GitHub Pull Requests page: **[DeFiScan GitHub - Pull Requests](https://github.com/deficollective/defiscan/pull).** - -![defiscan-bounties](https://raw.githubusercontent.com/deficollective/deficollective.github.io/refs/heads/main/assets/images/defiscan-bounties.png) - -We're launching with an initial batch of 8 bounties, with more to come. - - -## Review Submission - -**Submitting a protocol review is an ongoing collaborative process.** It usually takes 2-4 weeks to complete and is verified by the team. The reviewer must be available for feedback and follow-up questions during this process. - -Submitting a review will require you to be available to the team for questions and feedback on **[the DeFiCollective Discord](https://discord.gg/zpDT7eeWv4)**. Once done, you can check GitHub to pick a protocol with a bounty available (see previous paragraph for details) and proceed: - -1. **Claim Your Bounty:**Reach out on our Discord and let us know which bounty you want to work on. We will remove the available label and assign you the GitHub issue. -2. **Submit Your First Draft:** Fork the repository and write your draft review. Take the existing reviews as inspiration. Follow the review structure and create a protocol diagram (we will provide an Excalidraw canvas for that), **submit your draft review as a PR within 2 weeks** (failure to do so will result in us opening the bounty for others again) -3. **Collaborate on Feedback:** Ping the defiscan team on our Discord and work with the team on any updates necessary. -4. **Get Reward:** When final, we will merge your PR and make the payout. - -Join the DeFiCollective Discord to get started: [DeFiScan channel on Discord](https://discord.gg/7RKxSJvvXM). We can't wait to see your contributions and build a comprehensive DeFiScan together! diff --git a/content/english/blog/defiscan-update-methodology-batch-2.md b/content/english/blog/defiscan-update-methodology-batch-2.md deleted file mode 100644 index fb77ba3..0000000 --- a/content/english/blog/defiscan-update-methodology-batch-2.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: "DeFiScan: Updates to the methodology (03/2025)" -meta_title: "" -description: "We discuss updates and clarifications on the DeFiScan methodology." -date: 2025-03-12T12:00:00Z -image: "/images/articles/defiscan-announcement.png" -categories: ["Policy"] -author: "nilsbundi" -tags: ["DeFiScan", "DeFi Risks", "DeFi Maturity", "Decentralization"] -draft: false ---- - -With the next batch of DeFi protocols reviewed, including Aave, Compound, Uniswap and more, we have identified a number of areas in the DeFiScan methodology that require clarifications and/or improvments. - -In this post we discuss the following updates: -- **Autonomy risk scores to account for decentralization of protocol dependencies** -- **Security Council to mitigate insufficient Exit Windows in onchain governance** -- **Security Council requirements to shift from "non-team" to "non-insider" rule** - -These updates are implemented in the DeFiScan methodology immediately and applied to current and future reviews. - -## Autonomy risk scores - -The Autonomy dimension captures risks from centralization in protocol dependencies. Such dependencies include oracle price feeds in lending protocols, the collateral asset in a CDP, and any other third-party infrastructure that a DeFi protocol is integrated with. - -In this update we have revised the centralization risk scores associated with a protocol dependency to reflect **the risk of failure of a protocol dependency due to centralization in the dependency itself**. -The updated Autonomy risk scoring methodology thus builds on the existing assessment of the severity of a dependency failure: - -- High severity: a failure of the dependency may result in the theft or loss of user funds -- Medium severity: a failure of the dependency may result in the theft or loss of unclaimed yield or may otherwise materially change the expected protocol performance -- Low severity: No dependencies or a failure cannot materially change the expected protocol performance - -The methodology then continues to assess centralization of the dependency itself: - -- Highly centralized: Stage 0, or equivalent, dependency -- Moderately centralized: Stage 1, or equivalent, dependency -- Decentralized: Stage 2, or equivalent, dependency - -*Note that the dependency itself may not necessarily be a DeFi protocol with an associated Stage score. In this case, centralization of the dependency is assessed based on equivalent criteria where possible.* - -These two scores, the severity of a dependency failure and the centralization of the dependency itself, are then combined into an Autonomy risk score according to the table below. Thereby, the risk from dependencies associated with a high severity of a potential failure can be mitigated by decentralizing control in the dependency. Thus, a DeFi protocol may improve its Autonomy score by carefully selecting dependencies that are decentralized. - - - - - - - - - - - - -
High - Medium - Low -
Dependencies may cause theft or loss of user funds AND exhibit Stage 0, or equivalent, centralization - Dependencies may cause theft or loss of unclaimed yield, or may otherwise materially change the expected protocol performance, OR dependencies exhibit Stage 1, or equivalent, decentralization - Dependencies (if any) cannot materially change the expected protocol performance, OR dependencies exhibit Stage 2, or equivalent, decentralization -
- -As an example, consider a lending protocol that relies on an external oracle price feed. If this feed fails, e.g. by pushing an asset price of 0 due to an operational error or the oracle system being comprimised by malicious actors, user funds may be lost or frozen thus earning the lending protocol a "High" severity score. The lending protocol has two options to improve its Autonomy score: -1. Implement price validation rules and fallback mechanisms in case of an "invalid" price pushed by the oracle feed -2. Integrate with "sufficiently" decentralized oracle systems to ensure respective risks are mitigated - -Similar to the Upgradeability risk dimension, here centralization of the dependency refers to the ability to individuals or groups of individuals to control critical permissions. For the oracle system in the example, this can mean that asset prices are determined by a single party or a single party, or group of parties, controlling contract upgrades. - -Hence, DeFi protocols effectively inherit centralization risks of their dependencies. This concept is very similar to how DeFiScan already translates centralization risks exhibited by the underlying chain. - -## Role of Security Council in onchain governance - -The Security Council is used as an acceptable measure to mitigate Upgradeability risks and enable a DeFi protocol to reach Stage 1 decentralization. - -So far, the framework allowed a DeFi protocol with "High" Upgradeability risk score, earned due to the existence of permissioned functions with a potential impact of *theft or loss of user funds*, to achieve Stage 1 decentralization if control over these permissions was transferred to a Security Council. Thereby, the requirement to protect ciritical control in the DeFi protocol with an Exit Window was effectively overruled by the existence of the Security Council. - -With this update, we expand the role of the Security Council to also offer mitigation to the risk of an insufficient Exit Window in an onchain governance system. Specifically, if permissions resulting in a "High" Upgradeability risk score are controlled by an onchain governance system with an Exit Window of less then 7 days, then a **Security Council must have the ability to veto proposals** for the DeFi protocol to reach Stage 1. - -As a result of this update, the Stage 1 requirements change to: -- '✅ At least a "Medium" risk score for Chain, Autonomy, Accessibility' -- '✅ IF Exit Window receives "High" risk, THEN a Security Council must be in place with ownership of or veto over permissions' - -This setup offers similar protections to users than if permissions were controlled by the Security Council. At the same time, it allows DeFi protocols to already initiate steps towards fully handing over control to onchain governance and Stage 2 decentralization. - -## Security Council requirements - -The objective of the Security Council requirements is to establish a robust, intermediate, governance structure over (critical) protocol permissions. As part of these requirements we have outlined a rule where at least 50% of the signers need to be "non-team" members. Combined with the 51% signer threshold, this results in an update of the protocol to be confirmed by at least 1 "non-team" signer. The objective of this rule is to enforce an outside perspective on each protocol update and reduce the risk of "the team" to push an unintended or malicious update. - -With this update, we now expand the requirements for a Security Council to include **at least 50% non-insider signers**. The shift from "non-team" to "non-insider" is motivated by a lack of clarity around the term "team" and a push to strengthen the integrity of a Security Council as an objective and robust intermediate governance unit. The latter is also informed by various discussions with DeFi teams and (recent) observations on governance practices. - -The updated Security Council requirements thus are: -- At least 7 signers -- At least 51% threshold -- At least 50% non-insider signers -- Signers are publicly announced (with name or pseudonym) - -Thereby, we define an "insider" as any party of the "inner circle" of individuals or entities developing, maintaining and operating the protocol, such as the "team members" or a company, and its employees, mandated to perform certain services. On the other hand, an "outsider" thus is any individual or company free of a direct conflict of interests. - -## Affected DeFiScan reviews - -No existing review is affected by this update. diff --git a/content/english/blog/defiscan-update-methodology.md b/content/english/blog/defiscan-update-methodology.md deleted file mode 100644 index 648dce8..0000000 --- a/content/english/blog/defiscan-update-methodology.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: "DeFiScan: Updates to the methodology" -meta_title: "" -description: "We discuss updates and clarifications on the DeFiScan methodology." -date: 2024-12-12T12:00:00Z -image: "/images/articles/defiscan-announcement.png" -categories: ["Policy"] -author: "nilsbundi" -tags: ["DeFiScan", "DeFi Risks", "DeFi Maturity", "Decentralization"] -draft: false ---- - - -> 🚨Update (2024-12-27): We align the terminology on protocols not meeting (all of) the Stage 0 requirements with L2Beat's "Others" category that was recently [introduced](https://medium.com/l2beat/framework-update-l2-projects-recategorization-5d43b0d1fe50). All other changes in the methodology remain unaffected by this update. - -In October we have introduced DeFiScan - a new framework and database for the analysis and monitoring of the maturity and risks of DeFi infrastructure in a verifiable manner. - -Within the first weeks we have assessed and published reviews on various DeFi protocols on the DeFiScan [website](https://defiscan.info). While conducting the analyses, we identified a number of aspects that require clarification or improvement to adequately understand and reflect the maturity of a DeFi infrastructure. - -In this post, we present these learnings and enhancements to the DeFiScan framework. Finally, we discuss how the updates affect the results for the existing protocol reviews. - -## Failure to meet Stage 0 requirements - -The Stage 0 requirements set some fundamental properties common to all DeFi protocols. The objective is to define the basic technological requirements based on which the maturity of DeFi protocols can be assessed. Any protocol not fulfilling these requirements A) is not considered a blockchain-based, "financial" application, B) lacks a "decentralized" basis, or C) cannot be assessed because important information is not publicly available. - -We find two challenges with this: - -1) In a number of cases, we found that protocols fail to meet a subset of the requirements simply because of an oversight or not being aware of the significance of it. As an example, we found reputed projects which are clearly built and operated following the outlined principles but e.g. missed verification of a smart contract. While the analysis cannot be completed in this case, the existing results can still add value to users. - -2) The classification of non-DeFi protocols is implicit rather then explicit. Because DeFiScan only analyzes protocols that fulfill the Stage 0 requirements, users have no information on "Other" protocols and the reason why they fail the Stage 0 "test". Listing "Other" protocols and the requirements they fail to meet makes this classification explicit and adds further transparency. - -**Updates to the methodology** - -In order to address these challenges, we introduce a new protocol category, "Others", which is assigned to protocols meeting only a subset of the Stage 0 requirements: - -* ✅ Blockchain-based, financial technology -* ❌ Assets are not in custody by centralized entity -* ❌ Public documentation exists that outlines the protocol and its expected performance -* ❌ Source-available codebase -* ❌ Verified contracts - -In other words, protocols characterized as a "Blockchain-based, financial technology" but NOT meeting any of the other Stage 0 requirements are now categorized as "Others". Protocols in the "Others" category thus either miss an adequate technological basis on which further decentralization is possible or their decentralization stage cannot be evaulated due to a lack of public information. - - -## Defining the protocol scope - -Often times DeFi protocols consist of different "components" representing different abstraction layers. It is commont to separate these into two main groups, the "core" and "peripheral" contracts. The core contracts implement the main state and business logic of the DeFi protocol while the peripheral contracts add additional functionality that simplifies users interactions and overall UX. - -We have thus engaged in many constructive conversations around which parts of a DeFi protocol are to be considered "in scope" for the analysis vs which are "out of scope". While we were not able to identify a "one-size-fits-all" answer to this question, we here provide a definition of the protocol scope that we found very usefull in most cases. - -**Updates to the methodology** - -The scope of a DeFi protocol relevant to analyze its stage of decentralization is defined as - -*A set of smart contracts that:* -- Is tightly integrated, or interacts through various cross-contract calls -- Forms a cohesive UX where all contracts combined effectively give access to the underlying financial service -- Is developed, maintained and marketed by the same team - -This definition implies that the protocol scope does not only include the core contracts but also peripheral contracts if users effectively cannot access the protocol without these and if they are developed, maintained and marketed as part of the offering by the same team. - -## Impact of missing Exit Window - -An important dimension of the DeFiScan framework is the *Exit Window*. It ensures that protocol upgrades and parameter updates are delayed by a certain period within which users are able to safely withdraw funds or otherwise exit their positions in case of an unwanted change. - -Currently, the framework applies scores in this category in isolation from the underlying changes, that can be made to the protocol and should be delayed by the Exit Window. That means, an Exit Window score of "High" risk is assigned irrespective of the potential impact of a protocol update. This can result in an unproportional overall risk score compared to the effective impact of existing protocol permissions. - -**Updates to the methodology** - -Instead of assigning the Exit Window risk score in isolation, the methodology now couples the remaining risks, due to the existence or absence of an Exit Window, to the achieved Upgradeability score of a protocol. - -Specifically, the Exit Window risk score is applied as follows: - - - - - - - - - - - - -
High - Medium - Low -
Upgradeability score is "High" AND permissions are NOT protected with an exit window or the exit window is less than 7 days - Upgradeability score is "Medium" OR permissions are protected with an exit window of at least 7 days - Upgradeability score is "Low" OR permissions are transferred to an on-chain governance process AND protected with an exit window of at least 30 days -
- -This means that the Exit Window score is based on the Upgradeability score and can improve the same if appropriate governance and update delay functions are implemented. Thereby, the Exit Window score reflects remaining risks relative to the potential impact of the underlying permissions. - -## New DeFiScan results - -Based on the changes to the DeFiScan framework, a number of protocol reviews and results are updated: - -- Aerodrome: Exit Window score is now "Medium" (previously "High") -- Velodrome-v2: Exit Window score is now "Medium" (previously "High"), Stage is 1 (previously 0) -- Maverick-v2: Stage is now "Review" due an unverified contract (MaverickV2Factory) \ No newline at end of file diff --git a/content/english/blog/ef-grants.md b/content/english/blog/ef-grants.md deleted file mode 100644 index c6e0274..0000000 --- a/content/english/blog/ef-grants.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "The Ethereum Foundation allocates a grant to DeFiScan" -meta_title: "" -description: "With the support of the Ethereum Foundation, DeFiscan will be able to pick up the pace to cover ever more protocols." -date: 2025-03-25T08:00:00Z -image: "/images/ef-grants-cover.png" -categories: ["Announcement"] -author: "tokenbrice" -tags: ["DeFiScan, Grants"] -draft: false ---- - -The Ethereum Foundation has allocated a grant to The DeFi Collective to develop further [DeFiScan](https://www.defiscan.info/), DeFi’s first framework that formalizes the decentralization stages of DeFi technology. - -It will enable us to speed up ongoing efforts, with the **North Star goal of maximizing DeFiScan's percentage of DeFi TVL coverage**. The funds received will help us onboard one full-time contributor dedicated to DeFiScan, scale up our community submission program, and raise awareness of DeFiScan. - - -### Growing DeFiScan’s team with dedicated full-time contributors - -DeFiScan is a public good dedicated to providing transparency on DeFi protocols’ level of decentralization. Much like L2BEAT pioneered extremely high-quality reviews on the decentralization of L2 chains, we strive to provide the most accurate and reliable information on DeFi protocols. DeFiScan aims to provide transparent, unbiased information on DeFi protocols' decentralization levels, enabling users to make informed decisions about protocol usage and associated risks. We are building the tool we would have loved to have when we started exploring DeFi. Our North Star is to reach 95% of the total DeFi TVL covered with qualitative, accurate, unbiased, and up-to-date reviews. - -Reviewing the decentralization of DeFi protocols is no easy feat. One needs to have a deep level of expertise and put in the right amount of time to produce an accurate and unbiased review of one protocol. Each review needs to be double-checked by multiple experts before it is published to ensure neutrality. - -To progress towards our North Star, we are working both with internal contributors and harnessing the power of the community, and we will continue reinforcing these two paths to producing high-quality content: - - - -* We are hiring two full-time contributors to DeFiScan. Preference will be given to profiles that have already submitted and successfully merged one or several DeFiScan reviews. If you are interested, grabbing our attention is straightforward: show us that you can do the work. -* Community members can also participate by submitting individual reviews. The first submission will be rewarded with a minimum of 1,000 LUSD and up to a new maximum payout of 3,000 LUSD per review, reflecting the complexity of reviewing large, intricate codebases like Aave. We will publish a blog post detailing the revised review program shortly. - -Finally, we want to keep investing in awareness, education, and outreach activities. More specifically, that means: - - - -* Graphic redesign of the DeFiScan website, Twitter-optimized review social sharing card, and additional infographics. -* Event attendance & presentation: representing DeFiScan at events (ETH Belgrade, ETH Bucharest, ETH Zurich, ETHCC and others Ethereum, DeFi events), and organizing events like workshops. - - -### What it means for DeFiScan and DeFi - -Following the investments mentioned above, we can increase the pace of review publication. **We aim to publish 25 reviews over the** **next 6 months**, covering currently missing DeFi staples such as Aave v3, Lido v3, Uniswap v4, Pendle, or Maker/Sky. - -Launched in October 2024 with 7 initial reviews**, the total has already doubled to 14 in ~5 months**, and we’ve learned tons about the reviewing process and the intricacies of applying the DeFiScan framework. - -With increased resources and awareness, DeFiScan will have all it needs to grow its coverage, awareness, and mindshare in the DeFi ecosystem. - -All major protocols will eventually be reviewed, and with their decentralization status neutrally documented, there will be no more surprises. The DeFi Collective's support of stage 1 and 2 protocols means that **all incentives are now in place to maximize the number and TVL share of maximally decentralized protocols.** - -We are thankful to the Ethereum Foundation for proactively recognizing the value of the technical information delivered by DeFiScan.This support is a testament to DeFiScan's pivotal role in driving the decentralization of the DeFi landscape, and we are honored to be advancing this mission within the Ethereum ecosystem. We are also thrilled to see this grant implemented shortly after the [Ethereum Foundation’s first sizable deployment of assets](https://x.com/ethereumfndn/status/1889978208986280031) in the DeFi ecosystem. - -The future of DeFi looks… ever more transparent! diff --git a/content/english/blog/make-defi-decentralized-again.md b/content/english/blog/make-defi-decentralized-again.md deleted file mode 100644 index 92485e2..0000000 --- a/content/english/blog/make-defi-decentralized-again.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: "Make DeFi Decentralized (Again)" -meta_title: "" -description: "We discuss the challenges of defining decentralization in DeFi, explore the trade-offs when trying to achieve decentralization and propose steps to advance decentralization." -date: 2023-11-09T13:00:00Z -image: "/images/articles/make-defi-decentralized-again.jpg" -categories: ["Research"] -author: "nilsbundi" -tags: ["Research", "Decentralization", "Policy"] -draft: false ---- - -Decentralized Finance, or DeFi, has ushered in a profound transformation within the financial industry. It offers a way to enhance the conventional financial infrastructure with immutable programs that take the role of traditional intermediaries. The underlying objective of this movement is to **enhance inclusivity, transparency, and security of financial services** as these are delivered by open and predictable programs through a public infrastructure. - -As the DeFi ecosystem experienced rapid growth in the past years, it has embraced concepts that foster scalability and agility in tailoring its services to user demands. This has effectively translated to introducing central control points within DeFi programs or the underlying settlement layer. This evolution has been accompanied by the innovation of governance structures designed to exert this control in a decentralized manner. - -The total value locked (TVL) in DeFi programs stands at approximately $50 billion today, with an all-time high of about $200 billion in 2021, according to [Defillama](https://defillama.com/chart/chain/All?&include_borrowed_in_tvl=true&theme=dark). Notably, the majority of this TVL is overseen by some governance structure, sparking discussions about the actual degree of decentralization in the DeFi services industry. Indeed, multiple pseudo-decentralized DeFi services have suffered losses in the hundreds of millions of consumer funds due to exploits of vulnerabilities introduced by centralization. - -As a response, **policymakers and regulators around the globe increasingly engage with the DeFi services industry**, seeking to implement appropriate regulations to protect consumers from the risks exposed by DeFi services. Therefore, two critical questions have emerged. First, what entails decentralization in DeFi services? Secondly, how can the DeFi services industry respond to the risks inherent in the services offered and better protect consumers? - -This article delves into the first question and the challenges we encounter when trying to capture the concept of decentralization in DeFi programs and computer systems in general. While the question seems trivial at first, it turns out to be hard to answer as the concept of decentralization in (computer) systems is a complex one. We further explore the trade-offs faced when trying to achieve decentralization. Finally, we propose steps to establish DeFi services as a genuinely decentralized force, fostering a more inclusive, transparent, and secure financial ecosystem. - -## Decentralization is a spectrum - -Decentralization as a property can be found in many systems, including biology, economics, and, of course, computer science. Interestingly, it is hard to find a generally accepted definition of the property. Colloquially, decentralization characterizes a system that has no single point of failure. Or, in other words, a system design where no single agent or component has a monopoly over a (critical) system function. A simple model that is sometimes drawn is that a decentralized system can be split into two parts, and both parts continue to function independently. This is an effective but, of course, informal definition that fails to account for the **different layers of decentralization**. Vitalik Buterin attempts a more comprehensive characterization of decentralized (computer) systems in this [article](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274). Buterin outlines three dimensions along which computer systems exhibit characteristics of decentralization: -- **Architectural (de)centralization** or the number of physical computers a system is made of and the fault tolerance the system has -- **Political (de)centralization** or the number of individuals (or groups of individuals) needed to exercise control over the computers that make up the system -- **Logical (de)centralization** or whether the system’s interface and data structures are a single, monolithic unit or function as individual, independent units - -![Dimensions of decentralization](https://miro.medium.com/v2/resize:fit:720/format:webp/1*U2UuIGNa-RQZFSBFWDN3ew.png "Dimensions of decentralization according to Vitalik Buterin" ) - -*Figure 1: Dimensions of decentralization in computer systems. Source: [Buterin](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274)* - -Buterin's characterization points to the realization that decentralization is not a binary property, but (computer) systems have to be classified on a decentralization spectrum. On the far left, we find fully centralized systems such as traditional corporations or a centralized database. On the contrary, the far right of the spectrum is characterized by fully decentralized systems like BitTorrent or the English language. In between, there is a wide range of system characteristics that exhibit features of partial decentralization. - -In a more rigorous [analysis](https://www.scitepress.org/Link.aspx?doi=10.5220/0009892405050512), Harry Halpin explains the decentralization spectrum in terms of *centralized*, *federated*, and *decentralized* architectures. While proposing this discrete scale for the spectrum, Halpin also acknowledges a degree of ambiguity around these terms when it comes to mapping them to real-world computer systems. - -Given the ambiguity around the characteristics of decentralized systems in general, it does not come as a surprise that **no clear definition for decentralization in DeFi systems has emerged** so far. At the same time, the degree of centralization of DeFi systems has increasingly gained attention recently. On the one hand, this can be explained by significant losses of consumer funds following exploits of vulnerabilities in DeFi systems and the resulting uncertainty around their security. On the other hand, policymakers and regulators have increasingly taken an interest in the subject, resulting in new regulations that, once implemented, demand clarification of the concepts. - -{{< notice "note" >}} We will not be able to define decentralization in DeFi systems in this article. Still, we can draw some conclusions from the discussion that may help develop a definition in the future: - -- **Decentralization is a spectrum**: decentralization is not a binary property but comes in different shapes -- **Decentralization is multi-dimensional**: decentralization is characterized along different dimensions of a (computer) system -- **Decentralization is dynamic**: decentralization is not a static property, but systems rather change their characteristics, including their decentralization properties, over time -{{< /notice >}} - -## Decentralization has a price - -Decentralization is hard. As a DeFi project, as the DeFi industry, we have to be aware of the price we pay to achieve decentralization. In general, a tradeoff exists between decentralization and other desired properties of a system. For instance, the [Scalability Trilemma](https://vitalik.ca/general/2021/04/07/sharding.html) argues that a blockchain system has three desired properties, *Scalability*, *Security*, and *Decentralization*, but can only ever achieve two of these simultaneously. In other words, blockchain systems pay a price for being decentralized: Either the system is decentralized and secure, but it will not be scalable. Or the system is decentralized and scalable, but it cannot be secure at the same time. - -![Scalability Trilemma](https://vitalik.ca/images/sharding-files/trilemma.png "Scalability Trilemma according to Vitalik Buterin" ) - -*Figure 2: Trilemma faced by Blockchain Systems. Source: [Buterin](https://vitalik.ca/general/2021/04/07/sharding.html)* - -Similarly, the [Stablecoin Trilemma](https://static1.squarespace.com/static/564100e0e4b08c9445a5fc5d/t/5c71e43ef9619ae6c83c30af/1550967911994/The+State+of+Stablecoins+2019_Report+2_20_19.pdf) says that stablecoins, one of the main DeFi applications in terms of TVL, face a tradeoff as they attempt to achieve the desired properties of *Stability*, *Efficiency* and *Decentralization* (in the original paper linked above the properties were described with the terms *Collateralization*, *Capital Efficiency* and *Decentralization*). The trilemma argues that a stablecoin can only achieve two of these three properties simultaneously. Thus, stablecoin systems pay a price for achieving decentralization, which is that they either are unstable because the stablecoin chooses to be decentralized and efficient, or they are inefficient if the system optimizes for being decentralized and stable. - -![Stablecoin Trilemma](https://cepr.org/sites/default/files/styles/flexible_wysiwyg/public/image/FromMay2014/ganesh13mayfig1.png?itok=i6kVoVMH "Stablecoin Trilemma according to Viswanath-Natraj and Amit Chaudhary") - -*Figure 3: Trilemma faced by Stablecoin Systems. Source: [Viswanath-Natraj and Amit Chaudhary](https://cepr.org/voxeu/columns/algorithmic-stablecoins-and-devaluation-risk)* - - -We find similar trade-offs in other DeFi systems, such as staking services, oracle systems, lending markets, and exchanges. Fundamentally, **the choice for decentralization means to give up control over a system**. A (fully) decentralized system can thus never have a central point of control, no matter whether control is exercised by an individual or groups of individuals. The implication is that decentralized systems must implement autonomous mechanisms to respond to all sorts of (adverse) activity. This requires more careful design, planning, and implementation, resulting in higher engineering costs and longer go-to-market times. Decentralized systems also often suffer from certain unattractive features, such as higher transaction costs and slower finality - like DeFi services running on a decentralized and secure (but not scalable) blockchain compared to services that run on a secure and scalable (but not decentralized) blockchain. - -## Advancing decentralization - -The DeFi industry has a considerable journey ahead to evolve into an inclusive, transparent, and secure public infrastructure that forms the backbone of financial services, allowing FinTechs to build new financial products on top that cater to a broader consumer base. A key challenge lies in our understanding of DeFi's foundational principle, that is decentralization. - -Without a clear and widely accepted framework for this crucial foundation, the DeFi industry lacks its guiding principles and an effective communication tool for policymakers, regulators and the broader public to appreciate the distinct characteristics decentralization has to offer for an inclusive, transparent and secure financial infrastructure. On a positive note, recent regulations such as [MiCA](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica) in Europe in fact recognizes the different role of (truly) decentralized financial services and proposes a differentiated approach to regulation. Credit is also due to advocacy groups like the [European Crypto Initiative](https://eu.ci) and [Coin Center](https://www.coincenter.org), which have played a pivotal role in communicating DeFi's informal decentralization principles to policymakers. - -With this recogniton, the need for clarity becomes even more prevalent as the clarity offered by these new regulations critically depends on an appropriate implementation of the decentralization principle in the first hand. Whether it is to harness the benefits or to ensure compliance with specific regulations, furthering our understanding of decentralization is of paramount importance for the prosperity of our industry. - -{{< notice "info" >}} To advance the decentralization of finance, the DeFi Collective has taken the initiative to develop decentralization principles. We have identified three main objectives such principles should have - -- **Development guidelines**: support DeFi architects and developers in making educated design decisions -- **Transparency framework**: provide a framework to assess and make transparent centralization vectors in DeFi services -- **Communication tool**: enable the DeFi industry and its advocates to more effectively communicate to its stakeholders -{{< /notice >}} - -## Conclusion - -Decentralized Finance has experienced a steep growth trajectory in its early years. To continue this trajectory, the DeFi industry has to overcome several challenges. Most importantly, we need a clearer understanding of and guidelines around its core principle, decentralization. The DeFi Collective initiated work to fill this gap and lead the way for DeFi to become the inclusive, transparent, and secure public infrastructure it aspires to be. \ No newline at end of file diff --git a/content/english/blog/software-licenses-for-defi.md b/content/english/blog/software-licenses-for-defi.md deleted file mode 100644 index 6718152..0000000 --- a/content/english/blog/software-licenses-for-defi.md +++ /dev/null @@ -1,283 +0,0 @@ ---- -title: "Software licenses for DeFi" -meta_title: "Software licenses for DeFi" -description: "This article dives into software licenses for DeFi projects, outlining the basics before looking at various software licenses - in particular the Business Source License (BSL) - and their use in DeFi" -date: 2024-08-15T11:00:00Z -image: "/images/software-licenses-for-defi/software-licenses-for-defi-banner.png" -categories: ["Research"] -author: "florianprantl" -tags: ["Research", "Open source", "Collective"] -draft: false ---- - -In DeFi, we regularly observe clashes between ideals and realities; the topic of software licensing models for DeFi protocols being one of the latest and most prominent examples. In DeFi's early days, the consensus was to use fully open source licenses to align with DeFi's ideals of openness and transparency. However, DeFi staple protocols such as Uniswap or Aave have recently opted for more restrictive licenses. Others such as EigenLayer or Liquity are following suit. - -This article dives into software licenses for DeFi projects, outlining the basics before looking at various software licenses - in particular the Business Source License (BSL) - and their use in DeFi. - - -## Copyright and software licensing - - -### What is copyright? - -Copyright is a type of intellectual property right that protects creations of the human mind, unlike tangible assets like real estate or goods. In today’s world, IP is omnipresent and often a company’s IP value is much higher than the value of its tangible assets. Copyright is crucial for software companies as it grants protections and various rights to their software. It is created automatically without needing registration or formal procedures such as a trademark registration or patent filing. See [here ](https://www.lexr.com/en-ch/blog/intellectual-property-basics-entrepreneurs/)for more information about IP basics for entrepreneurs. - -_Important: Copyright only protects the source code of the software. Copyright does not protect the underlying ideas and concepts of the work. Most traditional software companies therefore do not rely on copyrights, but keep the source code secret (closed source). _ - - -### How do software licenses work? - -Imagine the copyright as an imaginary bouquet of flowers, with each flower representing a different right associated with your protected work. For instance, there might be a rose for reproduction rights, a lily for distribution rights, a daisy for modification rights, and a tulip for commercialization rights, and so on. Collectively, these flowers form your complete copyright bouquet. - -![alt_text](https://raw.githubusercontent.com/deficollective/deficollective.github.io/main/assets/images/software-licenses-for-defi/flower-pepe.webp) - - -You have the flexibility to manage your bouquet in various ways. You can give away your bouquet (entirely or partially) and give up your right to use it (transferring your copyright) or simply give away duplicates of your flowers (licensing your copyright). You can also specify whether you want to give the same duplicate to multiple persons or just to one (_exclusivity of the license)_, how long they can keep the flower (_term of the license)_, where they can use it (_geographical scope of the license)_, and so on. This is essentially what software license agreements do. - - \ -There are two common types of software licenses that you should know for now: - - - -1. Proprietary software licenses: Under proprietary licenses, the software is typically not available in source code form. Licensees are granted limited rights to use the software, often with restrictions on copying, modifying, and redistributing it. Examples include Microsoft Windows and Adobe Photoshop. -2. Free and open source software (FOSS) licenses: FOSS licenses go distinctively further; they allow you to copy, modify, and/or distribute the software, even for commercial use (hence provide more freedom). They are typically divided into permissive (MIT) and copyleft licenses (GPL). Copyleft mandates that you distribute derived works under the same license, ensuring the same freedoms down the road. Permissive licenses carry minimal restrictions, usually requiring only prominent attribution and retention of the copyright notice. - - -## Business source license (BSL) - -The business source license (BSL) is a standard software license which sits in the middle between FOSS and traditional proprietary licenses. The concept originates from the MariaDB Corporation, which provides the template license text, holds respective trademarks and maintains an FAQ about BSL [here](https://mariadb.com/bsl-faq-mariadb/). - - -### Non-production use | additional use grant | additional commercial license - -Under BSL, users are granted a license to use the software in a 'non-productive manner'. This means any environment not delivering significant value to a business (e.g., forking a protocol even without direct monetization such as adding a token would likely be productive use already). - -BSL also allows licensors to specify additional use grants for productive or commercial purposes under certain limitations, usually without payment. Uniswap has done this for v3 [here](https://app.ens.domains/v3-core-license-grants.uniswap.eth?tab=records), whereby they had UNI holders vote on the distribution of such additional use grants. - -Licensors can also grant an additional commercial license against payment (and any other terms the parties agree to) on top of BSL. This provides a pathway for developers to monetize their software until the transition of BSL to the designated FOSS license (see below). - - -### Source available - -To avoid confusion in terminology, BSL is not a FOSS license or open source. However, it is a 'source available' license, meaning the source code is publicly accessible and verifiable, typically through a public GitHub repository. - - -### Time-delayed transition to open source license - -A key feature of BSL is its built-in transition to a FOSS license. After a predetermined period (max. 4 years), the software automatically transitions to a recognized open source license ('change license'), such as the GNU General Public License (GPL), the MIT or the Apache License. The mechanism ensures that the software will eventually be freely available for any use (still subject to the respective FOSS license). - -The transition can be accelerated. Staying with the example of Uniswap, UNI holders are able to vote on the accelerated transition from BSL to GPL. - - -## BSL in decentralized finance (DeFi) - -In March 2021, Uniswap announced the third iteration of its AMM protocol, with the core protocol published under BSL 1.1. Uniswap referred to the BSL as a 'time-delayed GPL-2.0-or-later license', stating that the BSL would transition to GPL 2.0 (or a later version) upon April 1, 2024. For that initial duration of 2 years, however, any productive | commercial use of the v.3 source code would be prohibited. Uniswap did, however, involve the UNI holders by allowing them to vote on granting additional use grants to different projects (giving those projects the right to use the codebase productively despite the BSL) and voting on expediting the transition to GPL 2.0. - -After Uniswap v3, many other DeFi protocols have started to experiment with BSL: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- copyright holder - license - productive | commercial use - additional use grant - change license - change date -
Uniswap v3 - Uniswap Labs - GPL 2.0 -

-(formerly BSL 1.1) -

yes - n/a - n/a - n/a -
Uniswap v4 - Uniswap Labs - BSL 1.1 - no - Any uses listed and defined here - GPL 2.0 (or later version) - The earlier of -
-(i) 15 June 2027; -
-(ii) a date specified here -
Aave v3 - Aave - MIT -

-(formerly BSL 1.1) -

yes - n/a - n/a - n/a -
Compound v3 - Compound Labs - BSL 1.1 - no - Any uses listed and defined here - GPL 2.0 (or later version) - The earlier of: -
-(i) 31 December 2025; -
-(ii) a date specified here -
Morpho Blue - Morpho Association - BSL 1.1 - no - Any uses listed and defined here - GPL 2.0 (or later version) - The earlier of: -(i) 1 January 2026; -
-(ii) a date specified here; -
-(ii) upon the activation of the setFee function Morpho Blue Core’s applicable protocol smart contracts deployed for productive use. -
Eigenlayer - Layr Labs, Inc. - BSL 1.1 - no - n/a - MIT - 1 May 2025 / -
-6 February 2027 -
Liquity v2 - not published yet -
Curve - No license (see here) -
- - - - - -### Compromise on decentralization? - -Probably the most discussed point in relation to BSL in DeFi is the question whether BSL is 'anti-DeFi' and against the core values of the space. Many DeFi projects that implement BSL are themselves built on resources provided by the open source community in the first place. Abandoning this is seen by some as an attack on the underpinning values of DeFi. - -With respect to the values discussion, this certainly holds weight. BSL is not open source, and should also not be portrayed as such. Additionally, BSL can potentially pose a barrier to further innovation in the space (see below). However, a few points to consider: BSL is arguably still 'better' from a values-perspective than proprietary licensing or publishing under no license at all (as e.g., Curve has done). BSL provides a clear and deterministic path to FOSS with the automatic transition to the FOSS change license. With respect to decentralization, a core value lies in transparency, which BSL does not compromise on. Due to source-availability in BSL, users are still fully able to review and independently verify source code. - - -### Alternative monetization for your product - -Monetization in DeFi primarily happens in two ways: You issue and sell a token (and subsequently profit from higher valuation, additional sales, etc.). Further, you implement some form of transaction, protocol, frontend, etc. fee. The fee distribution typically happens through a dedicated rev-share token ('lock token XYZ on the protocol ABC to receive fees'), through governance (voting on fee distribution), or by routing fees to a reward address directly controlled by the project. - -BSL offers an alternative monetization possibility: During the initial period before transition to FOSS, people are prohibited from forking your protocol. However, you are free to give out _separate _licenses to projects to use or alternate your protocol code in return for payment to you. - -In practice, this means signing an additional license agreement with potential licensees that defines whether they can exclusively use the protocol code (e.g., exclusivity for a certain chain), how long the license lasts, what the payment is, etc. These additional license agreements don’t have to be the same for each partner, but can be tailor-made. To stay with the above analogy, you can pick and choose the flowers you want to give out. - -To be fair, this monetization approach is evolving and largely untested in DeFi. It resembles a traditional whitelabel licensing approach found in web2. One well–known issue with that lies in the enforcement of potential license infringements, which is notoriously difficult. Assuming you will grant some sort of exclusivity to your license partners, that exclusivity will be a large part of the value of the license, and your partners will rely on you enforcing this. The legal system, which is still very much bound by jurisdictions and country borders, can quickly reach limits when faced with enforcing your rights in a court (which court?) against (anon) persons sitting anywhere in the world. Also, BSL licenses are less battle-tested in courts and do not have the support with license infringements that many foundations and non-profits provide with respect to FOSS licenses. - - -### Scaling your product - -As the DeFi landscape rapidly expands with alternative L1s, L2s, L3s, LXs, DeFi on Bitcoin, etc., competition between projects to attract builders, consumers, and liquidity is intensifying. One could argue that the market will naturally resolve this by ultimately favoring protocols that provide the most value to users. FOSS supports this notion by ensuring free competition, allowing anyone to freely fork a protocol and enhance it to offer more value. However, we need to recognize the downsides of this approach as well: - -From a user perspective, while the end goal is to have the best product, navigating through new forks (with sometimes confusing or misleading attestation to the original project up to outright scams), can be challenging and risky. BSL offers a more controlled environment for initial testing and subsequent scaling of the protocol, which should be in the interest of the end user’s safety. - -From a project perspective, substantial efforts can be put in a protocol just to see it fragmented instantly through numerous low-effort forks. Uniswap has experienced this in the immediate forking of v2 by Sushiswap, who simply slapped a token onto their protocol. Here, BSL provides a (time-limited) moat to improve and materialize the project’s innovation and investments. People can’t simply copy paste your protocol on day 1 and siphon your liquidity, user base, etc. While, going forward, this is probably less of a concern for the well-established DeFi brands such as Uniswap or Aave, it is a real risk for smaller and lesser known projects. - -Another example is Liquity, who opted to pursue a BSL rather than go FOSS at the launch of its v2 protocol. The team has cited the lack of collaboration between the 35+ forks of its v1 protocol; the damage to users some of those getting exploited caused; and the cost to its own development team of needing to address unwarranted fears stemming from them. Altogether, these factors combined to leave value on the table that could have gone to users in the form of tangible incentives or heightened mindshare. - - -### Navigating pitfalls in DeFi regulation - -A notoriously overlooked point in the context of licensing models is their potential implications from a regulatory perspective. DeFi builders face an array of legal and regulatory uncertainties in their work. Simultaneously, regulators globally are getting more engaged in the topic of how DeFi should be defined (what is decentralized?) and how it should (or should not) be regulated. The regulatory topic is extensive and ongoing, so I won't discuss it in detail here. Nonetheless, it's important to be aware that a protocols licensing strategy (or more clearly: it's general monetization strategy) can be linked to regulatory risks: - -As outlined above, a typical monetization strategy lies in the combination of token sales and protocol revenue sharing mechanisms. (Public) Token sales are increasingly subject to regulatory scrutiny, which is part of the reason we have been seeing so many VC-funded projects launch without public sales through high FDV airdrops and CEX listings. The issue with revenue sharing mechanisms is more subtle: Dedicated revenue sharing tokens are very prone to security classification (those tokens are quite easily compared to securities with dividend- or interest-like payments). Additionally, ongoing management of these tokens (like managing liquidity for the token on different venues) can carry regulatory risk. Revenue sharing mechanisms outside a token may particularly raise regulatory questions about the decentralization of the protocol (the Swiss regulator, FINMA, has e.g., suggested that accrual of income from a DeFi application suggests lack of decentralization). - -BSL may offer the possibility to mitigate these pitfalls by shifting your business model closer to that of a web2 white labeling solution. However, this is untested and the regulatory landscape for DeFi is evolving quickly. The (very far reaching) VASP Guidance by FATF has, for example, previously suggested that whoever 'owns' a dApp could be considered a regulated VASP, whereby BSL could be an indication of such 'ownership' as opposed to an open source license. - - -### Impact on innovation in DeFi - -Your copyright protects the specific source code of your software, not the underlying idea or concept. This means that, in theory, any developer can create their own product based on the same concept without infringing on your copyright. They just need to write original code. - -However, in practice, it's challenging to differentiate between genuinely original work and work derived from copyrighted software. If sued, developers face a high legal risk if they cannot prove the originality of their work in court. To mitigate this risk, they would have to ensure their work is original, through rigorous and costly procedures like clean room design. Especially in the DeFi space, where developers are scarce and usually familiarize themselves with new DeFi building blocks, this can slow down the pace of innovation. - -On the other hand, one might argue that this practice could lead to more sustainable and long-term oriented innovation: At first, DeFi innovation thrived off a free and open forking practice. However, with money flowing in, we were seeing more and more lazy fork strategies along the lines of (1) forking a well known and battle tested protocol, skipping developing and auditing work, (2) spending all VC cash on KOLs, marketing and BD, (3) cashing out and abandoning the protocol, (4) rinse and repeat. This cycle drains money from the ecosystem and stagnates innovation. BSL is trying to introduce alternative ways to incentivize teams to build genuinely new DeFi solutions, which could ultimately lead to a more sustainable pace of innovation. - - -## Key Takeaways - -* DeFi is often faced with balancing ideals and practicality. The phenomenon is observed in software licensing models chosen by DeFi protocols, with a recent shift from Uniswap, Aave and others from FOSS (GPL, MIT, etc.) to BSL licenses. -* BSL is not an open source license. Rather, BSL is a middle ground between FOSS and proprietary licenses. BSL is restrictive for an initial period, and then mandates an automatic change to a FOSS license after max. 4 years. -* For effective decentralization, source availability is critically important to ensure transparency and allow users to verify code. FOSS and BSL licenses are both source available license types. -* BSL allows DeFi projects to experiment with alternative monetization models, beyond the typical token sale / revenue share token model to a more traditional whitelabel licensing model. -* BSL can provide a time-limited moat for projects to materialize upon their work and innovation in DeFi. This helps in fending off low-effort forks looking to make a quick buck by adding a token, and can help align the larger community around the project in a symbiotic way. -* BSL can be seen as a barrier to further innovation. However, judging from the reality of forking practices in DeFi, it is yet to be seen whether BSL cannot ultimately lead to a more long-term and sustainable (albeit slower) pace of innovation in DeFi. diff --git a/content/english/blog/the-great-unmasking.md b/content/english/blog/the-great-unmasking.md deleted file mode 100644 index a6c8255..0000000 --- a/content/english/blog/the-great-unmasking.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: "The Great Unmasking: let’s find out together how much De is in our Fi" -meta_title: "" -description: "How much De is in my Fi? Help the crowds figure it out and earn LUSD for it!" -date: 2025-01-08T05:00:00Z -image: "/images/the-great-unmasking.png" -categories: ["Campaign"] -author: "tokenbrice" -tags: ["DeFiScan", "Community Review Program", "The Great Unmasking", "Others"] -draft: false ---- - -“One of the best ways to achieve decentralization is to expose centralization.” - -– Julien Assange (on justice/injustice) - -“How decentralized is this really?” has been an age-old question in DeFi. Until now, it was up to each user to form their own opinion for each protocol: an exceptionally technically demanding full-time job. We’ve built DeFiScan precisely to address this, and enable anyone to get both a quick overview of the decentralization status of a given protocol (the five dimensions metrics and their respective risk level), and a full detailed and sourced rundown (the report). - -With 8 protocols already reviewed and 7 currently in the process, we’re thrilled to see the positive reception of the framework and its adoption amongst responsible builders who are now starting to self-review. However, we believe it’s time to scale DeFiScan further, with the **introduction of a new stage: Others.** - -**This program has been replaced by [the DeFiScan Bounty Program](https://deficollective.org/blog/defiscan-bounties/)**. - -### What does an “Others” decentralization stage mean? - -The DeFiScan framework has a few requirements to enable the analysis to be performed. Starting now, a review of Others grade will be published for the protocols that do not meet the stage 0 requirements. - - -#### Others = does not meet the stage 0 requirements - -Simply put, the five Stage 0 requirements are bare minimal practices that a protocol must observe even to be qualifiable of “DeFi: - - - -1. **Blockchain-based, financial technology** – else there is nothing for us to review. -2. **User assets are not in custody by a centralized entity** – else we can’t access the risk created by the centralized custodian. -3. **Public documentation exists that outlines the protocol and its expected performance** – having accurate and up-to-date documentation is not only a responsible practice but also facilitates the DeFiScan review of the protocol. -4. **Source-available codebase** – without access to the source code, the protocol is essentially a black box to its users and to us. -5. **Verified contracts** – another good practice that, in our case, enables us to ensure that the smart contracts reviewed are indeed the ones used by the live protocol instance(s). - -While these five requirements seem consensual and minimalist, many protocols do not meet them. Thus, we decided to explicit the Others stage to broaden the scope of analysis of DeFiScan; **on top of telling you *how much* “De” is your “Fi”, DeFiscan is now able to tell you if there is any “De”* at all***. - - -### Others Logic - -The Others stage has a special status in the framework, operating under a different logic. Stage 0, 1 and 2 are based on requirements to be met: if they are, the protocol is awarded the corresponding stage. Allocating a stage requires completing a full and exhaustive analysis of the protocol. Others, on the other hand, works more like eliminatory criterion: failing on any of the five requirements is sufficient to classify a protocol as Others, without conducting the full analysis (that cannot be conducted until the requirements are met). - -Our goal with this endeavor is not to shame and condemn such protocols but merely to explicit their decentralization status and provide a more comprehensive overview of the current landscape of blockchain-based financial technology. If a given protocol, initially classified as Others, was to be updated to meet the Stage 0 or above requirements, our team would be thrilled to update the review. Overall, the objective of the DeFiScan team remains to maximize the amount of maximally decentralized protocols, and providing clear unbiased information about decentralization stages is one of the best levers to pull to achieve such a result. - -Expliciting the Others decentralization stage will help to nurture a healthy competition for protocols to reach stage 0 or higher, and thus eventually establish stage 0 as a standard. - - -### Introducing: The Great Unmasking - -Introducing the Others stage also enables us to broaden the scope of who can contribute to DeFiScan. Finding an Others protocol simply requires proof that at least one of the five stage 0 requirements is not met. - -So to spice things up, we’d like once again to call to the community to contribute, and we will reward those who do so. **The Great Unmasking is an incentivized Others stage protocol discovery campaign**: any sourced and factual report of a Others stage, concerning a protocol that is not already reviewed, and **handling at least $10M of assets (TVL) on an EVM-chain** will be **rewarded with 100 LUSD**. To ensure broad participation in the campaign, submissions are limited to up to 5 per individual. In practice, that means finding: - -1. Critical unverified contracts -2. Assets in centralized custody -3. Essential function undocumented -4. Non-source available code - -For the first trial of the great unmasking, we are allocating a 10,000 LUSD budget, enabling to reward up to 100 submissions. If the campaign proves successful, we will happily scale it further. - -Submissionss are expected on [DeFiScan repository](https://github.com/deficollective/defiscan), and if you have any questions, hop on the [DeFiScan Discord channel](https://discord.gg/7RKxSJvvXM). - -We look forward to reviewing the community submissions and opening the great unmasking ball with a surprising finding: the first protocol for obtaining the dreaded Others grade is no less than… Uniswap V3 on Arbitrum! Indeed, Uniswap’s Arbitrum deployment harnesses unverified smart contracts for critical functions involved with the NFT LP positions (NFTDescriptor - 0x42B24A95702b9986e82d421cC3568932790A48Ec, Multicall - 0xadF885960B47eA2CD9B55E6DAc6B42b7Cb2806dB, and NonfungibleTokenPositionDescriptor - 0x91ae842A5Ffd8d12023116943e72A606179294f3). - -While it’s unlikely that it stems from ill-intent from the Uniswap team, having those contracts unverified prevents us from analyzing their code, and thus makes it impossible to conclude anything regarding the risk level they pose. We hope the contracts will be verified shortly, enabling the full analysis to be conducted. - -Meanwhile, all eyes are on you, DeFi enthusiasts and decentralization enjoyers: what other surprises are we to find? You tell us, and earn your share of the 10,000 LUSD!