[Implemented] Support trader claim trading rewards for API source

Proposal Structure

  • Title: [DRAFT] Support trader claim trading rewards for API source
  • Author(s): @Joy
  • Related Discussions:
  • Submission Date: 06.13.2023 (June 13 2023)

Simple Summary:

Update Hashflow trading API to make trader be able to claim their trading rewards.


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.


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.

Downside (Cons):

  • n/a


  • yes: agree with this proposal
  • no: do not agree with this proposal
1 Like

I agree with this proposal. it is not really relate to normal user but it is fair for everyone in the end.

1 Like

This is a fair proposal.

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, i support this proposal.
There would be no meaning if user was credited rewards but not able to claim.

Agree with this proposal :+1:

sound good!
I agree :wink:

This is true spirit of hashgangs, no one is left behind. 100% yes for me :100:

Sound good. I agree.

I am thinking that

    • After 30 day of rewards wallet migration, all the rewards that expired will not be changed.

should be at least XX days windows to match the current criteria.

1 Like

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.

This proposal has passed the Temp Check poll and is now an HIP.

Reminder on how the process works from here on out (see gov process article):

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.


This proposal is not systemically risky and is the same as the original ballot proposal

1 Like

Proposal doe not introduce systematic risks and matches the original proposal.

1 Like

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.

This proposal does not introduce systematic risks and matches the original proposal.

@Joy Thanks for the message - see above =)

1 Like

Sure @brian, thanks for your reply.

So if the Guardians approved it, should we move to the next step that the proposal is submitted for final vote?

Gm yes the temp check and HIP review period had passed, so the community can put it up for a final vote.

1 Like

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 :grin:

consistent and reasonable.

This HIP has been voted on and was passed by the DAO.