Discussion: Ethereum Claim Phase for $FIS Migration and Implementation Details

Discussion Topics

  • Should the automatic claim mechanism only include accounts with a value of at least $1 (approximately 50 $FIS)?
  • Is the 6‑month claim window sufficient for users to complete the claim process?
  • Are there edge cases or special scenarios the community believes should be considered during the migration?

1. Current Progress of the $FIS Migration

In previous community discussions, StaFi proposed reducing $FIS inflation to 0 and migrating the token to Ethereum, while transitioning StaFi Chain from the Validator model to Foundation Mode.

During the first phase, StaFi Chain successfully completed the transition to Foundation Mode. The migration has now entered the second phase. Part of the $FIS supply has already been moved to Ethereum through the StaFi Chain–Ethereum Bridge, but recent data checks indicate that a portion of $FIS has not yet migrated.

For these remaining assets, the next step of the migration is the Ethereum Claim Tool, which allows users to claim their assets directly on Ethereum.

2. Rationale for Migrating $FIS to Ethereum

Migrating $FIS to Ethereum is proposed as part of StaFi’s broader architectural transition. The main considerations include:

  • Liquidity and ecosystem integration: Ethereum hosts the most mature DeFi ecosystem and deepest liquidity, enabling better integration with exchanges, DeFi protocols, and infrastructure.
  • Alignment with StaFi’s staking infrastructure strategy: StaFi’s long‑term focus is increasingly centered on staking infrastructure and LSaaS (Liquid Staking as a Service). Ethereum provides a mature environment to support this direction.
  • Expanded application scenarios: Operating within Ethereum allows $FIS to interact more easily with DeFi, RWA, and other on‑chain applications.
  • Simplified architecture and lower operational overhead: As StaFi Chain gradually ceases operation, the overall architecture becomes simpler, reducing long‑term technical and operational maintenance costs.

3. Ethereum Claim Phase

The next stage of the migration is the Ethereum Claim Phase, designed to simplify the migration process and distribute the remaining assets through an automated mechanism.

Key characteristics include:

  • Automated processing
  • Automatic calculation of claimable balances
  • Minimal user interaction

To ensure data consistency, StaFi will take a state snapshot of StaFi Chain at a designated block height (Snapshot Height). This snapshot will be the final reference for calculating user balances, and any activity after this point will not be included in the claim calculation.

After the snapshot, the system will generate the claim dataset and determine the claimable amount for each eligible address. Users will then be able to claim their ERC‑20 $FIS on Ethereum through the Ethereum Claim Tool.

To complete the claim process, users must:

  • Import their StaFi Chain address into the Polkadot.js wallet
  • Prepare a valid Ethereum address in MetaMask

Users will sign messages using both wallets. The system verifies address ownership through this dual‑signature process, after which the corresponding $FIS can be claimed on Ethereum. Once the snapshot is taken, StaFi Chain will officially stop operating, and the claim dataset will be finalized based on the snapshot state.

4. Eligible $FIS Categories for Claim

In this phase, the system will automatically calculate and process the following categories of $FIS:

  • Unvested $FIS from the Genesis allocation
  • $FIS staked through Validators
  • $FIS staked through the rToken App (rFIS)

The system calculates the claimable amount according to predefined rules. Once completed, eligible addresses will be able to claim their corresponding ERC‑20 $FIS through the Ethereum Claim Tool without additional manual calculations.

Note: This process only applies to $FIS that has not yet migrated to Ethereum. If your $FIS is already in ERC‑20 format on Ethereum, no action is required. The official ERC‑20 $FIS contract address is: 0xef3a930e1ffffacd2fc13434ac81bd278b0ecc8d

5. Technical Implementation

To ensure security and verifiability, the claim mechanism uses SR25519 signature verification together with Merkle Tree validation.

Specifically:

  • Eligible addresses and balances included in a Merkle Tree
  • Merkle Proof required for claim verification
  • SR25519 signatures used to verify StaFi Chain address ownership

This design ensures that the distribution process remains transparent, verifiable, and consistent with mechanisms widely used across the blockchain ecosystem.

6. Special Considerations

Maintaining the Ethereum Claim Tool requires ongoing infrastructure and operational support, including servers, verification services, and security maintenance. As a result, the tool cannot run indefinitely.

Considering operational costs and the time required for users to complete the claim process, the Ethereum Claim Tool is proposed to remain available for 6 months. During this claim window, eligible users would be able to claim their ERC‑20 $FIS on Ethereum.

Once the claim window closes, any unclaimed $FIS would no longer be recoverable. Users are therefore encouraged to complete their claim as soon as the Claim Tool becomes available.

To reduce system processing overhead, addresses with a value below $1 (approximately 50 $FIS) are proposed to be excluded from the automatic claim mechanism. For users holding smaller balances, StaFi recommends manually bridging $FIS to Ethereum through the StaFi ↔ Ethereum Bridge before the bridge migration window closes (March 22).

7. Summary

The second phase of the $FIS migration introduces an automated Ethereum claim mechanism designed to simplify the migration process and improve transparency.

Community feedback on the proposed design is highly encouraged. More detailed instructions and operational guidance for the claim phase will be released in future updates.