What are the steps for creating an ilp enabled wallet

Hi all,
There is a lot of information about ilp, stream, moneyd, rafiki, spsp and open payments.
But I no longer know where to look for “instructions/code” to build an application that will use the ilp and its layers that are most recommended and updated. Is there one place that show the steps to follow like what version of ilp to install and from where, which source code is the latest to build an app with, the latest tools etc’?
For that matter, I would love to know (if they are ok with that) what Coil is build on (not for copying them ofcourse), they are a great example since they already provide service to clients.
Or maybe just a page with step by step guide
Thanks in advance

Welcome @moveValuefast.

Those are some great questions!

To build applications on top of Interledger, it is recommended that you operate at the STREAM layer. This is where applications and interledger interfacing logic will reside. Currently you could build a wallet using SPSP and STREAM. I have a demo repo here https://github.com/matdehaast/wallet-receiving-example to begin that shows how to setup a basic wallet that supports receiving.

We are actually busy build an open source custodial demo wallet built on Interledger (https://rafiki.money and https://github.com/interledgerjs/rafiki.money/). We are doing this to build out the newer application level protocol Open Payments. Open Payments is an iteration on SPSP designed to enable more use cases. I would recommend looking at that code for an example of a more complex implementations


1 Like

Hi @moreValuefast,

We at xpring.io are doing something very similar to what Matt described above, with similar intentions.

We’re building on open-source code to demonstrate how a “wallet” can become ILP-enabled. In fact, we would love it if you copied our code to use in your own project (or contribute back to our projects even). Our primary goal (similar to rafiki I think) is to be a sort of “reference implementation” that others can take and adapt for their own usage.

Our software will be slightly different from the rafiki.money implementation for two reasons: First, to ensure good protocol design by ensuring our protocols aren’t tied to any particular programming language (e.g., a good chunk of the xpring ILP wallet is implemented in Java with front end in JS, whereas Rafiki is all JS).

The second reason is to ensure we don’t design protocols too narrowly by focusing on only one particular use-case. E.g., you will find that the rafiki wallet focuses on ILP and openpayments, whereas the xpring.io wallet portal will support these in addition to other payment networks or use-cases to show how ILP technologies can coexist with other offerings a typical digital wallet might have today (ex: PayPal or Coinbase, neither of which support ILP currently but for which ILP support would be useful).

On the xpring.io side, our ILP wallet is basically just a React app powered by the Java ILP Connector (https://connector.interledger4j.dev).


First of all, I thank you and Matt for your detailed answers.
I’m not a code person i’m a business development guy but i will make sure our developer checks the two sources of code before deciding on how to build our “wallet”.

I came across ilp and this forum not as an enthusiastic coder :slight_smile:
I started by holding coins like BTC, ETH and XRP in 2013 and decided to explore more in depth what Ripple does and followed their employees on twitter and that’s how I started to follow (justmoon) Stefan Tomas’s work and today I’m here :slight_smile:

I would love to keep in touch and see how we can collaborate

Thank you

1 Like

Hi David,

What’s the current status of the open source code?
How stable would you say it is to use as a baseline for new applications and use cases?

I can’t speak to the JS code but the Java Connector is what I would label as “pre-production” - we’re still implementing new features, especially around openpayments.dev. Once the project goes to v1.0 I would consider it “production ready.”

1 Like

thank you for the answer. Now that puts me in a dilemma :slight_smile:
Do I wait for the production version for working on my business demo or should I start with building my demo with the current version.

For demo you can certainly use the current version. For production though, wait for 1.0.

Sounds reasonable, thank you. Is there any way you can estimate how long it will take for the production version to be ready?
Are we talking about weeks or months?