Consortium bridge

As a bridge allow to transfer an asset from a foreign chain to a home chain. Often, the home chain is a PoA chain and the bridge validators are also a PoA. Often, to simplify the set up, PoA identities of the chain are set similar to the PoA bridge. I was thinking of an entreprise use case. ( consortium case ) where this PoA bridge does not want to serve all public ethereum address, but only a subset of addresses defined for his consortium. Allowed addresses will be defined by the PoA(chain and bridge) authority. Nevertheless, this consortium wants to use and bridge an asset coming from a public foreign chain to make business logic between them on their home chain. A sort of whitelisting will be needed for the bridge. Is there a manner to simulate this behaviour with the current bridge code or does this will need some change to configure this behaviour?

The bridge will have to watch only a subset of address for deposit and withdraw between chains.

As erc20 transfer cannot be refused, for those not part of this whitelisting, the asset will be stuck on the foreign bridge contract side. Ideally, it should be possible to those external address to withdraw this asset or to claim it if they transfer an asset to the bridge by error and it is stuck on the foreign chain. Adding and removing address in the whitelist must be watched carefully to not generate bugs or attacks. Or maybe to simplify, not allowed with an immutable whitelist list in smart contract.

Do you think this kind of behaviour support will be interested in your poa-network code base or it is better to fork and implement it?

1 Like

Hi! You are very welcome to contribute this functionality in the our code base. Please create a new issue in and we can discuss how it is better to implement from the architectural point of view.

1 Like

Ok. I initialize a spec proposal as the starting point for discussion about this :

1 Like

Thanks I will take a look.

1 Like

Aside from this specification, I wanted to share also a little bit more about the context and myself.

I am a blockchain developer at iExec and I meet Igor at web3 summit last October in Berlin.

We discuss bridge solution and the industrialized bridge that poa network working on, based on the parity bridge idea.

A bridge solution is one component we planned to use first in our solution while continuing exploring more solutions that may come in the future (substrate, polkadot or others).
We explained this in this article

Since then, we test it and we have been happy to contribute back to some fixes and functionalities. The token decimals support and some fixes : pull 153,166.

In our next release of iExec V3, we want to address scenario where some consortium bridge may be bootstrap and used as explained above.

We will be happy to co-develop and test this consortium bridge feature with you.

Finally, I want to congrats also all the team for all the quality work you have done in the ecosystem! (token bridge, blockscout, xdai etc …)

We can discuss further by email if needed. Here my email:

Francois Branciard

1 Like

Hi Francois! Nice to e-meet you around here.

The work you guys are doing is very interesting and seems to have a lot of parallels with what we are doing and how we believe in side-chains as solutions to scalability and interoperability.

We’ll be posting updates continuously about our bridge developments here so will be looking forward to discuss any future development as we move forward.



Also moved the topic to the TokenBridge category

Doing a bit of house cleaning around the forum :slight_smile:


@branciard hey, we answered to your issue here

1 Like

Thank you, it looks good to me.