Passing duplicate tokens to Redemptions and TokenRequest may have unintended consequences
Both `Redemptions` and `TokenRequest` are initialized with a list of acceptable tokens to use with each app. For `Redemptions`, the list of tokens corresponds to an organization's treasury assets. For `TokenRequest`, the list of tokens corresponds to tokens accepted for payment to join an organization. Neither contract makes a uniqueness check on input tokens during initialization, which can lead to unintended behavior.\\nIn `Redemptions`, each of an organization's assets are redeemed according to the sender's proportional ownership in the org. The redemption process iterates over the `redeemableTokens` list, paying out the sender their proportion of each token listed:\\n```\\nfor (uint256 i = 0; i < redeemableTokens.length; i++) {\\n    vaultTokenBalance = vault.balance(redeemableTokens[i]);\\n\\n    redemptionAmount = \\_burnableAmount.mul(vaultTokenBalance).div(burnableTokenTotalSupply);\\n    totalRedemptionAmount = totalRedemptionAmount.add(redemptionAmount);\\n\\n    if (redemptionAmount > 0) {\\n        vault.transfer(redeemableTokens[i], msg.sender, redemptionAmount);\\n    }\\n}\\n```\\n\\nIf a token address is included more than once, the sender will be paid out more than once, potentially earning many times more than their proportional share of the token.\\nIn `TokenRequest`, this behavior does not allow for any significant deviation from expected behavior. It was included because the initialization process is similar to that of `Redemptions`.
Resolution\\nThis was addressed in Redemptions commit 2b0034206a5b9cdf239da7a51900e89d9931554f by checking `redeemableTokenAdded[token] == false` for each subsequent token added during initialization. Note that ordering is not enforced.\\nAdditionally, the issue in `TokenRequest` was addressed in commit eb4181961093439f142f2e74eb706b7f501eb5c0 by requiring that each subsequent token added during initialization has a value strictly greater than the previous token added.\\nDuring initialization in both apps, check that input token addresses are unique. One simple method is to require that token addresses are submitted in ascending order, and that each subsequent address added is greater than the one before.
```\\nfor (uint256 i = 0; i < redeemableTokens.length; i++) {\\n    vaultTokenBalance = vault.balance(redeemableTokens[i]);\\n\\n    redemptionAmount = \\_burnableAmount.mul(vaultTokenBalance).div(burnableTokenTotalSupply);\\n    totalRedemptionAmount = totalRedemptionAmount.add(redemptionAmount);\\n\\n    if (redemptionAmount > 0) {\\n        vault.transfer(redeemableTokens[i], msg.sender, redemptionAmount);\\n    }\\n}\\n```\\n