Several Phase 1 details are still up for consideration, but wanted to at least provide a few quick updates (below) on some of the current thinking.

TLDR:

Any node operator will have the ability to join Phase {1} Node requirements will most likely remain the same, with one addition The node onboarding experience will be much better

1. Any node operator will have the ability to join Phase {1}. While whitelisting nodes might allow us to showcase better performance numbers in Phase {1}, the benefits of not whitelisting and stress testing the system with as many nodes as possible is more beneficial to protocol development/optimization at this stage. Plus this provides a better opportunity to really test the performance-based reputation system and see how it scores different nodes.

In a mainnet environment, there would be a warm up period for all new nodes where their performance would be tested prior to being allocated any real work, so less performant nodes joining the network is only a temporary issue. That part of the system will be introduced in a later testnet phase. So for now might as well take advantage of not having that in place, and seeing how the reputation system and overall performance is impacted in less optimal conditions. If the reputation system performs well, hopefully there won’t won’t be too big of an impact.

In order to get the most out of this exercise, the Foundation plans to benchmark performance of the public Phase {1} testnet against an internal test set of nodes (maybe 50) run for a few days in a controlled scenario so that it is possible to compare performance between the two environments and define where to optimize.

1. Node requirements will most likely remain the same, with one addition. The final details will be released before Phase {1} begins, but as of now, expect node requirements to remain as described in the documentation and used in Phase {0}. However, one additional node recommendation will be added which is a minimum GB/s download and upload speed.

2. The node onboarding experience will be much better. As mentioned in the previous Phase {1} blog, there will be a testnet faucet onboarding flow for nodes, which will eliminate the whole whitelisting process and onboarding delays experienced by node operators in Phase {0}. And the team is still actively improving the whole process to ensure that node operators have a seamless experience onboarding to the network for Phase {1}.

FAQ’s Q. Do I still need to fill out the node application? What if I already did?: As of now, it is not mandatory or necessary to fill out the node application to join Phase {1}. If you already did fill it out, don’t worry, it might still be used in future testnet phases.

Q. What wallets will the testnet faucet support? What network will the faucet be on?: The faucet will live on Fleek Network, but still TBD if you will need a wallet or not. The whole thing might just be facilitated via CLI and directly airdropping to nodes. If you do end up needing a wallet, most likely any Ethereum/EVM compatible wallet would work. The full and final details will be shared before Phase {1} begins.

Q. Can I run multiple nodes in Phase {1}? It is expected that the faucet will have some form of rate limiting, yet to be defined, to ensure fair access and avoid abuse. But yes it will most likely be possible to run multiple nodes. We anticipate some node operators will run nodes in multiple different geographies to help the network achieve better global coverage and geographic distribution.

Thanks to all operators and participants for the patience and feedback given! Expect further updates soon - while the core team focuses on reaching this next milestone.

If you have ideas, or feedback regarding our plans for Phase {1} - share them with the team! Find us on the Fleek’s Discord.

Fleek Foundation ⚡

With that, the road to Phase {1} begins, scheduled to begin the first or second week of October. Alongside a smoother overall experience, Phase {1} comes with a shift in focus, from the initial proof of concept and correctness of Phase {0} to a new milestone: proving performance.

Not every detail regarding  Phase {1} is decided as of now, but it is important to start sharing some early info so that all interested node operators can be prepared and can start submitting node applications when they open on Wednesday, September 20th at 12pm EST  (applications will open on Discord). Expect to see more info released in the leadup to the official start of Phase {1}.

TLDR:

• The official start of Phase {1} will be the first or second week of October; the exact start date to be announced in the next week or two.

• Primary objective of Phase {1} is to prove performance and test the first few proof-of-concept edge services deployed to the network.

• Node Operators interested in participating will be able to apply on Discord as of Wednesday 20th at 12pm EST.

• More details will be published throughout the lead-up to the start of Phase {1}

Let’s get into some details:

Phase {1}: High-Level Overview.

As mentioned, Phase {1} will primarily be about proving performance. After proving correctness in Phase {0}, the next most critical thing to prove is that Fleek Network can meet (or exceed) traditional CDN/edge-level performance in a decentralized setting.

To get a true feel for real-world performance, this phase will test the network under various scenarios, and track the following key metrics across different geographies for the different services being tested:

Key Metrics Being Tracked:

Response times, broken down into:

• Time to First Byte (TTFB)

• Time to Full Load (TTFL)

• Service Specific Metrics

Scenarios Being Tested:

• Node Count

• Request Count (Stress Test)

• Geographic Distribution of Nodes

• Geographic Distribution of Requests

• Node Slashing/Misbehavior

Services Being Tested:

• IPFS content retrieval (CDN/bandwidth)

• IPFS upload (bandwidth)

• Image Resizing/Optimization (compute)*

• Turborepo Cache Server (compute/bandwidth)*

The above are still being decided and subject to change.

Phase {1} Goals: Nodes, Protocol, Services.

Like Phase {0}, the goals for this phase are pretty straightforward. While the overall goal pivots from proving concept/correctness to proving performance of the network, the specific goals for this phase can still be broken down into 3 groups:

Node Level:

• Further understand and optimize node operation from a performance perspective

• Test throughput, quality, and reliability of services being tested

• Track request distribution amongst nodes (based on geography and reputation score) to better inform how the economic model could be optimized

• Collect cost data from node operators to better understand how resources might be priced initially at the network level

• Gather valuable insights to make further enhancements for the next phase

Protocol Level

• Evaluate the reputation/slashing/reward system

• Improved Sequencer/Broadcaster testing

• Finalize NetKit, p2p network between nodes

• Introduce Blake3 browser support

• Revamp the CLI experience

Service Level

• Initial testing of services to understand and optimize from a performance perspective

• Evaluate service performance based on different geographies, node count/requirements, service type (bandwidth, compute), stress testing, etc.

• Use the cost data collected from node operators to help ensure service/resource pricing is cost-competitive for developers (bandwidth, compute)

• Collect valuable insights to help finalize the external-facing SDK to release as part of the next phase

Testnet Phase {1}: FAQ

As a Node Operator interested in participating in Phase {1}, what should I do?

Applications for node operators will open on Fleek’s Discord Wednesday 20th at 12pm EST. This is a rolling application form in preparation for the release of Phase {1} in October.

1. Follow the instructions in the #access-guide channel and submit your application.

2. The team will provide updates in Discord to all applicants and might reach out for further information.

3. Stay tuned to updates in the #node-announcements channel regarding node hardware requirements, or preparations for Phase {1}.

Are there any incentives for Phase {1}?

You can refer to this blog for further information regarding testnet participation initiatives. In short, for now there are no direct incentives during any of the specific testnet phases, but there are several overall initiatives (outlined in the Testnet Participation section of the blog linked above).

Will Phase {1} be a permanent testnet or will it be shut down after a certain amount of time (if so how long)?

Phase {1} will not be a permanent testnet. The initial plan is to run this phase for 1 week, and if the tests being conducted perform well, this timeline might be extended.

As a developer interested in testing services, what should I do?

There will be a simple UI where developers will be able to test the initial services included in Phase {1}, but for developers interested in building services (not just using them) expect things to escalate in Phase {2}, when the Service Development Kit will be released.

Will node operator onboarding be a 'free for all' again? Or will it be different?

It will be different in the sense that we will introduce a testnet faucet and staking of test FLK tokens as the way for nodes to onboard to the network, which means there will be no onboarding queue/delay like last time. But at the moment whether it’s a ‘free for all’ again or not is still undecided, because there are potential benefits to both approaches. For example, not restricting nodes allows us to test performance with the highest potential node count, whereas whitelisting nodes gives us better guarantees that we have a more mainnet realistic environment to test performance with. So just in case we do decide to whitelist nodes this phase (or future phases), doing the application form now still makes sense.

What's new about Phase {1} compared to Phase {0}?

In this phase, several new core functionalities will be added to the network, which nodes will execute automatically:

• Service deployment and running.

• Transaction Synchronizer and Broadcaster.

• Reputation/slashing/reward system

• NetKit, p2p network between nodes

• Blake3 browser support

• Revamped CLI experience

• Integrating Fleek Network services to external stacks for testing.

• For all new additions prioritized for this phase, visit here.

Why did you pick these specific services to test?

These services have been picked specifically because they  allow for direct benchmarking against existing production metrics from third-party application mirrored services (ex. Fleek.co and other partners the Foundation is collaborating with).

If I participated in Phase {0} as a node operator, do I need to re-apply?

Initially, yes. All existing Node Operators will have their role transitioned to Node Operator {0}, determining their participation in Phase {0}. We will receive new applications for Phase {1}, and approved operators (if there ends up being any approval process) will be identified for this phase and further phases with a specific role.

Follow along with each phase of the testnet on X, and join the community of node operators in our Discord Server– see you all soon with more information surrounding Phase {1} ⚡

The Fleek Foundation ⚡

This very early test phase turned out to be a huge success, at its peak seeing 850 nodes successfully running across the network (with a lot more waiting to be onboarded). And, thanks to feedback from this phase’s node operators, the core devs have collected and started to address optimizations and improvements for the next phase– the details of which will be announced next week.

TLDR:

• Primary focus of this first phase {0} was to establish the network and prove the concept

• This goal was achieved, seeing 850 nodes at peak, most falling within 1-182.4ms latency range and a reputation score of 34 or better (Highest = 40) without any set node requirements (ex. some nodes could have been running on laptops or raspberry pis).

• Improvements for the next phase will prioritize the Broadcaster and Synchronizer improvements, with 60+ other fixes/improvements planned out of this phase.

• More information about the next phase of the testnet, Phase {1}, will be made available on Tuesday, September 19th.

Let’s dive a little deeper into some of the findings from Phase {0}, including planned improvements and performance benchmarks:

Phase 0 Focus: Proof of Concept

During this phase, the primary focus was to set the initial swarm of nodes to establish a network that operated as expected, test the consensus and base reputation/on-chain systems, as well as:

• Identify any gaps, missing, or broken systems that need attention

• Experiment with various committee sizes

• Test network configurations

• Gauge the early performance of protocol-level functionalities

Essentially, the core development team wanted to prove that the network functions as a concept, and collect necessary improvements for this planned downtime period in between phases, both of which were achieved.

With the overwhelming support from the community, the whitelisting process became a little bit chaotic. But, thanks to the chaos and lack of hard node requirements, edge cases were identified and all possible outcomes were tested (i.e. nodes going offline, not meeting requirements, etc.) throughout the phase. So the chaos was actually useful and beneficial.

Collected Performance Metrics

The one-week Phase 0 period saw some great participation from the community, with the vast majority of participants actively participating in feedback and testing. This community participation allowed the core devs to collect key performance benchmarks throughout the period– here's a closer look:

• Latency: The network maintained consistent latency results, with about 85% of interactions falling within the 1-182.4ms range. This consistency was observed throughout the phase, impressively without any set node requirements.

• Reputation Scores: Nodes exhibited varied reputation scores, with the highest being a score of 40 and the lowest at a score of 10. A majority of nodes had a score of around 34 or better.

• Node Count and Geographical Spread: The network saw 850 nodes participating at its peak, with a significant presence in Europe and the US (East and West Coast).

All things considered, these metrics are very promising because phase {0} testnet was purposefully a free-for-all so we could stress test metrics exactly like this in less than ideal conditions. For example, most of the performance degradations were due to things that would not exist in a mainnet setting (not setting any node requirements, having no value at stake, not having a formal node whitelisting process in the absence of staking, etc.).   The next testnet phase will be a more realistic environment and provide the community with more accurate data that better showcases the real capabilities and performance of the network.

Priority Improvements

Based on the insights and feedback gathered from node operators during this phase, as well as the tests and measurements conducted, the core devs have identified a few priority areas for improvement before the start of the next phase. One major finding was that the consensus mechanism worked as expected, but the transmission of messages from consensus to non-committee nodes emerged as a bottleneck.

To address this, the primary focus of the downtime will be on improving the network’s Broadcaster and Synchronizer:

• Broadcaster: Gets messages from consensus to nodes not on consensus.

• Synchronizer: How peer nodes sync unsynced nodes.

This should facilitate smoother communication between nodes and avoid a few recurring hiccups experienced during phase {0}. But even further, thanks to reports from node operators, the core devs have identified 60+ improvements they will aim to address during the period the network will be offline. You can see the full list of planned fixes and improvements here.

Phase {1}: Expect Details Next Week

The exact goals and timeline for the next phase are being finalized this week, with a strong focus on integrating the feedback and insights acquired during Phase 0, and adding in a few aspects/functionalities of the edge platform, before kickstarting the next phase.

More information and important dates for Phase {1} will be shared this coming Tuesday, September 19th.

That’s a wrap on Phase {0} of the Fleek Network rollout! Overall, it was a huge success and the community participation during this phase allowed the core devs to collect metrics and incoming improvements key to the success of the next phase.

The Foundation wants to thank all node operators and community members who participated and helped make phase {0} a success. A lot was learned, and it will definitely help accelerate the development of the network.

Stay tuned throughout the next week as more information is made available on the rollout of Phase {1} of the testnet– follow us on X and join the Discord server to be notified as soon as the next application is available.

The Fleek Foundation ⚡

During Phase {0} of testnet, the first deployment of the network will be active for a 1 week-long period (Sept 5 - 12), where we’ll run, benchmark and collect data/feedback for one week and then shut the network off to analyze, build, optimize, and publish data while the network is off. We expect a little bit of messiness/chaos by design, so that we can begin troubleshooting the network live and identify any bugs and collaborate with the community as early as possible. So if anything breaks, don’t be too alarmed.

Phase {0} Schedule:

• Tuesday Sept 5th:

  • Testnet Phase {0} starts today, 5pm EST.

  • Node Office Hours available today from 5:00-7:00pm EST in Discord

• Fridays Sept 8th:

  • Weekly Node Operator Open Call in Discord 3:00pm EST

• Tuesday Sept 12th:

  • Network shutdown and analysis.

  • Initiate optimization week.

• Wednesday Sept 14th:

  • Publish Feedback and data results.

  • And estimates for permanent testnet spin-up.

• Next steps:

  • The follow-up gameplan is determined by the success of this first week’s test. The next phase might resurface the network with services, chain upgradability, or a new Phase {0} round of testing might be required.

We will report the findings the week of the 12th, and announce the exact date for the testnet’s next phase after the first batch of optimizations.

Phase {0} Goals: Network Setup, Node & Network Metrics

The goals for Phase {0} are straightforward as we’ll be running the network for the first time in a messy-by-design environment. In Phase {0} nodes will participate in the network’s general consensus and execute a basic ping, Hello World, and IPFS retrieval services to test basic network/compute performance. We can break our goals for this phase into 3 groups:

At the protocol level

• Get the initial consensus running and prove the core protocol.

• Test the basic rewards/proof interactions of nodes.

• Benchmark the consensus performance in transaction validation/processing.

• Test the evolution of the above in different node counts/configurations.

At the node level

• Define ideal node requirements and setups.

• Measure overall node performance across them.

• Identify any limitations in setups.

• Execute basic services.

At the network level

• Form the initial swarm of nodes.

• Gather data on operational costs and setup performance impacts.

• General network topology performance mapping.

• Measure, test, and identify the overall best network settings.

Getting Started as a Node Operator

The main way to start getting involved in this phase of Fleek Network’s testnet is by running a node.

Installation & Node Approval

To get on-boarded as a node operator, not only will you need to install and run the node, but also you must visit our Discord to submit a form with your node’s key/IP to get ‘allow-listed’ to join the network. Follow these steps:

1. Join our Discord, and go to the Fleek Network Nodes Section

2. Follow the instructions in the #access-guide to get onboarded.

3. Visit our documentation and install the node via the manual/assisted installer.

4. Visit #access-form, run the node commands, and submit the information in the form. The commands needed are the following, which generate both public/consensus keys:

   • cargo run -- keys generate

   • cargo run -- keys show

5. The team will review and approve your application, allow-listing your node.

6. You will be notified in the #access-approved channel and given the Node Operator role.

7. The network will spin up and begin work today, 5PM EST, September 5th.

8. All announcements for node operators will be sent to #node-announcements

9. All Friday’s at 3pm EST we will conduct Node Community Calls in #node-stage.

10. You can ask for help in #troubleshooting, or chat with the team in the #node-operators channel

1. It’s important to note that the official run-time of Phase {0] is 5pm EST on September the 5th, and nodes will need to re-pull/re-install the binary at that time to ensure the latest version is live. You can find our schedule for testnet on Discord, or the top of this blog, and an initial hardware requirement breakdown below.

Expectations

During this testnet, we expect node operators to:

• Report any issues/feedback regarding node installation or general operation in Discord.

• Report the hardware setups utilized for the nodes being run.

• As for general operation metrics, the node will report back automatically to the network.

• Stay attentive to announcements in #node-announcements, as the team might request additional tests/feedback (e.g. running specific commands or test a mock service).

Hardware/Node Requirements for Phase 0

For testnet Phase {0}, we recommend the following initial setup:

• CPUs that adhere to the x86_64 architecture (64-bit) [Required]

• A minimum of 16GB of memory [likely to increase in future testnet phases]

• Reasonable disk space for installation, estimated at 20GB

These requirements are not final, and will be refined based on the metrics and feedback collected during each phase of the testnet.

We encourage trying different setups to help figure out optimal requirements and provide feedback in our Discord server. We’re starting with a minimum of 16GB of memory in order to make participating in Phase 0 more economical while initial loads are smaller, increasing as the loads grow or the performance shows the need.

The Road to Phase {1}

This early phase will set the network’s foundation and initial configuration in preparation for introducing the Service Development Kit in Phase {1}.

The estimated duration for Phase {0} is September, but the transition between phases depends on achieving the goals of the previous phase. As the first metrics for this phase start rolling in, we’ll be sharing results publicly.

We encourage everyone to stay tuned to our Discord and Twitter to follow-along with the progress. Again, we thank every node and developer helping us take this first step, your help is of immeasurable value!

Fleek Foundation ⚡

Find us on Twitter

Join our Discord

Everything in this document is to be considered a first draft, subject to change based on the data and feedback collected throughout all phases of testnet. The purpose of sharing a first draft is to provide clarity to prospective node operators and developers interested in participating in any pre-mainnet activities.

The goal is for the Fleek Foundation, Fleek Labs, and the community of potential network users and other participants to work collaboratively to finalize these details and implement the network launch after the final testnet phase.

Initial Testnet: Phase 0

The official launch of the Phase 0 alpha testnet will be Tuesday September 5th. We will release more detailed information regarding Phase 0 next week before the official launch, as well as tools to improve the onboarding experience. For those that are curious and eager to prepare, you can check out the Github.

Hardware/Node Requirements for Phase 0

For testnet Phase 0, we recommend the following initial setup:

• CPUs that adhere to the x86_64 architecture (64-bit) [Required]

• A minimum of 16GB of memory [likely to increase in future testnet phases]

• Reasonable disk space for installation, estimated at 20GB

These requirements are neither final, nor set, and will be refined based on the metrics and feedback collected during testnet. We encourage trying different setups to help figure out optimal requirements. Starting with a minimum of 16GB is to make participating in Phase 0 more economical while initial loads are smaller, but we anticipate that requirement to increase as testnet progresses. But if your Phase 0 node is struggling, we recommend bumping to 32GB.

Road to Mainnet: Phases 0-5

Fleek Network will utilize a multi-phase approach to rolling out mainnet. The current high level plan, set out below, depends on a variety of factors and may change in response to development timelines and/or data/feedback collected throughout the different phases. Each phase has its own purpose and goals, details of which will be shared prior to the start of each phase. We expect to update the community about any significant changes to the below plan in advance, to the extent we can:

• Phase 0 (September 5th): Node Rollout

  • Initial network and node testing (performance, hardware specs, clustering, costs, metrics, etc.)

• Phase 1 (mid-late September): SDK/Service Rollout

  • Introduce the SDK and test the building and utilizing of services on the network, as well as some optimizations based on Phase 0.

• Phase 2 (October): Initial Economics Rollout

  • Introduce and test a more concrete version of the economic algorithm, including staking, pricing, and other elements/situations using test (valueless) tokens, as well as some optimizations based on Phase 1.

• Phase 3 (November): Layer 2 Contracts Rollout

  • Introduce a test version of the aspects of the protocol that will live on an Ethereum L2 (staking, deposit and token contracts, communication between L2/FN, etc).

• Phase 4 (December): Final Rollout

  • Introduce the final form of the first generation of the network, based on all data/feedback and optimizations throughout all the phases, and allows testing of what a realistic mainnet environment will be like.

• Phase 5 (Q1 2024): Mainnet Launch

The goals for all stages involve completing and revising the following:

• Network performance

• Hardware/node specs

• Sandboxing of services

• Packaging and pricing of initial network resources/commodities

• Parameters related to the FLK token

• Security testing/auditing

• Criteria for allocation of pre-mainnet community tokens

Testnet Participation

For those interested in participating in any testnet phases or pre-mainnet activities, below are a few Fleek Foundation initiatives that are important to consider:

• 1% of the Total FLK Token Supply is allocated for the pre-mainnet community

  • The exact allocation of that 1% to node operators, service builders and users has not been determined at this time. That will be determined closer to the launch of mainnet. A criteria/point system will likely be used to ensure any distributions are based on what brings value, and to leave out sybil attackers or airdrop farmers, similar to how many other projects are currently doing airdrops.

• Reputation Score Building

  • Nodes will be able to begin building their reputation during testnet. That reputation can be carried over to mainnet, which is important because work in the network is allocated to nodes primarily based on the nodes’ reputation.

• FLK Node Purchase Program

  • For certain node operators who perform well during the testnet, the Foundation (through a subsidiary entity) may allow these operators to buy FLK tokens directly prior to, or just before, mainnet launch so that they have the tokens they need to participate and so that there will be good node coverage at mainnet launch. Any such offer would be made separately and only to node operators who are non‐U.S. Persons located outside of the United States.

• FLK Grants

  • An additional portion of the total FLK token supply is expected to be reserved for grants/airdrops (tentatively, 20%). Additional grants may be made by the Foundation during testnet to specific node operators, service builders and/or users on a case-by-case basis for building meaningful features for the ecosystem. The Foundation will provide further information on the grant proposal process at a later date.

Resource Pricing

To start, Fleek Network only plans to charge for bandwidth and CPU cycles consumed. Pricing will be set at the network level, and resources will be priced and paid for in USD denominated stablecoins. The exact pricing methodology will be determined and finalized throughout the testnet phases based on different factors. Those factors include:

• Cost data the Foundation collects from node operators during testnet

• The final specs of the SDK (which will determine what data the protocol can verifiably collect from nodes and reliably charge for)

Please be aware, there will be no fees paid during any of the testnet phases, the above is solely for illustrative purposes to give nodes a better understanding of the current thinking and what the process to finalize resource pricing might look like. We will work collaboratively with node operators throughout testnet to fairly determine resource pricing to ensure appropriate node incentivization while offering competitive pricing to developers.

It’s also important to note that node operators are independent of the Foundation, the network, and each other. They are responsible for managing their own economics, including any taxes payable in any jurisdiction relevant to them due to their participation in the network.

The FLK Token:

FLK is a staking token that is an integral part of the Fleek Network. Nodes running the Fleek Network client software are required to obtain and stake FLK in order to participate in the network and to have the opportunity to earn fees for providing work. Below is some high-level information on the anticipated characteristics of the FLK token:

• Stake amount per node is set/managed at the protocol level, and consistent across all nodes

• Work is allocated based on location (latency) and reputation (performance)

• Resources on the network are priced and paid by users in USD denominated stablecoins

  • Pricing of resources happens at the network level.

• Nodes only receive rewards related to work they perform, based on resources used/consumed (including FLK rewards)

• FLK rewards are paid out per epoch (~24 hours). The FLK reward pool for each epoch is split proportionally between nodes who performed work during that epoch, calculated by the amount of USD revenue each node earned compared to the total revenue earned during that epoch.

• 20% of the total FLK token supply is set aside for staking/rewards. The actual rate of rewards/inflation will be algorithmically controlled and updated based on network usage and other factors such as market price of FLK.

DISCLAIMER: All information in this post about the FLK token and other elements of the Fleek Network is being provided solely for informational purposes and does not constitute an offer to sell FLK tokens, or a request for such offers, in any jurisdiction. There are currently no plans to sell FLK tokens. If FLK tokens do become available, you should not rely on the information in this blog post in making purchasing decisions, as the blog post was not prepared for that purpose and there will be important additional information to consider. In addition, we will likely publish further blog posts with updated information about the platform launch.

ALTHOUGH THERE ARE NO PLANS TO SELL FLK TOKENS AT THIS TIME, FOR THE AVOIDANCE OF DOUBT, IF FLK TOKENS EVER WERE TO BE SOLD, THEY WOULD BE OFFERED FOR SALE ONLY OUTSIDE OF THE UNITED STATES TO NON‐U.S. PERSONS, PURSUANT TO THE PROVISIONS OF REGULATION S OF THE U.S. SECURITIES ACT OF 1933, AS AMENDED (THE “SECURITIES ACT”). THE OFFER AND SALE OF FLK TOKENS WILL NOT BE REGISTERED UNDER THE SECURITIES ACT, AND MAY NOT BE OFFERED OR SOLD IN THE UNITED STATES ABSENT REGISTRATION OR AN APPLICABLE EXEMPTION FROM THE REGISTRATION REQUIREMENTS.

Algorithmic Economic System

The TLDR of the current implementation being discussed is that the network will handle the economic system/inflation algorithmically, using a concept we are calling NME, which stands for [N]et present value (npv) [M]arket price [E]quillibrium.

The algorithmic economic system has several goals, listed below in order of priority:

• Provide an opportunity for receiving consistent blended earnings to node operators based on their work in most market conditions

  • “Blended” means taking into account both the USD stablecoin fees that nodes are earning, as well as the FLK rewards they are earning (including factoring in the time-weighted average market price of FLK).

  • This means if network usage/revenue increases, FLK rewards will likely decrease, and vice versa. This also means that if the time-weighted average market price of FLK increases, nodes should reasonably expect that the amount of FLK rewards will decrease, but the value of FLK rewards received (in USD terms) will remain approximately the same.

• Don’t overcompensate nodes, especially in times of market volatility

  • If the market price of FLK deviates from the NPV calculated in-protocol based on time-weighted average protocol-level revenue, nodes should reasonably expect that FLK rewards by number would be reduced.

• Keep the network economy in equilibrium in most market conditions

• Provide better incentives to node operators that are long-term aligned

The algorithm driving the above system will run autonomously in-protocol. However, we anticipate that certain parameters of the algorithm may be treated as parameters that can be adjusted/updated with a network governance proposal, as needed. We currently anticipate that the parameters that can be adjusted will be:

• Maximum FLK inflation/reward rate

• Resource pricing (bandwidth, compute, etc.)

• Average cost of running a node

• Target node margin rate

• Stake amount (# of FLK) per node

• Discount rate

• Time-weighted average market price of FLK

• Maximum stake lock time

• Stake lock multiplier

Protocol-Owned Liquidity

In addition to the in-protocol algorithmic network economic system, the DAO/protocol will also manage 5% of the FLK token supply, which we anticipate will be set aside specifically to allow the community to take certain actions intended to provide long-term benefits to the network’s ecosystem and to help maintain the intended balance in the network economy. It will behave based on predetermined conditions and rules that are publicly auditable. The high level function would be the following:

• Set limit asks to sell tranches of FLK tokens at different price levels in the event of a market price increase that deviates from NPV

• Set limit buys to buy FLK tokens in the event of a price decrease where market price is lower than the current NPV

Benefits:

• Helps keep the economic system in equilibrium by using protocol owned FLK inventory to absorb volatility

• Generates additional revenue for the protocol by capturing fees related to these activities

• Provides better liquidity for node operators who might want to liquidate a portion of their FLK rewards

• Smooths out volatility/price changes in periods of extreme market fear/greed

FLK Token Distribution

The following is an initial rough draft of the potential FLK token distribution, subject to adjustments or revisions.

Overall Distribution

Community Distribution

As a reminder, all information presented above is not final, and is subject to debate, change, and input from both the testnet results/metrics and the Fleek Network community. The Fleek Foundation is open to all inputs, and welcomes the community to share thoughts or ideas via Fleek Network’s communication channels (Discord, Twitter).

The Fleek Foundation and Fleek Labs are excited to kick-off the network’s testnet phase and begin collaborating with the community on the Road to Mainnet.

Fleek Foundation ⚡

Find us on Twitter

Join our Discord

Let’s set the stage: This is not the full release of the new Fleek app. Today marks the start of our initial closed testing phase, leading up to an open testing period, and later in September, the full v1 release of the new app.

We wanted to draw a line in the sand in August to go public with a release, and force us to start gathering feedback early, and stress-test the platform before opening up with migration tools to move from Fleek.co.

It’s an early release, not final, and it will be iterated upon. And that’s where testers come in to help ⚡Here’s how to join as a tester.

Become an Alpha Tester

We're opening the app for users to test it and provide feedback during this closed alpha period. Applications start today on Discord! We will start approving and welcoming testers to use the app over the coming days!. It’s super easy to get involved:

1. Apply: Join our Discord, and visit the #FLEEK.XYZ-ALPHA-TEST section to apply.

2. Hold: The team will approve your submission and notify you in the #Whitelisted channel!

3. Learn: Check out our documentation early to get prepared.

4. Test: Once approved, sign up to the platform and tell us what you think on Discord.

It’s important to note: that you can apply with an email, or a wallet, and you need to sign up with the same wallet once approved.

As an alpha tester, get early access to a few familiar features we’ve been improving for the release of the new platform. Here's a quick overview of what you can start testing on as soon as approved.

Closed Alpha Features: Hosting, Templates, Storage, Gateways

Hosting

Get a web3 app live on web3 infrastructure, Fleek’s bread and butter. Connect your git provider, input your build details, and deploy a site as fast as Fleek, now backed to Filecoin/Arweave and served via IPFS. Deploy a site of your own or try one of our templates, directly on the new UI.

ENS, DNS, IPNS

Configure ENS domains to serve as access points for your sites on Fleek, with automatic and gasless updates; or a traditional DNS. You can also create and manage IPNS records, changing the associated hashes on-demand.

Storage & Gateways

Store your files on Fleek! Upload files & folders, and try our new decentralized storage layer, using Arweave/Filecoin as the base layer, with a common IPFS addressability layer on top. This includes setting up custom gateways to access your storage content.

Templates

A newcomer to the platform, templates! Kick-start your new decentralized app with a boilerplate, or one of our use-case templates. Pick from our library, and soon build your own and submit it to our templates hub for the community to use.

A Note to Fleek.co Users

Fleek.co users might be wondering about what will happen to their projects when we make the transition from Fleek.co to Fleek.xyz. Don’t worry– nothing is changing right now. Simple migration tools and guides will come a little later down the road in September to help you onboard. In the meantime, apply to become a tester and get an early preview of the new and improved platform.

Read this FAQ for more details on testing the new app as a Fleek.co user!l 🤙

Wrapping it Up

Remember, what you're seeing now is just the closed alpha of Fleek.xyz. If you don’t end up getting approved for this closed testing period, don’t worry! The open V1 is just around the corner, with the full release of the platform following shortly after in September.

If you’re as excited for the release of v1 of Fleek.xyz as we are, apply to become an alpha tester and get hands-on with the new platform. We’re looking forward to seeing feedback from the community, and we’ll see you soon with the open testing period of the platform ⚡

Follow along with the release of Fleek.xyz here!

What does the new path look like? Here’s the good news:

• We’re now building NFAs on top of ENS names (rather than having a separate NFT).

• The new NFA’s also leverage the omni-chain capabilities of LayerZero open-edition NFTs.

• As well as verifiable DNS records through 3DNS.

• Making NFAs simpler, more usable, easier to verify & integrate, and multichain.

So now, any web3 project already using ENS can easily turn on NFA capabilities. And if they already use Fleek, it will be as simple as a click of a button ⚡

Expect a first version to launch in late September or October (depending on some external timelines out of our control). We promise it will be worth the (extra) wait. Now let’s dive in a bit deeper.

NFAs Revamped: Leveraging ENS, LayerZero, and 3DNS

Our revamped strategy is super simple:

1. Use ENS name NFTs as the master NFAs rather than creating a separate NFT.

2. Store the metadata for builds and modules as text records directly in the ENS name

3. Verifying the DNS associated with the app via 3DNS (and having the ENS name NFT own the 3DNS NFT for that domain via ERC6551).

4. Mint the NFA prints (the one's users mint/hold) using LayerZero’s open-edition omni-chain NFTs, allowing users to hold them on any LayerZero-supported network.

Why The Switch to ENS?

Using ENS is a no-brainer because:

1. It streamlines the NFA creation process for a lot of projects by using an existing NFT (ENS name) that they essentially already use to represent their app.

2. By using ENS, we can eliminate the necessity and complexity of creating new contracts/standards, which require expensive audits, upkeep, and new trust assumptions.

3. ENS already has built-in features for IPFS/IPNS, as well as a ton of integrations to wallets and other projects that might play an important role in surfacing, accessing, and minting NFA’s (similar to the role they play with other NFTs or ENS names).

4. It simplifies the NFA architecture and helps eliminate certain aspects of it, such as verification of ENS owners (bc now the ENS name NFT is the owner, so it’s auto-verified)

How: We're using ENS name NFTs as the master NFAs, saving each NFA’s build metadata and modules in the corresponding ENS name as text records that point to IPFS/IPNS hashes, just like we do for the IPFS sites themselves today.

Why LayerZero?

Bringing in LayerZero for the NFA prints takes things to another (omnichain) level:

1. Prints aren’t restricted to living on just one network

2. Prints can live on a different network than the master NFA (the ENS name)

3. Even with being on different chains, the print NFA’s always verifiably read from the master NFA (the ENS name)

4. Users can mint print NFA’s super cheap or even free, even with having the ENS name on Ethereum.

How: LayerZero will act as our multi-chain connector, making sure prints are versatile and accessible across supported networks. Each print will have its metadata tied to its main ENS name’s token ID. Developers will be able to choose which chains their NFAs are available for users to mint from. Similar to holographic NFTs, but we would deploy print contracts on each Layer-Zero-compatible chain, with the appropriate NFA data.

Why 3DNS?

3DNS is a new and exciting project that helps take NFAs (and decentralized frontend hosting as a whole) even further:

1. With 3DNS we can ensure verifiable DNS records and updates on NFAs.

2. It's already compatible with ENS and adds a new dimension to DNS records– turning them into NFTs that the ENS name can own via erc6551 (token-bound accounts).

3. All updates to the DNS records associated with the domain happen on chain, and can only be changed by the owner of the domain NFT (which in this case would be the ENS name)

4. Forcing DNS record changes on-chain provides better security to end users by reducing chances of a hack/malicious updates resulting in loss of funds

How: 3DNS, compatible with Internet Corporation for Assigned Names and Numbers (ICANN), will operate as the on-chain name server. This will bring ENS-type benefits to DNS names, while still providing the traditional DNS benefits (ICANN compatible, works natively in all browsers, etc.).

[Bonus] Can PWA’s Fit In With NFA’s?

Yes definitely. With friend.tech and the current issues plaguing web3 apps in traditional app stores (ex. Apple), the recent resurgence in PWA’s is definitely worth paying attention to. And we think there could be a lot of synergies between PWA’s and NFA’s. Any PWA could be an NFA, and any NFA could become a PWA. You could now potentially imagine a future where there is a decentralized, permissionless app store (which could be built on top of the NFA collection), where you could discover and mint/install ‘apps’ on your phone home screen or in a wallet, but where the app is hosted/loaded on-chain and accessed with no central operator. Def a lot to still explore and figure out, but the future looks bright (and decentralized) 🤙.

And that’s about all for this update! We just wanted to be transparent on why NFAs won’t be introduced with the new platform initially, and give everyone a heads-up on where development is currently. We’re super excited about the new direction NFAs are headed and can’t wait to roll out the finished product.

If you have any questions about NFAs, the new ENS-oriented approach with LayerZero + 3DNS, or anything else related to the new Fleek platform, our team is always open to chat in our Discord server.

Follow along with the release of the new Fleek.xyz platform here!

As the industry has watched Ethereum’s state grow, multiple approaches to address the issue have emerged over the past few years. Things such as subnets and sharding are some of the more popular current approaches, but they focus more on splitting state, not necessarily eliminating it. But with the emergence of zero-knowledge proofs, now a new stateless trend is emerging, and there’s a good chance it’s the best approach to address the issue.

Ethereum is already all-in on the stateless direction. Vitalik and other researchers at the foundation have been talking about it since 2021. And they’ve recently announced they are prioritizing statelessness as one of the next big protocol upgrades. Fleek Network is embracing statelessness as well, but in a very different way (stateless execution rather than blockchain state). So we thought it’d be helpful to dive deeper into this trend and what it actually means.

The Statelessness high-level TLDR is:

• Most current popular state scaling solutions (sharding, subnets) focus on splitting state.

• While splitting state is useful, statelessness or eliminating state would have a bigger impact on addressing the issue.

• The emergence of viable zero knowledge proofs has opened the door for different approaches to statelessness, meaning using proofs for verification instead of state.

• Ethereum is implementing it via state expiry and weak statelessness, meaning their nodes don’t need to hold historical blockchain state, but their execution remains stateful.

• Fleek Network’s approach involves having nodes keep a very succinct blockchain state, but not having any execution state by default.

Now let’s dive deeper.

Most current popular solutions focus on splitting state, not eliminating it.

The current popular approaches (sharding, subnets, rollups), focus on state division and parallelization. It can be an effective solution at a certain scale, but the complexity of synchronizing state splits and coordinating separate shards/subnets/rollups is not trivial. While optimizations like Danksharding will continue to improve the splitting approach, it’s likely that if eliminating state were an option, it could unlock significant simplicity, cost, performance, and decentralization benefits.

Ethereum has known statelessness is the answer for a while.

This is not a new conversation, and solutions have been in debate for years now, ever since the statelessness roadmap proposed by Vitalik back in 2021 - together with Dankrad Feist’s statelessness breakdown.

The recent prioritization of statelessness over sharding makes a lot of sense. Because if you can figure out how to eliminate state, that’s much more impactful than figuring out how to more efficiently carry the forever-growing state.

The emergence of zero-knowledge proofs has opened the door for statelessness

Most of the current solutions mentioned above for scaling state (sharding, subnets, etc.) were ideated before proofs/zk were a legitimate viable option. But now that they are a viable option, they enable entirely new design patterns for protocols. For example, allowing for the execution of compute/services off-chain or in a stateless manner and just generating cheap proofs to be posted on-chain and used for verification. One of the best early examples of this paradigm shift was Mina Protocol, utilizing ZK to maintain an extremely light chain with constant state size of 22kb that is just recursively proving state every block.

How Ethereum’s Statelessness Works

State expiry / weak statelessness, implemented together, can allow for simple pruning of state and also allows the utilization of proofs to enable witness clients to be able to verify a certain piece of information existed at a certain position/moment of state - without needing to store a full archival node (e.g. via Merkle proofs). To avoid confusion, Ethereum will still have state, this change just means that nodes will no longer need to carry historical state, but rather they can just prove historical state at the point of execution using verkle trees.

In short:

1. The concept of a state tree per period (~= 1 year) would be introduced.

2. When a new period begins, a new state tree is initialized and used onwards.

3. Newer trees always take precedence in information.

4. Only the two most recent trees can be modified, by creating copies into the new tree that supersede the old copies.

5. Full nodes only are expected to hold the latest 2 trees, readable without using witnesses.

6. For reading past data, a witness/proof constructed to proof past state/tree data (<1mb proof, utilizing verkle tries)

The other alternative proposed, state rent, is similar to a CDN model where it would require a continuous payment to maintain a piece of state in memory for a certain period of time. While an interesting approach, it carries certain complexities described in the latter sections of this article:

• Would eventually be replaced by weak statelessness

• Introduces a UX hurdle in rent handling

Side note: The fact that state rent is similar to a CDN model is not lost on us. We are excited to explore how Fleek Network could potentially help other protocols keep state hot 🔥

How Fleek Network’s Statelessness Works

In the case of Fleek Network, statelessness means something very different. It means not having any execution state by default. The execution of services on the network by nodes is stateless, while the network just keeps very limited state focused on:

• I. Token Balances (FLK token and stablecoins),

• II. Staking information

• III. Node Reputation

• IV. Data on how much work a node has performed in a given epoch.

Nodes perform work/execution off-chain and just periodically submit batches of successful delivery acknowledgment proofs to the network in order to get paid. Doing this keeps the overall network extremely light.

It’s important to clarify that while the core protocol is stateless,  developers can still have state at the service level by relying on external data availability/storage layers or building state into their service (similar to the state rent concept from Ethereum mentioned in the previous section).

If interested, you can follow the implementation of the above and provide feedback on Fleek Network’s Github.

How Fleek Network Could Potentially Help Protocols Embrace a Stateless Future

At a basic level - by Fleek Network itself offering stateless execution, any protocol, middleware, or app that builds and/or utilizes services on Fleek Network will inherit the same benefits that statelessness provides to Fleek Network itself (lower latency, lower cost, edge-optimized, etc.).

At an advanced level - as mentioned above in the Ethereum section, we might be able to help different protocols keep state ‘hot’ in a trustless, verifiable, and cost-effective way. Similar to how a CDN/Edge keeps files and data hot/cached in different geographic regions to serve it performantly, the same could apply to state. You could essentially treat the protocols (Ethereum, DA layers, storage layers, rollups, etc.) as the state origins/storage layer, and Fleek Network as the hot state/cdn/edge layer.

Conclusion

Statelessness is an emerging trend that is certainly worth keeping an eye on. Ethereum is embracing it, and so is Fleek Network as well as a growing list of other protocols. However the definition of statelessness is not uniform, and it is being applied in many different ways (blockchain state, execution state, etc.) When it comes to scaling state/combating state bloat, statelessness very well could become the best long-term solution that has the biggest impact on mitigating the issue. As we continue to build out Fleek Network, we’ll keep discussions and research open to help keep pushing this trend and blockchain scalability forward.

If you have thoughts, feedback, or further research to share that can expand, improve or challenge our current approach - feel free to reach out, we’d love to chat and jam on this topic. Find us on Discord and spark a conversation!

Fleek Network team ⚡

Find us on Twitter

Join our Discord

It’s an interesting time to be building a Web3 protocol. There are an abundance of options to choose from across the entire stack, each with their own set of tradeoffs. Whereas before everyone had to essentially ‘roll their own chain’, the growing shift towards blockchain modularity has now opened up the design space for building protocols quite drastically, where many core aspects across the stack can be outsourced.

From optimistic and zk rollups, validiums, app chains and side chains, sovereign chains/rollups, shared security and borrowed security, data availability/publishing, sequencing and proving, etc. There are a lot of factors to consider.

And while the optionality and customizability is great, it also gives you a lot more to consider. Properly evaluating each option and the nuances between them, especially as they relate to your specific use case/considerations, can be a huge undertaking.

We figured it might be helpful to others to share a bit about our exploration and outcomes regarding that process and deciding on an initial architecture for Fleek Network. The TLDR is that:

• For EVM compatible chains, being an L2 makes a ton of sense

• For non EVM chains, the benefits of being an L2 (vs. app chain/sidechain) aren’t as clear currently, especially when considering the cost difference

• Proving consensus (sidechains, zk bridges, IBC, etc.) could be a more cost effective approach for non-evm chains rather than proving all your execution (L2’s)

• Using EigenLayer to rent economic security from ETH coupled with a sidechain (proving consensus) could potentially give you the best of both worlds (lower cost + better economic security), but more research is needed.

What even is an Ethereum L2?

There are a lot of great technical definitions out there that you can read. But there is also a bit of ambiguity currently when it comes to defining what constitutes an Ethereum L2, and who does/doesn’t qualify as one. But if you ask us, the simplest layman definition we have come to use for an Ethereum L2 is:

Ethereum has the final say on the state of your rollup/blockchain, in a way that users don’t need to trust the rollup/blockchain operator.

Why did Fleek Network want to be an Ethereum L2?

Mainly to borrow the security of ethereum rather than try to build our own. And the reason we want to do that is because in most cases it’s much cheaper and easier to rent economic security rather than buy/build it.

That’s the whole alt-L1 vs L2 narrative/argument. For an alt-L1, they need to stand up their own economic security and pay out high inflation rewards in their native token in order to sustain the proper security parameters that keep their decentralized system safe and functioning properly. Or in other words, the value of their token has a huge impact on the safety, security, and sustainability of their service.

But if you could just rent that from Ethereum, you could get the same or better economic security for much cheaper, and you could build much faster compared to trying to do it all yourself. Plus there are additional positive network effects to being an L2, like lower barrier to entry for existing Ethereum users to try your product.

So should every new protocol be an Ethereum L2?

No. What we’ve learned is that being an L2 makes a ton of sense for EVM chains. But not necessarily for non-EVM chains, at least not today. That is because in order to be an L2 you need to rollup all your execution onto Ethereum, which can be expensive.

For EVM chains it makes sense because just by economies of scale they are able to reduce gas costs by bundling a bunch of EVM transactions together and submit them to the L1 in batches rather than one by one. But for a network like Fleek Network that is non-EVM (FN core doesn’t use a VM), it would be prohibitively expensive to rollup all our execution data to Ethereum without any meaningful added benefits to justify the cost.

That is because we wouldn’t be rolling up EVM call data, so the benefit of posting it to Ethereum would be muted by the fact that Ethereum couldn’t really do anything with the data.

What would it cost Fleek Network to be an Ethereum L2 vs a Sidechain?

Being an L2 would make Fleek Network significantly more expensive to operate. Because as mentioned to be an L2 you need to roll up all your execution data onto Ethereum, which is the biggest cost associated with L2 rollups. Whereas if Fleek Network decides to just be a sidechain, then we can avoid that cost of posting all execution data to Ethereum, and instead just carry out a proof of execution within our network, only posting proof of consensus when someone bridges out.

So as long as someone is comfortable with Fleek Network consensus and how it works, then you would have similar security guarantees as an L2. The guarantees wouldn’t be as good as a pure L2, but they are still good, and the cost difference makes it a worthwhile tradeoff for some use cases:

Cost per Interaction as an L2 (as of today)

1 Fleek Network Delivery Acknowledgement SNARK: 116 bytes
Ethereum Call Data Cost: 68gas per byte
Current Gas Cost: 50 gwei (Aug 2, 2023)

=

370,736 gas or 0.0004 Eth or: 

~$0.73 per interaction

And that cost per interaction doesn’t include the actual cost of the work performed (ex. CPU, Bandwidth, etc.). So being forced to post all that data on Ethereum would be prohibitively expensive.

Yes, with 4844 and EigenDA those costs could be reduced, but it still would be more than we would like for a use case where every penny matters (web services pricing).

Cost per Interaction as a Sidechain:

~$0.0001 per interaction

Basically the little cost we do have as a sidechain is an indirect cost passed off to the users of Fleek Network when they deposit/withdraw tokens (FLK, stablecoins) to stake or pay for services on the network or claim fees for work performed.

Essentially the cost is the gas they pay in those transactions. And since deposits/withdrawals happen a lot less frequently than interactions on the network, the cost is shared across a large number of interactions, and by using L2’s we can reduce that cost even further.

Why does the difference in cost between L2’s and Sidechains matter so much for Fleek Network?

1. Since we don’t use the EVM, we don’t get the same benefits that an EVM compatible chain gets for rolling up execution data to Ethereum (ex. Ethereum can’t prove the correctness of non EVM state). So we’d basically just be incurring additional costs to the network and impacting node profitability for no additional benefits.

2. EVM compatible L2’s are all competing against Ethereum (and other L2) costs, and are therefore a bit less price sensitive because everything is relative to Ethereum costs. Fleek Network is competing against Web2 cloud platform prices where every penny matters, so we must be able to justify every cost the network incurs.

Are there other benefits for Fleek Network not being an L2?

In addition to the cost benefits, there are other benefits such as:

1. Instant finality (instead of needing to wait for Ethereum block times to finalize transactions on Fleek Network)

2. Higher throughput (by being able to leverage our own Narwhal & Bullshark consensus)

3. Less friction (no gas costs need to be passed along to clients/users)

4. Better performance (not needing to rollup execution keeps the network/nodes leaner)

5. Don’t need a sequencer (since we don't need to roll up our execution data)

So Fleek Network isn’t an L2. Is it a side chain then?

Yes technically it’s a side chain, based on the correct definition of an L2. What this means is we have our own network of nodes that come to consensus (Narwhal & Bullshark), which allows us to have the throughput, finality, and costs we need for an Edge Network. But we also have plans for things that make us more than just a sidechain.

For example we are evaluating using EigenLayer to rent economic security from Ethereum to achieve the same goals that made us want to be an L2 in the first place, which is that “in most cases it’s much cheaper and easier to rent economic security rather than buy/build it”. That basically gives us the benefits of having our own consensus (instant finality, higher throughput, etc.), but still enjoying most of the benefits that L2’s get from renting economic security from ETH.

The difference being we get the benefits via EigenLayer re-staking and therefore don’t need to post our call data to Ethereum so we can keep costs low.

So Ethereum Sidechain + EigenLayer = L2?

Not exactly. It’s more like an in between. But it definitely gets you pretty close to the qualifications, benefits, and security qualities of a pure L2, but with a lot less constraints (cost, throughput, finality, etc.).

We aren’t quite sure what this setup is called, but I’m sure the Ethereum/EigenLayer communities will come up with something cool. In our opinion this setup could give you great balance between an L2 and a sidechain.

Are you worried that this EigenLayer setup will negatively impact native tokens?

Not really. Because besides the tokens actually trying to be money (ex. BTC, ETH), the value of most of these utility tokens shouldn’t be based on their money-ness. It should be derived from the cash flows of operating/performing work within the network, much like taxi medallions. And so borrowing economic security from ETH via EigenLayer shouldn’t negatively impact that analysis.

If anything, it could potentially help drive usage/adoption to new protocols/networks using this setup because they will have better safety/security characteristics and token-economics vs. alt-L1’s who need to entirely role their own economic security, which is typically entirely based on the value of their own native token.

As we continue to develop the network and take on decisions such as these where it’s not always so black and white, we will openly share our decision-making and thought process. This way if we make a mistake in our analysis hopefully someone will notice and help us correct it ahead of time.

So we invite anyone to reach out if this blog sparked any thoughts, questions, suggestions or criticisms. We’re always happy to jam on this topic and are very open to feedback/being corrected.

Fleek Network team ⚡

• Find us on Twitter

• Join our Discord

The new paper details the approach and purpose behind building Fleek Network as a decentralized edge platform that can power not just a web3 CDN, but a wider array of web and edge services that anyone can build and utilize.

1. Read the new whitepaper⚡

2. View the open-source repo⚡

3. Ask Questions in Discord⚡

4. Come to the Q&A Space this Thursday⚡

Similarly to the modern web, web3 is moving towards modularity. Fleek Network’s edge architecture provides a decentralized performance layer that any app, service, middleware, or protocol can leverage to optimize their speed/latency instead of needing to build that layer themselves  or compromising web3 values by using Web2 performance layers like AWS or Cloudflare.

From traditional web services like decentralized hosting CDN, edge functions, etc. to web3-native ideas like decentralized pinning, ephemeral rollups, proof generation, and sequencing… we’re excited to explore what can be built on this edge layer. Stay tuned for our initial testnet release next month, where we’ll set the foundations for the network, prove out the performance, and allow developers to begin experimenting.

We hope you enjoy the paper.

Fleek Network team ⚡

• Find us on Twitter

• Join our Discord

Performant and verified content addressing & streaming of all data, from files cached by the CDN service to a JS function to be computed by a service that passes through Fleek Network and its services. How is that achieved? By using Blake3, a content hashing algorithm.

The TLDR is that Fleek Network:

• Is content addressable at its core, addressing all data by content hashes.

• Uses Blake3 to hash stream and verify data in chunks, with parallel processing.

• Provides proofs of file size and streaming of specific segments of a piece of data.

• Uses a streaming library based in BAO, with optimized chunking/verification.

• Enables full verification without sacrificing performance/latency.

What does it mean that Fleek Network has a content addressable core?

As we shared in our previous blog, edge networks at their core apply the concept of geo-distributed work allocation, to not just the caching/serving of data (CDN), but to an additional suite of web and edge services (compute, SSR, databases, container orchestration, etc.). Think of it as a CDN sitting on top of not just data being cached and served, but on the requests for all services (ex. a client requests a serverless function to execute) and the corresponding responses (ex. a node replies with computed result).

This means a lot of data is streamed in edge networks for MANY purposes, between nodes and clients. And the same applies to Fleek Network.

To achieve that in a performant way, in a nutshell, the network bakes the core primitive of IPFS (IPLD) and content addressability (using Blake3) into the network. All data in Fleek Network is linked and addressed via a hash that represents its content. If the content changes, it will be represented by a new/different hash. More so, files can be divided into pieces/chunks for efficient streaming, and each chunk receives a hash which represents that chunk as part of the file as a whole.

These sub-hashes are not stored and ephemeral, and given Blake3’s efficiency, it allows clients to compute them on the fly and verify that they belong in the file as a whole. How fast? We can stream data and verify it trustlessly with virtually no latency ( ≈45 nanoseconds).

What’s the relationship between Blake3 and IPFS/IPLD?

Blake3 is an IPFS compatible content hashing algorithm. Both IPFS and IPLD support the usage of Blake3 hashes (among other hashing algorithms). We decided to use Blake3 for Fleek Network because of its overall performance and features that align perfectly with the edge network use-case.

If Fleek Network fetches any data from IPFS that has been hashed with a different algorithm, it will simply receive those other hash types and map them to their Blake3 equivalent hashes to maintain Fleek Network’s standard and efficiency while still maximizing compatibility and flexibility regarding hashing.

What are the overall benefits of using this approach?

The main benefit is being able to achieve full verification without impacting performance/latency. For example, the network streams data piece-by-piece. Blake3 allows us to verify this data along the way, chunk by chunk - allowing us to still deliver files in a performant way, without its verification hindering performance. This means:

• If the file fails mid-way, the verification will catch it earlier than later.

• If everything is ok, the end-client gets data procedurally, and faster.

• Given files are chunked, multiple nodes can parallelize and help stream the data faster.

That’s not just great for use-cases like video streaming, but to also propagate data across nodes on Fleek Network extremely fast if, for example, they need to quickly scale up a compute function to a lot of new nodes.

Also, since file hashes are very small in size (i.e a 1600 Petabyte file would still always produce a 32 bytes hash) optimize the entire network’s system of inter-node communication and interaction: when nodes gossip/communicate, they speak of hashes, not “full files”. Overall, it’s a great performance optimization across the network and several functionalities.

What's Blake3 Role in this?

Blake3 in short is a hashing algorithm. It does not handle the processing of data or fetching keys, it simply takes the data and provides the appropriate hash. The network uses this hash to address and retrieve data, and because Blake3 uses merkle tree structure to generate this hash, it can verify the content/data as it is received incrementally (chunk by chunk). Blake3 starts at the bottom of the tree, and builds its way up to the root hash determining the data is complete.

In a distributed/decentralized system, trustlessness is key, and Blake3 enables trustless data streaming at a performance level ideal for a decentralized edge network and on par with centralized alternatives.

The root hash represents the whole file, and then Blake3 works its way up the tree in pairs to verify the data chunk by chunk. MO and M1, as hashes, also represent the pair of hashes below (and so on).

How is verified streaming optimized?

We have built a custom data streaming/verification library, based on BAO, that allows the sending of an early pruned tree, and procedurally handles the rest when needed. The receiver only needs enough to verify its way up from the bottom to the root hash, not the entire horizontal tree. So, we can bring our scissors and do a little merkle-tree pruning ✂️:

This custom library also allows another performance optimization, where we can send a smaller hash initially (left side), and then procedurally send other necessary hashes as the respective data chunks are sent along and need verification.

Plus, having an initial estimate of the entire tree structure, and knowing data is chunked in 256kb pieces, the network can conduct efficient proof of size, easily predicting and proving the file’s size before it has arrived. The chunk file-size is also a redefinition from BAO’s implementation, originally set at 1kb, generating smaller hash-trees and data-chunks that are faster to generate but still easy to stream.

Blake3 not only allows file size prediction, but with the parallelization mentioned above, nodes can process this at a multi-cpu-core-level and actually stream independent chunks/hashes of the tree from different nodes, building the tree up many layers at a time. That’s performance optimization working overtime for you. :)

Is all data mapped to a Blake3 hash?

Yes! Fleek Network uses Blake3 to address all data coming and going in the network, regardless of their source/origin.

The interesting aspect is that Fleek Network uses a Distributed Hash Table (DHT) to keep a permanent mapping of any given data’s hash to all of its historic origins. Much like a CDN, we map where the file came from (origins, single or multiple), and its associated hash in the network, so that if the file’s needed again it can be re-fetched and re-cached by the network’s nodes. Fleek Network’s also capable of mapping mutable data, e.g. from https origins, to Blake3 hash!

This adds a couple of cool features to the network:

• We can unify files from any source under a single type of ID: Blake3 hashes.

• One hash/file can have multiple origins, for redundancy, under the same hash.

• Given the above, if an origin fails, we can easily fall-back to another to re-fetch.

Once again, performance is core to the concept of an edge, and especially in a decentralized edge network the optimized verification of data is key - which makes Blake3 an excellent choice for the network’s needs. Stay tuned as we run onwards towards the updated whitepaper release this month, where we’ll be sharing more on this - and other performance characteristics of the network. ⚡ Until next time!

Here is the TLDR version:

• An edge server architecture takes computing, data & delivery closer to end users, instead of using centralized servers

• It combines the best parts from CDNs and serverless architecture to do it fast & scalable

• We need edge because latency & performance are a huge deal for end users

• This is a standard for the modern web, so bringing it to web3 can make a big impact

Now for the more in depth version :)

What is the Edge?

In short, what we call “the edge” is a distributed network of servers that allow developers to store, compute and serve content as close to users as possible, using location and a smart topology of the network to reduce latency and improve performance. Having your app, files, computation, or services on “the edge” means hosting/executing them on multiple servers worldwide, so these can be served close to the user/client that needs it, rather than having to funnel it back –and far– to a centralized, unique server.

Edge gets its name from early web architecture. As data started to be created everywhere, with continuous needs for processing and computing, the “cloud” reached the ceiling of what can be optimized inside a central center to meet this demand. Instead, to maintain performance, and scale these new use-cases popping up (e.g. streaming), the web moved to the literal “edge” of the network, right besides the data, clients, and users, and started executing there instead of bringing everything back home to the main servers.

This idea of geographic proximity originated from Content Delivery Networks (CDNs), a widely adopted concept on the modern web. But besides caching and delivering data performantly, like CDNs, edge networks can optimize tasks that are heavy duty for end users, such as fast storage/retrieval, streaming and continuous/live compute. Some examples include server-side rendering for modern frontend frameworks (e.g. Next.js) , CRDT-based databases, and image/data optimization (SSR), all services that benefit and scale better running in multiple locations at once, rather than a central server.

Why do we need edge networks?

Latency

Latency, the time it takes for data to pass from one point on a network to another, has to be as low as possible to provide a good user experience on the modern web. High load times are the bane of web developers: according to Google, the chance of a bounce –a user abandoning the site– increased by 32% when a page load time went from one to three seconds, and by 90% when the page load time went from one to five seconds.

From the user’s perspective, speed is essential. We’ve learned to expect sites and applications to load instantly, and when our browsers take more than a couple of seconds than normal, our “something’s wrong” instinct kicks in instantly. But the real challenge is data that needs to be processed and delivered in near real-time with low tolerance for latency, like gaming on-demand via streaming.

As you may have deduced already, most latency issues are caused by distance: servers and end users are sometimes far away from each other, and those extra milliseconds add up. A practical example: two pings from the same region in Santiago, Chile. First, to a local server…

test1$ ping www.nic.cl -c 3
PING www.nic.cl (200.7.7.3): 56 data bytes

64 bytes from 200.7.7.3: icmp_seq=0 ttl=57 time=10.623 ms
64 bytes from 200.7.7.3: icmp_seq=1 ttl=57 time=8.988 ms
64 bytes from 200.7.7.3: icmp_seq=2 ttl=57 time=20.704 ms

- -- www.nic.cl ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.988/13.438/20.704/5.181 ms

…and the second to the other side of the world, in Russia:

test1$ ping www.nic.ru -c 3
PING www.nic.ru (31.177.76.4): 56 data bytes

64 bytes from 31.177.76.4: icmp_seq=0 ttl=50 time=275.234 ms
64 bytes from 31.177.76.4: icmp_seq=1 ttl=50 time=315.850 ms
64 bytes from 31.177.76.4: icmp_seq=2 ttl=50 time=285.775 ms

- -- www.nic.ru ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 275.234/292.286/315.850/17.209 ms

That is a huge round-trip time, huh? If we were to request a site from Siberia, it would take a considerable amount of time to load compared with a local server. But here’s the real kicker: any web application with low tolerance for latency would be absolutely unusable.

Therefore, closing the gap between client and server is absolutely critical to ensure quality of service for applications. This is where the edge comes in, by distributing edge servers in geographically relevant locations and automatically routing end users to them.

Performance

The modern web is heavy to load and compute, and heavy duty applications are the culprit: real-time streaming & VR/AR not only require bandwidth and low latency, but massive amounts of computing power. Even the most simple websites and apps today are dynamic, taxing our machines with interlocked databases, languages and frameworks.

Sure, when the web started, performance was an afterthought. Static sites –like the Geocities sites we used to visit in ‘99– didn’t need much rendering, but modern frameworks push the envelope to the extreme. Now, data/compute demands are a growing constant, and as we hinted above, some types of compute, processing, and data handling benefit extremely from parallel execution, where edge can shine.

Image processing (as seen below) is a perfect example. Distributing the load in a p2p edge network significantly reduces the execution time needed, getting files back to each user on time, without making their execution dependent on each other, or a single server.

In short, having a distributed edge network means our apps and websites are less resource-intensive for end users, which means less use of CPU and memory on their machines and less chance of browser/app hangs. Also, taking computation away from users means smaller payloads are sent, so less bandwidth is used.

Serverless

Another headache for developers has always been the configuration and capacity planning of servers and data centers. Having a classic cloud model that requires a dedicated DevOps engineer makes no sense if you’re trying to push a simple, low-demand application; this means a lot of computational power goes unused.

The serverless execution model was created to deal with this, simplifying the process of deploying code into production. Solutions like Google App Engine and AWS Lambda started a trend: instead of spinning up servers/resources for each new service or code you need executed, you run it serverless. Simply specify what needs to be done, and how, and the network will allocate as many resources as needed to do so, on-demand.

Normally, the main issue would be distribution. “Serverless” may seem abstracted but it’s still computation performed by centralized servers, far away from end users. But, combined with an edge infrastructure, that situation changes and you have both the benefits of serverless execution, and a geographically aware network. Win/win.

Web3 and the Edge

Web2 and web3 are following a common suit. Micro services on web2 keep our web service simple, and easy to deploy on aware edge networks; and on Web3 we’re seeing the rise of modular and use-specific protocols to cater for each need of the web3 stack.

But, unlike in the modern web, web3 does not have the same performance and orchestration layer that micro services in web2 have on top, abstracting both how these services are executed and delivered to clients. Edge networks, and all the benefits we described above, are the backbone of that layer.

This puts web3 services, protocols, and middleware in a tight spot. Do they compromise and fill this gap using web2 edge - hence making their service more “web2.5” than web3? Or do they start worrying about things outside of your service’s scope and attempt to build this performance/orchestration layer akin to edge, integrated into their own protocol?

Introducing a web3 edge network can help cover some of this issues, so:

1. Bring centralized web-like performance to web3 without sacrificing on web3 values.

2. Lower the barrier of entry and speed up time to market for developers building web3 infra/middleware by offloading a portion of their stack to the decentralized edge.

The key takeaway is this: web3 edge networks could allow the ecosystem to create and enable services, such as CDNs or serverless functions, that are as performant as their web2 counterparts. By providing this common layer, we can imitate the current web2 abstracted dev-experience, and level the field by making it easier for developers of web3 protocols, middleware, services and apps to build their core features, and leave the performance/latency optimizations to the edge layer above, similar to the modern web.

Getting a truly comprehensive view of the edge gets us right on track for the new Fleek Network whitepaper, which will outline the design for a highly performant decentralized edge network.

We’re super excited to share the complete whitepaper with you in the near future. Until then, and if you want to get the details –or haven’t heard of it– you can revisit our most recent update. ⚡ Until next time!

The move will happen in phases, and during all phases, the Fleek experience will remain the same across all products/services. Plus, as with all migrations to decentralized infra, we will keep the legacy centralized infra running in tandem until we are 100% confident in the performance and reliability of the decentralized infra. With that said, the benefits of this move include:

1. Better File & Data Storage/Availability Guarantees

2. Better Web3 Alignment (less use of centralized infra)

3. Equal Performance + Better Pricing

We accomplish this by separating the file storage layer of IPFS from the content addressing/routing layer of IPFS. Our goal is to make IPFS storage layer agnostic and bring the content addressing/routing benefits of IPFS to every file and data storage protocol/product, and eventually the entire web.

How Will This Work?

As mentioned above, by separating the content addressing/routing layer of IPFS from the storage layer built into IPFS, we are now able to store IPFS content on any storage layer without losing the content addressing/routing benefits that people love about IPFS.

The new setup uses decentralized storage networks (Filecoin, Arweave, etc.) as the storage layer, and Fleek Network as the IPFS content addressing/routing layer. Fleek Network maps an IPFS CID to all files/data on the network’s storage layers, and keeps a mapping of the CID to Origin in perpetuity. In the beginning, while Fleek Network is working its way to mainnet and beyond, we will also store and utilize an off-chain copy of the mapping.

The best part is that this setup keeps everything 100% IPFS compatible, meaning the content can always be accessed via any IPFS gateway. One added benefit of this new setup however is that if the content for any reason ever falls off IPFS, Fleek Network would be able to fetch the content from the origin (Filecoin, Arweave, etc.) and keep the file available via IPFS for as long as it remained available on the origin. And that part of the process we will abstract and make super seamless for users on the Fleek platform.

How Does This Enable Better Pricing Without Sacrificing Performance?

Today all ‘pinning providers’ are essentially running IPFS nodes on centralized cloud platforms like AWS, Digital Ocean, etc. and then accelerating those nodes with Cloudflare or another CDN. Therefore they must pass along those storage/bandwidth costs (plus a premium) to sustainably provide IPFS pinning services to their customers. However centralized cloud platform prices are quite high to begin with, and comparatively decentralized storage protocols typically offer significantly cheaper storage.

So by switching our IPFS storage layer to decentralized storage protocols, we can offer customers significantly lower rates for storage, while continuing to use a CDN (Fleek Network) to ensure performant and cost-effective retrieval/delivery of the content.

Why Don’t All IPFS Users/Pinning Providers Use Decentralized Storage?

Today, decentralized storage protocols (Filecoin, Arweave, etc.) don’t speak “IPFS”. So, if you want to use decentralized storage protocols with IPFS, you essentially need to store the content twice: once on the storage layer, and again at the IPFS layer. The two layers don’t talk, so if the file isn’t on IPFS, you would need to write custom logic to know that it exists on another storage network and to go check for it. So the short answer is, it really wasn’t feasible to do so before.

But once Fleek Network is live, for the first time it will provide an opportunity to connect IPFS to all the file and data storage protocols/layers, and so we will hopefully see other pinning providers and users of IPFS switch to this setup. It will provides real benefits over the current setup/usage of IPFS in terms of cost, performance, storage/availability guarantees, and censorship resistance/decentralization.

Will Fleek Users Notice a Difference?

Not unless you want to notice the difference. Your direct user experience will stay the same. You still can host sites, upload files and have them seamlessly uploaded/stored on ‘Fleek’, but now, we're storing your files/data on decentralized storage networks that you have the option to choose from (Filecoin, Arweave, etc.) instead of storing your files/data on Fleek controlled cloud platforms.

You might just see some added details/info in the UI to transparently show/share the details of your data living on those networks (ex. storage deal ID’s, costs/renewals, etc.). It will be like getting a new iPhone, your overall experience using the product will look/feel the same, but there will be some noticeable improvements under the hood ✅

When Is This Coming?

The upgrade to decentralized storage will come with the full Fleek.xyz platform release in August.

That’s just a quick look at one of the exciting upgrades coming to the new Fleek.xyz platform launching in August.

For more info on the rollout of Fleek.xyz, check out our Platform Timeline and Milestones Update blog. If you want to jam more on decentralized storage join our Discord community and link up with our team!

For more information on using fleek gateways create and setting custom domains for your private IPFS gateways check out our docs ⚡

Let’s get into some details:

Private IPFS Gateways: Connecting Custom Domains

With this update, we're giving you more options for your storage gateway. Before, when storing files through the Fleek CLI, you'd get an IPFS.io.cid URL to access the content, using a shared IPFS gateway to view/resolve files.

Now, you can set up a custom domain for a private gateway for another layer of:

• Privacy & Branding: Only your content is served, and you are not responsible for the content of others on the same gateway.

• Reliability & Performance: Unlike public gateways, which are resource-locked, we provide a consistent file propagation experience.

The gateways will only serve your user-uploaded content, and you can also whitelist the domains that you work with. The big takeaway from this: private gateways are now faster and offer a more personalized & secure experience.

For step-by-step instructions on getting started with Custom IPFS Gateway Domains, check out our docs.

That’s all this time! The team has heard you guys asking for this to be added for a little while, so we’re pumped to finally bring it to you.

We’re always looking for more features the community wants to see added to the platform– if you have any suggestions, reach out to the team on Discord.

We’re gearing up for an exciting summer– stay tuned 🤙

Tea was created with a promise in mind and heart: to change how packages and dependencies are handled, and how open-source developers are rewarded for their efforts to maintain them. Let’s get a taste of that tea and look under the hood, to understand what makes this brew a delicious addition to your stack ☕

TL;DR: What is Tea?

Tea is not just another package manager: it’s a cross-platform, unified package infrastructure to install and distribute app packages, with the added benefit of working with your CLI to install packages automatically. It uses “magic” (more on that later) to assess the tools and dependencies you need to run a program or script and install them.

This goes to solve one of the most awkward problems in development: globally-installed tool versions. Every product we code is different and relies on different libraries every time, but we still install most of them globally –sometimes with conflicting or buggy results. Tea works around this by installing dependencies in closed environments, every one of them specific for all projects you are currently working on.

Tea is also pushing the envelope around the package manager concept by using a GUI, a feature more commonly seen on app stores than package repositories. While Tea works seamlessly within the CLI, a GUI allows packages to have much more information available for users and peer reviewers.

That’s especially important because the “infrastructure” side of Tea has a purpose in mind, one that has taken ages to realize correctly: leveraging blockchain technology to enable indirect compensation for open-source developers. But before we go there, let’s delve deeper into Tea’s features, and how you can integrate it in your stack.

Tea in Features: The “magic” of Brewing

As a developer, there’s a high chance that you already have a package manager installed in your coding machine. So, why should you use Tea? We mentioned two main features: the “magic”, and the developer environment.

Tea’s “magic”

We’re using “magic” in quotes not only because it’s not literal magic, but because the creators of Tea call it that. The so-called “magic” is a series of hooks that get integrated into your shell when you install tea for the first time:

• A hook when changing directory that sets up project environments

• A hook for the “command not found” scenario that installs that command before running it

Therefore, when running any library or script, Tea will automatically deploy to look for the necessary packages or dependencies. If you don’t have them, then Tea installs them encapsulated in ~/.tea, to be able to retrieve them later. Packages are never installed in PATH, and aren’t accessible from the rest of the system.

As “magic” can be too much –or too automated– for some users, it can be deactivated when installing Tea.

Developer environments

Tea can automatically determine the tools a project directory needs based on the files it finds inside. Tea’s “magic” automatically fetches the specific versions those projects need and runs them.

To make matters more interesting, Tea can parse and read YAML front matter: if you need specific versions of dependencies, you can create a markdown table encapsulated in YAML front matter in your readme.md file with the versions of the packages you need.

Tea + web3 = Compensation for open-source developers

Have you ever heard of “the Nebraska problem”? This theory, coined by Randall Munroe from xkcd, states that huge parts of our modern digital infrastructure are supported by a library created and sacredly maintained “by a random person in Nebraska” who usually does it for personal reasons or a belief in the open-source philosophy.

These libraries are all around our web infrastructure, and their developers are rarely compensated for their job.

How is Tea going to change that? Moving the package registry on-chain, and essentially creating a protocol –tea token included– to enable a reward platform for developers: package maintainers would publish their releases to a decentralized registry powered by a fault-tolerant blockchain. This means automatic & secure indirect compensation to developers by creators, users and peer reviewers in the developer world by means of the tea token (or, as the whitepaper describes it, “steeping tea”).

The protocol side of Tea is still in an early stage of development, but we hope it gets the push it needs to bring life and a sustainable compensation model to thousands of developers of libraries and dependencies that are so seldom rewarded.

Getting Started With Tea

• Using Tea

• Pantry

• Quickstart CLI Guide

• FAQ

• Tea GUI (Beta)

• Install QEMU with Tea

• Install sway with Tea

We hope this overview has given you a good starting point for getting started on brewing Tea! Be sure to follow Tea to keep up to date on further updates.

Keep expanding your stack— check out our previous Build3rs Stack for more web3 infrastructure overviews. You can also join our Discord server to jam with the team and learn more!

For more resources, please visit our LinkTree ⚡

TLDR: The new platform took a bit longer than originally anticipated. But the bright side is that extra time allowed us to work in some cool changes/updates, and better align the new Fleek Network direction. The new Fleek platform will now launch in August and the full sunsetting of and one-click migration off the legacy Fleek.co platform will happen at some point before the end of the year (we will provide plenty of heads-up).

Some updates/features of the new platform that we’re excited about are 1) NFA’s (a V1 will be part of the platform launch in August) and 2) we’ve replaced our use of centralized storage providers for IPFS (ex. IPFS nodes running on AWS/Digital Ocean) with decentralized storage protocols (Filecoin & Arweave).

Not only does this align better with web3 and Fleek Network, it actually allows us to offer significantly lower storage costs to our users without sacrificing any performance or developer experience!

Keep reading for a look at everything we have planned for this summer, and some more details on the new features and updates coming to Fleek.xyz.

Summer Milestones to Get Excited For:

July-August

1. Fleek.xyz UI Betas

2. Fleek.xyz Platform (V1 launch)

3. NFA’s V1 (part of new platform launch)

4. Filecoin & Arweave/Bundlr Storage (part of new platform launch)

5. Fleek Network Testnet (experimental features in new platform) .

6. Migrating From Fleek.co (one click migration in new platform).

Q3-Q4

1. Proper Next.js support

2. Cron Jobs

3. Serverless Functions

4. Server Side Rendering

5. Fleek.co Sunsetting

We will share a lot more details in the coming weeks/months as we approach the different milestones. But, feel free to reach out on Discord if you have any questions or want to jam on any ideas beforehand.

In the meantime below are a few questions people might be wondering:

Is There Anything I Need to Worry About as a Current Fleek.co User?

Nope. With the new platform launching in August, we’re moving the sunsetting of the legacy platform until sometime after Fleek.xyz’s launch to give everyone plenty of time to make the migration/transition. Migrating will be as easy as one click on the new platform so it will only take a few seconds.

What Does the New Decentralized Storage Setup Look Like?

Instead of hosting IPFS nodes on AWS/Digital Ocean, which requires storing all the files on centralized cloud platforms, we now separate out IPFS content addressing/routing (which most people use IPFS for) from storage. By doing so, we can now utilize the benefits of IPFS (ex. content addressing/routing) on top of any storage/data layer (Filecoin, Arweave, etc.) without needing to redundantly store the files on both layers. Not only is this setup more decentralized/web3 aligned, but it also allows IPFS users to get better guarantees on the storage of their files/data. In addition to the decentralized storage protocols, Fleek Network plays a significant role in how we will be able to do it in a decentralized/trustless way.

The cool part is Fleek users won’t even notice a difference. The performance and developer experience with this new decentralized storage setup is the exact same. And besides the better security guarantees, it’s also a lot cheaper, so we will be able to pass on significant storage savings to our customers.

What’s the Latest on NFAs?

NFAs are now going to debut as a part of the new platform launch in August. They will be woven into the existing hosting flow so you can 1-click turn your site into an NFA.

For the past few months, we've been tweaking how NFAs work to ensure it’s a seamless and value-add product/experience for both app developers and end users of web3 apps/dapps. Those tweaks include:

• Users Now Mint NFAs like they would any other NFT: Before NFAs acted more like gateways/access points to the app, now every user essentially mints an NFT print of the app, which provides the user a more censorship-resistant & always-accessible version of the app that doesn’t need DNS in order to load/be usable (ex. can load through a wallet/locally in browser). It also provides some cool security/anti-phishing benefits we are working on.

• Transitioned from a custom standard to ERC721: allowing for easier integration in current apps/wallets/web experiences/interfaces.

Expect a more detailed update post on NFAs in the coming weeks.

What Does the Fleek Network Testnet Mean for the Fleek Platform?

The plan is to gradually start surfacing certain Fleek Network-powered features into the new platform this fall, but making it clear they are ‘experimental features’ to start, and then gradually increasing the usage of Fleek Network in our infra/products as we approach/launch mainnet and the network/infra hardens.

Things to expect this year would be:

1. adding the Fleek Network CDN service as an option for existing hosting/storage products on the platform

2. leverage some of the edge compute services being built on Fleek Network to power some of the new features on the roadmap (ex. cronjobs, serverless functions, SSR, etc.).

Alright, that's all we’ve got for now.

If you have any questions or ideas about any of the topics we mentioned in this blog, feel free to reach out. You can find us on Discord - our support team is always around to help! Catch you later 🤙

TLDR: The past few months were largely spent on expanding our initial CDN research into a full decentralized Edge Network. Most of that work is now done, and we have a new draft whitepaper and github repo that we will release publicly in the coming weeks, and a testnet for the decentralized edge network that will launch in August.

Below is a more detailed update on what we’ve been working on and some revised roadmap timelines.

What have we been working on?

• Re-architecting Fleek Network to be an Edge Network rather than just a CDN.

• New Protocol Design (explained in the whitepaper)

• New Whitepaper (draft complete; public release in July)

• New Github Repo (New repo will be open sourced in July; URSA will be archived)

• New Verifiable Streaming Library in Rust on top of Blake3 (similar to Bao)

• New service Delivery Acknowledgements SNARKs

• Atomo Lock-free Execution engine

It took a little while because while we leveraged the initial CDN research we did, from a network design and code perspective, we started the edge network from scratch. But now we’re approaching the point where the new repo is almost ready to share publicly (July for sure), so after being heads down for the past month we are ready to resume regular updates, starting with what milestones are on the roadmap for this summer:

Summer Milestones & Timelines

Here are the Fleek Network milestones coming this summer to look forward to! These pave the road to bring the decentralized edge network to testnet in August.

July

• New Whitepaper (public release).

• New Repo (open sourcing)

• Node Operators (communications & upgrading).

• Educational Content & Breakdowns (explaining the edge network, Atomo Engine, Delivery Acknowledgements, Blake3/BAO implementation, and more.)

• Initial Performance Benchmarks (ex. latency/throughput from internal testing)

August

• Economics Paper (public release)

• Testnet Launch (initial phase of a multi-phased path to Mainnet)

• Initial Edge Services (CDN and JS VM PoC services)

• Service Development Kit (initial release)

What are the highlights of this new Edge Network direction?

Instead of restricting our network architecture/capabilities to a CDN service, we were able to rethink/redesign Fleek Network’s core to support a full decentralized edge platform upon which many edge services (ex. CDN, serverless functions, etc.) can be built. The new architecture separates each aspect of the network (blockchain <> edge infrastructure <> services) so that anyone can build new edge services on Fleek Network.

What will be different in the new github repo?

It’s a brand new codebase, and we’ve redesigned the layout of the repo to provide more clarity and better understanding of the core protocol, as well as making it super easy to onboard as a node operator!

As a node operator on the current devnet, what should I expect?

Just stay tuned to our Discord so you’ll be first to hear about updates/timelines for upgrading to the new node software once the new github repo is released (in July). Our DevEx team is already preparing some tooling and guides to help make it easy when the time comes. Your work, feedback, and help in the devnet has been much appreciated and we’re excited to share some more info in the coming weeks regarding the official testnet launch in August.

What will the initial testnet in August look like?

The initial phase of testnet will have two main purposes. First, to stress test the network’s general performance and operation with a decentralized network of node operators; Second is to test the first two POC services, which are the CDN (static and dynamic content acceleration) and a simple edge compute POC (Javascript VM).

The second phase of the testnet which will happen either late August or early September (depending on when exactly the first testnet phase starts), will be to introduce the Service Development Kit (SDK) and test out people building new edge services on the test network. We expect to prepare a dope hackathon in tandem with the second phase of the testnet to get the ball rolling and help the community start building awesome edge services!

That’s all for this update! We’re signing out, but stay tuned as we follow up next week with more details on these milestones, and the core definitions of this new network architecture.