Add GET endpoint to retrieve possible feeRecipient values
lukeautry opened this issue · comments
Spoke with this Craig over at 0xtracker about this one and agreed it may belong in the SRA spec or should at least be acknowledged somewhere.
ERC dEX now has multiple possible feeRecipients. We may have dozens/hundreds/enough to require paging through in the future. Craig has implemented something on his side that allows the mapping to take place, but it may be useful for other aggregator type apps to also have access to this same data. As an example, we added this endpoint: https://aqueduct.ercdex.com/rest.html#operation/GetFeeRecipients
So a simple endpoint, e.g. GET /fees/recipients, returns ['address-one', 'address-two'].
I think this would be a great addition to SRA. I propose we add it to V2.
Thanks for the suggestion @lukeautry!
This seems like it's kind of the wrong way around.
If you have a service like 0xtracker.com that wants to be able to report what relayer an address is associated with, this helps so long as the address is from a relayer they're already pulling addresses from. If it's from a new relayer altogether, they still have no idea where to go to query for that relayer's name.
OpenRelay announced our affiliate program yesterday, where we're setting up fee recipient contracts for our affiliates. Those contracts have a "relayerName" property on them to help address this problem. Obviously not all fee recipient addresses are going to be contracts, but we figured the process for tracker sites could be something like:
- We see a fee recipient address
- Is it in our database? If so, use that.
- Is the fee recipient a contract? If so, does it have a "relayerName" property? If so, use that.
Having API endpoitns on the established relayers might help populate the database in the first place, but if a fee recipient pops up who isn't in the database, it doesn't tell anyone where to go to find out.
I think we should add it to SRA v2.
@AusIV's point that the mapping we want is address -> relayerName and not relayerName -> [address] is well taken, but when thinking through how to achieve this it seems that these are the options:
- We host an off-chain or on-chain registry of this information. (We already have the relayer-registry but my understanding is that fee recipients could be pretty dynamic, and submitting a PR for every change is untenable).
- We deploy or expect relayers to deploy a fee sharing smart contract that they maintain such that they can communicate only one address as the fee recipient.
Both these options seem like a lot of overhead. At least by adding the /fees_recipient endpoint, we have a decent way of getting the mapping now (by iterating through the relayers and querying this endpoint), and can build more complex systems off of it in the future.
We deploy or expect relayers to deploy a fee sharing smart contract that they maintain such that they can communicate only one address as the fee recipient.
Yeah, the reason I don't like relying on a contract is that it assumes that the feeRecipient is, in fact, a smart contract. While this is the most obvious use case, it may not be the only use case.
For instance, imagine a relayer that does multi-tenancy of some sort where every token pair has a different fee recipient. Perhaps some assets are in a different tier of asset and thus require fee servicing from a distinct entity. In those cases, the fee recipient is still a normal address and observers would need some way of mapping this back to the relayer.
This is being added in #26 (comment)