Node configuration for Trinity wallet support

Tech Updates Sep 06, 2018

Following the beta release of Trinity Desktop, we have received multiple reports of nodes being incompatible with Trinity Desktop, despite working well with Trinity Mobile.  

This blog post explains the differences between the mobile and desktop platforms which lead to this issue. We then outline the measures node owners should take to ensure compatibility with the Trinity Wallet on all platforms.

In addition, we have created a tool to check your nodes for security issues and Trinity compatibility — Click on the link, check your node and continue reading below if any issues are reported.

Trinity Mobile and Trinity Desktop differ in how they make requests to IOTA nodes. Trinity Mobile uses React Native Fetch API, whereas Trinity Desktop uses Chromium browser Fetch API. These APIs differ in small details — one of these details is how Cross-Origin Resource Sharing(CORS) requests are executed.  

Public IOTA nodes receive requests from entities outside the domain on which they are hosted. Therefore these nodes should allow cross-origin requests by adding anAccess-Control-Allow-Origin: *header to the responses. This basically states that anyone (including the Trinity Wallet) can make requests to the node, and that it is not restricted to a certain domain.

Trinity Desktop additionally checks for a single occurrence of the Access-Control-Allow-Origin header. If your node proxy is misconfigured or it is additionally behind a CDN proxy (e.g.Cloudflare) the header could be added more than once, resulting in Trinity Desktop not accepting it.  

You can check your node by using the Node check tool, or perform a sample request to your node and check if the header is occurring once, by running this command in the Terminal:  

curl -I -X OPTIONS https://your.node:443
Misconfigured response example
Correctly configured node response

To verify that the public node server understands and accepts the CORS protocol, Trinity desktop issues a Preflight request before the actual request. To support Preflight requests, node proxies must be configured to allow OPTIONS requests by responding with:  

  • an Access-Control-Allow-Methods value containing at leastPOST, OPTIONSand
  • an Access-Control-Allow-Headers value containing at leastContent-type, X-IOTA-API-Version.

Receiving this response, Trinity Desktop is satisfied that it is allowed to make requests to the node, and continues with the actual POST request.  

To check this use the Node check tool, or fire up the Terminal with the following command and check that required headers are returned correctly:  

curl -I -X OPTIONS https://your.node:443
All required headers are correctly returned

If you set up your node by following a tutorial, please contact the author of the tutorial and share this blog post.

If you set up your node and the SSL proxy yourself, see for further helpon how to correctly enable CORS on different systems. If that also fails, you are always welcome to ask for help on the #trinity-discussion of the IOTA Discord.  

As an alternative, you can always use a node from the Trinity Desktop built-in node list which is regularly checked for up-to-date nodes.


IOTA Foundation

Official posts from the IOTA Foundation, and migrated posts from old platforms.