In an effort to continue decentralizing, we have created a mechanism for the community to host the Uniswap Interface
The open-source Uniswap Interface built by our team and community is automatically deployed daily to IPFS
Community members can pin the IPFS hashes to ensure availability
We use IPNS + DNSLink to point /ipns/app.uniswap.org
to the latest IPFS release
app.uniswap.org is now served exclusively from the latest IPFS release, however any IPFS gateway can be used directly
The URL uniswap.exchange now forwards to app.uniswap.org
The ENS contenthash for uniswap.eth
now 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.
The IPFS releases can be found on GitHub.
subdomain is given a CNAME record pointing at cloudflare-ipfs.com
When a user visits the domain app.uniswap.org
, the browser first looks up the DNS record and finds a CNAME to cloudflare-ipfs.com
. 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 x-ipfs-path
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!