ASP White Paper

Important notice

This paper describes a specified technology and utility ecosystem. It is not an offer to sell securities, a solicitation, investment advice, a guarantee of launch, or a promise of profit, price appreciation, liquidity, rewards, exchange listing, or regulatory approval. Testnet ASP has no monetary value. Any future mainnet release will require separate approvals and final documentation.

Contents

AirShare+ connects people, places, opportunities and payments in one real-world network. Developed by Airsidian Inc, AirShare+ combines social connection, local discovery, jobs, services, commerce, crypto and payments in a single utility network. AirShare+ is in its live beta launch. People use the network to meet, find what is nearby, discover work, arrange services and participate in local commerce; each screen identifies what is available during beta. ASP is the economic and payment layer underneath these experiences; its purpose begins with useful activity inside the network.

The maximum lifetime supply is 100 million ASP with six display decimals. Supply would be allocated across community rewards, marketplace and participation incentives, ecosystem treasury, liquidity, contributors, and partnerships. Only a limited portion would enter circulation initially. No ASP presale has taken place.

1.1 The network and its economic layer

Management has confirmed 100,000,000 ASP as the lifetime supply cap and the burn mechanism as part of the system design. ASP staking is not part of the launch plan. Native asset issuance, burn execution and exchange require verified implementation before activation. Initial issuance and circulation are separate quantities.

The full utility stack brings together job and task payments, marketplace purchases, services, rewards and other in-app transactions, with transaction fees, the burn mechanism, treasury and custody infrastructure, and eligible governance or voting. These functions support network activity; availability remains explicit in each product screen.

AirShare+ is the first major application described in this paper. ASP and the underlying account, payment, custody and intelligence infrastructure can eventually support additional Airsidian products and services. Expansion requires separate integration, permissions and activation evidence; it does not imply that other applications or markets already operate.

1.2 What is available today

ASP is separate from any future Airsidian corporate share allocation. A beta checklist or test-credit balance is not a share certificate, token redemption right or investment entitlement.

1.3 What ASP is intended to do

• Pay for eligible jobs and completed tasks, marketplace purchases, local services and other in-app transactions using one economic layer.

• Reward verified contribution and participation without promising investment returns.

• Support community signaling and governance mechanisms that resist simple wealth-based capture.

• Create transparent, verifiable supply and burn records on Cardano.

• Allow future dApp and smart-contract integration without rebuilding the asset as a conventional contract token.

1.4 What ASP is not

• ASP is not equity, ownership in Airsidian, or a claim on corporate revenue or assets.

• ASP is not a stablecoin and is not promised to maintain a fixed dollar value.

• ASP is not a bank deposit and is not represented as FDIC-insured.

• ASP does not guarantee voting control, profit, yield, liquidity, redemption, or exchange listing.

• Testnet ASP cannot be purchased, redeemed, or converted into future mainnet ASP.

AirShare+ is a major application within the broader Airsidian ecosystem. Its social connections and local signals create the context for opportunities, completed work, commerce and payments. ASP supplies a common economic unit for eligible transactions across that network. The architecture keeps the everyday experience centered on what people want to do, with wallet, custody and settlement infrastructure supporting the activity underneath.

2.1 One network three supporting layers

AirShare+ is the experience layer: people, places, opportunities, work and commerce. ASP is the economic layer: eligible payments, fees, rewards and settlement. Seer is the intelligence layer: guidance, useful insights, moderation signals, trends and system intelligence from appropriately authorized network activity and platform data.

A member can discover an opportunity, agree a task or purchase, complete the interaction and follow its payment record within the same network. On-chain and off-chain adaptability supports different transaction types: private internal account movements for suitable in-app activity and Cardano settlement where a public-chain transaction is needed. The accounting must reconcile across both paths; off-chain does not mean unrecorded or hidden from the custodian.

Real-world utility first. Every ASP function must serve people, places, opportunities, work, commerce or payments, with a product purpose independent of token price.

Safety before scale. Real value remains disabled until technical, operational, licensing, and governance gates close.

Transparent supply. Minting, treasury movement, vesting, rewards, and burns must be independently verifiable.

Customer assets are not company funds. Custodial balances must be segregated and reconciled.

Simple user experience. AirShare+ should abstract blockchain complexity without hiding material risks or fees.

Progressive decentralization. Governance can expand only when participation, security, and legal structure can support it.

Chain adaptability. Critical product records should remain portable if Airsidian later launches or adopts another network.

3.1 Public transparency commitments

• Publish the verified Cardano policy ID before any mainnet distribution.

• Publish maximum supply, circulating supply, treasury balances, vesting wallets, and cumulative burns.

• Identify which actions occur on-chain and which are recorded on Airsidian's internal custodial ledger.

• Disclose material smart-contract, custody, counterparty, liquidity, and regulatory risks.

• Maintain change history for tokenomics and governance rules.

ASP is designed to operate on Cardano as a native token within the Cardano ecosystem. Its primary utility is the economic and payment layer underneath AirShare+, with potential use across the wider Airsidian ecosystem. Cardano is the underlying blockchain; ASP is the application token. Native ASP issuance is still in preparation.

Cardano supports native assets at the ledger level. A Cardano token is identified by its policy ID and asset name, and basic transfers do not require execution of a separate token contract. Smart contracts remain available for functions that genuinely require programmable enforcement, such as governed treasuries, participation contracts, or specialized mint-and-burn controls.

ADA pays Cardano transaction fees and supplies the minimum ADA required in native-token outputs. ASP is a distinct native asset identified by policy ID and asset name. Holding ASP does not make it ADA and does not itself participate in Cardano consensus staking. Treasury ADA, customer ADA and any pool rewards require separate accounting.

5.1 Minting-policy objective

The specified policy should permit a single authorized initialization and thereafter reject all positive issuance while allowing properly authorized burns. A simple reusable signing-key policy alone would not prove a permanent lifetime cap. The 100 million ASP lifetime cap, one-time initialization condition, burn authority and no-remint rule must be formally specified and independently tested before the policy ID is final.

• Initialization requires a defined one-time condition and approved multisignature authority.

• The target is to prevent any administrator from exceeding the lifetime issuance cap or replacing burned units through later minting. That protection is not implemented or audited yet.

• Burns require authorized transactions and auditable references.

• Treasury and policy keys use separate roles, hardware protection, recovery procedures, and approval thresholds.

• Testnet keys, policy IDs, and assets are never reused on mainnet.

5.2 Precision and asset identity

The specified six decimals imply 100,000,000,000,000 base units at the 100 million ASP cap; 0.01 ASP equals 10,000 base units. Cardano records integers. Services must use checked integer arithmetic, store the exact policy ID and asset name, and reject wrong-network or look-alike assets. Existing beta credits use a separate internal representation and must not be silently converted into this future supply.

Allocation is not the same as immediate circulation. Treasury-controlled allocations remain non-circulating until released under published authority, schedules, and operational controls. The specified initial circulating range is 10-15 million ASP; the exact amount and release schedule remain open.

6.1 Presale status

No ASP presale has taken place. Airsidian has not included a presale in the current launch plan. Test ASP has no monetary value and may not be sold or represented as an investment. Any future mainnet distribution must follow a published release policy and applicable approvals; participation in AirShare+ does not promise token appreciation, profit, liquidity, or an exchange listing.

• No early purchaser receives ASP at a confidential preferential price.

• Team and contributor allocations remain subject to disclosed vesting and conflict controls.

• User rewards are earned only under published program rules for verified activity.

• A future public purchase feature, if ever approved, would require separate pricing, consumer-disclosure, licensing, tax, sanctions, and token-classification review.

ASP is intended to function as an optional payment method inside approved AirShare+ experiences. Marketplace and job prices may be displayed in a familiar reference currency while settlement uses the calculated ASP amount. A quote must state its source, timestamp, expiration, fees, burn contribution, and final amount before confirmation.

7.1 Jobs and completed duties

AirShare+ may let an authorized requester offer ASP for a defined job, duty, task, service, or community contribution. The app records the scope, ASP amount, deadline, acceptance criteria, authorized payer, and dispute terms before work begins. ASP is released only after the required completion event or an approved dispute decision; Airsidian then posts the corresponding entries to its custodial ledger and includes the payment in an on-chain settlement batch when required.

A requester publishes or assigns an eligible job or duty with a stated ASP payment.

An eligible participant accepts and completes the work.

The requester, approved reviewer, or rule-based workflow verifies completion.

AirShare+ releases the stated ASP to the participant's custodial balance, less only charges disclosed in advance.

The receipt identifies the job, payer, recipient, gross ASP, fee, burn contribution, completion evidence, and settlement status.

7.2 Proxy Jobs payment states

The specified duty flow is offer → accepted → funds reserved → work submitted → review or dispute → approved settlement → receipt. A requester should fund or reserve the full worker payment and disclosed fee before work begins. A pending reservation is unavailable for a second payment. Partial milestones, cancellation, deadlines, worker acceptance and dispute escalation must be agreed in advance.

Seer may help write a clear duty description, summarize completion evidence and guide both parties through status. She cannot certify physical work merely from a chat message or approve her own payment decision. Settlement needs the designated human approval or a separately approved deterministic rule, with an appeal path.

For illustration only, a duty paying 100 ASP with a separately disclosed 1 ASP fee would debit 101 ASP, credit the worker 100 ASP, and allocate 0.01 ASP from the earned fee to a pending burn reserve. The remaining 0.99 ASP is company fee revenue before other costs. No such production fee schedule is currently activated.

7.3 General transaction lifecycle

A verified user selects an eligible product, service, or transfer.

The app displays the ASP amount, recipient amount, platform fee, burn contribution, network treatment, and refund status.

Airsidian checks account status, location, limits, sanctions controls, fraud signals, and available custodial balance.

The internal ledger posts an immutable double-entry record. On-chain settlement occurs only when required by the operating model.

The user receives a receipt with transaction ID, timestamp, amount, fee, burn amount, status, and support path.

7.4 Fee mechanism

Airsidian charges the disclosed platform fee when the relevant production service is activated for eligible job payments, marketplace purchases, transfers, or other enabled services. The fee is separate from the seller's or worker's stated payment unless the confirmation screen expressly shows a different arrangement. Airsidian recognizes the fee in its operating ledger and funds the scheduled 0.01 ASP burn from that earned fee; the burn is not an additional deduction from the recipient.

• The confirmation screen shows the gross payment, payer charge, recipient amount, Airsidian fee, burn contribution, and any network charge.

• Fees are shown before authorization and cannot be hidden inside an exchange rate.

• No-fee transactions generate no automatic burn unless Airsidian intentionally funds it from an approved treasury budget.

• Failed or fully reversed transactions do not generate a final burn unless a disclosed nonrefundable fee was validly earned.

• Bots, wash activity, and self-dealing do not qualify for incentives or Burner recognition.

The marketplace may enable approved users to exchange eligible goods and services using ASP. Airsidian's role, custody model, dispute process, prohibited items, refunds, tax reporting, seller verification, and jurisdiction availability must be disclosed before activation.

At checkout, AirShare+ reserves the buyer's ASP, confirms the seller and listing remain eligible, and posts settlement to the private custodial ledger. Depending on the product rules, funds may release immediately, after delivery confirmation, or after a disclosed holding period. A refund reverses the applicable internal entries when still reversible; completed on-chain transfers require a new authorized return transaction rather than deletion of the original record.

8.1 Delivery disputes and refunds

Marketplace settlement must link the order, listing snapshot, delivery evidence, buyer and seller approvals, and exact payment authorization. A delivery claim alone is not final proof. Product rules define when a hold expires, who can decide a dispute, and which evidence is shared. Disputed or refundable fees should not be included in a burn batch until eligibility is established.

An internal refund uses compensating ledger entries, preserving the original receipt. If tokens have already been burned, they cannot be unburned; the company must fund any valid fee refund from its own reserve. A return from an external wallet requires a new transaction and cannot be guaranteed.

ASP may support community signaling on specified new AirShare+ items, features, marketplace categories, badge designs, community programs, and other published choices. A proposal page should explain the item, choices, voting window, eligibility rule, vote-weight method, quorum, result status, and whether the outcome is advisory or binding. Token ownership alone should not buy unrestricted control over AirShare+ or Airsidian.

9.1 Anti-capture model

• Verified-person eligibility and anti-Sybil controls.

• Voting-power caps so a small number of large holders cannot dominate every decision.

• Quadratic or conviction-based mechanisms only after simulation and abuse testing.

• Separate proposal categories for community preferences, treasury grants, product priorities, and protocol changes.

• No community vote can require unlawful conduct, expose confidential security controls, seize customer property, or override sanctions and safety obligations.

9.2 Initial voting scope

9.3 Current pair vote and future voting controls

ASP / ADA stays first. The prepared next vote chooses XRP or Cosmos ATOM as an additional planned pair, not a replacement primary chain. After a closed vote with a sole winner, Listings can show ASP / ADA, then ASP / XRP or ASP / ATOM, followed by Next voting. Ties or no votes select neither. Selection does not create liquidity, a bridge, an exchange listing or permission to trade.

The current beta ballot uses the amount of in-app credits a member locks as vote weight, with one recorded ballot per account per proposal and release after the fixed deadline. The caps, verified-person rules and anti-capture mechanisms above are specified improvements, not claims about the current implementation. Custody, security and regulatory decisions remain outside community voting authority.

ASP staking is not part of the launch plan. Members do not need to stake ASP to use eligible payments, jobs, services, marketplace purchases or ordinary transfers. The network focuses on useful activity and completed transactions.

Participation rewards can recognize verified contributions under published eligibility rules, per-account limits and an approved funded budget. Rewards are drawn from the defined allocations within the 100 million lifetime supply cap. Holding ASP alone does not create an entitlement to yield. No ASP lock-up or staking reward program is offered at launch.

AirVoting reservations and job or marketplace payment holds serve specific transactions. They remain separately disclosed, time-bound account states; they are not an ASP staking program. The same funds cannot be spent while reserved. Release and refund entries preserve the original audit record.

10.1 ADA delegation is separate

Delegating ADA to a Cardano stake pool supports Cardano consensus and may earn protocol rewards. ASP is a separate native asset and does not secure Cardano consensus through staking. Any delegation of company-owned ADA is a separate treasury decision with its own accounting. Customer assets are not automatically delegated, lent or reused.

Any later ASP reward or locking product would require a separate decision, published terms and verified implementation. There is no promised APR, APY, fixed return or staking launch date in this paper.

ASP uses a defined, transparent burn mechanism funded from Airsidian's platform-fee revenue on eligible completed transactions. Burning means permanently destroying ASP through an authorized negative-mint transaction under the Cardano policy, thereby reducing outstanding supply. Burning does not guarantee scarcity-driven demand, price appreciation, liquidity, or economic return.

11.1 Burn examples

11.2 Burn safeguards

• The burn floor is 50,000,000 ASP of total outstanding supply after the one-time issuance, not circulating supply. Initial circulation of 10–15 million ASP is a separate release measure. Company-funded and voluntary burns share this floor: reject any burn that would reduce outstanding supply below 50 million ASP. The minting policy must enforce the floor and forbid positive reminting after initialization. Until those controls are implemented and independently tested, execution remains disabled.

• Automated burning pauses when a circuit breaker, reconciliation exception, policy error, or security incident is active.

• Burns never come from segregated customer balances without the customer's explicit voluntary instruction.

• Published reports distinguish fee-funded burns, voluntary personal burns, corrections, and testnet activity.

11.3 From fee event to confirmed burn

An eligible, final fee event first creates a pending burn obligation using a unique transaction reference and policy version. The burn amount is capped by actually earned company ASP fees or an explicitly approved company top-up. A fee below 0.01 ASP must not silently debit the recipient or customer principal; the event waits for authorized funding or follows a published exception rule.

The service groups eligible obligations into a batch, verifies the source treasury UTXOs, supply-floor rule, reconciliation, approvals, minimum ADA and network fee budget, and constructs a negative-mint transaction under the ASP policy. An isolated signer authorizes it. Submission is pending, not burned. Only after the required Cardano confirmation policy is met does the service mark obligations confirmed and update the public burn total.

Duplicate job delivery must not create a second burn. Persist a stable batch ID and transaction hash, reconcile an uncertain submission before retrying, and recheck the final chain outcome after interruptions. Public reporting distinguishes scheduled, submitted, confirmed, failed and reversed-before-submission events. A treasury transfer or a database balance reduction is not proof of an on-chain burn.

Voluntary burns require an eligible member, exact asset and amount, sufficient available balance, explicit irreversible confirmation and step-up authentication. Personal consent is bound to one request. No customer asset is included merely because it shares an omnibus wallet with treasury assets. The policy must allow burning without enabling unauthorized reminting.

A Burner badge recognizes a user's cumulative, personally initiated and verified voluntary burns. Automatic platform-fee burns support the global burn counter but do not count toward personal badge status. Badges are recognition features, not financial benefits or promises of token value.

• Every voluntary burn requires an irreversible-action warning, amount review, strong authentication, and final confirmation.

• Badge records remain after the burn because they represent verified historical activity.

• Airsidian may exclude compromised, fraudulent, sanctioned, bot-driven, or self-dealing activity.

• The app should display ASP units, not a claimed future dollar value, beside badge progress.

Airsidian Inc is designated in this design as the custodial operator. Airsidian would control the production custody infrastructure and maintain an internal customer subledger representing each customer's entitlement to ASP held in controlled Cardano wallets. Custody does not convert customer assets into corporate assets.

13.1 Custodial responsibilities

• Maintain authoritative customer subledger balances and immutable transaction history.

• Segregate customer-controlled value from Airsidian operating, treasury, reward, liquidity, and fee wallets.

• Use role-based access, multisignature or MPC controls, transaction limits, allowlists, and dual approval for material movements.

• Screen onboarding, names, locations, funding sources, devices, and relevant blockchain addresses.

• Reconcile the sum of customer liabilities to controlled on-chain assets and approved pending items every day.

• Maintain recovery, key-compromise, incident-response, business-continuity, complaint, and withdrawal-review procedures.

• Provide accurate receipts, balance history, fee disclosure, support access, and applicable customer notices.

13.2 Internal transfers and on-chain settlement

ASP and ADA backing the service are held on-chain in Airsidian-controlled custodial wallets, while individual customer balances and routine in-app activity may be represented off-chain on Airsidian's private internal ledger. Airsidian remains the custodian in this hybrid model. The blockchain records controlled-wallet assets and approved settlement movements; it does not need to expose a separate public address or transaction for every user's marketplace purchase, vote, reward, or internal transfer.

This structure can improve user privacy, reduce network cost, increase transaction speed, support disclosed reversals before final settlement, and simplify small payments. It does not make transactions anonymous: Airsidian retains customer identity, authorization, compliance, and audit records and may be legally required to produce them. The interface must clearly distinguish pending, completed, reversible, irreversible, internal, and on-chain states.

13.3 On-chain / off-chain adaptability

• The product can route eligible activity between internal and Cardano settlement without changing the user's ASP unit of account.

• Customer-facing privacy comes from omnibus custody and internal accounting, not from hiding records from Airsidian or lawful oversight.

• On-chain wallet labels and public reports should avoid publishing unnecessary personally identifiable information.

• Proof-of-reserves or attestation designs must avoid exposing individual customer balances.

• Every off-chain balance remains fully reconcilable to the appropriate on-chain asset pool and approved pending items.

13.4 External withdrawals

Self-custody deposits and withdrawals are separate products and remain disabled by default. Activation requires supported-wallet standards, address validation, step-up authentication, cooling periods, sanctions and blockchain screening, travel-rule assessment where applicable, network-risk handling, customer education, and jurisdiction approval.

14.1 Expo Cloudflare and the custody boundary

Expo and React Native provide the phone interface. Cloudflare can serve the versioned white paper and other static assets, cache public network information and coordinate background work. Queues can carry confirmation checks and approved batch jobs; delivery may repeat, so ledger and chain operations require persistent deduplication. Durable Objects are a possible coordination layer, not an automatic guarantee that an external blockchain action runs once.

The authoritative customer ledger remains in its existing controlled backend unless a separately tested migration is approved. Cloudflare must not maintain a competing spendable balance. The device shows server-verified status while refreshes and long-running confirmation checks happen in the background. Image caching, screen rendering and network latency still require their own performance work.

Production signing keys do not belong in Expo, client JavaScript, white-paper files, ordinary logs or a language-model context. Workers would request signing from a separately approved custody service that enforces exact transaction limits and quorum controls. Public document hosting can be deployed independently of any financial worker. Burn execution is not connected to production funds. ASP staking is excluded from the launch scope.

14.2 Seer as the network intelligence layer

Seer connects intelligence across discovery, social interaction, work, services, commerce and payments. Authorized platform data, public activity and suitably aggregated network signals can support useful insights, local trends, moderation signals and system-health explanations. Today, Seer provides guidance, research and supported read-only checks; broader analytics depend on connected data sources and validated services. A description of the intelligence architecture is not a claim of continuous access to every activity.

Member guidance and operational intelligence use different access scopes. Seer must respect user choices, account permissions, data minimization and the privacy of personal conversations. Trend or moderation output needs source, time and confidence; it is a signal for review, not automatic proof of misconduct. Seer cannot sign payments, move funds, certify completed work or approve her own conclusions.

Seer can explain the approved white paper, decode statuses, guide users to Exchange, Burn mechanism, help them understand a receipt and use supported authenticated read-only tools. Answers should identify whether data is live, cached, specified or unavailable. An account lookup must be bound to the signed-in member and the tool permissions.

Future capabilities may include summarizing a job agreement, organizing marketplace dispute evidence, checking an allowed transaction status, explaining an expiring quote and preparing a draft instruction for user review. Each capability requires a defined tool, authorization checks, evaluation and release approval; describing it here does not mean it exists today.

Seer cannot hold a signing key, move funds, burn tokens, stake balances, approve payouts, alter a vote, bypass sanctions, decide a SAR or guarantee returns. A chat instruction never replaces the transaction confirmation screen. Final execution belongs to a deterministic authorized service after the member or designated staff approves the exact action.

Uploaded listings, messages, receipts and documents are untrusted input. Embedded instructions must not change Seer permissions. Minimize sensitive data, redact logs, avoid exposing other members’ records, test prompt injection and financial misinformation, and provide human support when confidence or permission is insufficient.

14.3 Future exchange and transfer execution

The dedicated Exchange screen starts with Buy ASP (pay ADA, receive ASP) or Sell ASP (pay ASP, receive ADA). Flipping direction clears the previous amount so a member must review a fresh intent. ASP / ADA is the sole initial pair. XRP or ATOM may be added following the eligible vote and a completed, separately validated integration.

Preview opens a separate review screen showing the authenticated sending account, the member balance that would receive the proceeds, the exchange venue or counterparty when known, and the settlement destination. It itemizes input and output amounts, exchange rate, minimum received, platform and network fees, total debit, preview date and time, and quote expiry. Both ASP and ADA USD reference values must identify their source and timestamp. Preview time is not the time of an executed trade.

The Confirm exchange button sits below the review. Today, no live quote is issued: unavailable prices, fees, destinations and output amounts are labeled accordingly, and confirmation is disabled. Beta ASP has no monetary value and cannot be exchanged for ADA. The preview never reserves funds or submits an order. Later activation requires a verified quote bound to the member and exact intent, fresh confirmation after any price or direction change, and server-controlled settlement; a device flag cannot authorize a trade.

A future ASP / ADA quote must identify the exact network and asset, venue or liquidity source, price timestamp, expiry, input, fees, slippage limit and minimum output. The server validates the quote again at authorization, reserves inputs once, submits through approved settlement infrastructure and returns an auditable receipt. An expired quote requires a new confirmation; it must not silently execute at a worse price.

Internal send and receive use ASP registered numbers mapped to the intended member, a reviewed recipient identity and an idempotent transfer request. External Cardano deposits require supported address and asset validation plus the confirmation policy before credit. Withdrawals require available funds, eligible destination, step-up authentication, screening and a signed transaction. Failed or ambiguous network results are reconciled before balances are released or retried.

Custody is a security-critical service. Mainnet activation requires an independently assessed architecture, documented key ceremony, separation of duties, tested recovery, resilient chain infrastructure, secure software delivery, and operational monitoring.

15.1 Production release evidence

• Threat model and architecture approval.

• Independent custody and minting-policy review.

• Penetration test and remediation evidence.

• Backup, restore, key-loss and compromise exercises.

• Normal and exception reconciliation tests.

• Transaction-monitoring and sanctions evasion test cases.

• Incident, complaint, liquidity, and vendor-outage tabletop exercises.

Management supplied a FinCEN filing reference in the source draft. The underlying filing, registrant details and current status have not been independently verified for this revision. A filing receipt or registration does not authorize ASP or replace applicable state, territorial or foreign permissions. Public regulatory claims must be checked against the retained evidence before use.

• Written, risk-based AML/CFT program with designated day-to-day responsibility, training, and independent review.

• Customer identification, sanctions compliance, transaction monitoring, case management, SAR decision controls, confidentiality, and record retention.

• State money-transmission and digital-asset licensing or documented exemption/authorization for every enabled location.

• Token classification and offering analysis before any sale, reward, locking, liquidity, or promotional program.

• Consumer terms, privacy notice, fee and risk disclosures, complaints, refunds, error handling, marketing controls, and asset-segregation disclosures.

• Approved banking, payment, identity, blockchain analytics, custody, and infrastructure partners with audit rights and exit plans.

During the controlled launch phase, Airsidian remains responsible for custody, security, compliance, treasury execution, and product safety. Public community signaling can inform decisions but does not replace accountable corporate governance or regulatory duties.

17.1 Transparency reporting

• Maximum and circulating ASP supply.

• Treasury, rewards, liquidity, contributor and partnership balances.

• Vesting releases and material treasury movements.

• Fee-funded and voluntary burns, with Cardano transaction references.

• Governance proposals, participation, outcomes and implementation status.

• Material incidents and remediation summaries where disclosure does not create additional risk.

19.1 User responsibility

Users remain responsible for protecting credentials, reviewing transaction details, understanding irreversible actions, complying with applicable laws, and obtaining their own tax, financial, and legal advice. Airsidian's controls reduce but cannot eliminate risk.

Sources should be checked again before production implementation because protocols, regulations, and agency guidance can change.

Final controlled-draft statement

Defined system rules require tested implementation before activation. Publish the verified asset identity, supply controls, program terms and authorized launch scope before real-value use.