History of PYTH

The History of PYTH: From Launch to Expansion

The history of PYTH is closely tied to the evolution of decentralized finance and the growing demand for high-fidelity, real-time market data on-chain. Unlike traditional oracles that rely on crowd-sourced price feeds, PYTH was designed to aggregate data directly from primary market participants, including exchanges and trading firms. This approach positioned it as a unique player in the blockchain oracle ecosystem.

Early Development and Initial Launch

PYTH was built to address a critical problem in DeFi: latency and reliability of on-chain price feeds. In contrast to other oracle solutions that primarily derive prices from aggregated public sources, PYTH's model relied on proprietary data contributions from institutional participants. While this model ensured high-accuracy data, it also raised early concerns about centralization and data accessibility.

The project was initially deployed on Solana, leveraging the network’s high throughput and low transaction costs. This decision allowed PYTH to provide frequent and detailed price updates, but it also tied the project to Solana’s network health and stability, which has historically experienced outages and technical challenges. Over time, the PYTH network expanded to additional blockchain ecosystems through cross-chain solutions and bridge integrations.

The Introduction of the PYTH Token

A major milestone in PYTH’s history was the introduction of a native token. This token was designed to facilitate governance, incentivize data providers, and secure the oracle network. However, the token launch also sparked debates about token supply distribution, particularly regarding allocation to early contributors versus public participants. Questions around decentralization and governance mechanisms remained ongoing topics of discussion as PYTH evolved.

Expansion Beyond Solana

While PYTH initially gained traction within the Solana ecosystem, it later expanded its oracle services to other blockchain networks, including Ethereum Layer 2s, Cosmos-based chains, and others. This multi-chain expansion was intended to increase adoption and establish PYTH as a more universal oracle solution. However, bridging PYTH’s data across chains introduced additional layers of complexity, especially regarding latency, trust assumptions, and smart contract security risks associated with cross-chain communication.

Challenges and Controversies

Throughout its development, PYTH has faced several criticisms. The reliance on proprietary data sources has led to concerns about transparency and potential conflicts of interest among price contributors. Additionally, the network’s infrastructure has been tested under high-stress market conditions, with some questioning the resilience of its update mechanism during periods of extreme volatility.

Despite these challenges, PYTH’s history reflects the broader evolution of blockchain oracles, highlighting the trade-offs between data accuracy, decentralization, and scalability.

How PYTH Works

How PYTH Works: On-Chain Oracle Network and Data Distribution

PYTH operates as a decentralized oracle network designed to source and deliver high-fidelity financial market data on-chain. Unlike traditional oracles that rely on third-party aggregators, PYTH sources data directly from market participants such as exchanges, trading firms, and financial institutions. This model reduces reliance on intermediaries and aims to provide more accurate, low-latency price feeds.

Data Publishing and Verification

Market participants, known as data publishers, provide real-time price updates to the PYTH network. These publishers stake their reputation on the accuracy of the information since incorrect or inconsistent data can lead to penalties or reduced usage by smart contracts. To enhance reliability, reported prices are aggregated using a weighted median approach, mitigating the influence of outliers or intentionally manipulated data points.

One challenge with this model is ensuring that enough publishers contribute high-quality data across all supported asset classes. While cryptocurrencies and equities are well-covered, less liquid markets may suffer from data scarcity or concentration risks if only a few providers dominate.

Pull-Based Oracle System

Unlike push-based oracles that continuously feed data on-chain, PYTH operates a pull-based model. Users must actively request price updates, triggering the on-chain aggregation process before retrieving the latest price. This design optimizes cost efficiency by avoiding unnecessary on-chain transactions, but it introduces potential drawbacks. Latency-sensitive applications may experience slight delays between price updates, and developers must incorporate fail-safes to handle stale or unavailable data.

Additionally, since data retrieval incurs transaction costs, frequent price pulls can become expensive, particularly when operating across multiple blockchains.

Cross-Chain Data Availability

PYTH supports multiple blockchains through its Wormhole-powered cross-chain messaging system. This mechanism allows price feeds to be consumed across ecosystems without requiring each chain to host its own set of data publishers. While this increases accessibility, it also introduces additional trust assumptions, particularly around Wormhole’s security and bridge integrity. Any exploit within Wormhole could compromise data reliability for dependent smart contracts.

Another consideration is the dependency on a limited number of relayers to transmit pricing data across chains. If relayers fail or experience congestion, prices may not update as expected, potentially exposing protocols to outdated or inaccurate information.

Economic Incentives and Token Utility

PYTH incorporates an incentive mechanism where consumers of price feeds compensate data providers. This pay-to-access model contrasts with free oracle solutions but theoretically ensures sustainable data availability. However, adoption hinges on network effects—protocols must be willing to pay, and publishers must remain incentivized to contribute high-quality data.

The challenge lies in balancing affordability for smaller protocols while maintaining meaningful rewards for data providers. If costs become prohibitive, adoption may suffer, leading to potential centralization of oracles as only well-funded protocols can afford PYTH's data feeds.

Use Cases

PYTH Use Cases in Decentralized Finance

Real-Time Data for On-Chain Smart Contracts

PYTH provides decentralized applications with high-frequency, low-latency price data for assets such as cryptocurrencies, equities, FX, and commodities. Unlike oracles that aggregate off-chain data from multiple third-party sources, PYTH sources price feeds directly from institutional players, including market makers and trading firms. This allows smart contracts to react to market movements with minimal lag, which is critical for protocols handling liquidations, derivatives pricing, and automated trading strategies. However, this direct-sourcing model comes with trust assumptions; while data providers are incentivized to report accurate prices, reliance on select institutions introduces potential centralization concerns.

Oracle Solutions for DeFi Derivatives and Perpetuals

A major use case for PYTH is in perpetual futures and options trading, where accurate and responsive price feeds are necessary to determine liquidations, funding rates, and settlement values. Decentralized derivatives platforms integrate PYTH to replace or supplement traditional oracles like Chainlink. Since PYTH updates more frequently than some alternatives, this helps mitigate manipulation attacks on thinly traded assets. However, frequent updates increase gas costs for protocols consuming the data, forcing developers to balance accuracy with affordability.

Cross-Chain Oracle Infrastructure

PYTH expands beyond single-chain applications by facilitating cross-chain price feeds through its pull-based model. Instead of pushing data at fixed intervals, PYTH allows protocols to request specific price updates when needed, reducing inefficiencies. This is particularly useful for L2 networks and application-specific blockchains where gas costs are a major concern. However, reliance on signed price attestations means there is an inherent delay in cross-chain data retrieval, which can be a limiting factor for high-frequency trading applications.

Risk Management in Lending and Borrowing Protocols

Lending protocols use PYTH to determine real-time collateralization ratios and liquidation thresholds. More frequent pricing updates help prevent undercollateralized positions from persisting on the platform, reducing systemic risk. The main challenge here is that if PYTH experiences an outage or delayed feed updates, lending platforms could be vulnerable to liquidations happening at incorrect price levels. While protocols often implement fallback mechanisms, prolonged disruptions pose financial risks for borrowers.

NFT and GameFi Price Feeds

Beyond DeFi, PYTH is starting to be utilized in NFT and blockchain gaming ecosystems, where real-time asset valuations are needed for dynamic pricing models. GameFi platforms leveraging PYTH for in-game economies can create responsive marketplaces, but adoption remains lower in these sectors compared to traditional DeFi applications due to infrastructure limitations and liquidity fragmentation.

PYTH Tokenomics

PYTH Tokenomics: Supply, Distribution, and Incentives

Token Supply and Emission Schedule

PYTH has a fixed total supply, with a structured emission schedule that regulates the release of tokens over time. A portion of the supply was allocated to early contributors, ecosystem development, and community incentives. The token release is subject to various vesting schedules, ensuring that early stakeholders cannot immediately liquidate large amounts, which could impact market dynamics. The emission model aims to balance supply distribution while sustaining long-term project incentives.

Distribution Mechanism and Stakeholder Allocations

A significant portion of PYTH tokens has been allocated to ecosystem participants, including oracle data providers, governance participants, and developers. This allocation structure incentivizes network growth and security but can also raise concerns about centralization if certain groups hold substantial control over circulating supply. A key component of the distribution strategy is rewarding data publishers, ensuring that high-quality price data continues to flow into the network.

Utility and Staking Dynamics

PYTH tokens play a crucial role in network operations, functioning as an incentive mechanism for participation. Token holders can stake to contribute to governance and network security, while data providers are compensated in PYTH for their contributions. However, the current utility model faces challenges in achieving sustainable demand since much of the token usage hinges on continued network adoption. If staking rewards or publisher incentives become the primary driver of token demand without organic use cases, sell pressure could build over time.

Governance and Token Holder Influence

PYTH adopts a governance model where token holders can vote on network upgrades, parameter adjustments, and protocol changes. While governance participation is essential to decentralization, the actual influence of smaller holders is often limited due to high voting power concentration among early stakeholders. This can impact decentralization goals if major governance decisions are determined by a small group of token holders.

Potential Risks and Inflation Considerations

One potential concern with PYTH’s tokenomics is the long-term impact of emissions on market dynamics. If a significant portion of vested tokens enters circulation too quickly, it could result in downward price pressure. Additionally, the reliance on token incentives for network participation introduces long-term sustainability risks if external demand does not scale at the same pace as emissions. Managing inflationary pressure while maintaining sufficient incentives for contributors remains a fundamental challenge.

PYTH Governance

PYTH Governance: Decentralized Decision-Making and Challenges

On-Chain Governance Structure

PYTH governance is structured around token-based voting, where PYTH token holders influence parameters related to the oracle network’s operations, upgrades, and ecosystem incentives. Governance proposals typically cover protocol upgrades, fee structures, and data provider incentives. Token staking may be required to participate in governance, ensuring alignment between governance participants and the protocol’s long-term interests.

Proposal and Voting Mechanism

PYTH governance follows a structured proposal process in which token holders or designated entities submit governance proposals. These proposals are then subject to community discussion before being put to a vote. Voting weight is proportional to token holdings, meaning entities with significant PYTH stakes exert more influence on decisions. Depending on the governance framework, there might be quorum requirements or execution delays to prevent rushed decision-making. However, concentration of voting power among large holders can lead to centralization concerns, particularly if governance participation is low.

Governance Token Utility and Distribution Concerns

The PYTH governance token is not only a vehicle for decision-making but also plays a role in incentivizing engagement. However, token distribution dynamics can raise concerns about governance centralization. If the majority of tokens are held by insiders, early investors, or a small number of entities, governance decisions may not reflect broader community interests. Transparency in token distribution and potential mechanisms like delegation can help address these concerns, but governance concentration remains a common critique in token-based voting systems.

Risks of Governance Attacks

Like other decentralized protocols, PYTH is vulnerable to governance attacks if a single entity or coordinated group accumulates enough voting power to push through proposals that benefit them at the expense of the broader network. This risk is particularly relevant in the context of oracle networks, where governance decisions could influence pricing mechanisms and data integrity. Measures such as time-locked proposals, veto mechanisms, or multi-signature approvals could mitigate governance attack risks, but their implementation depends on community consensus.

Governance Evolution and Future Considerations

The governance structure of PYTH is not static and can evolve over time. Community discussions around decentralized governance frameworks, potential integrations of governance councils, or shifts toward quadratic voting mechanisms could play a role in shaping how decisions are made. However, balancing decentralization, efficiency, and security remains a challenge for PYTH governance as it matures.

Technical future of PYTH

PYTH Current and Future Technical Developments

Expansion of Cross-Chain Oracle Infrastructure

Pyth Network continues to expand its cross-chain oracle capabilities, leveraging its pull-based data distribution model. Unlike traditional oracles that push data to predefined chains, Pyth enables developers to query and verify price updates directly on-chain, minimizing unnecessary transactions and fee costs. To increase adoption, new blockchain integrations and optimizations around latency reduction are ongoing. However, the reliability of cross-chain messaging layers remains a concern, as vulnerabilities in bridges or relayers can impact data availability and security.

Enhancements in Price Feeds and Data Accuracy

A major focus is refining Pyth’s aggregation mechanisms to reduce price deviations across providers. The network sources data from institutional-grade providers, but discrepancies in price aggregation methodologies between exchanges can introduce minor inconsistencies. Technical improvements, such as adaptive weighting models and faster oracle update intervals, are being developed to enhance price accuracy. While these changes improve real-time market data delivery, they also introduce greater computational overhead, which could impact efficiency on lower-throughput blockchains.

Streamlining Data Availability with State Compression

Data compression techniques are being explored to optimize the on-chain storage footprint. Pyth’s price updates generate large amounts of data, especially when supporting multiple asset pairs across different ecosystems. State compression and efficient Merkle proof structures are being tested to lower the cost of retrieval and verification without sacrificing integrity. The trade-off is that compression techniques add computational complexity for data consumers, which may require additional off-chain preprocessing.

Future Roadmap and Decentralization Initiatives

A priority in the roadmap is progressively decentralizing the oracle infrastructure. Currently, Pyth relies on vetted data providers for price aggregation, but there are ongoing discussions about mechanisms for increasing permissionless participation. Introducing a staking or slashing mechanism could help secure data integrity, but governance challenges remain around enforcement and potential data manipulation risks.

Automation and Smart Contract Improvements

Work is being done to automate oracle fee adjustments, ensuring sustainable economics for data providers while keeping costs manageable for developers. Smart contract upgrades are being designed to improve update efficiency, but security risks remain a key challenge if modifications introduce new attack vectors.

Challenges in Scaling and Adoption

While Pyth is being integrated into more blockchains, the dependency on cross-chain messaging and the infrastructure security of these networks pose external risks. Additionally, while its pull-based design reduces unnecessary on-chain updates, applications relying on rapid price changes may still require supplementary oracle solutions.

Comparing PYTH to it’s rivals

PYTH vs. CHAIN: Comparing Oracle Solutions

Data Sourcing and Accuracy

PYTH and CHAIN take different approaches to how they source and verify data. PYTH relies on a network of institutional traders, market makers, and exchanges to provide first-party data directly to the oracle. This is designed to reduce reliance on third-party aggregators but also means the data is only as reliable as its contributors. CHAIN, on the other hand, primarily aggregates data from multiple external APIs and feeds, emphasizing decentralization but potentially introducing additional layers where manipulation or inconsistencies can occur.

Latency and Real-Time Updates

Speed is a critical factor for oracles, especially when dealing with DeFi applications that require low-latency updates. PYTH is structured to provide real-time price data, utilizing its network of contributors to push updates at high frequency. CHAIN, while also focused on timely data delivery, depends on traditional polling-based methods for data retrieval, which might introduce delays in volatile market conditions. This difference can be significant for applications requiring ultra-fast updates, such as high-frequency trading or liquidation mechanisms in leveraged protocols.

Decentralization and Trust Model

CHAIN follows a highly decentralized model, in which data sources are combined from multiple origins, ensuring no single point of failure. This allows for greater censorship resistance and fault tolerance if any individual data provider becomes compromised. PYTH, by comparison, concentrates its data sourcing on a select group of primary contributors, which can lead to concerns about centralization if a small number of entities dominate data submission. However, this model also reduces potential inefficiencies associated with multiple intermediaries.

Blockchain Compatibility and Integration

PYTH has primarily focused on Solana and EVM-compatible chains but employs a pull-based model where data is updated only upon request by smart contracts. CHAIN, being an established oracle provider, is widely integrated across multiple blockchains and features a push-based mechanism that ensures smart contracts receive updates automatically. This structural difference means that developers who need consistent, automated price updates might find CHAIN to be more plug-and-play, whereas PYTH's model requires additional interaction for on-chain availability.

Cost and Accessibility

PYTH’s cost structure ties into its "pull" model, where users pay only when they access the data. This can be cost-efficient for applications that don’t require continuous updates. CHAIN, using a subscription-based service for its data feeds, ensures that information is consistently available but might become expensive for protocols that need frequent and highly granular price data. The trade-off between cost efficiency and reliability varies depending on the use case.

PYTH vs. UMA: A Deep Dive into Oracle Architecture and Incentives

When comparing PYTH and UMA, a fundamental distinction lies in their approach to oracle data aggregation and verification. PYTH operates on a pull-based model, relying on a network of institutional data providers to submit off-chain price feeds, which are then relayed on-chain when requested. This contrasts with UMA’s optimistic oracle system, which emphasizes human and algorithmic dispute resolution mechanisms to ensure data accuracy.

Data Submission and Verification Differences

UMA’s oracle model is structured around an “optimistic” assumption—submitted data is presumed correct unless actively disputed. This minimizes on-chain overhead, as data is only formally verified when challenged by economic participants. While this reduces gas costs and enhances scalability, it also introduces latency in finalizing data if disputes arise. PYTH, by contrast, sources prices continuously from its curated publishers but relies on users to trigger updates, limiting automatic synchronization across chains unless prompted.

Latency and Data Finality

UMA’s dispute window introduces a delay in data finality, which is a critical drawback for high-frequency DeFi protocols needing real-time pricing. PYTH attempts to address this by offering low-latency price feeds, sourced directly from market makers and trading firms. However, PYTH’s reliance on publisher incentives can sometimes result in uneven price updates across different assets, particularly for less-liquid markets. UMA, on the other hand, assumes price accuracy across reporting intervals but is susceptible to manipulation attempts if dispute mechanisms fail to trigger in time.

Incentive Structures and Economic Security

One of UMA’s primary innovations is its incentivized dispute process, where participants stake tokens to challenge incorrect data. This differs significantly from PYTH’s economic model, which compensates data providers via a publisher-reward mechanism. While UMA’s system reduces the need for continuous data submission, it also places significant reliance on the willingness of the community to actively monitor oracle outputs. PYTH’s structure provides continuous updates but is gated by network demand, meaning real-time feeds are not universally available unless explicitly paid for.

Adoption and Accessibility

UMA’s oracle system is designed to be highly flexible, supporting synthetic assets and complex financial contracts where dispute-driven data verification is acceptable. PYTH, with its on-demand pricing, is more suited for decentralized exchanges and derivatives platforms requiring immediate market data. However, PYTH’s reliance on fewer institutional publishers raises concerns about data centralization, whereas UMA’s oracle output relies on open economic mechanisms, albeit with some risk of oracle attacks in low-activity environments.

Pyth vs. Band Protocol: A Comparative Analysis

Both Pyth and Band Protocol operate within the rapidly evolving decentralized oracle landscape, but they take different approaches to data aggregation, network design, and target use cases.

Data Sourcing and Aggregation

Pyth primarily sources data directly from institutional participants, aggregating price feeds from high-frequency traders, exchanges, and market makers. This design is intended to provide low-latency, high-accuracy data with strong provenance. However, its reliance on first-party data providers means that participation in the network is somewhat permissioned, as only whitelisted contributors can provide price feeds.

In contrast, Band Protocol utilizes a more permissionless model, where independent validators fetch data from multiple external sources and aggregate it on-chain. This approach decentralizes price feed generation, reducing reliance on a controlled set of contributors. However, this can also introduce latency and inconsistencies in price updates, depending on the speed and reliability of external APIs.

Cross-Chain Integration

Band Protocol is built with Cosmos-SDK and operates through the Inter-Blockchain Communication (IBC) protocol. This allows it to natively interact with multiple blockchain ecosystems, making it highly interoperable beyond just EVM-based and Solana-based networks. Pyth, on the other hand, relies on its pull-based "Pythnet" for data distribution, pushing final prices to various chains through messaging systems like Wormhole. While this allows Pyth to avoid the traditional request-response mechanism of oracles, it does introduce reliance on additional infrastructure layers that may create security or latency concerns.

Economic & Security Models

Pyth’s economic model revolves around data providers being rewarded in exchange for contributing price feeds. The protocol enforces a combination of fee-based access and value accrual mechanisms for its users. However, this model inherently concentrates economic incentives toward large institutional providers, which can lead to centralization risks.

Band Protocol, in contrast, operates with a delegated proof-of-stake (DPoS) model, where BAND token holders delegate stake to validators who provide oracle services. While this staking mechanism enhances security, it also introduces potential slashing risks if validators provide incorrect or manipulated data. Furthermore, maintaining a sufficient number of validators to ensure decentralization remains an ongoing challenge.

Latency and Finality

Pyth is designed specifically for real-time, sub-second price updates, which is advantageous for latency-sensitive applications like derivatives and high-frequency trading. However, the tradeoff is that raw Pyth prices often require additional confidence intervals and are not inherently finalized on-chain without commitments from price publishers.

Band Protocol, being blockchain-agnostic, typically relies on periodic data queries rather than live-stream updates. This makes it more suitable for applications that do not require continuous real-time pricing but instead prioritize data integrity and reliability. However, the batch-query model results in higher latency compared to Pyth's on-demand updates.

Primary criticisms of PYTH

Primary Criticism of PYTH

Centralization Concerns in Data Feeds

One of the most significant criticisms of PYTH is its reliance on a permissioned set of data providers. Unlike fully decentralized oracle networks that aggregate data from multiple sources in an open and permissionless manner, PYTH relies on a curated list of publishers. This model raises concerns about potential centralization risks, including censorship, data manipulation, or single points of failure if a small number of entities control the data flow.

Restricted Data Access and Monetization Model

PYTH differentiates itself by offering exclusive, high-quality financial market data through a paywall mechanism known as the "pull oracle" model. While this approach incentivizes data providers, it also limits the accessibility of real-time data for DeFi protocols compared to open-source alternatives. Critics argue that this monetization strategy introduces friction for smaller projects that cannot afford to pay for real-time price feeds, leading to an imbalance in DeFi accessibility.

Latency Issues and Reliability of Updates

Speed is a core focus of PYTH, aiming to deliver low-latency, high-frequency price updates. However, some users have raised concerns about inconsistencies in update frequency, especially in volatile market conditions when timely oracle data is most critical. If updates are delayed or unreliable, DeFi applications relying on PYTH may experience issues such as inaccurate liquidations or mispriced trades. This risk is particularly relevant for protocols that require near-instantaneous price feeds for derivatives and lending markets.

Dependence on the Solana Ecosystem

PYTH has built strong integration within the Solana ecosystem, leveraging Solana’s high-speed transactions for oracle updates. While this offers advantages in terms of performance, it also raises questions about how well PYTH can operate across multiple blockchains. Although PYTH has expanded to other networks, some critics view its design as being overly reliant on Solana’s infrastructure. This dependence could pose risks in scenarios where cross-chain interoperability is required at scale or if the Solana network experiences instability.

Governance Transparency and Influence of Institutional Players

Another area of criticism revolves around governance and control. While PYTH has decentralized aspects, decisions around oracle upgrades, fee structures, and data provider inclusion are often seen as favoring institutional players. Some in the crypto community argue that a more transparent and community-driven governance model would be necessary to align with the principles of decentralization.

Founders

The Founding Team Behind PYTH: Key Players and Backgrounds

The Pyth Network was developed by a consortium of industry-leading financial firms and technology providers, many of whom remain actively involved in its growth. Unlike many crypto projects that originate from a centralized founding team, Pyth emerged from a decentralized collaboration of major trading firms, market makers, and crypto-native companies.

Institutional Origins and Industry Backing

The core contributors to Pyth Network include high-caliber trading and market data firms such as Jump Trading, a proprietary trading firm with deep expertise in latency-sensitive markets. Jump Trading’s crypto division, Jump Crypto, has played a notable role in the protocol's development, leveraging its financial infrastructure to enhance data accuracy and reliability.

Other initial backers encompass a mix of traditional finance (TradFi) institutions and crypto-focused organizations, including firms specializing in quantitative trading, derivatives, and decentralized finance (DeFi). This deep integration with TradFi firms distinguishes Pyth from other oracle solutions that rely purely on decentralized or crowd-sourced data aggregation.

Decentralization vs. Institutional Control

One of the criticisms surrounding Pyth’s founding structure is its heavy reliance on institutional market makers for price feeds. While this model enables high-frequency, low-latency data, it also raises concerns over centralization risks. Unlike fully permissionless oracle models, where data sources are broadly distributed, Pyth's network primarily depends on a curated set of contributors who may not always be aligned with broader DeFi principles.

Additionally, the involvement of traditional finance firms introduces regulatory and transparency concerns. Many of Pyth’s data providers operate under strict compliance rules, which could lead to limitations on how and where the network can be utilized, particularly as global regulatory scrutiny on crypto intensifies.

Technical Leadership and Development Efforts

In terms of technical leadership, contributions come from a mix of in-house engineers at participating firms and independent developers involved in the protocol. While core development started within Jump Crypto’s team, Pyth has worked toward progressively decentralizing governance and contributor access. However, questions remain regarding how much influence the founding firms still exert over decision-making processes, particularly when major upgrades or protocol changes are introduced.

The Role of Partnerships in Expansion

The founding team's network of partnerships has been instrumental in driving institutional adoption. Working with leading exchanges, DeFi platforms, and blockchain foundations has accelerated Pyth’s integration across multiple ecosystems. However, this also means that strategic decisions around onboarding new chains or adjusting data contribution mechanisms are often made in alignment with major financial players rather than purely by DAO-based governance.

Authors comments

This document was made by www.BestDapps.com

Sources