Paymium releases a remittance protocol RFC

Download the RFC document.

After witnessing the Coinbase and BoA derps trying to patent “increased molecular agitation of dihydrogen monoxyde”[1], Paymium has decided to release its remittance protocol RFC to the public.

The process described by this protocol is in no way rocket science, but will still greatly benefit from being properly timestamped, and documented. Never hurts interoperability to speak the same language. This document is a work in progress, feedback is very welcome.

The implementation of remittances settled with Bitcoin obviously require liquidity sources on both ends of the remittance tunnel, this specification is to be implemented by exchanges or brokers that can efficiently transfer money in their local zone.

It leverages these local liquidity sources in order to provide streamlined money transmission features to end-users, without relying on the Bitcoin network to support the load of individual transfers[2], but only for settlement operations.

In essence, the remittance protocol is simply a way for an exchange to quote another exchange for a requested amount in fiat.

If, for example, Rhonda in the U.S. wants to send 2,000 € to Jean-Robert, in France, Rhonda’s exchange will end up presenting her with a “Please confirm you’d like to send 2,000 € to Jean-Robert at Paymium. This will cost you $2,250.67” message.

The settlement part isn’t covered by the document, for the pretty simple reason that settlement is a business matter, not a technical challenge. It would also vastly complicate everything. Maintaining a balance, manually settling daily, automating Bitcoin transfers when a threshold is reached are all valid approaches to settling these remittances.

May the capital flow!

[1] Commonly referred to as “hot water”.

[2] Read: “without relying on the big-blocks insanity”.

7 thoughts on “Paymium releases a remittance protocol RFC

  1. jurov

    Why explicitly mention HTTP(S)? With MPEx-style GPG communication, oauth is not needed and any suitable network protocol can be used.

    /info : How often should this be called? I presume available services will be specified in the initial agreement between the parties anyway and this call would only serve as check if there isn’t any problem?

    /transfer: The reply should be easily and without doubts matchable to the request, say, by having same UUID or by repeating supplied information. Also (applies universally), when making protocol human-readable, best go in full way and use ISO date format.

    /cancel: Same thing with UUID

    /history: Reply isn’t valid JSON

    /balances: RFC Should explicitly specify it’s in satoshi.

  2. Sergej Kotliar

    Great idea!

    Some bugs/feedback:

    * / should also show which countries it can send out money to. EUR and USD are currencies in many places, and a remittance partner should be able to handle the country in question.
    * / should probably also indicate withdrawal method

    * /transfer should handle specifying amounts in either/or the sending currency or in the recieving currency. I.e. “I want to send 10 EUR” or “I want them to receive 10 USD”.

    * Some services have limitations on amounts, or can only handle withdrawals in fixed denominations. So it would be useful if one of the requests responded with
    { currency: USD
    min: 10
    max: 1000
    step: 10
    (i.e. steps of 10 between 10 and 1000). Or even denominations: [10, 20, 50, 100, 500]

    Best of luck with this, will be following closely.

  3. Downhill Ventures

    The immediate comment, without even trying to grok the subject matter, is that this is a poor to bad specification on almost every level. Entirely too much hand-waving, “oh yeah we use that, wasn’t that obivous?”, implicit assumptions and almost no mention of possible failure modes, nevermind dealing with them.

    Then there’s the design approach issues: Specific technologies thrown in for convenience without justification, that nonetheless create long-term dependencies. Bluntly said, this is doing what every “webapp” monkey does too, with about as much comprehension of the reasons why. So you’re in good company, in fact you’re doing better than the rest because you wrote *something* down. But it doesn’t make the product any better.

    Then there’s lots more issues on the (undefended and often hard to defend in the first place) technology choices. But there isn’t really much point detailing them at this stage, since:

    There are lots of implicit dependencies but no explicit ones, so obviously there is no need for a references section, so references to earlier work, nevermind discussions and explanations why this approach is better is not to be found either.

    Uncharitably summing up, this is a good example of how “the bitcoin community” appears to busy itself with merrily reinventing the wheel in interesting new shapes and appearing to be in competition to see who can pay the largest price for the most angularly-enhanced wheel.

    1. David FRANCOIS Post author

      There seems to be a slight misunderstanding about what this is, and what it is not.

      This isn’t a piece of academic research on the general theory of bestest, biggest, fastest, and most generalizable remittances protocol that also feature generic XML dictionary types.

      This is a simple draft laying out how grown-up businesses could exchange structured data in order to conduct business. Specific technologies are thrown in for convenience, that’s a feature. That you don’t feel they’re not suitably justified, is a problem that resides in your own head and that may or may not, depending on your degree of brainrot, be fixed by actually “grokking the subject matter”.

      1. Downhill Ventures

        Nope. Go read a few IETF RFCs. The good ones all build upon previous work, list that work, discuss why they’re doing things, explain how they’re doing things, and so on, and so forth. This attempt at something vaguely similar by a “grown-up business” that apparently hasn’t ever seriously tried interfacing with anything else but their own latest-buzzwords-only “web platform” is indeed something many businesses try, then fail for reasons that should be, but clearly are not obvious to you, and thus another project becomes a sad statistic on the “outright failed” half of all ICT projects.

        But, since you do happen to believe you’re a “grown-up business” and this entitles you to avoid nastiness and failure by simply declaring it limited to someone else’s head, go right ahead, conquer the world with “RFCs” where comments are unwanted if they note the specifications have about the level of specificty somewhere below that of a W3C missive. For we all know the W3C are masters of concise specification and they succeeded wonderfully, since writing browsers to their specifications is clearly easy, especially the “parsing the DOM” part. You’ve done something vaguely in the same ballpark, so obviously, huge success awaits you!

        1. David FRANCOIS Post author

          Again, this is not supposed to be anything like an IETF RFC, this is an RFC in the sense that it is an actual request for comments.

          It’s pretty common for the intellectually challenged , instead of actually engaging what’s at hand, to try and relate it to stuff they’re used to. The idea that this approach is in any way relevant or interesting is dubious at best.

          Save the word salad for reddit, SA or whatever, who cares.


Leave a Reply to jurov Cancel reply

Your email address will not be published. Required fields are marked *