tbDEX Messages

[mistermoe]

General Requirements

• The reputability of a PFI is checked out of band
• The root message must be an ASK

Transition Diagram

Each Vertex is a message and each edge represents who can transition to a given vertex

Note: Assume that any vertex can transition to a CLOSE by either participant

flowchart TD
    ASK --> |PFI| COND_OFFER[Conditional Offer]
    COND_OFFER --> |Alice| CLAIM_SUB[Claims Submission]
    CLAIM_REQ --> |Alice| CLAIM_SUB
    CLAIM_SUB --> |PFI| CLAIM_REQ[Claims Request]
    CLAIM_SUB --> |PFI| SETTL_REQ[Settlement Request]
    SETTL_REQ --> |Alice| SETTL_DETAIL[Settlement Details]
    SETTL_DETAIL --> |PFI| CLAIM_REQ
    SETTL_DETAIL --> |PFI| SETTL_REQ
    SETTL_DETAIL --> |PFI| SETTL_RECEIPT[Settlement Receipt]

Loading

Message Types

Ask

Description:

field	data type	required	description
have.currency	string	Y	The currency that you currently hold
have.amount	int	Y	The amount that you currently hold. Amount must be in the smallest denomination of said currency
want.currency	int	Y	the currency that you want
want.amount	int	N	the minimum amount you're looking for

ConditionalOffer

Description:

field	data type	required	description

ClaimsSubmission

Description:

field	data type	required	description

ClaimsRequest

Description:

field	data type	required	description

SettlementRequest

Description:

field	data type	required	description

SettlementDetails

Description:

field	data type	required	description

SettlementReceipt

Description:

field	data type	required	description

CloseThread

Description:

field	data type	required	description
reason	string	N	Reason for closing

[hellendou]

Things to add:

Credential Exchange for PFI
Clarity on "amend"
State machine for payments (adding instrument, capturing, paying out, risk, chargebacks, failure cases, ect.)

[hellendou]

also, instead of have and want it's usually source and destination

[hellendou]

A shallow look at how I'm imagining the state machine from the perspective of the PFI

[mistermoe]

As mermaid md

    graph TD
    A[Receive Ask] --> B{Conditional Offer}
    B -->|Denied| C[Close Offer]
    B -->|Accepted| D[Request IDV]
    D --> |Send Credentials| E{Evaluate IDV Risk}
    E --> |Soft Fail| D
    E --> |Hard Fail| C
    E --> |Passed| G[Request Payment Info]
    G --> |Send Payment Info| H{Evaluate Payment Risk}
    H --> |Hard Fail| C
    H --> |Soft Fail| D
    H --> |Passed| I{Capture Funds}
    I --> |Failed| G
    I --> |Passed| J[Release Funds]

Loading

[decentralgabe]

This diagram is a little unclear too. An offer being accepted doesn't intuitively result in "request IDV". Perhaps...

Conditional Offer -> Offer Negotiation -> (IDV -> Eval -> Validate -> other info -> eval -> validate) -> Offer Accept

[decentralgabe]

@mistermoe replying to your first image

Sequentially, here are my thoughts:

A conditional offer means it's conditional on...something. I'm guessing that something is up to the offerer. The following "Claims Submission" seems to be a response to that something. Why not call it a Conditional Offer Request? Or, have a way to show that a "Conditional Offer" has multiple components, one of which is a "Claims Request", I imagine another component would be "Offer Details". I do see "Claims Request" after "Claims Submission" in the first diagram which is confusing.

The loop of "Settlement" can also benefit from some terminology clarity. Going between request and details...ok, but this seems to be a "Settlement Negotiation" process. Perhaps "Settlement Request" is followed by "Settlement Submission" or "Settlement Response" which can be followed up with additional "Settlement Requests" or a "Settlement Result" (yes or no), which I believe is a "Settlement Receipt".

Maybe we should step back and describe the functional states before diagraming. I see a "Settlement Process" which contains a few different components: bids, asks, negotiation, verification, and results. What are the possibilities for each? (and let's get better terminology)

[mistermoe]

@decentralgabe fully agreed on many of your points. The initial diagram is a pretty outdated now. @hdou731 and I worked through a handful of changes which I'm in the process of documenting right now. I also built out a project to help us iterate on these ideas in code. We arrived at many of the same thoughts you did albeit for different reasons. Once I have those changes up I'll revisit your reply and flag all of your suggestions and you can take a look.

I should've been clear about the initial diagram being a first stab brain dump that was far too in flux to merit evaluating yet. I will say though that starting with diagrams helps me think through the problem