Migration to the New Phase: The Road Ahead for Fizz and Provider Nodes

We are excited to announce the upcoming migration to a new phase of the Spheron Network, a major upgrade designed to improve performance, simplify participation, and bring more stability to our platform. This is a strategic evolution in response to everything we’ve learned so far. This article explains the full migration process, what changes are coming, why they matter, and how they benefit both new and existing participants in the ecosystem.

Overview: What Is the Migration About?

This new phase introduces several critical improvements to the Spheron Network's infrastructure, user experience, and operational efficiency. During this migration, we are updating Fizz and Provider nodes to align with new standards and upgraded architecture.

The goal of this shift is to move beyond the limitations of the current environment and enter a more production-ready space. The process will involve temporary pauses in certain services, a reset of the leaderboard and points system, and new deployment requirements for node operators and developers.

Temporary Changes During Migration

While the migration is underway, the following changes will take place:

Fizz node registration will be temporarily paused. No new nodes can be registered during the migration window.
Resource updates to existing nodes will be disabled.
Deployments via Console and Supernoderz will be paused.
Active leases will be closed out automatically.

These measures are necessary to ensure a smooth transition and prevent deployment conflicts during infrastructure updates.

The migration will occur in two stages:

Console services will return first, with a short delay of 2–3 hours expected.
Supernoderz will come back online the following day with a similar process for fund reactivation and redeployment.

What Happens After Migration?

Once the migration completes, the network will resume operations with updated policies & features. Here’s what you can expect:

1. Introducing uSPON: A Major Step Toward Full Ecosystem Utility

This update introduces uSPON. Think of uSPON as a USD-based unit that you’ll use across Spheron. It’s not a tradable token, it’s not for speculation, it’s just a clean, internal way to handle payments and rewards within our ecosystem.

Here is how it works:

1 uSPON = $1 in value
Fully unlocked from Day 1
Can be swapped for $SPON at TGE (Token Generation Event)
Not tradable or transferable between users — only usable in the system

uSPON gives us a clean and stable way to operate, without the volatility or complexity of typical Web3 tokens.

Why We Built uSPON?

We’ve been listening to builders, partners, and new users, and we realized we needed a smoother experience, especially for people who aren’t deep into crypto.

We built uSPON to make the Spheron experience more accessible, stable, and future-proof. It’s a big step toward making this ecosystem work for everyone, not just Web3 pros.

With uSPON:

Builder can build easily on Spheron utilizing uSPON as the base layer
We can expand to new regions without running into token regulations
It’s easier for Web2 users to jump in without learning crypto
We get clear insights into platform usage and adoption
And it still supports the $SPON value through our future buyback system

This setup gives users, developers, and token holders a better experience and a stronger ecosystem.

What Happens at TGE? When TGE happens, you can convert all your uSPON into $SPON—100% unlocked from Day 1. There are no lock-ups, no cliffs, just full flexibility.

2. Points Reset

All FN points will reset to zero. This includes:

Fizz node scores
Leaderboard rankings
Era progress

Your old points won’t be deleted. They will still be visible on your dashboard for historical reference. This reset ensures that new participants joining this phase aren’t disadvantaged and that competition remains fresh and dynamic.

3. Era Restart

The current era will close, and a new one will begin. This helps keep the network competitive and encourages new node operators to participate.

4. CPU Multiplier Update – Effective in the New Phase

We’re updating the CPU multiplier in the FIZZ Node to ensure a more balanced and sustainable reward system across contributions. Starting from the new phase, the CPU reward multiplier will be adjusted from 1x to 0.2x. With this change, users will now receive 5 FN per CPU unit per era.

For example, if a contributor attaches 32 CPU units, they will earn 160 FN per era (32 x 5 = 160 FN).

This update will only apply to the new phase and will not impact FN points or rewards from previous phases. All prior contributions and rewards remain unchanged. This adjustment aims to create a fairer reward distribution and better reflect the network’s evolving performance and resource needs.

We encourage all contributors to review this update and make any necessary adjustments to their resource allocation. This important change affects FN rewards going forward, and we want to ensure everyone is informed and prepared.

Major Benefits in This Phase

Several enhancements and policy changes significantly improve user and developer experiences:

No Gas Fees: Registration and specs updates no longer require gas fees. The Spheron team will absorb these costs.
Free Nebula NFT: At no extra cost, every new participant receives a Nebula NFT as proof of involvement.
Stellar NFT Option: The Stellar Phase benefits remain available for purchase, offering a 1.5x rewards multiplier.

Removal of Low-Quality GPUs

We are discontinuing support for several older and underpowered GPUs to ensure consistent performance. Node operators will no longer be able to register or update specs using these GPUs:

NVIDIA T1000, Tesla P4

GTX 1050 / Ti, 1060, 1070 / Ti, 1080 / Ti

GTX 1650 / Ti, 1660 / Ti / Super

RTX 2050, 2060 / Super, 2070, 2080 / Super, 2080 Ti

RTX 3050 / Ti, 3060 / Ti, 3070 / Ti

RTX 4050, 4060 / Ti

This helps preserve network quality and minimizes performance variability.

Provider Update

Spheron providers now need to maintain a small amount of ETH in their wallets to accept bids. During migration, we sent ETH to all the providers to make the migration smooth, but going forward, they need to maintain their wallets with enough ETH in them on the Base Mainnet.

Also, to make it easier for users to look into the provider's wallet balance and debug why their deployments are not passing, the same can be visible on the provider’s dashboard.

It is crucial to maintain sufficient ETH liquidity since deployments to Fizz nodes through your providers will use the same wallet's ETH balance to pay gas fees for bidding transactions.

Something like below 👇

Setting Custom Base Mainnet RPC WSS URL on your Provider

To ensure reliable Base Mainnet bidding for deployments and accepting other transactions, you should provide your own dedicated Base Mainnet RPC endpoint. Public Base Mainnet RPCs are rate-limited and can cause deployments to fail or stall under load, creating a poor experience for developers interested in leasing from your provider.

Obtain a Custom RPC URL. Choose any popular provider and create a free API key:

a. Alchemy: https://www.alchemy.com/base

b. Infura: https://docs.metamask.io/services/reference/base/

c. QuickNode: https://www.quicknode.com/docs
Set the Custom Base Mainnet RPC WSS URL
To set a custom Base Mainnet RPC WSS URL, you need to run this command:
```
 sphnctl set rpc wss://[RPC URL]
```
Example:
```
 sphnctl set rpc wss://base-mainnet.g.alchemy.com/v2/your-api-key
```

Now, restart both the provider and the gateway to apply the new RPC changes

 kubectl rollout restart statefulset/spheron-provider -n spheron-services
 kubectl rollout restart statefulset/spheron-gateway -n spheron-services

Note: The RPC URL should be in the format of wss://[RPC URL]. You need to get the WebSocket URL from the RPC provider.

Developer-Specific Updates

If you're a developer working with Spheron's CLI or SDK, here are a few things to note:

CLI Updates

You’ll need to update your CLI to the latest version to stay compatible with the new system.
You must also manually set the correct RPC URL since the default public endpoint may not work reliably in the new environment.

SDK Upgrade

The SDK must also be updated to the latest version.
Detailed change logs and updated documentation will be published alongside the migration.

These changes are essential for ensuring that your deployments and automation scripts continue to function correctly.

Why We’re Doing This

We’re making this move because the network has outgrown its original structure. The current design served us well for early development and experimentation, but it’s time to move toward a more robust and scalable system.

This migration is a direct response to:

Community feedback
Real-world usage data
Technical pain points

This new phase introduces a platform that is:

More reliable
Easier to use
More rewarding for contributors

Final Thoughts

We’re entering a more powerful and stable era of the Spheron Network. Our goal is to give every contributor, from first-time node operators to experienced developers, the tools and environment they need to thrive and Builder can build easily on Spheron utilizing uSPON as the base layer.

Thank you for being a part of this journey. This migration is a big step forward, and your support and patience make it possible.

Hang tight. The best part of Spheron is that it is just getting started.