⚙️How It Works

Here's how Mysticswap works, in a nutshell:

• Points/assets live in an external source of truth, like a partner's database.

• We integrate with said partner so Mysticswap and the partner have access to the same point count per user at any given moment. See How To Integrate to see how we make that happen.

• We issue an ERC20 token that can only be traded on Mysticswap, where we can control it's movements and make sure the total amount of points per user mirrors what's in ours and our partner's backends.

• When a user logs in to Mysticswap, if they have points in a partner's point program, they can mint the corresponding tokens. Those tokens i.e. points can now be traded on Mysticswap!

• After every trade, we update the respective users' point count. Partners then read info from our webhooks to update their own point count accordingly, so everyone has the same information.

How we deal with edge cases

• A user might attempt to mint tokens twice before the project updates the available balance: to prevent this, the minting process is designed to only occur when the available balance changes during the Data Update webhook call. This ensures that any attempt to mint tokens between this period is invalidated, preventing double minting of points.

• A user might create multiple listings for tokenized points before the project updates the token count: our Smart Contract addresses this issue by making unaccepted listings invalid/expired. This prevents users from exploiting the system by creating multiple listings that could potentially be accepted before the token count is updated.

• A user might attempt to trade or send tokens elsewhere before Project updates the token count. To mitigate this risk, only certain addresses are allowed to transfer the token. This restriction ensures that only authorized (admin and Seaport contracts) can perform transactions, preventing unauthorized transfers before the token count is updated. This measure helps maintain the integrity of the tokenized points system by ensuring that only genuine transactions are processed.

Solving synchronization issues

• Failed balance synchronization during webhook call: a rollback mechanism is implemented for failed updates to ensure a stable state is achieved.

• Negative difference due to reduction/slashing of user points by partner or others: a burn mechanism is implemented to address negative differences in the current balance.

Solving differences in point counts before webhook calls

We understand that, while points are quickly being gathered by active users, points may increase since the last time the partner has updated point counts. In this case, users won't be able to access the newly added points until after the Data Update Webhook sync has been completed. This process is designed to perfectly synchronize the points deducted and added on both ends.