Introduction
Hey everyone!
After listening to some feedback and discussion about how the current SWAP.HIVE <> HIVE transactions are being done, one of the most complaints I heard was "oh but the bridge I am using is out of funds!" or something along those lines.
To solve that issue, I wrote @swaps, a simple aggregator that ensures (as much as it can) that you receive your SWAP.HIVE, or HIVE -- depending on which coin you send to it. By checking and using well-known and reputable bridges on the network.
How to use it?
Very simple! Just send >1.5 HIVE/SWAP.HIVE to @swaps with no memo (or put one in, if you'd like, doesn't really matter) and hopefully, in a couple of seconds, you should receive your HIVE or SWAP.HIVE, depending on which token you sent. If you send @swaps SWAP.HIVE, you'll receive HIVE. If you send it HIVE, you'll receive SWAP.HIVE. If by chance, the bridging services utilized by @swaps are completely out of funds, the bot will automatically refund you instead. (Read further for a hopeful solution to this problem.)
Currently, the service utilizes Leodex & Beeswap depending on their wallet holdings. So basically, you do not have to bother checking them if they have funds or bother with seeing if you got your refund... or actually be like my friend who forgot about his SWAP.HIVE because it got refunded and he never checked.
In the next couple of weeks, I am planning to implement an internal liquidity/swap system to ensure even in the worst-case scenario where both services that @swaps utilizes are out of funds, that @swaps can handle the coin bridging itself.
Why should I use it?
Because it's easy! You do not have to bother checking liquidity on other platforms. Simply use Keychain, Peakd, Hive.blog, Ecency -- whatever platform you're using to send your coin to @swaps, and it will convert it and send it to you.
In the future, with an internal liquidity system implemented, you can expect lower fees :)
Note
Please do note that while I and a couple of other people have tested the bot vigorously, it is possible that there might be some issues. I tried to prepare for most edge cases (in terms of node errors, library errors etc.) to automatically refund the user if a problem occurs. But if, by chance, you do not get a refund, please contact me.