# Guidance for new Blockchains

This document provides a comprehensive guide for integrating <mark style="color:purple;">Fiat24</mark> into a new blockchain ecosystem. It outlines the key technical and operational requirements to ensure a smooth deployment. The guidance is divided into four main sections:

1. defining the **namespace** for account identification
2. assessing **blockchain readiness** as an external prerequisite
3. optional **pre-confirmation** model for real-time processing, and
4. designing the **front-end UX** to ensure seamless interaction with the Fiat24 services.

## Part 1 : Namespace <a href="#introduction" id="introduction"></a>

Fiat24 is a holistic payment infrastructure built on NFT-based identity. Each NFT carries a unique number that maps to a real **Swiss bank account** (IBAN). When Fiat24 is deployed on various blockchains, two problems must be solved:

1. Collisions across networks—e.g., NFT #10365 on Chain X unintentionally sharing the same IBAN as NFT #10365 on Chain Y—we must explicitly partition the namespace per blockchain and bind IBAN mapping to a chain-aware identifier rather than the token number alone.
2. Client data across different blockchains remains securely isolated. Each chain’s client data must be stored and accessed separately, so that a client on Chain X cannot be viewed or accessed by any provider from Chain Y.

To maintain clear client separation and prevent identity conflicts across multiple blockchains, each integrated blockchain must acquire a **single-digit NFT** ranging from **#1** to **#8**. This NFT acts as the **namespace** identifier, ensuring that account numbers and NFT identities remain unique across all networks. The only exception is the Arbitrum network, which does not require such an allocation because it inherently holds the NFT number 0 as its namespace.&#x20;

The assigned NFT number is appended to Fiat24’s official clearing number, **83051**, forming a distinct namespace pattern for each blockchain. For example, a blockchain assigned the NFT number “3” will use the namespace **830513**, whereas another assigned “7” will use **830517**. This systematic approach guarantees that identical NFT identifiers on different blockchains (for instance, NFT #10365) correspond to **different logical accounts** within Fiat24’s infrastructure.&#x20;

By enforcing this namespace partitioning, Fiat24 can integrate multiple blockchains while preserving strict data isolation, preventing cross-chain access or duplication of client information. This mechanism provides a simple yet robust way to maintain account consistency and compliance across a multi-chain environment.

{% tabs %}
{% tab title="Arbitrum" %}
Arbitrum `chainId = 42161` is the native blockchain of Fiat24. Specifically, NFTs numbered **#1** to **#8** are exclusively reserved for deployment on other blockchains, so its NFT range for clients starts from Number 10.

The IBAN namespace assigned to Fiat24 is **830510**.

{% code title="NFT Range" %}

```javascript
10 - 9999999999  
```

{% endcode %}

<pre class="language-javascript" data-title="IBAN Range"><code class="lang-javascript">CH00 8305 1000 0000 0001 0 -
<strong>CH00 8305 1099 9999 9999 9
</strong></code></pre>

{% endtab %}

{% tab title="Mantle" %}
Mantle Network `chainId = 5000` has the NFT **#1,** and the IBAN namespace assigned to Fiat24 is **830511**.

{% code title="NFT Range" %}

```javascript
1 - 9999999999  
```

{% endcode %}

<pre class="language-javascript" data-title="IBAN Range"><code class="lang-javascript">CH00 8305 1100 0000 0000 1 -
<strong>CH00 8305 1199 9999 9999 9
</strong></code></pre>

{% endtab %}

{% tab title="Untaken #2 - #8" %}
NFT #2 to #8 have not given yet.
{% endtab %}
{% endtabs %}

## Part 2 : Blockchain Readiness <a href="#introduction" id="introduction"></a>

It typically takes considerable time for a new blockchain ecosystem to mature. Fiat24 cannot operate until several essential foundational components of that ecosystem are established.

### 2.1 EVM

All Fiat24 smart contracts are developed using Solidity, the native programming language of the Ethereum ecosystem. Consequently, any blockchain that aims to deploy Fiat24 must be **fully EVM-compatible** (Ethereum Virtual Machine). EVM compatibility ensures that Fiat24’s existing smart contracts can be deployed and executed without modification, preserving their logic, security model, and interoperability with existing tools and libraries. This requirement also allows seamless integration with widely used developer environments such as Hardhat, Remix, and Foundry, as well as compatibility with **s**tandard RPC endpoints, MetaMask, and other Ethereum-based wallets.&#x20;

Non-EVM blockchains would require a complete redevelopment of the Fiat24 contract suite, which is not supported under the current integration framework. Therefore, before initiating deployment, your blockchain team must verify that the network’s runtime environment fully supports Solidity-based contracts, gas metering, and transaction execution semantics equivalent to Ethereum. In practice, most layer-2 networks and EVM-compatible chains such as Polygon, and BNB Chain meet these criteria, enabling straightforward deployment. Ensuring this compatibility significantly reduces integration time and technical risk while maintaining functional consistency across all Fiat24-supported networks.

### 2.2 USDC

Since USDC is the only cryptocurrency accepted by Fiat24 — a strict legal requirement that cannot be violated — it is therefore critical to ensure that the new blockchain has sufficient USDC circulation before deployment.

### 2.3 DEX

{% hint style="info" %}
The namespace requirement may be exempted when the system accepts USDC top-ups exclusively.
{% endhint %}

Since the Fiat24 smart contract only accepts USDC, users who wish to top up with other cryptocurrencies must first use a DEX to convert their assets into USDC before sending funds to the Fiat24 contract. Therefore, it is essential to ensure sufficient liquidity for these trading pairs to guarantee smooth conversion.

### 2.4 RPC

Your blockchain must provide standard RPC endpoints. To minimize integration effort, it is ideal if the chain is already supported by infrastructure providers [Alchemy](https://www.alchemy.com/) and [Infura](https://www.infura.io/).

### 2.5 Etherscan

Ideally, the blockchain explorer should be built on the Etherscan platform, as the Fiat24 backend relies on it in multiple components.

## Part 3 : Pre-confirmation Module <a href="#introduction" id="introduction"></a>

{% hint style="info" %}
This section is relevant only for blockchains whose block time exceeds 500 milliseconds.
{% endhint %}

The Fiat24 debit card spending module is designed to process payments in real time, meeting the stringent performance requirements of the Mastercard network. To achieve this, client funds must be transferred from their on-chain wallet within a very short time window before the authorisation result is returned to Mastercard.&#x20;

On high-performance blockchains such as Arbitrum or Solana, where the block time is typically less than 500 milliseconds, this process works seamlessly. However, for blockchains that are not inherently optimized for real-time transaction processing, the confirmation latency may exceed the acceptable threshold. In such environments, Fiat24 cannot always guarantee that a sufficient number of confirmations will be received before the authorisation decision must be made.&#x20;

To address this limitation, an additional **pre-confirmation mechanism** is required. This component can temporarily validate transactions prior to full network confirmation, ensuring smooth user experience and compliance with payment network timing. In certain cases, this module may need to be supported by a **collateral fund account**, providing a liquidity buffer that allows instant authorizations while the underlying blockchain transaction finalizes. Together, these measures ensure reliable and secure real-time payment processing across diverse blockchain infrastructures.

## Part 4 : Front-End UX <a href="#introduction" id="introduction"></a>

Fiat24 relies on a user-friendly front-end interface to make its banking and payment features accessible to end users. This interface can take the form of either a **decentralized application (dApp)** or a **native mobile application**, depending on the target user base and the preferred deployment environment. The front-end plays a critical role in connecting the user to the Fiat24 smart contract ecosystem, handling functions such as wallet integration, NFT identity visualization, transaction management, and real-time account information display.&#x20;

While Fiat24 provides the full suite of backend services and APIs required for seamless operation, the development of the front-end layer for a new blockchain integration is **NOT** included in our scope. Instead, your development team will need to take ownership of this task, ensuring the interface aligns with your blockchain’s ecosystem and user experience standards. Fiat24 will, however, offer comprehensive technical support throughout the integration process. Through this collaborative model, your team retains flexibility in design while benefiting from Fiat24’s technical expertise and proven infrastructure.

The whole project is expected to take around 2 to 4 months.