Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Method to describe RegistrationStrategy, without knowing details of contract implementation #6

Open
aoxborrow opened this issue Aug 19, 2022 · 2 comments
Labels
low priority Not urgent or required

Comments

@aoxborrow
Copy link
Contributor

aoxborrow commented Aug 19, 2022

Since we are allowing TLDs to deploy their own RegistrationStrategy contracts with a generic interface, we won't necessarily know how the pricing works, or how it implements discounts. We may want to know the character length and registration length pricing for TLDs to show to the user. Part of the RegistrationStrategy implementation could be a method that can basically return a pricing matrix for various types of SLDs. Something like this:

getPricingMatrix()
[
    // internally, this runs getPriceInDollars('a.tld', '1 year'), etc.
    // num characters => price for 1-10 years
    '1' => [10,10,10,10,9,9,9,9,9,8],
    '2' => [5,5,5,5,4,4,4,4,3],
 ]

Alternatively, maybe we just require simple function interfaces that return this information specifically (while avoiding any premiums/discounts):

getPricingForLength(_length)
getDiscountForDays(_days)
@hodlthedoor
Copy link
Collaborator

This interface seems too specific, different rules have the possibility to have different prices for the same length labels.

I think we should change SubdomainDetails to have array of prices for the next 10 years or something like that.

@aoxborrow
Copy link
Contributor Author

aoxborrow commented Dec 8, 2022

Yes, the final computed price can depend on a bunch of different factors. But I think this is important for Registrars and resellers to be able to summarize the pricing strategy:

The registration and renewal price for .bar is $10/yr.*
* Some short or premium names may cost more

Otherwise, they would have to just pick a random name like asdfljkaasdf and get pricing for it and then assume it's the same for others?

Maybe all we need is public methods to access the various pricing strategy data structures for a specific TLD:

    mapping(bytes32 => address) public reservedNames;
    mapping(bytes32 => uint256) public premiumNames;
    mapping(bytes32 => mapping(address => uint256)) public addressDiscounts;
    mapping(bytes32 => uint256[]) public lengthCost;
    mapping(bytes32 => uint256[]) public multiYearDiscount;

e.g.

getLengthCost(tldNameHash)
getAddressDiscounts(tldNameHash)
getMultiYearDiscount(tldNameHash)

These methods could be provided by PricingStrategy, and maybe we enforce them in PricingStrategy interface?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
low priority Not urgent or required
Projects
None yet
Development

No branches or pull requests

2 participants