About RNS integration levels
Overview
The Ronin Name Service (RNS) integration encompasses two levels, each of which can be implemented independently. The first level is the easiest and provides the highest impact for users, whereas the second level improves your dApp's usability and enhances your users' experience. This page explains each level in greater detail.
Level 1: Configure RNS name resolution
The first step to supporting RNS is to make your app understand RNS names and accept them anywhere an address is accepted. To understand how to do this, see Resolve RNS names.
When a user enters an RNS name instead of an address, remember the RNS name, not the address it currently resolves to. In the same way that your browser automatically redirects you to the new IP address of a website if its server changes, users can update their RNS names and have their apps automatically resolve to the new address as well.
If your app handles user funds or other critical resources, you may want to keep track of the address to which a name resolves and alert the user if it changes.
By accepting RNS names in your app, you eliminate the need for users to copy and paste or type out long Ronin addresses, such as 0x048360059c5afbbb460b8b17a0b41fc7e57cc11a.
Level 2: Support reverse resolution
The second step of RNS integration is displaying primary RNS names wherever your app displays addresses.
If a user enters an RNS name, you should retain this name and show it to them whenever you would normally show the address.
If a user enters an address, or the address is obtained elsewhere, you may still be able to show an RNS name, by performing reverse resolution. This way, you can display the primary name of an address when it's available. If no primary name is provided, your app can fall back to displaying the address as it did previously.
Reverse resolution makes it easier for your users to identify the accounts they interact with, because the accounts are associated with a short human-readable RNS name instead of a long Ronin address.