## Summary
Users will lose their `$TGLD` tokens if they bridged their tokens to a destination chain where its `totslSupply` has reached the `MAX_SUPPLY` where no more `$TGLD` tokens can be minted.
## Vulnerability Details
- `TempleGold` contract enables users from bridging their `$TGLD` tokens across chains by **burning** these tokens on the source chain and **minting** them on the destination chain, but if the destination `TempleGold` contract has reached its `MAX_SUPPLY` of minted tokens; then no more tokens can be minted meaning that no more bridging can be done to this chain.
- Since `TempleGold` contract doesn't implement a non-blocking receive mechanism, the failed bridging call will be stuck in the channel (layerzero endpoint) until it's manually retried in another transaction by calling [`retryPayload()`](https://github.com/LayerZero-Labs/LayerZero/blob/a1fb11a3b9c0ac449291816e71eacede4e36613e/contracts/Endpoint.sol#L127C14-L127C26) on the destination lz endpoint, and this can be done only if the `totalSupply` on the filled (has reached its maximum total supply) chain has been reduced when other users bridged from this chain to other supported chains leaving some room for the pending minting of the bridge tokens to be executed.
## Impact
Users will lose their bridged-but not minted `$TGLD` tokens as these tokens are burnt on the source chain and can't be minted on the destination chain due to `totalSupply` reaching its maximum limit.
## Tools Used
Manual Review.
## Recommendations
In `TempleGold` contract: add a mechanism to store the failed txns due to reaching `MAX_SUPPLY` limit (implement a non-blocking receive mechanism instead of reverting and blocking the lz channels)
and implement an inbound/outbound that tracks the tokens bridged from/to the `TempleGold` contract, and enable minting of the delayed/pending bridged tokens whenever there's a room left to mint.