Verification and Validation
Before Dexible will accept an order for execution, it passes through a series of checks, both in the SDK and in the infrastructure itself. These checks are to protect the trader from mistakes in order details and to protect the infrastructure from extraneous expenses.
All interactions with the Dexible API requires a signature made from the wallet that owns the assets being traded. This ensures that only the order owner can query or manipulate the order details. In the near future, we will also support a JWT signature method such that a web-token can be retrieved and used for 24 hours before needing to be refreshed. When using the SDK from a stand-alone application, the SDK will handle signatures internally. When using from a browser-based app, JWT is likely needed or every interaction would require a signature from MetaMask, etc.
To mitigate spam or DDoS risks, all requests must be signed by a wallet that has some amount of ETH. This makes it more difficult to bypass our API thresholds by creating many ETH wallets. The current rate limit is 1 request / second since the state of the system won't change much in a single second (at least not until we introduce faster L2 networks). We will tune this rate limit as needed.
Instead of transferring custody of assets to Dexible, traders simply grant a spend allowance for the input side of a token trade. Traders have freedom to grant whatever allowance they are comfortable with so long as it covers the amount of all active orders referencing the input token. To save on transaction fees associated with token approvals, we recommend increasing the amount to cover whatever orders you expect to push through Dexible, or a MAX_UINT256 amount if you expect to push a lot of orders for the same token through the system.
Because Dexible receives its fees in output tokens, it must ensure that it does not take on excessive exposure to extremely low-liquid tokens. This means Dexible will verify that tokens being swapped meet certain criteria to ensure the maturity and acceptance of the token in the ecosystem. As discussed earlier, a minimum requirement is that all tokens have a Uniswap V2 path to WETH in order to compute equivalent gas costs. Additional criteria is used internally by the infrastructure to ensure broad community support.