Vulnerability: Anyone can execute certain functions that use cross chain messages and potentially cancel them with potential loss of funds.
Severity: high

Description:
Certain functions that route messages cross chain on the `Game` and `MainVault` contract are unprotected (anyone can call them under the required state of the vaults). The way the cross chain messaging is implemented in the XProvider makes use of Connext's `xcall()` and sets the `msg.sender` as the `delegate` and `msg.value` as `relayerFee`. There are two possible attack vectors with this:\\nEither an attacker can call the function and set the msg.value to low so it won't be relayed until someone bumps the fee (Connext allows anyone to bump the fee). This however means special action must be taken to bump the fee in such a case.\\nOr the attacker can call the function (which irreversibly changes the state of the contract) and as the delegate of the `xcall` cancel the message. This functionality is however not yet active on Connext, but the moment it is the attacker will be able to change the state of the contract on the origin chain and make the cross chain message not execute on the destination chain leaving the contracts on the two chains out of synch with possible loss of funds as a result.\\nThe `XProvider` contract's `xsend()` function sets the `msg.sender` as the delegate and `msg.value` as `relayerFee`\\n```\\n    uint256 relayerFee = _relayerFee != 0 ? _relayerFee : msg.value;\\n    IConnext(connext).xcall{value: relayerFee}(\\n      _destinationDomain, // _destination: Domain ID of the destination chain\\n      target, // _to: address of the target contract\\n      address(0), // _asset: use address zero for 0-value transfers\\n      msg.sender, // _delegate: address that can revert or forceLocal on destination\\n      0, // _amount: 0 because no funds are being transferred\\n      0, // _slippage: can be anything between 0-10000 because no funds are being transferred\\n      _callData // _callData: the encoded calldata to send\\n    );\\n  }\\n```\\n\\n`xTransfer()` using `msg.sender` as delegate:\\n```\\n    IConnext(connext).xcall{value: (msg.value - _relayerFee)}(\\n      _destinationDomain, // _destination: Domain ID of the destination chain\\n      _recipient, // _to: address receiving the funds on the destination\\n      _token, // _asset: address of the token contract\\n      msg.sender, // _delegate: address that can revert or forceLocal on destination\\n      _amount, // _amount: amount of tokens to transfer\\n      _slippage, // _slippage: the maximum amount of slippage the user will accept in BPS (e.g. 30 = 0.3%)\\n      bytes("") // _callData: empty bytes because we're only sending funds\\n    );\\n  }\\n```\\n\\nConnext documentation explaining:\\n```\\nparams.delegate | (optional) Address allowed to cancel an xcall on destination.\\n```\\n\\nConnext documentation seems to indicate this functionality isn't active yet though it isn't clear whether that applies to the cancel itself or only the bridging back the funds to the origin chain.

Impact:
An attacker can call certain functions which leave the relying contracts on different chains in an unsynched state, with possible loss of funds as a result (mainly on XChainControleler's `sendFundsToVault()` when actual funds are transferred.

Recommended mitigation:
Provide access control limits to the functions sending message across Connext so only the Guardian can call these functions with the correct msg.value and do not use msg.sender as a delegate but rather a configurable address like the Guardian.