# Bridge Protection Question and Suggestions - Vagueness on multiple token support - Source contract can initiate bridging for multiple tokens. - Capacity variable is not token specific - Single token address is set in destination contract constructor - There is condition to check native token when bridging is initiated - If we decide to go with a contract for single token, that talks to single remote chain, we will end up deploying many contracts and will make ops very difficult down the line. Totally fine if we plan to rewrite contract when that is reached. - Capacity increase issue. - There is a comment saying socket never increases capacity. Please share more info, would love to help debug - Maybe it is because increaseCapacity message is being sent with zero value, we need non zero for fees. - Arch - How is capacity set initially? - Why is resolve gated? can we somehow make it public? - What is deadline? If it means the time after which insurance becomes processable we need some way to enforce it on chain. Resolvers can process insurance even if deadline is not reached. - Handling fallbacks - Sometimes bridges end up going to fallback, Hop can give htokes if slippage tolerance is not met. And these htokens need to be exchanged for normal tokens manually on their AMMs. - CBridge (although not supported right now) give refund to sender on source chain. - Need special functions to handle these cases. - Also a good idea to have admin gated token rescue functions for initial versions. - Gas savings - bridgeId may not be needed in payload. - Do we need to store purchasesByChain? - Variables set in constructor can be made immutable. - Operation type can be avoided since there is only one type of message from source to dest and one type in reverse. There are never 2 types of messsage on same path. - Admin fees can be collected in same contract, have a claim function that can be used by admin. Reduce resolve gas cost by batching erc20 transfer to admin. - Misc - Premium may need more precision. 0.1% is 10 bps.