[ANCHOR-719] Update SEP31 to replace SEP12 with async kyc flow #1502

JiahuiWho · 2024-07-12T17:44:20Z

What's Changed:

SEP-6, 8, 30
Nits and prettify

SEP-12
Nits

SEP-31

KYC completion is no longer required before creating a SEP-31 transaction. Sending anchor can optionally pre-register customers and use the obtained sender_id or receiver_id to create transaction, or leave these fields empty.
After the transaction is created, the Sending anchor will call GET /customer?transaction_id=<sep31-txn-id>&type= to determine the required fields for each type of client, and then make a PUT call to the same endpoint to update the information

philipliu

This change makes a lot of sense and brings SEP-31 closer to the new KYC standard set by SEP-6, although the current approach would break existing clients. I left a recommendation for how we can avoid this.

ecosystem/sep-0012.md

ecosystem/sep-0031.md

philipliu · 2024-07-16T18:22:17Z

ecosystem/sep-0031.md

-          }
-        }
-      }
+      "max_amount": 1000


I think it's possible to use the new KYC flow and keep the sep12 block right? The new flow works if the SEP-12 request is type=sep31-large-sender and transaction_id=.... The special types sep31-sender and sep31-receiver can be hardcoded values we use in the Anchor Platform but we don't need to restrict them at the protocol level. Otherwise, this would be a breaking change for SEP-31 clients.

It's possible, but I don't think it's necessary because the sending anchor no longer needs to classify customers.

In the new flow, sending anchors can pre-register the sender and receiver with some basic information. Then, it’s up to the receiving anchor to determine what additional information is needed (such as whether the customer is foreign or a large sender) based on the transaction details and return the required fields to the sending anchor. This way, the receiving anchor can manage its own classified KYC customer decision-making process.

What are your thoughts?

Additionally, since SEP-31 is not currently being adopted by any clients, it's a good opportunity to make these improvements.

I don't mind getting rid of custom-define types entirely, but we would need to deprecate it, rather than straight removing

I'm also worry about some gaps in this flow with customized customer type.

If the sending anchor create a SEP-31 transaction without pre-register the customers, and is doing kyc now, how would they know what customer type they should use in the GET /cutomer?transaction_id=<>&type=<> call?

It's up for the anchor to decide, generally. Client is only supposed to either use sep-6 or sep-31 when interacting with business that uses AP

ecosystem/sep-0031.md

Ifropc · 2024-07-17T20:04:48Z

ecosystem/sep-0006.md

@@ -86,11 +86,11 @@ sequenceDiagram
    Anchor-->>-Wallet: transaction id

    note right of Wallet: If User has already <br> been accepted, <br> KYC is unnecessary.
-    Wallet->>+Anchor: GET [SEP-12]/customer?transaction_id=<id>&type=


Type should still be passed. Theoretically anchor can use numerical ids for transactions (by type), therefore it'd need to distinguish between sep-6 transaction id N and SEP-31.
In addition, it makes implementation on AP more straightforward (otherwise we need to query both tables to find transaction with this ID)

Sure I can add it back. Just curious, what should the customer type be for SEP-6? Currently, there is no configuration to define a SEP-6 customer type

Should just pass types as sep-6 and sep-31. We can make recommendation in the standard to follow this rule, but that's generally how AP should be implemented to use the correct table

ecosystem/sep-0012.md

Ifropc · 2024-07-17T20:08:31Z

ecosystem/sep-0031.md

-   the Sending Client to make the payment to the Receiving Anchor.
-1. The Sending Anchor makes [SEP-12 PUT /customer](sep-0012.md#customer-put) requests containing the collected
-   information for each client.
+1. Optionally the Sending Anchor can pre-register clients using [SEP-12 PUT /customer](sep-0012.md#customer-put) and


I think it'd be nice to have a bit more detailed description of how it works (basically explaining flow chart above)

Ifropc · 2024-07-17T20:09:53Z

ecosystem/sep-0031.md

-          }
-        }
-      }
+      "max_amount": 1000


I don't mind getting rid of custom-define types entirely, but we would need to deprecate it, rather than straight removing

philipliu

The changes look good. We should also update the SEP-31 version and changelog.

Ifropc

LGTM.
Could you update versions, run formatting (./bin/prettier.sh) and write a comment that for integrations using Anchor Platform type should be sep6 and sep31? This would be a guideline for wallets who sometimes look at this spec.

JiahuiWho · 2024-07-23T20:58:17Z

LGTM. Could you update versions, run formatting (./bin/prettier.sh) and write a comment that for integrations using Anchor Platform type should be sep6 and sep31? This would be a guideline for wallets who sometimes look at this spec.

How to distinguish sender from receiver if we are just using sep31? Or is this something up for anchor to decide?
The prettier does't give me anything on local, not sure what is going wrong...

Ifropc · 2024-07-23T21:03:40Z

The anchor that receives KYC should know if it's receiving or sending anchor based on transaction id I think

* [ANCHOR-719] Update SEP31 to replace SEP12 with async kyc flow (#1502) * update sep31 to leverage sep12 with txn_id * more prettify * address comments * more comments * fix sep31 diagram (#1513) * address comments * address comments * prettier

JiahuiWho added 2 commits July 12, 2024 13:10

update sep31 to leverage sep12 with txn_id

925576d

more prettify

8240b9a

philipliu reviewed Jul 16, 2024

View reviewed changes

Ifropc self-requested a review July 16, 2024 20:32

Ifropc requested changes Jul 17, 2024

View reviewed changes

address comments

6fefa91

JiahuiWho requested review from philipliu and Ifropc July 23, 2024 15:03

philipliu reviewed Jul 23, 2024

View reviewed changes

Ifropc reviewed Jul 23, 2024

View reviewed changes

more comments

08fffb5

philipliu approved these changes Jul 24, 2024

View reviewed changes

JiahuiWho merged commit 33447eb into ap-v3 Jul 24, 2024
2 of 3 checks passed

JiahuiWho deleted the anchor-719-update-sep31 branch July 24, 2024 15:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ANCHOR-719] Update SEP31 to replace SEP12 with async kyc flow #1502

[ANCHOR-719] Update SEP31 to replace SEP12 with async kyc flow #1502

JiahuiWho commented Jul 12, 2024 •

edited

Loading

philipliu left a comment

philipliu Jul 16, 2024

JiahuiWho Jul 16, 2024

Ifropc Jul 17, 2024

JiahuiWho Jul 22, 2024

Ifropc Jul 22, 2024

Ifropc Jul 17, 2024

JiahuiWho Jul 22, 2024

Ifropc Jul 22, 2024

Ifropc Jul 17, 2024

Ifropc Jul 17, 2024

philipliu left a comment

Ifropc left a comment

JiahuiWho commented Jul 23, 2024 •

edited

Loading

Ifropc commented Jul 23, 2024

[ANCHOR-719] Update SEP31 to replace SEP12 with async kyc flow #1502

[ANCHOR-719] Update SEP31 to replace SEP12 with async kyc flow #1502

Conversation

JiahuiWho commented Jul 12, 2024 • edited Loading

What's Changed:

philipliu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

philipliu left a comment

Choose a reason for hiding this comment

Ifropc left a comment

Choose a reason for hiding this comment

JiahuiWho commented Jul 23, 2024 • edited Loading

Ifropc commented Jul 23, 2024

JiahuiWho commented Jul 12, 2024 •

edited

Loading

JiahuiWho commented Jul 23, 2024 •

edited

Loading