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