Closed MicaiahReid closed 1 month ago
If we know the namespace, we know the pricing function, and we know the formula being used, this should be calculated by the front end providing the registration process, but yes we can implement a read only function to get a name price
I'd be in the camp of restoring the get-name-price
we had in v1. The price computation and the pricing function is quite involved, it would be a burden for developers to re-implement in javascript, rust, etc. It took me a few days to implement and test it in Clarity.
What was the rationale for removing this read-only
endpoint / the downside of exposing it ?
That for managed namespaces the returned information won't be the real one since managers will handle their own pricing function, but I can add a check for that.
Will work on adding it back
Thanks for this @lgalabru @MicaiahReid
@lgalabru @MicaiahReid this issue has been addressed and merged
@lgalabru and I are the process of testing the BNS-V2 contract using txtx.
We're creating some runbooks that will make it easy for users to try out the protocol.
When preordering + registering a BNS name, I noticed that the expected
stx-to-burn
is calculated by the private functioncompute-name-price
. There's currently no way (as far as I can tell) for a user to determine what the requiredstx-to-burn
is for a given name.Is there a plan to introduce a read only wrapper around
comput-name-price
(a la BNS v1'sget-name-price
function)? It seems like the contract would be unusable without this function, but maybe I'm missing something?