Building on the XRP ledger. ♥ Wife, kids, 🦜 & programming (TS, nodejs, Linux ...) – BDFL at @XRPLLabs (XRP ledger tools development 🎉)

At some point in the future the Flare network will be launched by the people at Flare Networks. The native token of the Flare network is “Spark” (just like the native token of the XRP ledger is “XRP”).

The Flare network and the XRP ledger are separate ledgers based on entirely different underlying technology, each with their own characteristics, advantages & use cases. The two ledgers will be in a relationship together though. Here's a somewhat technical, but step by step explanation of how the XRP token on the XRP ledger relates to the FXRP token (representing XRP on the Flare network), and how the (native Flare network) Spark token comes into play.

At some point in the future, the people at Flare Networks will launch their actual network, and . In short, all people holding XRP in non custodial wallets (you keep your keys) will be eligible to claim Spark tokens.

Some exchanges will distribute Spark as well. If you own XRP at an exchange that doesn't participate, you can still withdraw your funds to your own non custodial XRP ledger account – eg. using XUMM wallet (read on for more information).

Before I continue, I'd like to emphasize that I am *not* part of the Flare team, *don't* have more details / information (like timelines, etc.) and have *no financial incentive* to promote the Flare network and/or Spark token.

As the founder of XRPL Labs, working on XUMM (a non custodial XRP ledger wallet) I would simply like to offer our users (and Ledger Nano users, using *XRP Toolkit*) a way to prepare for the Spark token distribution.

Please note: I am *not* the right person to ask questions about the Flare network, the Flare project, the Spark token, the Spark token distribution, the amount of Spark tokens to receive, the distribution timeline, etc. Please reach out to the Flare Networks team if you have any questions about these things.

Receiving Spark tokens

Spark tokens will be distributed at a moment that is still to be announced by the Flare team on the Flare network, based on the amount of XRP owned on the XRP ledger.

The way this will work:

  1. XRP ledger account holders will need an account (private key & account) for the Flare network. Private key & account can be generated already, to be used in the future on the Flare network once the network is ready.
  2. XRP ledger account holders will prove account ownership by signing a reference, pointing at their account on the Flare network. This reference will be stored in a “MessageKey” field on the account level on the XRP ledger.
    This means your “r...” account address on the XRP ledger will point at your own “0x...” account on the Flare network.
  3. Once the Flare network & team is ready (they will announce this in advance), they will read all XRP ledger accounts pointing at Flare network accounts, check their balance and distribute an equal amount of Spark tokens to the Flare network account pointed at in the XRP ledger account.
  4. Users with eg. 1000 XRP in their own account on the XRP ledger will then own 1000 Spark in their other account on the Flare network.

A tool for XUMM and XRP Toolkit (Ledger Nano) users

To make step 1 and 2 safe and as easy as possible, I created a tool:


Using my tool you will be guided through the process of storing a reference on your XRP ledger account to your (probably: to be generated) account on the Flare network.

You can already use the tool today, even though the Flare network isn't ready yet, and the Flare team haven't launched their Spark token distribution programme yet.

If you have questions, please be patient: the Flare team will share more details over time, or check their timeline: some questions have already been answered by the Flare team.

*»* *Launch the tool (step by step, with instructions)*


Photo by Umberto on Unsplash

For geeks, developers & curious people: an explanation of how pointing at your Flare account from your XRP ledger account works.

  1. Take a ETH-compatible public account address you own the private key (or secret, like mnemonic, seed, ...) of, eg. 0x415f8315c9948Ad91e2Cce5b8583A36dA431fb61
  2. Strip the first two characters, and turn the string to upper case characters: 415F8315...A431FB61
  3. Prepend 02 and 24 zeroes: 020000...000415F8315...A431FB61
  4. Store this value in the MessageKey field on your XRP ledger account (on ledger) using an AccountSet transaction

Now (at some point, when they are ready) the Flare network will:

  1. Find & monitor all XRP ledger accounts with an MessageKey set on the account level
  2. Check the XRP balance for those accounts
  3. Take the last 40 characters (the ETH-compatible public account address) of the MessageKey value for the account, and send the XRP balance equivalent in Spark tokens to that ETH-compatible account on the Flare network

As you own the key (secret, mnemonic, seed, ...) to access the account on the Flare network, only you will now be able to access the Spark tokens (on the Flare network, a different network than the XRP ledger).

So PayID was launched today. An open standard to send crypto (and even non-crypto) using a handle that looks like an email address (“email address for payments”). I published a short blog about PayID.

I'm very proud that our XUMM app and platform is one of the first clients supporting PayID (for sending to XRP ledger accounts only, for now). Seeing XUMM listed in the Founding members section is pretty cool!

As expected I received quite some questions, and I tried to answer most (if not all) of them. I'd like to highlight some questions & my answers, as I believe there will be more community members & readers with the same questions. So here's my curated FAQ.


PayID (Tech. answer)



Checks Amendment

Great thread by David Schwartz

PayID & XUMM in under 5 minutes


Ever wondered why, when sending cryptocurrency around, you have to copy/paste these long weird addresses (and potentially: destination tags while when an e-mail the destination can look like hi@wietse.com? Or more common: user@provider.tld (eg. john.doe@gmail.com).

Well, those long crypto addresses are a thing of the past. Or: will be. In the past months alongside industry leaders across technology, crypto, and finance we’ve been working to develop PayID: an address for payments that works like email. With an $ instead of an @ sign. The PayID standard is an open (and open source) standard, and supports all rails: not only crypto (all chains), but even fiat payments (eg. bank account numbers, like IBAN accounts for the SEPA area).

Just like email addresses, a PayID can be issued to you by a provider. One PayID can contain multiple destinations (multiple rails), so one PayID can contain eg. your XRPL address, a bank account, a BTC address, etc.

For geeks, companies, hobbyists, it's even easy to run your own PayID server/service to serve your own PayID on your own domain.

At XRPL Labs we collaborated with the PayID workgroup since day one, and we're really proud to be one of the four first wallets with PayID support from day one.

Developers paying attention to our XUMM (backend & app) Github commits may have already noticed “PayID” appearing in some commits. XUMM already features PayID resolving (when sending funds), and later this year (2020) all XUMM users can create their own profile with hosted PayID's for incoming payments.

If you open XUMM, go to Send and enter in the recipient name/address, you'll notice a PayID result containing my XRPL account address (read on after the demo movie below)


Q3+Q4 this year (2020) the XRPL Labs team will work on XUMM user profiles (opt in), where you will be able to claim your own slug. You will then be able to (opt in, again) select one or more of your XRPL accounts and assign them a slug as well. PayID's will be included (for all users), like:

  • **yourslug$xumm.me** (for your primary account)

  • **yourslug+savings$xumm.me** (for your additional Savings account)

I envision a future where all crypto companies will offer PayID to their users as well, making depositing to an exchange a worry-free and user-friendly experience. I believe there will even be chain and vendor agnostic services. Just like “@gmail.com” serves a huge amount of users, providers (like XUMM) will too.

Try: wietse$xumm.me

We believe PayID can be a great addition to the payments ecosystem, further improving cryptocurrency usability.

For more information on PayID go to PayID.org

This version is an early release of the upcoming 0.5.1, to push out some updates in advance. This allows some other XRP ledger ecosystem developers like NixerFFM & TowoLabs to move forward with their product releases relying on XUMM.

This release will be available in the AppStore & PlayStore the last week of May 2020.

Added / Improved

  • Added showing release notes on the first start of XUMM after installing an update
  • Account list now shows if the account is Read Only, Read/Write and/or a Regular Key (rekeyed)
  • Support for AccountDelete transactions
  • Added haptic feedback (can be turned off in Settings)
  • If there's no (internet / network) connectivity, XUMM will now show a “Disconnected” message
  • If there's a destination account address (r...) or Payload link on the clipboard, XUMM offers to open it
  • Allow selecting a preferred transaction explorer
  • Unremovable Trust Lines (currencies) now shows a message in advance (instead of trying to remove anyway)
  • Timeout on sending & confirming a transaction
  • Updated conditions for IOU (currency) exchange Liquidity warning

Changed / Fixed

  • Entering an amount for a Sign Request without a predefined amount is now mandatory
  • When sending a payment, the currency code for a HEX currency code was not decoded to text
  • When a node is unavailable, another node will be contacted. On the next XUMM start the fallback will now be reverted
  • Issuer name now displayed on the home screen (assets)
  • Transaction Fee is now min. 12 drops (fixes “zero fee” bug)
  • Sometimes the account list (for account switching) didn't scroll down far enough
  • Fixed app freeze on “Explain Balance” after AccountDelete attempt
  • No longer count destination tag 0 (zero) for mandatory destination tag detection (Send flow)
  • On small screens, the keyboard would be on top of the Name field when adding contacts
  • Sharing the transaction hash sometimes copied an empty string instead of the tx hash
  • Read only accounts with Regular Key (became read/write) didn't allow adding currencies from the home screen
  • Fixed condition (multi window) where PIN wasn't asked
  • When changing the passcode: first digit could not be removed
  • Fixed “invalid payload” message on for some OfferCreate sign requests
  • Fixed condition causing Trust Lines (currencies) not showing up

The XRP TipBot migration to Uphold is now in motion for one and a half day, and already 1850 users moved almost 130k XRP to Uphold.

The one thing I didn't address: ILP Payment Pointers. The ones Coil donates to. I didn't, as I knew the people at Coil and Uphold were working on something nice.

Just in: Coil & Uphold partnered. You can now use your Uphold card(s) to receive payments over ILP.

Please update your Payment Pointer at Coil! (Instructions below).

In the meantime, donations coming in to your XRPTipBot.com payment pointer can be forwarded to Uphold. To do so, visit the XRP TipBot Account page.

If you linked your Uphold account and you have “leftover XRP” in your TipBot account (eg. due to ILP donations to your payment pointer) you will find a notification & button to migrate the balance to your linked Uphold card:

I will provide this migration for some time to come, but please don't let that delay you migrating your Coil payout options.

Instruction: update your Payment Pointer at Coil to point to Uphold

Please go to Uphold, and select your TipBot Card. Go to “Add Funds” and select From Interledger Payment Pointer.

Now click the Generate Payment Pointer button.

You will get a ILP Payment Pointer. Copy this, you will need it in the next steps.

Now go to your Coil Account Payout Settings:


If your account is configured to direct donations to your XRP TipBot account or a manual payment pointer containing “xrptipbot.com”, click Change:

Select “Setup” for Uphold, and paste the ILP Payment Pointer you generated at Uphold:

That's it. You're good :)

Your Coil donations will now end up in your Uphold card.

If you are a NY resident and you can't use the Uphold ILP services, please select one of the other payout options at your Coil.com Account Payout settings.


Photo by Åaker on Unsplash

The XRP TipBot (Twitter: #xrptip, Reddit: /u/xrptipbot, Discord: @xrptipbot) is a hobby project I started in 2017. Created for fun and the XRP Community. If you don't know me: I'm Wietse, a software developer from The Netherlands, working full time on XRP ledger related projects.

During the last 2.5 years the TipBot had a good run. Over 2.5MM XRP tipped in almost 1,000,000 tips, mostly on Twitter. (10k active App users. 62k accounts. 36k signed in users, 18k monthly active users). One specific feature contributed greatly to this (relative, still a hobby project) success: the fact that anyone can be sent a Tip with just one message (Tweet/Post), without the recipient having to “setup” an account (at xrptipbot.com). Tip balance could just be forwarded using the same syntax, or a withdraw could be requested at xrptipbot.com.

As you can imagine it made me so incredibly proud to see all those users from around the world sharing their love and generosity with other people. Charities received thousands of dollars in XRP and medical bills were paid by random strangers. Taking advantage of the speed and low fees the XRP ledger offers.

The Netherlands was a great place to live for my TipBot hobby project-that-got-a-bit-out-of-hand (as it involves crypto custody). With no specific regulatory requirements for cryptocurrency custody I was able to keep some XRP in a hot wallet, waiting until a tipped stranger claimed the funds XRP using an on ledger withdrawal.

This changed, rapidly. A little over three weeks ago the NL government passed the bill that will kick off the regulation of crypto currency custody in The Netherlands. While I feel this is a good thing, there are a few very problematic issues as well:

  1. Bill passed April 21st. A six month grace period was promised starting Jan. 10th (this year), but:
  2. Mandatory registration at the NL regulator by May 18th. That's a few days from now.
  3. Worst of all: uncertainty. Costs. Subsequent calculation somewhere in 2021 (next year)! Costs are already estimated at ~25k per year, and with more and more crypto businesses in NL closing shop (because of the uncertainty and deadline), the regulatory costs will be spread out over less companies, resulting in a horrible bill in 2021.

Did I mention the TipBot is a without any fees for users?

So. A deadline I cannot possibly meet. Costs I cannot possibly predict. Implementing KYC and AML myself. While plans still exist to do all of this in a more generic way I decided I can't get my ducks in a row within a few weeks (now days), and I don't want to charge absurd fees for using the TipBot. That wouldn't make any sense, and take all the fun out of it.

I've been racking my brain, trying to come up with a workaround / alternative.

With XUMM in Beta, maybe I could take the entire TipBot on ledger? While I initially thought this was a viable option, the more I thought about it, I realized it wasn't. There's the 20 XRP account reserve, so new users would not be able to onboard unless someone tipped them 20 XRP at once. Then there's usability. While there's always plenty of room for improvement, I aim to build user friendly software that doesn't need an entire step by step manual. If onboarding would mean a user would have to download a non custodial wallet app, generate an account, write down a secret, purchase & send XRP (or get a 20 XRP tip), etc., what good would that be?

When it comes to usability, one of the companies in this space I really admire is Uphold. I had some calls with them before (about integrations, working together, XUMM, etc.) and I really appreciate their vision, team & leadership. Their platform feels like home, and they have a great, well documented API. A dream come true for any developer 🎉

So I called them. A week ago. What would/could XRP TipBot ❤️ Uphold look like? Would we be able to partner up in a matter of days? We had calls at odd hours (early mornings & late nights (time zones)).

The Uphold team went all out to help me. To allow the XRP TipBot to survive. And they did!

The XRP TipBot will live on. One difference: all XRP TipBot users will have to link an Uphold account to be able to hold & receive balance. I assume many XRP Community members & crypto enthusiasts already have an Uphold account: they will be able to link their account (two clicks and done) a few days from now. Users without an Uphold account can register at Uphold first. (It will be possible to skip this and simply withdraw your TipBot balance, of course).

So yes. Users will have to link an Uphold account before they can send or receive Tips in the near future. But the upsides of XRP TipBot ❤️ Uphold... 🤯

A few days from now, when linking your Uphold account to your TipBot account is possible, thanks to the existing Uphold platform, the XRP TipBot will benefit from their:

  • Fiat on-ramp
  • Fiat off-ramp
  • Crypto currency exchange (from / to the TipBot linked account)
  • Optional: linked TipBot balance for multiple social media accounts, eg. Twitter (Private) + Twitter (corporate) + Reddit + Discord sharing balance. Or separate balances per account. Mix and match!

The TipBot (and App) will live on!

I will soon provide more information on the migration, as I'm finishing the last lines of code. But I promise you that no one will have to part with a single drop of XRP, and the people at Uphold and I will make the migration as simple as a few clicks.

XRP TipBot users: thank you for being awesome. I hope to see you around in the 2nd life of the XRP TipBot 😘

To the people at Uphold: THANK YOU for offering a warm welcome to the XRP TipBot users.


Photo by Kristopher Roller on Unsplash

The third XUMM Beta release (version 0.4.1) has just been published to the Apple (iOS) App Store & Google Play Store. The updates will be available for download & install in a short while.

This version contains 53 (!) improvements, reported by several community members. Some issues were directly reported to the XUMM issue tracker on Github by @nixerFFM (Daniel) & @raredata (Markus). Thank you, community, Daniël & Markus!

Noteworthy updates/improvements/changes:

  • Improved “deeplinking”, where XUMM automatically opens when a 3rd party application uses XUMM for signing. Please note: this doesn't work from Twitter in-app links. This is a Twitter limitation, affecting all Android/iOS apps.
  • Only show spendable balance and a “Balance breakdown” panel is added, explaining on ledger account reserves.
  • Support for “Read Only” accounts & regular keys 🎉 – You can now import your (r...) account as a Read Only account. When a regular key is configured & the regular key is present in XUMM as a Read/Write account, you can now use the account for signing & sending transactions :D (Eg. Toast Vanity Accounts will now work).
  • Account balances are now no longer visible in the split second before unlocking the app.
  • Improved destination tag handling (separate popup screen), better user interface flow. Auto detection of required tag for exchanges with faulty hot wallet configuration.
  • Escrows with Conditions can now be finished (as reported by xumm.community users)
  • Some users couldn't remove currencies from their account (Trust Lines) eg. in case of a (invisible, really low) leftover balance (and rippling account config). Leftover balance will now be auto exchanged for XRP upon currency (Trust Line) removal.
  • QR codes with a destination tag and/or prefilled XRP amount only picked up the destination account. Now the tag & amount are auto filled as well (when scanning from the App home screen)
  • Improved destination address book matching (include tags, fall back to address book record without tag)
  • Show empty fields as well on eg. AccountSet transaction
  • Support for HEX private keys (import using the `family seed` method) – this is for you Richard 😚
  • Allow account import based on a family seed using the QR scanner.
  • Other currencies are now removed from the “Add currency” list if already present.
  • IOU-to-IOU payments with a Transfer Fee (eg. send & deliver Bitstamp USD, Gatehub EUR, etc.) can now be signed and sent with a manual payment flow (“Send”).

There will be another 0.4.X release (0.4.2) soon, and after that we will spend some time on improvements under the hood before working on 0.5.0.

Meanwhile, besides working on the App & XUMM platform, we're working on a Translation Panel (will be added to the XUMM Developer Console) so contributing community translations will be easy, straight forward & offer context aware preview in your own XUMM app.

Thank you for your trust, support, input & enthusiasm 😘

The XRPL Labs team

Ali, Tristan & Wietse

The second XUMM Beta release (version 0.3.0) has just been published to the Apple (iOS) App Store, after the Android version was already released at the end of last week.

Please note that this version has been removed from the Chinese App Store by Apple, since cryptocurrency transactions are still not legal in China. XUMM is still available in all other regions.

Some of the most reported bugs are fixed in this release, like:

  • Sending funds with a destination tag zero (0) now doesn't result in an endless wait for transaction confirmation
  • Decimal character (on the keyboard) wasn't visible for some Android users
  • On ledger memo can now be longer (previous release allowed only a few words)
  • Fixed a bug causing the app not to show account transaction history for some accounts
  • Improved connection handling to the xrpl.ws nodes on Android (previously causing multiple connections to be setup)
  • Non-standard length mnemonic accounts can now be imported, as well as mnemonic accounts with a passphrase (“25th word”) – PLEASE consider THIS before importing your mnemonic account.
  • App PIN code allowed some Android users to use non-numeric characters, locking users out of signing (sending funds).
  • Memo's from transactions flagged on the https://xrpforensics.org advisory are now hidden by default.
  • Updated/improved the English translation here and there, removed some typo's and changed “Unknown” (when sending and entering the destination account to “No name found” (less confusing)
  • Added the “Switch account” button on the upper right corner of the home screen for iOS users as well (previously: only possible to switch accounts on iOS by holding the Home icon (lower left corner))
  • Improved Android “Back button” handling
  • Fixed a bug causing some Android users to be stuck in the intro screen, being unable to setup XUMM
  • Fixed a bug where it was possible to skip the FaceID/Fingerprint check when opening the app
  • Fixed several minor bugs causing the app to crash in rare conditions

One of the bugs we're still working on is XUMM being unblurred for a second when opening, before the PIN/FaceID/Fingerprint is requested. We're aware of this bug and it'll be fixed soon.

Of course we changed some more, the full list of changes can be found .

Thank you, #XRPCommunity, for all your testing, reporting, help & contributions. We have some more bug squashing to do, and we're already working on some make overs and improvements for new Beta releases (we are planning on releasing new Beta versions every one~two weeks, until we feel confident enough to publish our final V1 version).

Frequently asked questions so far are mostly about:

If you want to test Sign Requests, please check out http://xumm.community by NixerFFM or try it by sending a small donation to XRPL Labs.

If you want to reach out 1:1 to share screenshots / bug reports / ... please use the Chat icon on the lower right corner at https://support.xumm.app.

😘 – Thank you, stay safe!

Ali, Tristan & Wietse

With the launch of XUMM upon us, we're happy to announce we will be releasing XUMM not just for the XRP ledger but also for the CasinoCoin ledger.

While our primary focus lies on the XRP ledger and the XRPL ecosystem (both today and in the future) we appreciate both the CasinoCoin team and the choices they made (and make). Their motivation to fork instead of build on the XRP ledger source code is one I can respect: they are adding use case supporting on-ledger features to the source code. I can also really respect and appreciate their team expanding their project in a solid, bootstrapped manner. They didn’t do yet another ICO, and they managed to build and expand their projects without relying on mass token sales.

With CasinoCoin being a fork of a previous version of the XRP ledger source code, there’s still a great deal of overlap between the source code powering both ledgers. We see the XUMM app and underlying platform for signing requests can add a lot of value to not only the XRP ledger, but to the CSC ecosystem as well. For their use case, both in online and brick and mortar environments, a reliable non-custodial wallet and (payment/sign) request based platform is key to the usability of the digital ledger. We decided to reach out to the CasinoCoin team, offering them a branded fork of our XUMM project.

John Caldwell, Director of Advocacy for the Foundation, said:

We are always looking for ways to improve our product, and working with the innovative and forward-thinking XRP Labs to deliver XUMM on the CasinoCoin ledger is a hugely exciting development for us. That they have seen the potential in our project is testament to the hard work put in by both our own development team and our wider community. We look forward to working closely with XRP Labs going forward.

(We decided not to follow our own “naming convention” of + UMM for the CasinoCoin version of our app, meaning we still owe you the name we’re going to give to our app and platform for the CasinoCoin ledger 🤣)

It’s not that long ago since I got the opportunity to talk at Crypto Valley ‘19 in Zug, Switzerland. I browsed the participant list of the event, contemplating on the story to tell. Fully aware crypto would soon be regulated (NL, EU/EEA), I decided to share my thoughts on the importance, consequences and uncertainties regulation brings to developers & their endeavours, developing the “internet of value”.

With upcoming crypto regulation, working on projects like (or involving) the XRP TipBot, the xumm, Interledger (streaming payments, Coil, etc.) & XRPL decentralized exchange, turbulent times were ahead, that much was sure.

At that time, besides writing code, I was already investing a lot of time in whatever I needed to learn, take care of, etc. to take my projects to the next (regulated) level by 2020. Talked to the right people in NL, I visited Estonia a few times to start a company & apply for crypto licenses and reflected on my projects and plans from the perspective of the regulated-crypto-future. Baffled by the effort I’d had to put in, I decided to conclude my talk at Crypto Valley with my sincere desire for the existence of what I called: “Crypto Regulatory Compliance as a Service”. Allow software developers & founders in the “internet of value”-ecosystem to thrive. Allow them to invent, create and shape the future of payments and the exchange of value.

Fast forward a few months. The NL regulator, “DNB” organized a seminar for crypto businesses. Next year (like most other EU/EEA countries already require), crypto businesses in NL will have to register, being supervised and audited by the national regulator. KYC customers, transaction AML scanning, detect & report suspicious transactions to the Financial Intelligence Unit. This makes perfect sense to me, and I am sure regulation is a good thing to a growing and maturing ecosystem, making its way to more and more use cases and users. However: think about all those new & innovative use cases. Think about micropayments. Think about streaming payments, the internet of value. Now imagine all small teams of developers, crypto enthusiasts, innovators having to get contracts with KYC providers, AML data providers, defining risk profiles, scanning transactions, AML related interactions with customers… Think about the costs involved in starting even the smallest crypto project.

Let it sink in for a moment, and ask yourself what this will do to those teams of developers, innovators and small businesses reinventing payments, building the internet of value. Ask yourself what this will do to the end users and the security of their personal details: they will have to go through a cumbersome onboarding process for each and every crypto platform/app they want to use!

I visited the seminar by the NL regulator motivated by my own projects on the XRP ledger & Interledger. I realized that it’s almost impossible for me to put up with the efforts, costs and operational requirements coming my way. It wouldn’t make sense to go through all the trouble, just for my projects. This is something all crypto businesses, all apps & platforms, would have to deal with soon. I talked to a few crypto companies from other EU/EEA countries (who are a bit ahead of the crypto regulation curve compared to NL) and unsurprisingly it’s a big challenge over there as well.

After some sleepless nights I realized there may be a solution. Not just for me and my crypto adventures, but for all small crypto companies, crypto developers, crypto startups, crypto innovators, crypto apps & crypto platforms.

Maybe it’s up to me to turn that “Crypto Regulatory Compliance as a Service” idea I mentioned in my Crypto Valley presentation into an actual business?! Why not found a “Crypto Regulatory Compliance Company”: one company (“the company”) taking real good care of KYC, AML, risk profiles, customer service, security, PEP checks, sanction list checks, possible identity theft and everything else required to run a trustworthy, responsible, respectable crypto business?

Now allow crypto platforms/apps to forward their users to this platform. Once onboarded, the customer will be redirected back to the crypto platform/app with a token, granting the crypto platform/app to use our API to pre-authorize transactions, check for customer account status, customer limits, etc. AML / risk profile related questions will even be interaction between “the company” and the customer. The one account with “the company” can be used to access all connected platforms/apps, sending just a minimal amount of personal information to the platform/app.

(You are probably familiar with flows like the one I just mentioning: ever authorized an app to use “Sign in with [ Facebook / Google / Twitter / …]”? Well: it’s like that, but applied to crypto, KYC, AML, etc.)

So: I guess that’s what I’m up to. Not alone of course: I gathered a small team of great innovators and developers & consultants to realize this vision of “the company” that will unburden the internet of value in this new era of crypto regulation and compliance. We’ll allow devs, creators, innovators to build the future of payments, crypto, the internet of value and new generations of monetization. We’ll allow consumers to access connected crypto platforms/apps with their one account with our platform. And last but not least: we believe we can show the regulator that this crypto ecosystem can be more than a wild west or playing field for big boys. It can be a place where rapid innovation and regulation can go hand in hand.

Some to be expected FAQ’s

Will this be NL or EU/EEA only?

We’re aiming to start with EU/EEA wide coverage, meaning we will make sure the services of our envisioned platform is compliant in all EU/EEA countries, acquiring or registering a crypto business / license at the regulator in all EU/EEA countries.

Why do you believe you can offload the regulatory requirements from the individual platforms/apps?

Because we the end user will effectively become a customer of our envisioned platform, our platform & company will be in charge of knowing our customers, managing and monitoring risk profiles, scanning for money laundering, identifying transactions, etc. Our setup gives connected platforms/apps full control over blockchain connectivity, as long as they interact with our API, being authorized by our customer to use their platform/app as an interface. (This may sound familiar if you know about PSD2).

Will you share all that data?

No, we will definitely not be sharing your (not already public) data. Not even with the platforms/apps our users authorize. We are fully aware of the importance of keeping personal data safe. That’s why we believe consumers also benefit, sharing their personal data and identification documents one time, instead of with many different crypto platforms/apps. We will comply with laws and regulations of course, meaning we will comply with data requests by regulators and authorities, when accompanied by the appropriate and adequate documentation for such requests.

How do you intend to make money?

The primary revenue stream come from connected platforms/apps. We do intend to foster innovation, by charging no fees for our services until a platform/app reaches certain limits (# active users per month / transaction volume).

So what’s next?

My two co-founders and I will meet (soon) with a respected, experienced consultancy firm in NL to discuss our plans, vision, technical details and business processes & flows. We’ll discuss viability from a legal and regulatory perspective.

Cover photo by Vinicius Amano on Unsplash