We’re currently in discussions with multiple options (pNetwork, Binance Bridge for BSC, and Huobi ECO Chain) which would give us access to EOS, ETH, BSC, and HECO. We’re also building our own multisig oracle solution which will exist on ETH first and later BSC.

What naming conventions do we want to adopt for these wrapped tokens on different networks? In some cases, we may have multiple versions of the “FIO” token on the same network. How do we want to handle this?

What is a bridge?

A bridge is a mechanism for locking native tokens from one chain and making a wrapped or “bridged” version of them available on another chain. The bridge service allows token holders to move between the two chains by locking (or burning) on one chain and unlocking (or minting) on another chain.

Bridges we’re considering for FIO:

1. Our own multisignature oracle solution run by a selection of willing, active, trusted block producers.

2. pNetowork: https://p.network/

3. Binance Bridge: https://www.binance.org/en/bridge

Approach 1: Same name on all networks for all implementations

FIO is FIO is FIO. On any network, on any chain, if you have a FIO token and you trust the contract that issued it, you should be able redeem it for 1 native FIO (minus any potential fees). This approach would mean the token code remains the same for all implementations of the wrapped token.

Pros:

• Simple to understand that this is a “real” FIO token if you can just figure out how to convert it.

Cons:

• Does not work with FIO Protocol. FIO only maps a chain code and token code, not a contract address. That means FIO can’t function in a situation where there are multiple tokens with the same token code (but different contract addresses) on the same chain.

• Would be confusing for users who go to a swap service like Pancake swap, expecting to exchange for FIO on Binance Bridge but having no way of distinguishing that from FIO on pNetwork or wrapped FIO from the multisig oracle.

• Creates even more potential for scam tokens pretending to be a valid FIO bridge token but actually just being a scam. Note, this problem still exists anyway, but by saying multiple “FIO” tokens are “real” could make the problem worse.

Approach 2: Different token code per bridge solution

With this approach each bridge gets a unique token code, regardless of which network it’s on. This would mean the pNetwork bridge would have, for example, “PFIO” as the token code. This token would be known as the pNetwork version of FIO, it would have it’s own token logo. It would work on all bridges and networks that pToken supports. Binance Bridge could be called “BFIO” and own our multisig oracle solution could be called “WFIO” for Wrapped FIO supported and wrapped by the native blockchain validators via multisig.

Pros:

• Clearly defines exactly what type of bridge is being used. Each token code can be independently identified and explained in our documentation.

• Avoids confusion and reduces scam potential as there will only every be one valid “PFIO” token for the pNetwork bridge.

Cons:

• As more bridges emerge, more confusion may arise between the increasing number of various token codes (but this can be mitigated with good documentation).

Current Suggestion:

I’m thinking we go with Approach 2, but I’d like more input. The pNetwork team seems to think this is a good path to use a unique code pre bridge, though they’ve seen projects do both (stick with the native token or add a prefix). They said since we’re already planning to have multiple bridges, we will probably benefit from the prefix.

pNetwork: PFIO (or “pFIO”)

Binance Bridge: BFIO (or ”bFIO”)

Multisig Oracle (Wrapped FIO run by BPs): WFIO (or “wFIO”)

Thoughts? Feedback?

Conclusion:

We’re going to move forward with the suggestion of naming each wrapped token according to the bridge service provider solution involved.

PFIO: pNetwork

BFIO: Binance Bridge

WFIO: Multisig Wrapped FIO via BPs

HFIO: HECHO Chain Bridge (if we decided to do that)