They will technically be subdomains of pyth.sol, however, how you choose to refer to it within the context of your application is merely a UI-level decision. This means .pyth.sol can also be interpreted as .pyth at the App level. The Name service’s functionality is recursive by design, TLDs are functionally equivalent to domain names.
Similarly to Pyth, SNS is available on other chains. As of today SNS is available on BNB, Injective and BASE (not officially announced though) via Wormhole. Pyth subdomains will be bridgeable as well so ultimately you will be able to use your Pyth subdomain on every chain on which SNS is available. The long term vision of SNS is to be available on all chains that are connected to Solana via Wormhole while keeping Solana as the source of truth.
From what I understand, you can just use the .pyth subdomain. This would be registered with the .pyth database, and convert to the full .pyth.sol subdomain, which then convert to the Solana domain automagically?
Considering the .Pyth address would be associated to one address only: I don’t see why it couldn’t be associated with an ENS-type address in the future if a suitable proposal is brought forward and approved?
But I guess once the name is gone in .pyth.sol it won’t be available for .Pyth.ens?
I’m sure smart people will correct me here, but I’m here for the learning/roasting
Minimally I would suggest he integration of the Bonfida (either .sol or .pyth.sol or both) to the Staking Site. Currently it’s not.
I think that being able to mark a .pyth.sol SNS as Favourite directly on the Staking site would be great to make the usage of the SNS facilitated when the interest is coming from the Pyth community. This type of tech is generally not as intuitive as expected for basic/standard users.
I’m asking about duckling.pyth versus duckling.pyth.sol because I’d much rather own duckling.pyth.
In which case why not use alldomains for this since those are already domains and they don’t need to have .sol after them and dapps don’t have to chose and .pyth would work from the get-go in phantom and solflare
I would like to clarify the .pyth and .pyth.sol question raised in the replies above. The short answer is that it’s purely a UI convention.
The SNS SDK treats .pyth.sol and .pyth identically. I mentioned “.pyth.sol” and “subdomains” to emphasize the technical subdomain aspect. A UI convention can be explained with a wallet application example e.g Phantom or Backpack. The wallet uses the SNS SDK and potentially other SDKs for resolution. The SDK choice is based on user input. For instance, if the user enters something.sol , the wallet uses the SNS SDK. If they enter something.somethingelse , another SDK is used.
However, the choice of SDK is determined by wallet developers. Let’s say a .eth TLD is created on Solana; the wallet won’t use this SDK because .eth is ambiguous on Solana without consensus or convention.
Using .pyth.sol is advantageous because it ensures a unified approach and avoids user base fragmentation. We wrote an article about the TLD vs. subdomain approach here. The adoption of .pyth vs. .pyth.sol as a UI convention depends on the Pyth community, and a new TLD doesn’t guarantee better adoption since application support is key. However, pyth.sol adoption is automatic in all applications supporting SNS. Since the SNS SDK understands .pyth and .pyth.sol the same way, establishing this new UI convention is straightforward. Broader adoption by wallets and other apps will rely on the social convention that SNS and Pyth create together. This unified TLD approach maximizes the value and usability of SNS for its users while guaranteeing the most secure approach in the domain name space
As with everything new, there needs to checks and balances. There is a danger of early bird cyber squatting. Basically, where early users flood this new protocol by mopping up all of the good names (of potential value) and having them forever, then selling them on at a huge price. This could swiftly clog up the system and destroy the idea. Therefore, some sort of sybil/anti-squatting policy is needed, with the T&Cs stating that evidence of ‘squatting’ can lead to the removal of a pyth subdomain account without notice. There should also be regular (annual or every 2 years) review of the ‘health’ of the system. Penalties for sybils are the removal of these accounts and potential inability to create further ones. Also, having an account ‘forever’ should be replaced by a ‘rental’ system, so when they pay, they only get it for a couple of years (with an option to renew first). So those that ‘squat’ and bypass such checks will have to pay a premium to keep it later (most likely releasing it back into the ecoystem when it comes for renewal). As in all things, checks for ‘bad actors’ need to be in place. Hope this makes sense?
Interesting… Perhaps evidence of staked Pyth (at least to the value of the current price of the requested Pyth Subdomain?). You can then track where the staked Pyth goes to see if it’s being moved to only set up these subdomains?
I don’t like the idea of a subscription service personally, but hoping this serves as an alternative replacement?
That’s a possible approach, but whatever solution is decided upon, there needs to be something in place to mitigate against bad actors. It needs to costly enough, with scheduled checks and balances so that it keeps this type of behaviour at bay (or at a minimum). I can foresee a ‘microsoft’ or ‘amazon’ type of squatter, or ‘X’ (being the most obvious one) for twitter, just thinking how clever they are in grabbing this. Then 12 months later, the real ‘X’ is interested in buying it, only to find a sale price tag of millions of dollars, for something the person bought originally for 5 bucks and owns, potentially, forever (but will likely sell for a tidy sum). Not sure of the solution, but raising this now for awareness.
