A Deepdive into RLC - 2024

A Deepdive into RLC - 2024

History of RLC

The History of RLC: Understanding iExec’s Journey in Decentralized Computing

RLC is the native utility token of iExec, a platform that aims to decentralize cloud computing by creating a marketplace for computing resources. The origins of RLC trace back to the emergence of iExec in 2016, founded by Gilles Fedak and Haiwu He, both of whom have academic backgrounds in distributed systems and a focus on blockchain technology. Their experience in grid computing—where distributed computing resources are pooled to perform high-demand tasks—served as the conceptual framework for iExec’s goals.

RLC, short for "Run on Lots of Computers," was introduced as the token within this ecosystem, designed to fuel transactions for computing power, data usage, and application monetization. The iExec team conducted an Initial Coin Offering (ICO) in April 2017, one of the earliest successful ICOs in the crypto space. By utilizing Ethereum’s ERC-20 standard, the project raised approximately $12 million in under three hours, a feat that underscored the growing interest in decentralized computing at the time. This funding was directed toward building the platform’s infrastructure and fostering partnerships within the blockchain and cloud computing ecosystems.

A key historical milestone for RLC was the launch of iExec V1 in late 2017, which introduced essential features like decentralized resource sharing and a task management framework. However, the project faced challenges in scaling its adoption, partly due to the niche nature of its market. Competing solutions from centralized cloud providers presented hurdles in convincing traditional industries about the economic and operational viability of decentralized alternatives.

As the platform evolved, subsequent versions—such as iExec V2 and V3—added more functionality, including support for confidential computing powered by Trusted Execution Environments (TEEs). These updates highlighted the ecosystem's pivot toward enterprise use cases, particularly in industries where data privacy and ownership are paramount. Despite these advancements, iExec has faced ongoing criticism for its limited user base and liquidity issues in the NFT-style marketplace for data and compute resources.

RLC’s history is marked by its positioning within the evolving narratives of blockchain scalability and utility. While its connection with Ethereum provided initial momentum, debates persist about the interplay between centralized cloud computing giants and iExec's decentralized vision. For proponents, RLC represents a necessary step toward democratizing resource access, but skeptics cite concerns over the underlying market fit and the pace of achieving mass adoption.

How RLC Works

How RLC Works: Decentralized Computing Power on the iExec Platform

RLC, the native utility token of the iExec decentralized cloud computing platform, operates as the backbone of the ecosystem, enabling participants to trade computational resources in a decentralized marketplace. iExec provides a framework that connects resource providers and users in a trustless manner by leveraging blockchain technology, specifically Ethereum, to manage transactions and ensure security.

Resource Tokenization Through RLC

At its core, RLC functions as the currency within the iExec marketplace. Resource providers—whether they offer computing power, data services, or application hosting—set their prices in RLC. Smart contracts serve as the intermediary, automating payment agreements and enforcing terms without reliance on centralized entities. Providers stake RLC to interact with the system, which ensures commitment toward delivering services.

One unique aspect of iExec is its resource tokenization. Providers register their resources as digital assets, creating a standardized, tradable environment for computing services. RLC acts as the settlement layer, enabling real-time, permissionless transactions for resource allocation.

Decentralized Off-Chain Computation

iExec employs a proprietary decentralized off-chain execution framework called the iExec Oracle Factory. This architecture allows applications to access off-chain data or perform complex computations, which are often cost-prohibitive or infeasible on-chain. A critical element here is the network's reliance on the Proof-of-Contribution (PoCo) protocol, a consensus mechanism that rewards resource providers for verified computational output. RLC holders and stakers play a pivotal role in incentivizing resource honesty while reducing redundant verifications.

However, the off-chain nature of iExec's operations raises a concern for centralization risks at the secondary level. Unlike fully on-chain solutions, there’s still a reliance on providers behaving as promised, which could lead to trust issues under certain attack vectors or misuse.

Barriers to Entry and Flexibility

While RLC enables seamless and flexible payment for small-scale users and large enterprises alike, its dependency on Ethereum brings cost and scalability challenges. High gas fees during network congestion impact transaction costs, potentially deterring microtransactions or smaller service requests. In addition, the technical barrier for onboarding new participants—especially resource providers—limits ease of adoption. Users must not only understand blockchain fundamentals but also interact with iExec’s specific API and toolsets.

Furthermore, RLC's utility is limited to the iExec ecosystem, meaning its value and functionality are directly tied to platform usage. This dependency might hinder broader adoption unless iExec expands integrations or partnerships to increase the token's relevance beyond its current scope.

On-Chain Transparency and Governance

All transactions within iExec are publicly verifiable on Ethereum, ensuring transparency, although this introduces potential privacy concerns. Sensitive data usage or computation details must often be encrypted or handled off-chain, which could complicate processes for certain use cases, like data-sharing industries. The governance of RLC also remains largely centralized to iExec’s team, raising questions about decentralization consistency across its ecosystem.

Use Cases

Use Cases of RLC: Powering Decentralized Cloud Computing

The RLC token is at the core of iExec, a decentralized cloud computing platform that facilitates access to distributed computing power and data. As a utility token, RLC serves as the medium of exchange within this ecosystem, fueling a variety of specific use cases centered around decentralized infrastructures. Below, we explore some of the key applications of RLC while also touching on the caveats associated with its functionality.

1. Accessing Decentralized Computing Resources

RLC enables users to pay for and access computing power, data sets, and applications offered by the iExec network. This functionality is particularly appealing in industries requiring scalable cloud solutions, such as artificial intelligence, finance, and healthcare. Instead of relying on centralized giants like AWS or Google Cloud, developers can use RLC to tap into a distributed pool of computing resources. However, one potential limitation lies in the adoption of the network itself—it inherently depends on attracting a critical mass of providers and users to deliver competitive performance and pricing.

2. Monetizing Idle Computing Power

RLC empowers individuals and organizations to monetize underutilized computing resources by offering them to the iExec marketplace. This could benefit smaller providers who would otherwise be excluded from the centralized cloud computing market. While this opens up opportunities for decentralized income streams, it also raises the challenge of ensuring consistent supply quality. Network participants may face variability in performance, availability, or latency, particularly if node operators prioritize profit over service quality.

3. Privacy-Preserving Data Sharing

With RLC, users can participate in secure data marketplaces where sensitive data is shared on a pay-per-use or subscription basis while preserving confidentiality. iExec employs innovative technologies like Trusted Execution Environments (TEEs) to ensure that computations occur securely without exposing raw data. A drawback to this use case is the complexity involved in setting up TEEs, which could pose a barrier to entry for developers and users less familiar with advanced security protocols. Additionally, questions around trust and compliance in cases of sensitive use, such as medical data, remain unanswered.

4. Enabling Decentralized Applications (dApps)

RLC can be used to pay for the backend infrastructure of decentralized applications hosted on iExec. By offloading heavy computations to the network, dApp developers can optimize performance and avoid centralized chokepoints. On the flip side, the ecosystem’s adoption is limited by competition from other blockchain infrastructures, which may already have greater developer loyalty or feature sets.

5. Proof-of-Contribution & Incentives

RLC is foundational to the iExec Proof-of-Contribution mechanism, rewarding contributors who provide resources or process tasks on the network. While this ensures transparency in resource allocation, it also introduces potential vulnerabilities if the mechanism is gamed or manipulated by malicious actors.

In conclusion, while RLC offers versatile use cases catering to decentralized cloud computing, its success is closely tied to the adoption, performance, and interoperability of the iExec network as a whole.

RLC Tokenomics

In-depth Analysis of RLC Tokenomics: Supply Dynamics, Use Cases, and Distribution

RLC, the native token of the iExec decentralized cloud computing platform, operates on the Ethereum blockchain under the ERC-20 standard. The tokenomics of RLC is meticulously designed to support a decentralized marketplace for cloud resources, but certain aspects of its structure raise critical considerations for users and investors.

Fixed Supply and Distribution Details

RLC has a fixed total supply of 87 million tokens, addressing concerns over inflationary pressures. This cap lends itself well to scarcity, but the distribution model introduces intriguing challenges. During its initial coin offering (ICO) in 2017, 60.2% of the total supply was allocated to contributors, while the remaining balance was split among the project team (19.2%), a reserve fund (15%), and external development incentives (5.6%).

This distribution structure raises questions of centralization within the ecosystem. The sizable allocation to the team and reserve fund has triggered debate over how much influence central parties may exert, especially when it comes to governance or token sales by the team over time. For a project marketing itself as decentralized, this level of concentrated control may warrant deeper scrutiny.

RLC as a Utility Token

At its core, RLC is a utility token that powers transactions within the iExec platform. Users utilize RLC to access computational resources, purchase cloud storage, or pay workers in the decentralized application pool. This utility-centric design ensures that RLC maintains intrinsic value tied to actual use cases rather than solely speculative trading.

However, concerns arise from the low barriers to entry for alternative cloud resource providers, both centralized (like AWS) and emerging decentralized competitors. This could potentially dampen the intrinsic demand for RLC tokens unless iExec scales significantly. Additionally, Ethereum gas fees sometimes pose challenges for microtransactions, further complicating RLC's usability on a broader scale.

Tokenomics-Driven Incentives

One of the strengths of RLC's tokenomics lies in its mechanisms for incentivizing contributors, such as developers, resource providers, and workers. The establishment of a marketplace incentivizes decentralization by economically rewarding contributions. Yet, the on-chain economy for RLC remains contingent on ecosystem adoption. A potentially limited user base could lead to less liquidity within the platform, indirectly affecting token dynamics.

Staking and Governance Gaps

Unlike many blockchain projects, RLC does not currently offer staking or explicit governance functions tied to its token. While this avoids some of the complexities of managing decentralized decision-making, it also limits the token's utility beyond its primary transactional role. This might discourage long-term holders searching for passive yield-generating mechanisms or direct involvement in the network's evolution.

RLC Governance

RLC Governance: Decentralized Decision-Making and Challenges

The governance structure of RLC, the native token of the iExec decentralized computing platform, is inherently linked to the broader ecosystem's decentralization ethos but presents a mixed bag of strengths and challenges. RLC holders play a critical role in shaping network-level decisions, yet the governance model is not immune to difficulties prevalent in decentralized systems.

Token Holder Participation

RLC’s governance framework relies on token holders as key decision-makers. This aligns with broader trends in crypto governance, where holders of a project's native asset are incentivized to participate in decisions that may enhance the network’s health and utility. Proposals regarding changes to the iExec protocol, improvements to resource allocation, or updates to operational guidelines can be proposed and often require community involvement for implementation. However, like many crypto assets, participation rates in governance votes can fluctuate. Low engagement by token holders has been a persistent issue, raising questions about the practical decentralization of decision-making.

Lack of Formalized On-Chain Governance

Unlike other leading blockchain projects that rely on fully on-chain governance mechanisms, iExec’s governance system has historically been more informal in structure. Governance discussions often take place within community forums, social channels, and off-chain environments, which governing bodies then use to compile input. This brings the advantage of flexibility but at the cost of transparency and verifiability. Critics argue that without formalized on-chain voting, the decision-making process could be skewed by centralized parties or whales with outsized influence.

Centralization Concerns

Although RLC governance espouses decentralization, there is room for improvement in mitigating the risk of centralization. Whale wallets—large token holders—might disproportionately affect voting outcomes, given the weight of their holdings. Additionally, core development decisions are still significantly influenced by the iExec team, which raises valid concerns about whether the system is decentralized in practice or merely in principle.

Smart Contract Risks

Another layer of complexity in RLC’s governance stems from technical execution risks. Smart contracts underpin many of iExec's operations, including staking and rewards distribution. While this automation enhances efficiency, vulnerabilities in smart contracts could introduce unforeseen challenges during governance processes, potentially affecting both vote execution and community trust.

Final Thoughts on Governance Challenges

RLC governance highlights both the promise and the complexity of decentralized decision-making systems. It serves as a useful case study on the balance between effective coordination and maintaining decentralization across a crypto ecosystem.

Technical future of RLC

RLC: Current and Future Technical Developments and Roadmap

Advancements in the iExec Framework

RLC powers the iExec decentralized cloud computing platform, which facilitates secure and scalable access to off-chain computing resources. Recent updates to the iExec SDK have prioritized developer experience, offering improved APIs and more robust tooling for decentralized application (dApp) workflows. Enhancements to the confidential computing framework based on Intel® Software Guard Extensions (SGX) have been particularly significant. By enabling developers to execute sensitive off-chain processes while preserving data privacy, the platform underscores its focus on real-world enterprise use cases. However, the reliance on SGX hardware raises questions regarding long-term sustainability, as any shifts in Intel's support or technological stack could lead to developmental bottlenecks.

Automation and Smart Contract Upgrades

iExec is in the process of refining its smart contract architecture to allow for greater automation, such as through zero-trust execution protocols and decentralized oracles. Two areas of development stand out: the Oracle Factory, which enables the creation of custom data oracles, and efforts toward improving the marketplace-based resource allocation system. The latter attempts to balance supply and demand for computational resources dynamically, but it still faces challenges on the scalability front, especially during periods of network congestion where transaction gas fees rise unpredictably on Ethereum.

Bridging Networks and Layer-2 Integration

To address Ethereum’s scaling issues, iExec has been integrating Layer-2 solutions, particularly those associated with Rollups. These integrations aim to reduce transaction costs for dApp developers and users without compromising security and decentralization. Despite this move, adoption among dApp developers has been relatively slow, suggesting either insufficient developer education or perceived complexity in onboarding to the Layer-2 ecosystem.

R&D in Application-Specific Use Cases

iExec's R&D teams are expanding into niche use cases, including AI, blockchain-based multi-cloud infrastructure, and scientific computations. By advancing compatibility with existing machine learning environments like TensorFlow and PyTorch, as well as focusing on distributed training for AI models, iExec remains positioned for long-term diversification. However, the practical realization of these goals depends heavily on enterprise adoption, which has historically been a gradual process for decentralized platforms.

Decentralization Versus Centralized Dependencies

While promoting decentralization, certain technical aspects remain centralized or semi-centralized. For instance, the Scheduler—the backbone of iExec’s resource allocation—currently operates under a chain of trust that raises centralization concerns. Decentralizing this component is listed in the long-term roadmap, but no tangible implementation timeline has been shared publicly, leaving this issue unresolved for the foreseeable future.

Comparing RLC to it’s rivals

RLC vs. FET: A Direct Comparison of Decentralized Computing Platforms

When evaluating iExec RLC (RLC) against Fetch.ai (FET), it's important to dissect how these two projects approach decentralized computing. Both aim to bring efficiency to computational resource allocation but differ significantly in scope, architecture, and use cases.

Core Focus and Architecture

RLC thrives with its marketplace model, enabling developers to rent idle computational power, datasets, and applications. Its infrastructure is built on Ethereum, emphasizing trust and security. On the other hand, FET is more ambitious in scope, leveraging its autonomous economic agent (AEA) framework. Fetch.ai incorporates machine learning to create intelligent digital agents designed to optimize resource allocation. This focus on automation sets FET apart but introduces complexity and potential execution risks.

Decentralization Approach

RLC's decentralized marketplace presents a clear and grounded proposition: anyone can monetize unused computing resources. This simplicity appeals to projects prioritizing pragmatic solutions. However, FET pushes the boundary with behavior-driven AI agents working independently across its ledger. While visionary, the reliance on AI-driven agents may limit FET’s appeal for projects requiring more predictable and deterministic systems.

Ecosystem and Integration

RLC integrates seamlessly with established blockchain ecosystems like Ethereum, which benefits from robust development support and a wide user base. Yet, this means RLC is bound to Ethereum’s scaling issues, such as high gas fees, limiting its usability during network congestion. FET, conversely, runs on its bespoke blockchain, giving it greater control over scalability. But, this independence risks slower adoption, as Fetch.ai lacks the ecosystem maturity and extensive tooling that Ethereum offers.

Token Utility and Incentives

RLC tokens are primarily utilized to pay for computational resources on the platform, aligning closely with the platform’s core functionality. This ensures a well-defined utility for the token but somewhat limits its appeal outside of the computational framework. FET token, being central to incentivizing and powering economic agents, takes on a broader role — potentially creating wider utility but also exposing it to higher complexity for token holders who may struggle to grasp its diverse applications.

Challenges and Risks

While RLC benefits from its Ethereum alignment, it remains susceptible to Ethereum’s bottlenecks, and the limited scope of its marketplace model could constrain future growth. FET’s AI-driven approach opens doors to innovative scenarios but introduces risk with its unproven deployment of autonomous agents and the higher technical barrier for adoption.

In sum, while both projects feature unique approaches to decentralized computing, their differences in design and risk factors cater to distinct niches within the broader blockchain landscape.

RLC vs GRT: Decentralized Computing Meets Graph Indexing

When comparing iExec RLC (RLC) to The Graph (GRT), their differences lie in how each project addresses decentralized resource management and data utilization. RLC focuses on providing decentralized cloud computing power, allowing users to rent and monetize computational resources. In contrast, GRT primarily tackles data indexing and querying for blockchain networks through a decentralized infrastructure. Their respective use cases complement rather than overlap, but differences in architecture, audience, and adoption paths reveal compelling points of comparison.

Core Purpose and Utility

RLC's ecosystem is built around matching demand for computing power with supply through its marketplace for off-chain tasks. Its ability to enable complex workloads, from AI model training to data processing, underscores its adaptability in computation-intensive applications. Meanwhile, GRT concentrates on blockchain data accessibility, enabling developers to query and interact with blockchain data efficiently. GRT's use of subgraphs—configurable APIs for decentralized indexing—has unlocked critical value for dApps navigating complex data structures across multiple blockchains.

The potential overlap emerges in how RLC and GRT manage resource optimization. While RLC decentralizes computational resources, GRT decentralizes the data layer itself, creating a synergy but leaving little room for direct competition.

Technical Architecture

RLC's technical foundation leans on its Proof-of-Contribution protocol, which incentivizes workers to provide off-chain computational resources verified on-chain. iExec's emphasis on preserving privacy through trusted execution environments (TEEs) provides added security for sensitive workloads, setting it apart in computational tasks. GRT, on the other hand, uses its Delegated Proof-of-Stake (DPoS) mechanism to involve indexers, curators, and delegators in the data querying lifecycle. Its framework ensures a decentralized, incentivized system for maintaining high-quality subgraph performance but does not address computation-heavy workloads—an area where RLC shines.

Challenges to Adoption

Despite GRT's strong adoption in the Ethereum ecosystem, its model heavily depends on subgraph creators and network reliability, making it less applicable to generalized use cases unrelated to data querying. By comparison, RLC's challenge lies in market penetration, as decentralized computation remains a niche use case with fewer immediate buyers than GRT's broad appeal to DeFi and dApp projects. Furthermore, GRT's reliance on Ethereum means scalability concerns persist, whereas RLC's multi-cloud approach offers more flexibility across diverse computational environments, albeit with potential complexity in user onboarding.

Ecosystem Synergy and Resource Utilization

RLC and GRT cater to fundamentally different actors in the blockchain space, but their visions align in decentralizing critical resources—computation for RLC and data for GRT. However, GRT's specific focus on querying for dApps contrasts with RLC's broader ambition to decentralize computational workloads. This makes their competitive overlap minimal, though each could benefit from the other's ecosystem strengths.

Both projects face scaling and adoption hurdles, but their focus areas ensure they address different sectors of a decentralized infrastructure stack.

RLC vs OCEAN: A Dive into Decentralized Data Markets

When comparing RLC (iExec) to Ocean Protocol (OCEAN), two prominent players in decentralized computational ecosystems, distinctions often arise in their respective focuses and methodologies for managing data and infrastructure. While both projects aim to decentralize access to vital resources, their competitive overlap primarily resides in how each facilitates data sharing, monetization, and access to computational assets in distributed environments.

Core Offerings and Use Case Differentiation

RLC emphasizes secure and decentralized access to computational power. Its marketplace enables users to buy and sell underutilized computing resources, targeting enterprises and resource-heavy applications, such as AI and deep learning. The focus is on off-chain computation, with RLC acting as the intermediary to ensure tasks are distributed efficiently and securely among providers.

On the other hand, Ocean Protocol is centered on creating data marketplaces where datasets can be securely shared, discovered, and monetized. It provides tools for permissioned access and integrates directly with AI and machine-learning pipelines through its compute-to-data framework. Rather than focusing on raw computational power, Ocean prioritizes facilitating data liquidity and access for developers, researchers, and data marketplace creators.

For users seeking data monetization opportunities, Ocean offers a more tailored solution, while RLC appeals to projects where computational outsourcing is the priority. This distinction highlights the varied niches the two projects cater to, but also underscores their partial redundancy when larger computational ecosystems require solutions that involve both raw data and computation.

Scalability and Network Architecture

Ocean Protocol’s architecture heavily integrates with its token mechanics to incentivize data staking and access. While this approach bolsters data liquidity, it introduces congestion risks during periods of network activity surges—especially when the demand for specific datasets spikes dramatically. This could affect user experience in situations where real-time computational needs collide with network bottlenecks.

In contrast, RLC sidesteps these issues by focusing on off-chain computational tasks enabled through its decentralized marketplace. However, this reliance on off-chain architecture does present its own challenges. Tasks are only as reliable as the individual providers offering resources, creating potential vulnerabilities in both task completion guarantees and trust dynamics in its ecosystem.

Interoperability Challenges

Ocean’s strength lies in its modular framework, which integrates with external technologies to create multi-layered solutions for data consumers and providers. Yet, its complexity can be a hurdle for new users and developers. By comparison, RLC’s application layer is more streamlined but less flexible in terms of directly integrating with external data-driven applications.

In summary, while both RLC and Ocean solve critical problems in decentralized infrastructure, their competing focuses often make them complementary in practice but indirectly lock users into distinct use-case pathways.

Primary criticisms of RLC

Key Criticisms of RLC: Challenges Facing the iExec Ecosystem

Despite its innovation in decentralizing cloud computing, the RLC token has faced criticism for several notable reasons. These critiques revolve around scalability, adoption hurdles, tokenomics, and the complexity of its use within the broader crypto landscape.

Scalability and Ecosystem Limitations

One primary concern with RLC is the scalability of the iExec platform. While the concept of decentralized cloud computing is compelling, questions arise about its ability to support enterprise-level demand consistently and efficiently. The iExec network relies on off-chain computing resources, yet the mechanisms for procuring this computation power at a large scale remain relatively untested in real-world scenarios. Competing with centralized giants like Amazon Web Services (AWS) or Microsoft Azure in terms of both performance and reliability is a monumental challenge. Critics argue that until the iExec platform can handle large-scale decentralized applications (dApps) with zero downtimes and comparable speed, mainstream adoption remains unlikely.

Token Adoption Friction

The role of the RLC token within the iExec ecosystem can also present barriers. Users are required to interact with RLC for payments and transactions on the platform, but this introduces friction for individuals and enterprises new to crypto. This reliance on RLC may deter non-crypto savvy developers or businesses, especially those unwilling to navigate the complexities of acquiring and managing tokens to utilize the service. Critics suggest that requiring a native utility token for access—rather than offering more interoperable fiat or crypto payment solutions—may limit adoption beyond crypto enthusiasts or blockchain-native enterprises.

Tokenomics Concerns

The tokenomics of RLC has also raised skepticism. The token’s utility is largely tied to the usage of the iExec platform, and its demand is directly correlated to the platform’s adoption. Critics point out that if iExec does not achieve significant traction or widespread commercial use, RLC risks losing its intrinsic value or remaining highly speculative. Additionally, concerns over token distribution have emerged, with some questioning whether the token is overly concentrated among early investors, team members, or developers, potentially leading to centralized decision-making in what aims to be a decentralized ecosystem.

Steep Learning Curve for Developers

The technical complexity of building on iExec further adds to the platform's challenges. With highly crypto-savvy developers as the primary target audience, the ecosystem's documentation and tooling are often deemed too niche or advanced for wider adoption. Competing platforms offer easier-to-use frameworks, APIs, and onboarding experiences, making iExec’s developer ecosystem comparatively less accessible. This could hinder the growth of dApps and result in limited network activity.

Each of these criticisms paints a nuanced picture of the hurdles RLC faces as both a crypto asset and the backbone of the iExec ecosystem.

Founders

RLC Founding Team: Key Players Behind iExec RLC's Development

iExec RLC, the decentralized cloud computing platform behind the RLC token, was co-founded by a group of computer scientists and blockchain enthusiasts with deep roots in distributed computing. The driving force behind the project is a seasoned team with a background in academic research and practical implementation of cloud and grid computing technologies, but like many crypto projects, it’s not without its challenges.

The co-founders of iExec are Gilles Fedak and Haiwu He, both recognized names in the world of decentralized computing. Fedak brings extensive experience in distributed systems, having earned his PhD in computer science at the University of Paris-Sud and worked at INRIA, the French National Institute for Research in Computer Science and Automation. Fedak’s research focused on grid computing and peer-to-peer systems, culminating in creating solutions that predate modern decentralized computing models. However, one sticking point for some investors is that strong academic credentials don’t always translate smoothly into the competitive crypto ecosystem, where agile leadership and broader industry experience can be equally important.

Haiwu He, the other co-founder, adds an international and technical dimension to the project. As a former professor at the Chinese Academy of Sciences with expertise in parallel computing and system architecture, Haiwu’s background complements Fedak’s European focus. What stands out is the strong academic focus of the founding team, which can be a double-edged sword—on one hand, it ensures a solid technical foundation for RLC and iExec's cloud infrastructure, but on the other, it raises concerns about limited direct experience in scaling commercial ventures and working in fast-paced markets like cryptocurrency.

The iExec team has consistently highlighted its origins in academia, particularly through its work on the XtremWeb-HEP project, a platform for grid computing that formed a key precursor to iExec’s distributed cloud model. While this narrative builds credibility in terms of expertise, the heavy reliance on academic and research credentials has occasionally been met with skepticism by a crypto community that often prioritizes demonstrable market execution over theoretical prowess.

Additionally, transparency around the current team structure beyond the co-founders has been somewhat limited. While the project occasionally showcases its technical and business team members in presentations and marketing, more detailed public information about the broader leadership team and their roles could help build additional trust within the ecosystem.

Authors comments

This document was made by www.BestDapps.com

Sources

Back to blog