> For the complete documentation index, see [llms.txt](https://docs.suno.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.suno.finance/legal/eligibility-and-onboarding.md). # Eligibility and onboarding Participation requirements, identity verification, and the separate effects of admission status, blocklists, and pauses. Suno separates access to its primary desk from ordinary token transfers. The configured desk checks admission; ordinary uWatt transfers do not consult that registry, allowing participation through secondary markets without prior desk approval, subject to pauses and blocklists. Participation is governed by the Terms and Conditions and the applicable offering document. Verification, sanctions screening, jurisdiction restrictions, and continuing compliance apply as set out below. ## Who may participate The Terms and Conditions require participants to have legal age and capacity, complete verification to Suno's satisfaction, use lawfully obtained funds, and comply with applicable law. Participants must not be subject to sanctions or fall within a Restricted Jurisdiction. They must keep those representations current. The named Restricted Jurisdictions include the United States, Canada, the People's Republic of China, Australia, Iran, and North Korea, together with jurisdictions under the specified comprehensive sanctions. Suno also applies a broader operational screening list. [Current designations](/legal/current-designations.md) records the published lists; screening and eligibility decisions must use the applicable current requirements. The restrictions concern acquisition, holding, and transfer, not only access through Suno's interface. Secondary-market availability does not waive them. ## Verification and continuing obligations Individuals may be asked for identity documents, legal name, birth information, nationality, residential address, proof of address, contact information, and a biometric verification check. Entities may need incorporation documents, representative and beneficial-owner identities, proof of authority, and wallet addresses. Higher-risk cases can require additional evidence. The designated verification provider supports the checks. Suno decides whether onboarding is complete and can refuse or revoke approval where information is insufficient, circumstances change, or continued participation creates the risks specified in the terms. Approval is not permanent. Users must report relevant changes, including address, beneficial ownership, and sanctions status. The [Privacy Policy](/legal/privacy-policy.md) explains the processing and retention of onboarding data. ## On-chain access controls | Mechanism | Effect | | ----------------------- | --------------------------------------------------------------------------------------------------------------------- | | Desk admission registry | When configured and not bypassed, checks the caller before stablecoin minting and USDC redemption | | uWatt blocklist | Restricts token movements involving blocked addresses and specified allowance operations | | uWatt pause | Stops token movement, including minting and burning | | Staking-vault controls | Use the uWatt pause and blocklist for share movement; do not consult the admission registry | | pWatt controls | Apply project-token pauses, blocklists, and transfer settings; the Reserve has a privileged pull function | | Project swap role | Restricts execution to an authorized operator; the swap function does not check each holder in the admission registry | The admission check is active when the issuer is connected to a registry and that registry's bypass is off. Leaving the registry address unset or enabling bypass disables the check. A loss of admission alone is different from a blocklist entry. The former closes the configured primary desk to that wallet. The latter can prevent token movement more broadly. A holder without desk access may be technically able to use another market, but market availability and legal eligibility remain separate conditions. ## Staking and the legal terms The Terms and Conditions, sections 5.8 and 6.4, and the uWatt offering document condition staking rights and distributions on completed onboarding and whitelisted status. The staking vault receives newly minted uWatt into a shared pool. As rewards vest, they increase the uWatt represented by outstanding c-uWatt. The vault uses token pause and blocklist controls rather than the desk's admission registry; removal from desk admission alone does not remove shares from the pool or its exchange-rate calculation. ## Wallet control, suspension, and continuity User wallets are non-custodial: users control their private keys, whether using a self-custody wallet or the designated embedded-wallet interface. Reserve custody is a separate arrangement. Non-custodial key control does not imply that token transfers cannot be frozen. The contracts retain blocklist and pause powers, and the pWatt Reserve role can pull project tokens during a swap without an ordinary holder allowance. Under the terms, suspension or termination can remove platform access and eligibility for distributions. Tokens can remain recorded on-chain while becoming restricted or losing contractual rights. The consequences depend on the legal action and the controls applied. Death, incapacity, and loss of keys can also interrupt access. Holders are responsible for understanding the wallet-export process and making appropriate continuity arrangements while able to do so. The contract does not supply automatic inheritance or recovery of a lost private key. Questions about verification or a change in status go to . The [AML/ATF policy](/legal/aml-atf-policy.md) describes the program behind these decisions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.suno.finance/legal/eligibility-and-onboarding.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.