Bonfida Case Study: Decentralized gateways for Solana Name Service domains using Marlin Oyster

Marlin Oyster is a verifiable computing protocol that offers TEE-based coprocessors to process complex workloads asynchronously over a decentralized node network. Services deployed on Oyster can run for an indefinite amount of time and can even serve TLS requests using HTTPS endpoints.

Bonfida is popular for having introduced the Solana Name Service (SNS). SNS replaces long wallet addresses with user-friendly domain names, allowing users to access resources with ease. These domains can point to IPFS hashes from which web files can be retrieved, simplifying access to decentralized websites. 

However, most web browsers do not natively support SNS domains, necessitating the use of gateways. Gateways act as intermediaries translating SNS domain requests into IPFS retrievals. They retrieve data from IPFS hashes corresponding to the requested domain before serving it to users, bridging the gap between traditional browsers and the decentralized web. 

Gateways are normally operated by trusted parties. This case study details how Oyster can be used to make trustless gateways for foundational services like SNS eliminating a critical point of trust in the decentralized DNS workflow.

Drawbacks of centralized gateways

DNS workflow

SNS is similar to how today's Domain Name System (DNS) operates. Much like remembering and typing "" on one’s browser is easier than working with a numerical IP address (e.g.,, web 3.0 users can access IPFS-hosted websites with ease by simply using human-readable domain names, such as "example.sol," instead of complex Content Identifier (CID) strings like "QmPK1s3pNYLi9ERiq3BDxKa4XosgWwFRQUydHUtz4YgpqB."

Gateways play the role of fetching the content at QmPK1… and serving it to users who request for example.sol on their web browser. As a result, even though the content at QmPK1… resides on a decentralized store, it is the gateway that users are interacting with and relying on to access the content through their normal web browsers.

While gateways are essential, they often come with a significant drawback – centralization. Centralized gateways can be compromised by malicious actors who may redirect users to unauthorized or harmful websites. Moreover, they can be points of censorship violating the privacy of web surfers. Thus, centralization poses a significant risk as it introduces a single point of failure, undermining the core principles of decentralization that decentralized frontends aim to achieve.

Challenges with decentralizing a gateway

Creating a decentralized gateway is no simple task. There are three major challenges:

- Ensuring non-tamperable translation: The gateway must translate SNS domains into IPFS hashes in a tamper-proof manner. The translation process should be resistant to any form of unauthorized alteration which can lead to possible phishing attacks. It's crucial to guarantee that the gateway code is public and verifiable.

Gateway challenges

- Preventing man-in-the-middle attacks: It's essential to ensure that the responses come directly from the gateway and not from intermediaries attempting to intercept or modify the data in transit.

- Control of DNS records for the gateway itself: Traditional DNS services rely on the owner of the domain to control domain records. This makes the gateway itself and hence any SNS domains that rely on its translation service susceptible to attacks to gain control of the owner's credentials.

Gateway challenges

Deploying a decentralized gateway on Oyster

A decentralized gateway consists of (i) a server written in Nodejs which accepts requests and translates SNS domains into IPFS hashes, and (ii) an IPFS node to query the data using IPFS hashes. To deploy on Oyster, we first created a docker image with Nodejs and IPFS installed with an entrypoint script to run the Nodejs server along with the IPFS node. This docker image was then converted into an enclave image which was deployed on Oyster. CAA records are then updated using an ACME account generated within the enclave to lock the domain to be served only by the enclave.


Decentralized Gateways

Oyster is a decentralized network of secure enclaves employing Trusted Execution Environment (TEE) technology to run code securely. TEEs separate the code running inside them from the rest of the host machine at the hardware level making them immune to tampering. The IPFS node is also run within the enclave along with the gateway code to ensure that SNS domains are correctly translated to the IPFS content they point to. This ensures non-tamperable translation of SNS domains to IPFS.

Decentralized gateways

The second challenge is solved by account validation of CAA records in DNS. When a request is made for an SNS domain through the gateway, the browser checks for certificates known only within these secure enclaves. The certificates can be securely generated within the enclave despite the fact that it runs on an otherwise untrusted third-party host because of the security properties of TEEs. This process ensures that only the gateway running inside the enclave can provide responses to requests.

Decentralized gateways Oyster

The third challenge involving control of DNS records for the gateway is effectively managed through on-chain domain providers like 3DNS. On-chain DNS maintenance ensures the transparency of DNS records and allows changes to be made only after verifying that the correct code within a TEE is handling the requests. This rigorous process prevents unauthorized changes to DNS records, safeguarding the availability of the gateway.


Advances in decentralized infrastructure like Bonfida’s SNS and 3DNS can help make access to frontends more secure and reliable. Oyster can play a central role in such architectures by eliminating the need to trust server operators. By leveraging Oyster, gateways for DNS services like Bonfida or even various RPCs can be run verifiably ensuring that the services are fully decentralized without compromising user experience.

The decentralized gateway for Bonfida is already live. To access the "example.sol" domain from your browser, simply append ".pub" to the domain, entering "" to access the IPFS content linked to the ".sol" domain. This gateway effectively addresses the first two challenges in decentralizing gateways, and work is underway with 3DNS to resolve the third challenge. Stay tuned for further updates.

Follow our official social media channels to get the latest updates as and when they come out!

Twitter | Telegram Announcements | Telegram Chat | Discord | Website

Stay connected

Subscribe to our newsletter.