Skip to main content

​
Overview

ArtStar operates in an art RWA context, so users cannot enter every asset flow without first meeting the required access conditions. KYC is a core part of the platform’s admission framework, bridging off-chain identity requirements with on-chain interaction permissions. From a product perspective, KYC is not just a standalone form. It is a governing status track that determines whether a user can proceed with purchases, qualify for specific opportunities, or access certain platform flows.

​
Core Objectives of KYC

ArtStar implements KYC to achieve the following objectives: * Satisfy compliance requirements for art RWA offerings * Provide a reliable basis for whitelist and access-control rules * Prevent ineligible users from entering the purchase flow * Consistently map off-chain review outcomes to on-chain prerequisites
KYC directly determines whether a user can move forward in the subscription flow. In most cases, only users with an approved KYC status can: * Unlock the purchase entry point * Proceed to the Mint flow * Satisfy specific whitelist validation requirements If the status is unverified, pending, or rejected, the frontend should present a clear explanation of the current state and guide the user toward the next step.

​
KYC Status and Workflow

KYC Status Definition

These statuses are not merely display labels. They are gatekeeping signals that directly affect product behavior: * unverified: Not yet verified * pending: Under review * approved: Approved * rejected: Rejected
A typical asynchronous state-transition flow looks like this:
1

Start Verification

The user initiates the KYC flow from the frontend.
2

Platform Initialization

The platform starts the third-party KYC verification process.
3

Document Submission

The user submits identity documents and any required supporting information.
4

Third-Party Review

The third-party provider reviews and validates the submitted materials.
5

Status Synchronization

The review outcome is synced back to the platform backend through a webhook or polling mechanism.
6

Status Update

The backend updates the user’s KYC status in the database.
7

UI Response

The frontend refreshes the user’s available actions, such as enabling the purchase button, based on the latest status.

​
Common Questions and Frontend Display

Usually not. A pending status should not be treated as purchase-eligible unless the business rules explicitly allow it.
No. KYC status should be sourced from the database and backend query results, not from frontend-only in-memory state.
This usually depends on the status synchronization strategy and can be affected by webhook delays, polling intervals, or frontend refresh timing.

​
Pitfall Guide

If the user refreshes the page, switches devices, or signs in again, locally stored state can be lost. The source of truth must remain on the backend.
These states represent different product meanings. One indicates the process has not started, while the other means the submission is complete and awaiting a result. Copy and interaction logic must distinguish between them.
When the KYC status changes, the Mint button, eligibility prompts, page copy, and guided actions should all update together to avoid mismatches between displayed status and actual permissions.