@ -83,3 +83,39 @@ The logical steps and flow of information involved in sending tokens from one ch
- If it's a native token, `BridgeRouter-B` sends the tokens from the pool it's holding in escrow
- If it's a native token, `BridgeRouter-B` sends the tokens from the pool it's holding in escrow
- If it's a non-native token, `BridgeRouter-B` mints the token to the recipient (
- If it's a non-native token, `BridgeRouter-B` mints the token to the recipient (
- *Note:*`BridgeRouter-B` can mint non-native tokens because the representative contract for the token on its non-native chain is deployed by `BridgeRouter-B` when it received a message sending the token from another chain. The router has administrative rights on representations.
- *Note:*`BridgeRouter-B` can mint non-native tokens because the representative contract for the token on its non-native chain is deployed by `BridgeRouter-B` when it received a message sending the token from another chain. The router has administrative rights on representations.
## Tracing a Message
Optics is currently still under active development. Because Optics batches messages and sends only tree roots, there is no way to track individual messages on-chain once a message is passed to the Home contract. A agent-querying tool could be built to query off-chain agents for individual transactions, but such a tool does not currently exist.
What this means for the token brdige is that there is going to be a state of unknown during the time of send and receipt. You can think of this as snail mail without any tracking but with delivery confirmation. The only things that can be confirmed on-chain are:
1) A transaction was sent on chain A to the BridgeRouter contract
2) The recipient addressed received a token mint on chain B
### Pseudo-tracking
1. Start by locating the `bridgeRouter` contract you are looking for, addresses in the config dir: