| XMPIP | Title | Author | Discussions-To | Status | Type | Created |
|---|---|---|---|---|---|---|
2 |
Monaparty Payment URI Scheme |
Cryptcoin Junkey <[email protected]> |
Accepted |
Informational |
2018-06-20 |
This XMPIP is based off of Counterparty CIP 2 by Devon Weller. This proposal extends CIP 2 to support specifying Monaparty assets.
This XMPIP proposes a URI scheme for making payments with Monparty assets and Monacoin.
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.
Counterparty CIP 2 is a widely used payment URI scheme for Bitcoin and Counterparty wallets. Monaparty should follow this same best practice and modify while extending the protocol to support specifying asset names.
Monaparty clients MUST NOT act on URIs without getting the user's authorization. They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.
Graphical Monaparty clients SHOULD register themselves as the handler for the "monaparty:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.
Monaparty URIs follow the general format for URIs as set forth in RFC 3986. The path component consists of a monacoin address, and the query component provides additional payment options.
Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986.
(See also a simpler representation of syntax)
monapartyurn = "monaparty:" monacoinaddress [ "?" monacoinparams ]
monacoinaddress = *base58
monacoinparams = monacoinparam [ "&" monacoinparams ]
monacoinparam = [ amountparam / assetparam / labelparam / messageparam / otherparam / reqparam ]
amountparam = "amount=" *digit [ "." *digit ]
assetparam = "asset=" *assetname
labelparam = "label=" *qchar
messageparam = "message=" *qchar
otherparam = qchar *qchar [ "=" *qchar ]
reqparam = "req-" qchar *qchar [ "=" *qchar ]
Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this XMPIP takes as separators.
Here, "assetname" corresponds to a valid Monaparty asset name. See Transfer asset.
The scheme component ("monaparty:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys.
monacoinaddress: A monacoin addressamountparam: amount of asset to send see belowassetparam: the type of asset to send see belowlabel: Label for that address (e.g. name of receiver)message: message that describes the transaction to the user (see examples below)(others): optional, for future extensions
If an amount is provided, it MUST be specified in decimal form and not in watanabes.
All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.
e.g. amount=50.00 or amount=50 is treated as 50. amount=50,000.00 is invalid.
Monaparty clients MAY display the amount in any format that is not intended to deceive the user. They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. For example, so long as the majority of users work in MONA units, values should always be displayed in MONA by default, even if mMONA would otherwise be a more logical interpretation of the amount.
Valid Monaparty asset names are strings of 4 to 12 uppercase Latin characters (inclusive) not beginning with 'A', or integers between 26^12 + 1 and 256^8 (inclusive), prefixed with 'A'. MONA and XMP are also valid Counterparty assets.
If the URI does not specify an asset, the Counterparty client SHOULD prompt the user to specify the asset they wish to send.
Variables which are prefixed with a req- are considered required. If a client does not implement any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables which are not implemented, but which are not prefixed with a req-, can be safely ignored.
This section is non-normative and does not cover all possible syntax. Please see the BNF grammar above for the normative syntax.
[foo] means optional, <bar> are placeholders
monaparty:<address>[?amount=<amount>&asset=<asset>&label=<label>&message=<message>]
Just the address:
monaparty:MUqM2tDnZXtJ4h87W2g8fFz9nW3GsYhMfu
Address with name:
monaparty:MUqM2tDnZXtJ4h87W2g8fFz9nW3GsYhMfu?label=Junkey
Request payment of 1.3 MONA to "Junkey":
monaparty:MUqM2tDnZXtJ4h87W2g8fFz9nW3GsYhMfu?amount=1.3&asset=MONA&label=Junkey
Request payment of 20 SOUP to "Junkey":
monaparty:MUqM2tDnZXtJ4h87W2g8fFz9nW3GsYhMfu?amount=20&asset=SOUP&label=Junkey
Request 5 XMP with a message:
monaparty:MUqM2tDnZXtJ4h87W2g8fFz9nW3GsYhMfu?amount=5&asset=XMP&label=Junkey&message=Donation+for+all+your+hard+work
Some future version that has variables which are (currently) not understood and required and thus invalid:
monaparty:MUqM2tDnZXtJ4h87W2g8fFz9nW3GsYhMfu?req-somethingyoudontunderstand=50&req-somethingelseyoudontget=999
Some future version that has variables which are (currently) not understood but not required and thus valid:
monaparty:MUqM2tDnZXtJ4h87W2g8fFz9nW3GsYhMfu?somethingyoudontunderstand=50&somethingelseyoudontget=999
Characters must be URI encoded properly.
This document is placed in the public domain.
Counterparty CIP 2 by Devon Weller