Flusso di lavoro applicazione Stablecoin

Una stablecoin è un token fungibile che rappresenta la valuta digitale con un'applicazione integrata della conformità.

Lo scenario stablecoin impone di conoscere le policy dei clienti (KYC) e antiriciclaggio (AML), le restrizioni di trasferimento e le approvazioni multi-parte. Il sistema supporta trasferimenti diretti e trasferimenti basati su blocchi, che richiedono l'approvazione prima che si verifichi il trasferimento.

• Minter, burner e ruoli notarili sono necessari.
• La politica del conto applica i flag KYC/AML e di restrizione.
• Il criterio di approvazione definisce le soglie e i requisiti degli approvatori sequenziali per i trasferimenti basati su blocco.
• Le restrizioni di trasferimento sono facoltative e possono essere configurate in qualsiasi momento.
• La corrispondenza dei criteri di approvazione viene utilizzata per determinare se le approvazioni sono necessarie quando si utilizza l'API holdTokens.
• Le API di cronologia delle transazioni supportano l'audit e il monitoraggio.

Nella tabella seguente vengono riepilogati gli attori in questo scenario.

Attore	Ruolo	Descrizione
Administrator	Amministrazione token	Inizializza il sistema, assegna ruoli, crea criteri di account e approvazione.
Minter	Minter	Richiede il conio dei token.
Approvatore zecca	Notaio	Approva o rifiuta le richieste di mint.
Approvatore usura	Notaio	Approva o rifiuta le richieste di burn.
Mittente	nessuno	Avvia trasferimenti diretti o basati su sospensione.
Approvatore	nessuno	Approva le transazioni in una sequenza definita. Gli approvatori sono titolari di conti regolari specificati come approvatori nel criterio di approvazione (non in base a un ruolo assegnato).
Notaio	Notaio	Completa o rilascia i trasferimenti basati su blocco dopo l'approvazione.
Destinatario	nessuno	Riceve i token trasferiti.
Auditor	Auditor token	Esegue query sulla cronologia delle transazioni a scopo di conformità e generazione report.

L'amministratore completa i passaggi seguenti per inizializzare il sistema.

1. Inizializzare una stablecoin utilizzando l'API initializeStablecoinToken.
2. Registrare le organizzazioni utilizzando l'API registerOrg.
3. Creare account utilizzando le API createAccount e associateTokenToAccount.
4. Assegnare i ruoli di minter, burner e notaio agli account appropriati utilizzando l'API addRole.
5. Creare criteri account utilizzando l'API createStablecoinAccountPolicyCheck.
6. Creare criteri di approvazione utilizzando l'API createApprovalPolicyCheck.

Dopo l'inizializzazione del sistema, un tipico flusso di processo segue questi passaggi di base.

1. Stablecoin di zecca.
   1. Il minter utilizza l'API requestMint per inviare una richiesta a mint stablecoin.
   2. L'approvatore della zecca utilizza l'API approveMint per rivedere e approvare la richiesta di creazione di stablecoin. In alternativa, l'approvatore della zecca può utilizzare l'API rejectMint per negare la richiesta.
2. Trasferisci stablecoin senza approvazioni.
   • Il mittente utilizza l'API transferTokens per inviare stablecoin a un utente.
3. Trasferisci stablecoin con approvazioni.
   1. Il mittente utilizza l'API holdTokens per richiedere il trasferimento dei token.
   2. Se necessario, gli approvatori utilizzano l'API approveTransaction per approvare il trasferimento, come specificato dal criterio di approvazione.
   3. Il notaio utilizza l'API executeHoldTokens per approvare la richiesta di trasferimento. In alternativa, il notaio può utilizzare l'API releaseHold per rifiutare il trasferimento.
4. Verificare il saldo del token.
   • Gli utenti possono utilizzare l'API getAccountBalance per ottenere la quantità di stablecoin in loro possesso.
5. Brucia i token.
   1. Gli utenti possono utilizzare l'API requestBurn per inviare una richiesta di masterizzazione delle stablecoin.
   2. L'approvatore usura utilizza l'API approveBurn per rivedere e approvare la richiesta. In alternativa, l'approvatore burn può utilizzare l'API rejectBurn per negare la richiesta.
6. Eseguire l'audit della cronologia delle transazioni.
   • Gli auditor e gli utenti possono utilizzare le API getAccountTransactionHistory e getAccountTransactionHistoryWithFilters per ottenere la cronologia delle transazioni per l'audit e la generazione di report.

Convalida criteri account

I criteri dell'account sono obbligatori per tutti i conti che trasferiscono o detengono stablecoin. I criteri degli account vengono convalidati nelle seguenti API: transferTokens, holdTokens, approveTransaction, executeHoldTokens.

Ogni criterio account include tre parametri: KYC, AML e restrictionFlag. Questi vengono convalidati sia per il mittente che per il destinatario prima che vengano trasferiti i token.

KYC (Conosci il tuo cliente)

Il trasferimento è consentito solo se i valori KYC sono true per i conti mittente e destinatario.

AML (antiriciclaggio)

Il trasferimento è consentito solo se i valori AML sono true sia per i conti mittente che per quelli ricevente.

restrictionFlag

Se il flag di restrizione è impostato su false sia per il conto del mittente che per il conto del destinatario, la convalida passa. Se il flag di restrizione è impostato su true per il conto del mittente o del destinatario, per le API holdTokens, approveTransaction e executeHoldTokens, il trasferimento è consentito solo se esiste un criterio di approvazione disponibile più basso e se l'importo rientra nei limiti dei criteri. In caso contrario, il trasferimento viene bloccato. Per il metodo transferTokens, il trasferimento è consentito solo se l'importo si trova nei limiti inferiore e superiore dei limiti di restrizione del trasferimento.

Corrispondenza criteri di approvazione

La corrispondenza dei criteri di approvazione viene attivata dopo una chiamata all'API holdTokens. I criteri di approvazione definiscono le soglie delle transazioni, i numeri obbligatori di approvazioni e i dettagli degli approvatori e impostano la sequenza per le approvazioni a più livelli. Un criterio di approvazione è obbligatorio per un'operazione di blocco. Senza un criterio di approvazione, gli utenti non possono bloccare o trasferire i token quando vengono applicate restrizioni.

La corrispondenza dei criteri di approvazione determina se le approvazioni sono necessarie prima che il notaio possa completare il trasferimento dei blocchi. Se le approvazioni sono necessarie, la corrispondenza dei criteri di approvazione determina quali approvatori sono necessari e in quale sequenza.

Se non è impostato alcun flag di restrizione sia per il mittente che per il destinatario, l'importo del blocco viene confrontato con tutte le soglie dei criteri di approvazione configurati per trovare una corrispondenza. Se viene trovata una corrispondenza, vengono utilizzati gli approvatori e la sequenza corrispondenti. Se non viene trovata alcuna corrispondenza, non è richiesta alcuna approvazione e la transazione passa direttamente al notaio.

Se è impostato un flag di restrizione per il mittente o il destinatario, viene utilizzato il criterio di approvazione più basso disponibile. Se non sono disponibili criteri, la transazione viene bloccata.

Dopo aver determinato una corrispondenza dei criteri, vengono estratti i dettagli riportati di seguito dal criterio da utilizzare nel processo di approvazione.

• Approvatori obbligatori
• Sequenza di approvazione
• Numero di approvazioni richiesto

Approvazione transazione

La convalida dell'approvazione della transazione viene attivata dopo una chiamata all'API approveTransaction. La convalida applica tutte le regole di approvazione definite nel criterio di approvazione corrispondente durante la chiamata all'API holdTokens. La convalida viene eseguita per ogni approvatore in sequenza in base ai passi riportati di seguito.

1. Convalida identità approvatore: verifica se l'utente corrente esiste nell'elenco di approvatori richiesti dal criterio di approvazione.
2. Convalida ordine sequenza: verifica se l'approvatore corrente è l'approvatore previsto nella posizione della sequenza corrente.
3. Controllo approvazione duplicati: impedisce allo stesso approvatore di approvare più volte la stessa transazione.
4. Convalida criteri account: esegue di nuovo la convalida dei criteri account per assicurarsi che gli stati degli account mittente e destinatario non siano stati modificati dopo la creazione del blocco.
5. Approvazione record: registra l'approvazione con indicatore orario, aumenta il conteggio delle approvazioni e controlla se tutte le approvazioni richieste sono state completate.

Se vengono registrate tutte le approvazioni, la transazione viene contrassegnata come pronta per il completamento dal notaio. Se sono necessarie ulteriori approvazioni, è atteso il successivo approvatore in sequenza.