XLS-81d: Permissioned DEX #256
Conversation
| |`TakerGets`|✔️|`object`|`Amount`|The remaining amount and type of currency being provided by the offer creator.| | ||
| </details> | ||
|
|
||
| This spec proposes deprecating the `BookDirectory` and `BookNode` fields and adding the following: |
There was a problem hiding this comment.
not sure how is this possible? what about the existing offers?
There was a problem hiding this comment.
It would only apply to new offers, and old offers could be lazily updated.
| |`BookDirectories`|✔️|`string`|`Vector256`|The IDs of the offer directories that link to this offer.| | ||
| |`BookNodes`|✔️|`string`|`STArray`|Hints indicating which pages of the offer directory links to this entry, in case the directories consist of multiple pages.| |
There was a problem hiding this comment.
what are the use cases of this? when is an offer included in multiple directories?
There was a problem hiding this comment.
it's going to a lot of dirty work to deprecate BookDirectory, not sure if the effort is worth it if there's not strong reasoning for this
| * The 160-bit currency code from the `TakerGetsCurrency` | ||
| * The AccountID from the `TakerPaysIssuer` | ||
| * The AccountID from the `TakerGetsIssuer` | ||
| * **The `DomainID` of the orderbook, if applicable** |
There was a problem hiding this comment.
just want to confirm, the use i can think of this is to allow iteration of offers for particular domainID, which is going to be used by cross currency payment and liquidity calculation in pathfinding
There was a problem hiding this comment.
Yes. The book directories need to exist, and have distinct hashes from the unpermissioned directories, so what makes the most sense in differentiating those is the DomainID.
|
|
||
| | Field Name | Required? | JSON Type | Description | | ||
| |------------|-----------|-----------|-------------| | ||
| |`domain`| |`string`|The object ID of a `PermissionedDomain` object. If this field is included, then the paths will be filtered to only show the valid paths for that domain.| |
There was a problem hiding this comment.
this would potentially introduce fundamental changes to the OrderBookDB that fetches currency pair using hash map. At this point i'm not sure of the feasibility and effort to add a "third" param to the OrderBookDB. But I think Pathfinding would be more efficient if this can be implemented.
However another option(also to be confirmed if this is viable) is to leave OrderBookDB as it is, and then filter out paths during liquidity calculation using DomainID. This is less efficient because we will be calculating liquidity for paths that don't have a domainID.
|
|
||
| ### A.1: How are AMMs handled? | ||
|
|
||
| AMMs are not explicitly supported within permissioned DEXes in this proposal. They could be added to permissioned DEXes in a future proposal. |
There was a problem hiding this comment.
does it mean that Payment transactions that specified DomainID cannot consume AMM pools?
There was a problem hiding this comment.
Correct. That's intentional.
|
|
||
| | Field Name | Required? | JSON Type | Internal Type | Description | | ||
| |------------|-----------|-----------|---------------|-------------| | ||
| |`DomainID`| |`string`|`Hash256`|The domain that the offer must be a part of.| |
There was a problem hiding this comment.
what kind of validations do we need to allow someone create an offer with a domainID? can everyone create it?
There was a problem hiding this comment.
Only domain members can create it.
| There will also be the following in addition, if the `DomainID` is included: | ||
| * The payment isn't a cross-currency payment. | ||
| * The domain doesn't exist. | ||
| * The `Account` is not a domain member. |
There was a problem hiding this comment.
how do we check if an account is a domain member?
There was a problem hiding this comment.
does it work like:
- look up the PermissionedDomain object
- iterate through the AcceptedCredentials array
- check if the
Subjectof the Credential object matches the account submitting thePaymenttx?
There was a problem hiding this comment.
- Look up the
PermissionedDomainobject - Iterate through the
AcceptedCredentialsarray (which only contains issuer-credential type pairs) - Check if the (subject, issuer, credential type) credential exists (where the
Subjectis the account submitting thePaymenttx)
Discussion thread can be found here: #229