LeisurePay security record

In the contract `Dispute`, the role `SERVER_ROLE` has authority over the functions shown in the diagram below. Additionally, this role has authority over the following functions: - `toggleClaim()` - `claim()` Any compromise to the `SERVER_ROLE` account may allow the hacker to take advantage of this authority and manipulate the outcome of a dispute or drain tokens from the contract via multiple different routes. Some examples include: - making a fake dispute with a high `usdValue` while using their own controlled accounts as the `sideA` and `sideB` addresses, as well as the arbiter addresses, so the entire balance of `lpy` tokens in the contract can be drained. - calling `claim()` and keeping the funds for themselves. - changing the addresses of `sideA` or `sideB` after the winner of a dispute is decided so that a malicious address collects the corresponding token amount. - setting `sideAWins` to a bool value that is contrary to the vote results. - adding or removing arbiters to affect the results of the vote. - specifying an inaccurate `ratio` corresponding to the conversion between `usdValue` and `tokenValue`.  --- In the contract `Dispute`, the role `DEFAULT_ADMIN_ROLE` has authority over the following functions: - `grantRole()` - `revokeRole()` Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and grant multiple malicious accounts the role `SERVER_ROLE` so they may use disputes to drain tokens from the `Dispute` contract.

The order of external calls and storage manipulation must follow the check-effect-interaction pattern.

While `tokenURI()` may perform a check that the token exists, it does not check whether one of the listed addresses for `_sideA` or `_sideB` owns the specified token. Please clarify whether the addresses listed for `_sideA` or `_sideB` are expected to own the token for which the dispute is held.