Using Arbitrary Message Bridging

as Deepit we are building a certificate application on Ethereum and are evaluating POA as a side chain.

Quickly our use case: a user requests to notarize a document, the system take in charge this request and issues a ERC-721 token. The tokens are issued on POA for scalability, performance and cost reasons.
But if the user want he can transfer one or more token on the Ethereum network were we deploy a twin ERC-721 contract. The POA ERC-721 token will be burned and the same token will be minted on the Ethereum side by the twin ERC-721 contract. We need a bridge!

We studied the POA Token Bridge smart contracts and the issue 46 proposing support for ERC-721 tokens. Igor Barinov in a call with us proposed the use of the Arbitrary Message Bridge that is on the PR 77. We also found the Oracle extension that support AMB (

We found AMB contracts and mechanism very exciting! We think that AMB contracts are in a good shape and they fit well with our use case. A ERC-721 bridge is also a good fit but AMB enable many possibilities and can address well generic future needs, so we are going to use AMB.

We have some questions:

  1. are the AMB smart contracts ready to deploy? if not we can contribute
  2. the AMB enabled Oracle on the branch is complete and working?
  3. it seems to us that the smart-contracts of AMB are so generic that it is enough to have only one instance (in each chain) for all users, in the production environment. But there are two working mode (SUBSIDIZED e DEFRAYAL) that suggest two different deploy. So we are asking what is your plan. Or do we need to do our deploy?
  4. again, the oracle is so generic that we think that are sufficient N instances (one for each validator) for all users; it is correct?

We have other questions about the implementation of our token but we leave them to a future post.
Thanks in advance
Michelangelo Riccobene


Thanks for paying attention on the AMB feature!

Yes, it was designed to be quite generic as so all other bridge types could be build on top of it.

So for your question the answers are the following:

  1. The most recent version of the AMB contracts is located as you noticed in PR 77. It is almost finished and it will be great if you could review the changes to find something trivial that needs to be addressed. There are few open questions there related to DEFRAYAL mode I could describe them in a separate message. If the bridge is going to be deployed in this mode it is necessary to work these questions out.

  2. The most recent changes in the tokenbridge oracle related to the AMB feature was migrated to the monorepo and placed in the branch amb-oracle. We did not run any life testing (only unit testing) for them yet. But can provide you assistance if you like to help with this.

  3. Our recent plans were to run the bridge as PoC in the SUBSIDIZED mode. It could require to add extra functionality to whitelist contracts that are permitted to originate messages through the bridge. There is no suggested corresponding changes for the contracts since we are working to close the security audit for v2.3.2 tokenbridge contracts. As soon as we finish, we will return to AMB to implement this.

  4. Yes, that’s correct. The plan was to setup N validators nodes for one bridge which could serve unlimited (in theory) number of contracts.

Hi Alexander,
thanks for your responses!

I have another question about our ERC-721 token: we have a generic bridge, and we have two ERC-721 token on each network (Ethereum and POA) . We need to be sure that only the ERC-721 token on POA side can invoke the mint method on the ERC-721 on Ethereum side (via bridge). There are similar constraints on the other way round. Whitelisting on the bridge can mitigate this problem but not solve it if the bridge is serving many applications.

There is a simple solution anyway: each ERC-721 token contract knows the address of the twin on the other side. This is simply accomplished with a setTwinAddress() method on each ERC-721 contract. So each token contract can check the originator of the call.

There is a more elegant solution: with CREATE2 we can deploy each token at the same address on Ethereum and POA netwoks. Is POA supporting CREATE2?

Merkle proof can be also considered but according to us is excessive for this scenario.

Can you suggest us a better solution? or a more general solution to this problem?


1 Like

Thanks for interesting question. I will think and answer later today or tomorrow.

Sorry for delay with the answer.

First of all, yes, both POA Core and Sokol support the CREATE2 call. The corresponding hardfork was done in April.

Then, if you are talking about the AMB feature it currently does not support transferring the sender account to the target contract. In order to not reassemble the message passed to the target contract and if the target method knows that it could be called by the bridge contract, it could be possible to get access to the sender account stored in the bridge contract in the way similar to the following:

contract AMB {
    function getMessageSender() external view returns (address);

contract targetContract  {
    address public pairedContract;
    AMB public bridge;
    bytes32 data;
    function targetMethod(bytes32 _data) external returns (bool) {
        require(msg.sender == address(bridge));
        require(bridge.getMessageSender() == pairedContract);
        data = _data;
        return true;

It is not implemented yet but it seems to be worth to have a new functionality in the bridge contract which will temporarily store the sender address before the target method call and zero the sender address when the method exits.

Another way to prove that the target method was called by an authorized person/service is to send the signature as part of data passed to the method. But it also is applicable for limited number of cases.

1 Like

Hi Alexander!
The solution you depicted is a good solution for us.
We understand that the bridge carries the sender but cannot pass it to the target contract because it doesn’t know his semantic and syntax.
So we are going to implement and test your solution. We will let you to know our results.


I have created a comment in the issue where AMB functionality is discussing.

1 Like

Hi everyone!

We have deployed a trial version of the bridge contracts supporting Arbitrary Message Bridging between Kovan and Sokol testnets:

There is also a reference contract that demonstrates how to interact with this bridge.

Thank you very much Alexander!

We have just done a round trip from Sokol to Kovan with your bridge instance and our ERC721 sample contract: we have minted a token on Sokol side and we have transferred it on Kovan side using the bridge. Now we are going to tune our code to manage permission and security issues using the IAMB interface to get the remote sender as you suggested.

Here the transactions:

I have two questions:

  • the bridge has a MaxGasPerTx parameter that is private, how much is it?

  • the addresses of the bridge contracts that you posted here point to two proxy contracts that in turn point to the real bridge contracts (HomeAMB and ForeignAMB). Why did you used proxy contracts? to be able to update the bridges in the future?


1 Like

Nice to hear that you was able to adapt your code to use our contracts so quickly!

Here is my answers:

  1. In order to get the value of maxGasPerTex you can call the method maxGasPerTx() on the proxy method. The call will be redirected to the implementation and return 2000000000000000000000 for this particular deployment. It is quite big so far and definitely will be less in a real deployment.
  2. Yes, we use the proxy template for our bridge contracts in order to have ability to upgrade the code if any security issue is found.
1 Like

Hi @michelangelo
Do you plan to verify smart contract of your AMB proxy for ERC721 or opensource the code?
We have some community members interested in it.

Hi Igor,
the ERC-721 that I used in the recent test is a raw and ugly contract made only to understand and test the bridge. In a few weeks we will deploy the quasi final version and we will verify it.
I hope this is ok for you.

Sure, no worries. Please keep up updated and good luck with your development.

Hi all,
very excited for this concept and use case!
We’re very interested in utilizing a side chain + bridge architecture for doing expensive on-chain verification with our NFT game

I saw that gas was being sponsored on ERC-20 bridge transactions, will this be the case again? I’m sure there will be limits too like the maxGasPerTx() that @akolotov mentioned. Will there also be a rate limit (as in max tx per day)? I’m also curious how the gas for the bridge tx is handled once they are no longer sponsored. Will they be paid up front in POA token (or xDAI) or will they be paid on the Ethereum side and revert if there is no gas waiting for reimbursement?

Hi! It will be great to see your game on POA or xDai chains!

Yes, currently it is assumed that the AMB feature will work in the subsidized mode. One of the reason is that we still have issues with the defrayal mode initially described here. The set of issues that needs to be addressed described in a separate work item. The questions you are raising will be answered as soon as the defrayal mode is implemented.

It is good idea to increase security of the bridge by limiting the gas totally spent by the contracts recipients during a day. So far, there is no such limit at all.

@okwme BTW, did you read an article where we describing How to develop a cross-blockchain application by using AMB bridge on the example of the erc677-to-er677 bridge?

Thanks for pointing out that issue @akolotov and linking me to the new article. The architecture makes sense to me :+1:

1 Like

I have created a new issue to add limit management for the bridge in AMB mode.

1 Like