Update Hashflow trading API to make trader be able to claim their trading rewards.
Abstract:
Currently, Hashflow give trading reward to those who used Hashflow Front End and Hashflow API for their trading. For normal FE user, they can easily claim their reward in Ethereum mainnet through Hashflow Front End. But for API user, the rewards has been credit to trader wallet (which usually a contract). Since Hashflow deployed on various chains so this trader-contract does not really exist in Ethereum mainnet, and trader-contract can not use Hashflow FE also. So in the end, they could not actually claim the trading rewards even the rewards has been credit.
The proposal is to support API user can claim their trading reward. These users will also be reviewed before receiving rewards. This could be implemented as following:
for newly request: Hashflow API will include a field rewardWallet, once user use the quote from Hashflow API to trading, Hashflow will credit the rewards to that wallet in Ethereum regardsless of where you trade.
for retroactive wallets which already have trading rewards before this proposal be implemented:
if the rewards had been credit to contract-trader address, Hashflow will migrate that rewards to a different wallet (based on user tickets on Discord). for Discord verification, user have to perform a trade through Hashflow or make a trader-contract transaction to provide that they own that trader wallet as condition agreed before the transaction (timing and amount, etc…).
at the time of implemented this update, there maybe some rewards expired. Hashflow will have 30 days period for API trader to create a ticket on Discord for rewards wallet migration. In that 30 days if API user did completed the rewards wallet migration, Hashflow will extends that rewards for more 7 days from the day of migration rewards (which mean they will have 7 days from the time migration to claim the rewards, after 7 days rewards will be expired as designed). After 30 day of rewards wallet migration, all the rewards that expired will not be changed.
Specification & Rationale:
See above.
Motivation:
Not only Hashflow, but also other exchanges do have their majority of trading via API key. These trading source is very essential to all platforms and give platforms sustainable growth as well as easier to approach more user.
This is one of the way to growing the ecosystem and widen the popular of our DEX, make our trading more flexible for everyone with multiple purpose, bring Hashflow as a top choice of trading source, which attract more traffic (volume) to our DEX.
Benefits (Pros):
make API user can claim their reward, then they can “really” be incentive, so they could take part in GOV and ecosystem equivalent to their contribute as equal to normal user.
platforms, trading venture with strategy of trading and control their PNL will have more reasons to use Hashflow as trading source (as long as our advantage of zero-slippage rate).
platforms could freely think of ways to use this rewards (incentive user, keep in treasury, etc). This could make protocols more flexible, make Hashflow the most popular DEX.
For Discord ticket handling (someone claiming that they traded before but their rewards expired), what is a good way to authenticate the user? That should probably be specified.
Good point. Just updated to add more specified. Basically for rewards expiration, we should think of the way that give them a chance to claim (since API user can not claim even through knowing that the rewards expired) but it can not be too long that API user can take advantage of that and Hashflow team does not need to take too much effort/period on this.
Yes, that is just an estimate. Mainly leave it there for team to allocate effort. Whatever time make team feel comfortable with, but need to be reasonable for everyone.
a. Forum post tag in the title has been updated to “[HIP]”
b. This forum post should remain open for minimum of 3 days before a final vote is submitted (to give time for others in the community to review and share their feedback as well)
c. Author reviews/incorporate new input/feedback that are applicable
d. Guardians have been notified to review and approve/veto this HIP
e. This HIP will need majority approval from the Guardians before it can be submitted by community for final vote - the Guardians will reply to this thread directly.
Thanks @brian.
Does the Guardians approve it? If not, can u or someone please tag them or let them know so they could give opinions? And after that we will continue as governance process.
Great to hear, that seem worth for the wait, finally.
So i guess what i could do now is wait for the community to raise and post for final vote then.
It would be great if u could share this to Hashflow community and encourage them to submit this final vote. Thanks everyone
