Frequently asked questions

Users sign their transaction requests on-chain and the protocol uses these signed transactions to then act as a registered agent for the user on another chain. The user's signature is all the Spanning Network needs to validate that a user is making the request.

Currently, the middle layer (BOS) used to pass messages between networks is trusted and centralized.

There will always be a use case for a centralized solution especially as Web3 reaches mass adoption. A centralized solution will always be the cheapest and fastest option for cross-chain requests.

For high-value/risk transactions, Spanning Labs does want to provide users and developers with a decentralized option in the future. The Spanning Network is very modular and can support multiple middle layers at once. A user/developer can specify in their transaction request which relay network they want as well as other routing parameters.

Once Spanning Labs has identified, tested, and validated a decentralized relay network that meets our standards of security and experience, it will be added as a routing option.

The Spanning Network doesn't custody assets nor do the Spanning Delegates. They are always held directly in a user's name.

When a transaction occurs, the Delegate on the destination network is given the rights for a limited time to enact a transaction on the sender's behalf.

The main thing a developer needs to do to work on the Spanning Protocol is added support for multichain addresses. This gives them the ability to correctly track users/owners on other chains.

Spanning Labs is focused on making sure the protocol is as easy to integrate for developers as possible. This includes building common contract extension standards so that a developer can integrate seamlessly.

Until we reach a critical mass adoption threshold, backward compatibility will be vital to the protocol's growth.

To support existing assets/tokens that are already deployed without multichain address support, Spanning Labs has built "legacy container" contracts that can be deployed to add multichain address functionality to already deploy contracts.

There are two main attack vectors in the Spanning Network:

1. If a user-submitted transaction to a blockchain is spoofed. This would involve stealing the user's private key.
2. If the node provider sends the middle layer false block data. BOS guards against this by monitoring multiple node providers at once to ensure they are in agreement before enacting a transaction. In the future Spanning Labs plans on running nodes in addition to this.

If the Spanning Network goes down, crosschain messages/requests won't be processed and settled to the destination chain until the network comes back online.

If you are a token holder on the network that the token contract is deployed on, you will maintain full utility and nothing will change.

If you are a token holder not on the network that the token is deployed on, your assets will be frozen. Application developers will be able to recover these assets for you and give you access to them via a verified linked account. Spanning Labs is working on developing plans for a recovery system for you to link your wallets between chains to make this recovery as easy as possible should it ever be needed.

The Spanning Network pays gas to settle transactions to their destination chains. To make the network sustainable, it must charge a fee to do so.

The fee can be pre-paid by the developer as a perk for their users or passed onto their users directly.