High-Level Design

Overview

This smart contract efficiently manages a stablecoin on Aptos, featuring minting, burning, and access control with denylisting for compliance and scalability.


Token Initialization and Metadata Management

Initializes the stablecoin with essential metadata like the symbol "USDK," decimals, and related web resources. A unique address for the stablecoin is generated for easy identification.


Roles and Permissions

  • Master Minter: Adds or removes minters.
  • Minters: Authorized to mint and burn tokens.
  • Denylister: Manages denylisting for compliance, blocking transactions for specific accounts.

Token Operations

  • Minting and Burning: Controlled issuance and reduction of supply, ensuring transparency.
  • Denylisting: Adds or removes accounts from participating in transactions to ensure compliance and prevent abuse.

Management and Security

  • Management References: Utilizes references like ExtendRef, MintRef, BurnRef, and TransferRef for dynamic token management.
  • Fungible Asset Registration: Integrates with Aptos' system for custom deposit and withdrawal operations, enforcing compliance.
  • Smart Contract Events: Logs events such as Mint, Burn, and Denylist updates for external tracking and integration.

This streamlined design focuses on security, regulatory compliance, and efficient management of the stablecoin lifecycle.


Additional Features

Note that because both AIP-73 and AIP-83 are not live yet, for the purposes of this tutorial we have excluded certain features: namely a) denylisting with freezing/untransferable fungible stores and b) global pause functionality.

Ideally, denylisting should be implemented by doing the following: Preventing the ability to add FA units to a newly created secondary store (using AIP-83).

  • Even if they can create secondary store objects, they shouldn’t be able store FA units.
  • Preventing the ability to transfer existing or new fungible store objects.

And, global pause should be implemented by doing the following:

  • Storing an is_paused boolean field in the State resource.
  • Creating an assert function that verifies whether the state is paused.
  • Using the Dispatchable Token Standard function to override deposit and withdraw in order to check if state is paused before conducting these operations.