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 and features. Here’s what you can expect:

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. 1 uSPON = $1 in value
2. Fully unlocked from Day 1
3. Can be swapped for $SPON at TGE (Token Generation Event)
4. 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.

Points Reset

All FN & SP points will reset to zero as Era start from zero. This includes:

• Fizz node scores
• Provider Node scores
• Leaderboard rankings for both Provider and Fizz node
• Era progress
• Tiering - it will not reset for the provider

Your old points won’t be backed up. 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.

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.

CPU Multiplier Update – Effective in the New Phase for Fizz Node

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: Every new participant receives a Nebula NFT as proof of involvement, at no extra cost.

Stellar NFT Option

: The Stellar NFT remains 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 small amount of ETH into 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 wallet with enough ETH into it on Base Mainnet.

Also to make it easier for the users to look into wallet balance of provider to debug why their deployments are not passing, the same can be visible on 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.

1. Obtain a Custom RPC URL Choose any popular provider and create a free API key:
1. Alchemy: https://www.alchemy.com/base
2. Infura: https://docs.metamask.io/services/reference/base/
3. QuickNode: https://www.quicknode.com/docs
2. Set the Custom Base Mainnet RPC WSS URL To set a custom Base Mainnet RPC WSS URL, you need to run this command:
Copy

sphnctl set rpc wss://[RPC URL]

Example:

Copy

sphnctl set rpc wss://base-mainnet.g.alchemy.com/v2/your-api-key

3. Now restart both provider and gateway to apply new RPC changes
Copy

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.

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 of Spheron is just getting started.