/ipns/app.uniswap.orgto the latest IPFS release
uniswap.ethnow points to the latest IPFS release allowing the URL uniswap.eth.link to be used
The Uniswap protocol is trustless and decentralized because it lives entirely on-chain. Anyone running an Ethereum node can interact with the contracts directly which will perform as programmed for as long as Ethereum exists. However, not everyone wants to run a node. Instead, many users choose to interact with Uniswap through web interfaces, trade aggregators, wallets, or other DAPPs that have integrated Uniswap natively in their smart contracts.
When using an interface, users should verify the transactions they sign match the transaction presented by the interface. However, it is not always easy to do this. This is why it is important to use reputable interfaces. We’re thrilled to see a growing ecosystem of high-quality interfaces for Uniswap, including Argent, 1inch, Rainbow, Paraswap, Zerion, Instadapp, and many more.
Open source interfaces (including many of the above) allow users to verify the code they are interacting with does what it claims. If a user runs the code locally, they can make transactions with confidence. However, as soon as the code is hosted, it is difficult for users to verify the website they are interacting has not been modified.
This is one of the problem that IPFS aims to solve.
Our team has always cared about decentralization, security, and accessibility. This is why we built an open-source interface for Uniswap that the community can directly run, verify and build upon. We’ve just taken another step forward by decentralizing the hosting of the Uniswap Interface using IPFS.
Using GitHub Actions, the Uniswap Interface is now deployed at least once per day to IPFS. Each release is automatically pinned using pinata.cloud, a free IPFS pinning service. The IPFS releases can be found on GitHub.
The domain uniswap.exchange is now redirected to app.uniswap.org, which is an alias to the Cloudflare IPFS gateway that serves the Uniswap Interface from IPFS.
app.uniswap.org subdomain is given a CNAME record pointing at
When a user visits the domain
app.uniswap.org, the browser first looks up the DNS record and finds a CNAME to
The server at
cloudflare-ipfs.com, i.e. Cloudflare’s IPFS gateway, looks up the
DNSLink record for the subdomain.
That TXT record contains the IPFS hash of the latest release.
Cloudflare’s IPFS gateway then fetches the content using the IPFS protocol and serves the interface to your browser via HTTPS.
Because IPFS gateways will not default to serving
/index.html as is expected by many single page applications, the Uniswap Interface uses a “hash” based router.
Some settings on the Uniswap Interface use localstorage, which is shared across users in some IPFS gateways.
When using an IPFS gateway and referencing an IPFS hash or IPNS name by the path (e.g. cloudflare-ipfs.com/ipfs/QmdJApBwfsGua9v…/) rather than the subdomain (e.g. bafybeig6hsm…cf-ipfs.com), other sites accessed from the same IPFS gateway can view and change your settings in the Uniswap Interface.
To avoid this possibility, you can use the subdomain format of IPFS gateway URLs, which are contained in every release along with the path format.
You can check what build you are being served from Cloudflare’s IPFS gateway by looking at your browser’s network console for the response headers sent directly from Cloudflare’s IPFS gateway.
Cloudflare’s gateway uses the IPFS hash of the deployment in the
etag header, and reports the resolved IPNS path in the
To keep the Uniswap Interface available, you can pin the hash of the latest release.
If this sort of work sounds cool to you, we’re hiring! Shoot us a message!