# Custodial

## With Backend

sequenceDiagram
autonumber

participant A as Alice
participant DF as DIDPay Webapp
participant DB as DIDPay Backend
participant I as Issuer
participant YC as YC PFI


A->>DF: Open DIDPay
DF->>DB: GET /balances
DB->>DF: Balances
DF->>DF: Render balances
DF->>DB: GET offerings
DB->>YC: Fetch offerings
YC->>DB: Offerings
DB->>DF: Offerings
DF->>DF: Render Offerings
A->>DF: Select BTC --> KES
DF->>DF: Render Amount Selection Modal
A->>DF: Type in desired amount and click next
DF->>DF: Renders Sender Details Modal
A->>DF: Type in Sender Details and click next
DF->>DF: Renders Recipient Details Modal
A->>DF: Type in Recipient Details and click next
DF->>DB: POST /transaction-details
DB->>I: POST /sanctions-cred-application
I->>DB: Sanctions VC
DB->>DB: use cred + txn details to form RFQ
DB->>YC: submit RFQ
DF->>DF: Exit Modal


loop indefinitely
  DF->>DB: GET /quote
  DB->>YC: Poll for Quote
end

DF->>DF: Renders Quote
A->>DF: Click Accept
DF->>DB: POST /accept-quote

loop indefinitely
  DF->>DB: Poll for Order Status
  DB->>YC: Poll for Order Status
end

* Resembles the custodial experience more accurately especially given that we can display a balance in DIDPay
* Sender details form is there so we don't have to build a KYC flow in DIDPay webapp. Alice wouldn't need to fill in details in the offramp flow with a real custodial wallet

## Without Backend

sequenceDiagram
autonumber

participant A as Alice
participant DF as DIDPay Webapp
participant I as Issuer
participant YC as YC PFI

A->>DF: Open DIDPay
DF->>YC: Fetch offerings using web5
YC->>DF: Offerings
DF->>DF: Render offerings
A->>DF: Selects BTC->KES Pair
DF->>DF: Render Amount Selection Modal
A->>DF: Type in desired amount and click next
DF->>DF: Render Payment Method Selection
A->>DF: Types in recipient details and hits next
DF->>DF: Resolve Issuer DID. Fetch Credential Manifest from DID
DF->>DF: Render Sanctions Credential Application
A->>DF: Fill out form and hit submit
DF->>I: Send Credential App to Issuer DID
I->>DF: Sanctions VC
DF->>DF: Store Credential in DWN
DF->>DF: Render Review Page
A->>DF: Click Submit
DF->>DF: Exit Modal
DF->>YC: Send RFQ

loop indefinitely
  DF->>YC: Poll for Quote
end

DF->>DF: Render Quote
A->>DF: Click Accept

loop indefinitely
  DF->>YC: Poll for Order Statuses
end

* There needs to be a single hardcoded DID and hardcoded keys associated with that DID
* if we intend to use web5-js then we will need to submit a PR that allows us to create and provide our own hardcoded DID because web5-js currently doesn't allow you to do that

* Given the single hardcoded DID, there's also only 1 DWN owned by DIDPay vs. user specific DWNs. All VCs get saved to DIDPay's DWN
* TODO: Add `Order` Tbdex Message
* Where do we get Alice's BTC/USDC balance from in this architecture?

# Issuance

## VC Issuance

sequenceDiagram
autonumber

participant A as App
participant I as tbdiligence
participant C as Castellum
participant S as SSIS


A->>I: POST /sanctions-cred-application
I->>C: POST /check-user
C->>I: User not on sanctions lists
I->>S: POST /create-vc
S->>I: VC
I->>A: VC

## VC Revocation