Skip to content

Commit 7bb19b0

Browse files
TapanitoTapanito
committed
adds XLS specficiation
1 parent eed3662 commit 7bb19b0

File tree

2 files changed

+145
-1
lines changed

2 files changed

+145
-1
lines changed

‎XLS-0033d-multi-purpose-tokens/README.md

+2-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
<pre>
22
Title: <b>Multi-Purpose Tokens (MPTs)</b>
33
Type: <b>draft</b>
4+
State: <b>Updated by: XLS-90</b>
45

56
Author:
67
<a href="mailto:[email protected]">David Fuelling</a>
@@ -1145,4 +1146,4 @@ With allow-listing, there needs to be a bidirectional trust between the holder a
11451146

11461147
**It is important to note that the holder always must first submit the `MPTokenAuthorize` transaction before the issuer.** This means that in the example above, steps 2 and 3 cannot be reversed where Alice submits the `MPTokenAuthorize` before Bob.
11471148

1148-
Issuer also has the ability to de-authorize a holder. In that case, if the holder still has outstanding funds, then it's the issuer's responsibility to clawback these funds.
1149+
Issuer also has the ability to de-authorize a holder. In that case, if the holder still has outstanding funds, then it's the issuer's responsibility to clawback these funds.

‎XLS-0090-multi-purpose-token-domain/README.md

+143
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,143 @@
1+
<pre>
2+
Title: <b>PermissionedDomain for Multi-Purpose Token</b>
3+
Type: <b>draft</b>
4+
State: <b>Updates: (XLS-33)[https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0033d-multi-purpose-tokens]</b>
5+
Requires: <b>(XLS-80)[https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0080-permissioned-domains]</b>
6+
7+
Authors:
8+
<a href="mailto:[email protected]">Vito Tumas</a>
9+
Affiliation: <a href="https://ripple.com">Ripple</a>
10+
</pre>
11+
12+
# Multi-Purpose Token DomainID
13+
14+
## _Abstract_
15+
16+
The issuer of a Multi-Purpose Token may require explicit authorization for individuals to hold the token. This is done through the issuer submitting an `MPTokenAuthorize` transaction, which authorizes each account individually.
17+
18+
The (XLS-80)[https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0080-permissioned-domains] specification introduces a new mechanism for broader authorization. The Permissioned Domain specifies a list of accepted `(Issuer, Type)` credential pairs within the domain. Any holder of valid credentials can interact with the protocols in this Permissioned Domain.
19+
20+
This specification adds `PermissionedDomain` support to the Multi-Purpose Token. By allowing the issuer to set a `DomainID`, we provide a more unified and efficient mechanism for controlling who may hold or receive the asset.
21+
22+
## 1. Introduction
23+
24+
## 2. Ledger Entries
25+
26+
### 2.1. `MPTokenIssuance` Ledger Entry
27+
28+
This section outlines the changes made to the `MPTokenIssuance` object. In summary, the XLS adds a new `DomainID` field to the `MPTokenIssuance` object.
29+
30+
#### 2.1.1. Fields
31+
32+
| Field Name | Change Type | Modifiable? | Required? | JSON Type | Internal Type | Default Value | Description |
33+
| ---------- | :---------: | :---------: | :-------: | :-------: | :-----------: | :-----------: | :------------------------------------------------------------------------ |
34+
| `DomainID` | `New` | `Yes` | No | `string` | `HASH256` | None | The `PermissionedDomain` object ID associated with the `MPTokenIssuance`. |
35+
36+
##### 2.1.1.1. DomainID
37+
38+
An optional identifier for the `PermissionedDomain` object linked to the `MPTokenIssuance`. If `DomainID` is specified, the account must possess credentials approved by the `PermissionedDomain` to hold the `MPT`.
39+
40+
### 2.2. `MPToken` Ledger Entry
41+
42+
This section outlines the changes made to the `MPToken` object. In summary, the XLS adds a new `Flags` value, `lsfMPTDomainCheck`.
43+
44+
#### 2.2.1. Fields
45+
46+
| Field Name | Change Type | Modifiable? | Required? | JSON Type | Internal Type | Default Value | Description |
47+
| ---------- | :---------: | :---------: | :-------: | :-------: | :-----------: | :-----------: | :------------------------------------------------------------------------------------------------------ |
48+
| `Flags` | `Update` | `Yes` | No | `number` | `UINT16` | 0 | A set of flags indicating properties or other options associated with the **`MPTokenIssuance`** object. |
49+
50+
#### 2.2.1.1. Flags
51+
52+
The `Vault` object supports the following flags:
53+
54+
| Flag Name | Change Type | Flag Value | Modifiable? | Description |
55+
| ------------------- | :---------: | :--------: | :---------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
56+
| `lsfMPTDomainCheck` | `New` | `0x0004` | `No` | If set, indicates that _individual_ holders must have credentials in the `PermissionedDomain` of the `MPTokenIssuance`. This flag is set automatically when the associated `MPTokenIssuance` object has a `DomainID` set. |
57+
58+
## 3. Transactions
59+
60+
## 3.1. `MPTokenIssuance` Transactions
61+
62+
#### 3.1.1. `MPTokenIssuaceCreate` Transaction
63+
64+
#### 3.1.1.1. Fields
65+
66+
| Field Name | Change Type | Required? | JSON Type | Internal Type | Default Value | Description |
67+
| ---------- | :---------: | :-------: | :-------: | :-----------: | :-----------: | :----------------------------------------- |
68+
| `DomainID` | `New` | `No` | `string` | `HASH256` | None | The ID of the `PermissionedDomain` object. |
69+
70+
#### 3.1.1.2. Failure Conditions
71+
72+
- The `PermissionedDomain(DomainID)` object does not exist on the ledger.
73+
74+
#### 3.1.1.3. State Changes
75+
76+
- No additional state changes are made to the ledger.
77+
78+
#### 3.1.1.4. Example
79+
80+
```js
81+
{
82+
"TransactionType": "MPTokenIssuanceCreate",
83+
"Account": "rajgkBmMxmz161r8bWYH7CQAFZP5bA9oSG",
84+
"AssetScale": "2", // <-- Divisible into 100 units / 10^2
85+
"MaximumAmount": "100000000", // <-- 100,000,000
86+
"Flags": 66, // <-- tfMPTCanLock and tfMPTCanClawback
87+
"MPTokenMetadata": "464F4F", // <-- "FOO" (HEX)
88+
"Fee": 10,
89+
"DomainID": "ASOHFiufiuewfviwuisdvubiuwb"
90+
}
91+
```
92+
93+
## 3.2. `MPToken` Transactions
94+
95+
### 3.2.1.`MPTokenAuthorize` Transaction
96+
97+
#### 3.2.1.1. Fields
98+
99+
This change does not introduce additional fields.
100+
101+
#### 3.2.1.2. Failure Conditions
102+
103+
This change does not introduce additional failure conditions.
104+
105+
#### 3.2.1.3. State Changes
106+
107+
- If the `MPTokenIssuance(MPTokenIssuanceID).DomainID` field is set:
108+
- Set the `lsftMPTDomainCheck` flag to the newly created `MPToken` object.
109+
110+
## 3.3. Other Transactions
111+
112+
### 3.3.1. `Payment` Transaction
113+
114+
The following changes are made to the payment transaction.
115+
116+
#### 3.3.1.1. Fields
117+
118+
This change does not introduce additional fields.
119+
120+
#### 3.3.1.2. Failure Conditions
121+
122+
- If `Payment.Amount` is an `MPT` and `MPTokenIssuance(Amount.MPTIssuanceID).DomainID` is set:
123+
- The `PermissionedDomain(MPTokenIssuance(Amount.MPTIssuanceID).DomainID)` object does not exist (the PermissionedDomain was deleted).
124+
- The `Payment.Account` account does not have Credentials accepted by the `PermissionedDomain` and:
125+
- The `MPToken` object of the `Payment.Account` account does not have the `lsfMPTAuthorized` flag set.
126+
- The `Payment.Destination` account does not have Credentials accepted by the `PermissionedDomain` and:
127+
- The `MPToken` object of the `Payment.Destination` account does not have the `lsfMPTAuthorized` flag set.
128+
129+
#### 3.3.1.3. State Changes
130+
131+
This change does not introduce additional state changes.
132+
133+
# Appendix
134+
135+
## A-1 F.A.Q
136+
137+
### A-1.1. Why does `MPTokenIssuance` use `PermissionedDomain`?
138+
139+
`PermissionedDomain` provides a less granular authorization mechanism to hold the `MPT`. Any account can hold the `MPT` as long as it has credentials issued by an Issuer accepted in the `PermissionedDomain`; in case the credentials expire or are revoked by the Credential Issuer, the holder can only transfer them back to the `MPT` Issuer and may not receive `MPTs`.
140+
141+
#### A-1.2. What happens when `MPTokenIssuace` uses `PermissionedDomain` and explicit authorization to hold an asset in the `MPToken` object?
142+
143+
Authorization is treated as a union. I.e. as long as the account has permission (either via `PermissionedDomain` of explicit authorization captured by the `MPToken.lsfMPTAuthorized` flag), it will be able to send and receive the `MPT`.

0 commit comments

Comments
 (0)