QINDEX Whitepaper

Important Notice

Document scope. This is a technical and economic whitepaper. It is not a prospectus, offering memorandum, subscription agreement, investment advisory agreement, or guarantee of product availability. Product-specific legal documents and deployed smart-contract code control where they conflict with this paper.

Digital assets, smart contracts, decentralized liquidity, oracles and AI-generated allocation signals involve substantial risk. QINDEX can lose significant value, become illiquid, experience delayed or unavailable redemption, or become worthless. No return, liquidity, market price, regulatory treatment or tax outcome is guaranteed.

QINDEX availability depends on jurisdiction, investor eligibility, sanctions and wallet screening, product approvals and other compliance requirements. QINDEX may be characterized as a security, commodity, derivative, fund interest, collective investment product, virtual asset or other regulated instrument depending on the facts and applicable law.

This paper describes the reference Base deployment and intended protocol design. Contract addresses, implementation versions, audit reports, supported assets, fee recipients and live parameters must be verified through QINV's official deployment registry before any transaction.

Document control

Reading note. Product terms, official contract addresses, live fee parameters, source-code verification and security-review status must be checked for the exact QINDEX deployment before use.

Executive Summary

QINDEX is QINV Onchain's tokenized portfolio-share product: a single ERC-20 token intended to provide proportional exposure to a dynamically allocated basket of crypto assets held by transparent smart contracts on Base. Users connect a wallet, deposit an accepted asset — initially USDC — and receive QINDEX shares based on the net value added to the vault. In normal operation, users may burn shares and redeem a proportional amount of the underlying basket.

The strategy layer combines QINV's quantitative research and AI-assisted allocation process with deterministic on-chain accounting. The models operate off-chain; they do not receive unrestricted control over vault assets. Instead, target weights are packaged with risk parameters, signed through an authorized workflow and submitted to contracts that enforce asset allowlists, deadlines, trade-size limits, slippage controls and role permissions.

QINDEX uses an elastic supply. New shares are minted only when assets are contributed to the vault, and shares are burned when assets are redeemed. It is not a fixed-supply speculative token and does not represent equity in QINV. Each QINDEX unit represents the same proportional interest in the net assets of its specific vault and strategy version, subject to accrued fees, liabilities and contract rules.

Authoritative fee for this whitepaper. QINV charges a 5.00% annual administration fee on total assets under management. The fee is accrued daily using a 365-day convention and reflected in QINDEX NAV / token value. A holder's QINDEX token balance is not reduced by daily accrual. Network, DEX, liquidity, slippage, tax and other transaction costs are separate.

QINDEX at a glance

1. Purpose and Design Principles

1.1 The portfolio problem

Crypto investors face a fragmented workflow: selecting assets, assessing liquidity and token risk, connecting wallets, routing trades, monitoring positions and rebalancing over time. A static index simplifies selection but may react slowly to changing market conditions. A centralized managed product can simplify operations but introduces custodial and counterparty risk. QINDEX is designed to combine a managed portfolio experience with public on-chain state and wallet-native access.

1.2 Design principles

• One position, diversified exposure. A holder interacts with one portfolio-share token rather than manually managing every basket asset.
• Transparent accounting. Vault balances, token supply, mints, burns, fee accrual and rebalances are designed to be independently observable on-chain.
• User-controlled access. QINV does not control a user's wallet keys. Users authorize their own transactions.
• Smart-contract custody, not company balance-sheet custody. Underlying assets sit in protocol vaults governed by code and privileged roles, not in an ordinary corporate wallet.
• Constrained AI. Models propose allocations; contracts and operational controls determine whether and how those allocations may be executed.
• Fail closed. Stale prices, unsupported assets, invalid signatures, excessive slippage or expired instructions should block execution rather than silently continue.
• Versioned change. Strategy methodology, contracts and material parameters must be identifiable by version so users can evaluate changes.
• Honest risk disclosure. On-chain transparency and diversification reduce some risks but do not eliminate market, technical, legal or operational loss.

1.3 Product boundaries

What QINDEX is. A tokenized portfolio share whose value is intended to follow the net asset value of a specific on-chain basket after fees, costs and liabilities.

What QINDEX is not. It is not a stablecoin, bank deposit, guaranteed return product, insurance policy, share of QINV AI ON-CHAIN LLC, or promise that the AI will outperform any benchmark.

2. QINDEX Token and Holder Rights

2.1 Token standard and identity

The reference QINDEX deployment is an ERC-20 token on Base. ERC-20 provides a common interface for balances, transfers and allowances, enabling wallets and compatible applications to recognize the token. Token symbols are not unique; users must verify the chain ID and official contract address before interacting. [4][5]

Each strategy and deployment may use a distinct contract address. A QINDEX token from one vault is not automatically interchangeable with a QINDEX token from another strategy, version or blockchain, even if the displayed symbol is similar.

2.2 Economic rights

2.3 Supply mechanics

QINDEX has an elastic supply rather than a fixed token allocation. Supply expands when users mint shares and contracts receive net assets; it contracts when users redeem and burn shares. The reference design does not require a token presale, mining schedule or speculative team allocation. Initial seed shares, if any, must be minted against actual contributed assets and disclosed in the deployment record.

Administration-fee settlement must not create unbacked shares. In the reference design, daily fee accrual is reflected in NAV and periodically settled through a documented smart-contract mechanism while user token balances remain unchanged.

2.4 Custody terminology

Important distinction. The user controls the private keys to the wallet holding QINDEX. The underlying basket assets are held by smart contracts. This removes ordinary centralized account custody, but it does not mean the holder directly controls each underlying token or that the contracts are risk-free.

3. Investment Methodology and AI Signal Process

3.1 Eligible asset universe

QINV first defines an eligible universe. Model output cannot add arbitrary assets that have not passed technical, market and risk review. Admission criteria are intended to include:

• Sufficient market capitalization and observable trading volume.
• Adequate liquidity on approved Base venues and practical trade sizing.
• Reliable token contracts and standard behavior; fee-on-transfer, rebasing or blacklist features require explicit review.
• Documented price sources and acceptable oracle coverage.
• Reasonable concentration, issuer, bridge and wrapped-asset risk.
• Operational compatibility with the vault, router and redemption design.
• No known legal or compliance restriction that prevents inclusion in the target product.

3.2 Quantitative allocation engine

QINV reports that its allocation models have been developed and refined through approximately eight years of quantitative research and backtesting. The reference process analyzes market and risk information such as price, volume, volatility, correlations, trend and momentum indicators, liquidity and selected on-chain or sentiment data. The exact model architecture and parameters are proprietary; the governance and execution envelope is designed to remain verifiable. [1][2][3]

A proprietary model is not the same as an unauditable process. QINV can disclose the eligible universe, rebalance timestamp, resulting weights, strategy version, risk constraints, transaction history, fees and realized portfolio state without disclosing source code or trade signals before execution.

3.3 Signal package and authorization

A reference rebalance package should contain at least:

• strategy and vault identifiers;
• methodology version and target rebalance timestamp;
• ordered asset list and target weights summing to 100% within tolerance;
• valid-from time, expiry time and nonce for replay protection;
• maximum total turnover, maximum trade size and asset-specific caps;
• slippage limits, price-deviation limits and approved routing adapters;
• emergency flags or stable-asset floor where applicable;
• authorized signature or multisignature approval.

3.4 Rebalance cadence

The reference QINDEX product normally targets weekly rebalancing. Weekly does not mean that every asset must trade every week. Drift bands, turnover limits, liquidity, execution cost and risk checks may result in no action, partial execution, delayed execution or cancellation. Emergency risk actions may occur outside the normal schedule where authorized by the product rules.

Rebalancing creates trading costs, slippage, tax consequences and tracking difference. The system should optimize for net portfolio outcomes rather than maximizing trade frequency.

3.5 Model governance and limitations

The model may be wrong, overfit, delayed or unable to generalize to unprecedented market conditions. Human curation and authorized operations introduce additional discretion. QINDEX therefore combines model output with hard risk controls, observable execution and versioned methodology. Past performance, backtests and simulations do not guarantee future results.

4. Technical Architecture

Figure 1. QINDEX reference architecture.

4.1 On-chain components

The names above describe logical modules; deployed contract names and whether modules are combined may differ. The official deployment registry and verified source code are authoritative.

4.2 Off-chain services

• Signal engine: produces target weights and risk metadata.
• Quote and route service: compares approved liquidity sources and builds bounded transactions.
• Keeper / operator: submits signed transactions but cannot bypass contract constraints.
• Indexer and NAV service: reads events and balances for dashboards, history and reconciliation.
• Monitoring stack: alerts on price staleness, supply/balance mismatches, failed trades, role changes and unusual outflows.
• Frontend: guides wallet connection, transaction review, mint, redeem and portfolio visibility.

4.3 Base and liquidity infrastructure

Base is an EVM-compatible Ethereum Layer 2, allowing QINDEX to use Ethereum token and smart-contract standards with lower transaction costs than typical Ethereum mainnet interactions. The execution layer remains exposed to Base-specific sequencer, bridge and rollup risks. [5]

Swaps may be routed through approved DEX and aggregator adapters, including 0x and Uniswap-compatible liquidity where supported. 0x provides smart-order routing across liquidity sources on Base, while Uniswap v4 supports customizable pool hooks. QINDEX does not assume that any single venue always provides the best price or sufficient liquidity. [6][7]

4.4 Pricing and oracle layer

On-chain balances are the source of truth for quantities. Prices used for NAV, display and mint validation should come from documented sources with staleness and deviation checks. Chainlink feeds may be used where available; other assets may require approved multi-source or time-weighted pricing. A missing or stale price should fail closed for affected operations rather than substitute an unverified value. [8]

4.5 Upgrade and deployment model

The reference design favors versioned deployments and explicit migration over silent economic changes. If upgradeable contracts are used, the implementation address, admin roles, timelock and upgrade history must be publicly observable. Material changes to accounting, redemption, fees or asset controls should receive advance notice and, where practical, require users to opt into a new vault version.

5. Mint, Hold and Redeem Lifecycle

5.1 Minting

1. The user connects a supported wallet on Base and verifies the official QINDEX contract and vault.
2. The user selects an amount of USDC and reviews the estimated QINDEX output, route, slippage, network costs and expiry.
3. The router receives USDC and executes approved swaps to construct the basket, or accepts an in-kind basket where supported.
4. The vault measures the net asset value actually received after execution costs and any disclosed entry charge.
5. The protocol accrues outstanding administration fees before calculating new shares.
6. QINDEX shares are minted to the user; events record the deposit, share amount and relevant accounting data.

Mint fairness. A quote is indicative. The final share amount should be based on net assets actually added, so an entering user neither dilutes existing holders nor receives a windfall from stale prices.

5.2 Holding and transfer

While held, QINDEX units remain in the user's wallet and can normally be transferred like other ERC-20 tokens, subject to compliance or contract restrictions. The number of units does not automatically increase through portfolio gains and does not decline through daily administration-fee accrual. Value changes through the NAV per share and any secondary-market premium or discount.

5.3 Redemption

1. The user selects the QINDEX amount to burn and reviews expected proportional outputs.
2. The protocol accrues outstanding administration fees and validates supply, balances, pause state and user eligibility.
3. QINDEX shares are burned.
4. The vault transfers the user's pro rata share of each redeemable basket asset, net of disclosed costs or liabilities.

Proportional multi-asset redemption is the reference design because it reduces dependence on forced swaps and preserves fair treatment during stressed liquidity. An optional USDC-only redemption may route assets through DEXs and therefore introduces additional slippage, liquidity and execution risk.

5.4 Availability and emergency conditions

QINDEX is intended to have no normal lock-up. Redemption can nevertheless be delayed, limited or paused because of smart-contract incidents, oracle failures, chain congestion, sanctions or legal restrictions, frozen underlying tokens, severe liquidity conditions or other emergency controls. Pause permissions should be scoped so that unaffected actions remain available where safe.

6. NAV, Accounting and Valuation

6.1 Core definitions

6.2 Valuation formulas

GAVₜ = Σᵢ (qᵢ,ₜ × pᵢ,ₜ) + cashₜ
q = asset quantity held by the vault; p = approved price input.

NAVₜ = GAVₜ − accrued administration feeₜ − other liabilitiesₜ

NAVPSₜ = NAVₜ / Sₜ
S = total outstanding QINDEX shares.

Prices are estimates of fair value and may not equal executable liquidation prices. Thin liquidity, token transfer restrictions, oracle latency and market gaps can create tracking differences between displayed NAV and realized redemption value.

6.3 Mint and redemption formulas

shares minted = net deposit value / pre-mint NAVPS
At genesis, an initial reference NAVPS is set in the deployment configuration.

asset i redeemed = (shares burned / pre-burn total supply) × redeemable balance of asset i

Accrued fees must be reflected before both calculations. Any amount reserved for liabilities must not be distributed as if it belonged to holders.

6.4 Reconciliation and proof of assets

The protocol should publish a machine-readable reconciliation showing:

• vault balances by asset and contract address;
• total QINDEX supply and holder-visible share price;
• accrued fee liability and latest fee settlement;
• latest approved prices, timestamp and source;
• mints, burns, transfers and rebalances by transaction hash;
• differences between on-chain balances, indexed data and dashboard values;
• strategy version and current target versus actual weights.

6.5 Secondary-market price

QINDEX may trade above or below NAVPS if secondary liquidity exists. Mint and redemption can create an arbitrage mechanism, but it is not guaranteed to eliminate a premium or discount because access, gas, asset liquidity, fees, restrictions or contract pauses may prevent arbitrage.

7. Administration Fee and Other Costs

7.1 Administration fee

Fee rate. 5.00% per annum on total AUM, accrued daily using a 365-day convention. This is an annual rate — not 5% per day.

For each day d, the administration fee accrued is calculated using the applicable daily total AUM. When AUM changes, the annual fee amount changes proportionally.

daily fee_d = AUM_d × (0.05 / 365)

fee over period = Σ_d [AUM_d × (0.05 / 365)]

The accrued amount is reflected in NAV and therefore in QINDEX value. The holder's token balance remains unchanged. The fee may be settled periodically by a smart-contract transfer or other disclosed accounting mechanism; the deployed code and product terms define the exact settlement flow.

7.2 Illustrative fee impact

Illustrations assume unchanged AUM, no return and no other costs. Actual accrued fees equal the sum of daily charges on actual daily AUM and may differ because prices, subscriptions and redemptions change.

7.3 Other costs

The 5% administration fee does not include third-party or transaction costs. Depending on the product and transaction, users or the vault may bear:

• Base gas fees paid in ETH;
• DEX, liquidity-provider, aggregator or routing fees;
• price impact, slippage and MEV-related execution loss;
• stablecoin issuance, redemption, bridge or transfer costs;
• taxes, withholding, reporting or governmental charges;
• product-specific entry, exit, redemption or performance fees only where separately disclosed before the transaction.

This reference QINDEX specification does not assume a performance fee. If a specific strategy introduces one, its benchmark, high-water mark, crystallization schedule and calculation must be documented separately and must not be confused with the 5% annual administration fee.

7.4 Fee disclosure standard

The user interface and on-chain analytics should display the annual rate, daily accrual convention, accrued unpaid amount, fee recipient, last settlement, any maximum rate encoded in contracts and a clear separation between QINV revenue and third-party transaction costs. Performance reporting should be net of administration fees and realized trading costs unless prominently labeled gross.

8. Token Economics and Composability

8.1 Asset-backed supply rather than allocation tokenomics

QINDEX token economics are driven by vault assets and share accounting, not by a fixed emission curve. The key economic questions are backing, supply, NAV, liquidity, fees and redemption — not mining rewards or speculative unlocks.

8.2 DeFi composability

As an ERC-20, QINDEX may be integrated by wallets, exchanges, lending protocols, automated strategies or other applications. Composability is not automatic endorsement or safety. Third-party protocols can introduce liquidation, oracle, approval, liquidity and smart-contract risks beyond the QINDEX vault itself.

QINV should not represent QINDEX as accepted collateral, listed or liquid on any venue unless the integration is live and independently verifiable.

8.3 Liquidity strategy

Primary mint and redemption at NAV are the core liquidity mechanism. Secondary liquidity may improve transferability but can fragment volume and create premiums or discounts. Market-making arrangements, incentives or protocol-owned liquidity, if used, should be disclosed separately because they can affect price formation and treasury risk.

9. Security Architecture and Operational Controls

9.1 Privileged roles

9.2 Security release gates

Before a production deployment is promoted as ready for public use, QINV should publish evidence of:

• verified source code matching deployed bytecode;
• independent security review with scope, findings and remediation status;
• unit, integration, invariant and failure-path test results;
• multisignature configuration and all privileged addresses;
• upgradeability and timelock details;
• documented oracle, route and asset allowlists;
• monitoring, incident response and emergency redemption procedures;
• official contract registry and user verification guide.

Audit status. An audit reduces but does not eliminate risk. This whitepaper does not claim that every current or future QINDEX contract has been audited. Users must review the published audit status for the exact deployed version.

9.3 Accounting invariants

• A mint may not issue more shares than the net asset value contributed permits.
• A redemption may not transfer more than the holder's proportional claim after liabilities.
• Fee accrual must be synchronized before mint and burn calculations.
• Target weights must sum to 100% within a defined tolerance.
• Unsupported assets and adapters cannot be introduced by the executor alone.
• Expired or replayed rebalance packages must revert.
• Stale or out-of-bounds prices must block price-dependent actions.
• Vault assets may move only through documented mint, redemption, rebalance, fee or recovery paths.

9.4 Incident response

The incident plan should define detection, classification, pause authority, user communication, forensic preservation, remediation, contract migration and post-mortem publication. Where safe, redemptions should remain available even if minting or rebalancing is paused. Some incidents may require a complete pause to prevent further loss.

10. Governance, Administration and Change Control

10.1 Initial governance model

QINDEX is not itself a governance token. The reference protocol is initially administered through role-separated operational accounts and a multisignature governance process. This approach prioritizes accountable incident response and controlled releases while the protocol matures.

10.2 Material changes

The following changes are material and should receive public notice, versioned documentation and, where practical, timelock protection:

• administration-fee rate, calculation base or fee recipient;
• mint or redemption mechanics;
• asset universe or concentration limits;
• pricing sources and oracle rules;
• strategy methodology or rebalance cadence;
• contract implementation or upgrade authority;
• compliance restrictions and transferability;
• new external protocols with custody or execution privileges.

The reference fee is 5.00% per annum. A material increase should not be implemented silently in an existing vault; the preferred approach is a new version with explicit disclosure and user choice. Fee decreases and emergency risk reductions may be treated differently if the deployed contracts permit them.

10.3 Future decentralization

A future governance system may delegate limited decisions to token holders or a separate governance token. Portfolio-share holders should not be exposed to unrestricted votes that can seize vault assets, add arbitrary tokens, bypass risk controls or retroactively change economic rights. Any decentralization must be introduced with a documented threat model and legal review.

11. Legal, Compliance and User Eligibility

11.1 Product-specific legal treatment

Tokenized portfolio products can fall within securities, collective investment, derivatives, commodities, virtual-asset, financial-promotion, investment-advisory or fund regulation depending on jurisdiction and structure. Technology does not determine legal classification by itself. QINV must assess each distribution model, user location, token right and service arrangement with qualified counsel. Current regulators emphasize facts-and-circumstances analysis and investor risk disclosure. [9][10][11][12]

11.2 Access controls

QINV may apply wallet screening, sanctions controls, geolocation, transaction monitoring, KYC/KYB, investor eligibility or source-of-funds checks. A public smart contract can remain technically reachable even when the QINV interface restricts access; users remain responsible for complying with applicable law.

11.3 Separation from Brazilian product

QINV Onchain is a Web3 product operated under its own terms and legal entity. It should not be confused with QINV's Brazilian app and advisory/custody relationships, which have different user flows, custodians, fees and regulatory arrangements. The 5% annual AUM fee described in this paper applies to the relevant QINDEX product, not automatically to every QINV product.

11.4 No advice and taxes

This paper and QINDEX interfaces are not personalized investment, legal, accounting or tax advice. Acquiring, transferring, rebalancing and redeeming crypto assets can create tax and reporting obligations. Users should obtain independent advice based on their jurisdiction and circumstances.

12. Risk Factors

No mitigation eliminates loss. The table summarizes controls, not guarantees. Users should be prepared to lose some or all of the value committed to QINDEX.

13. Transparency and Reporting Standard

13.1 Live on-chain information

The dashboard and public APIs should make it possible to verify, at minimum:

• official contract address, network and implementation version;
• total AUM, NAV, NAVPS and total supply;
• current vault balances and actual portfolio weights;
• target weights and rebalance history after execution;
• daily administration-fee accrual and settlement history;
• mint and redemption activity;
• price sources, timestamps and any stale-data warning;
• privileged roles, multisig and timelock configuration;
• pause status, incident notices and migration instructions.

13.2 Performance reporting

Performance reports should identify the calculation period, benchmark, starting and ending NAVPS, cash flows, administration fee, transaction costs, turnover, maximum drawdown and whether results are live, simulated or backtested. Net results should be the default. Any gross performance must be labeled and reconciled to net performance.

13.3 Methodology disclosure

QINV may protect proprietary model details while still disclosing the product rules that materially affect holders: eligible universe, key constraints, rebalance cadence, weight caps, price sources, fee model, change process and executed holdings. Public verification should focus on actual portfolio state and enforceable controls rather than unsubstantiated claims about AI.

14. Roadmap and Multichain Expansion

14.1 Base reference deployment

The public QINV Onchain product is positioned around Base, USDC entry, QINDEX portfolio shares, transparent smart-contract vaults and algorithmic rebalancing. Immediate priorities are production hardening, verified contracts, security evidence, fee/NAV transparency and robust mint/redemption operations. [1][2]

14.2 Strategy expansion

The architecture can support multiple portfolio strategies, each with separate vaults, share tokens, methodology versions, supported assets and risk parameters. New strategies should not reuse a symbol or interface in a way that obscures materially different risks.

14.3 Stellar-native implementation

QINV has also developed a strategy for a Stellar-native QINDEX implementation using Soroban contracts, Stellar wallets, liquidity adapters, event indexing and proportional redemption. If launched, that product should be a separate chain-native share class with its own contract ID, assets, supply, NAV and disclosures. It must not be treated as automatically fungible with Base QINDEX unless a separately audited cross-chain accounting and bridge system is deployed. [3][13]

14.4 Future capabilities

• institutional treasury and embedded-finance APIs;
• agent-readable portfolio and transaction interfaces;
• additional stable-asset entry and redemption options;
• tokenized real-world assets, subject to issuer, transfer, liquidity and legal review;
• additional chains only where liquidity, security and operational support justify the complexity;
• limited and carefully scoped governance participation.

Roadmap statements are forward-looking and may change because of security, market, partner, regulatory, funding or engineering considerations.

15. Conclusion

QINDEX is designed as a transparent on-chain portfolio share rather than a conventional speculative token. Its core proposition is straightforward: one wallet-held ERC-20 position, backed by a verifiable basket in a smart-contract vault, with dynamic QINV allocation signals, deterministic share accounting and an intended path to proportional redemption.

The design deliberately separates AI from unrestricted asset control. Models produce target weights; signatures, risk limits, contract permissions, liquidity checks and public events govern execution. This creates a system that is more inspectable than a purely centralized portfolio while acknowledging that privileged operations, off-chain data and smart-contract dependencies remain.

The economic model must be equally explicit. The reference QINDEX administration fee is 5.00% per year on total AUM, accrued daily and reflected in NAV. Users should evaluate that fee together with market risk, execution costs, strategy quality, contract security, liquidity and the possibility of total loss.

Verification before trust. Do not rely on a token symbol, interface screenshot or marketing statement. Verify the exact chain, contract address, source-code status, audit scope, vault assets, fee parameters, privileged roles and redemption path for the QINDEX version you intend to use.

Appendix A. Reference Contract Events

Names are illustrative. Actual interfaces are defined by verified deployed contracts and ABI documentation.

Appendix B. Fee Calculation Examples

The fee uses a 365-day convention. For a period of n days with variable AUM:

accrued fee = (0.05 / 365) × (AUM₁ + AUM₂ + … + AUMₙ)

Rounded values are illustrative. Contract accounting should use fixed-point arithmetic, explicit rounding rules and sufficient precision. Rounding should not systematically favor the fee recipient or users.

Appendix C. Glossary

Appendix D. Sources and References

QINV-specific product statements are based on current public QINV Onchain materials and internal planning documents. External references are included for technical standards and regulatory context. Access dates: July 23, 2026, unless otherwise stated.

1. QINV Onchain — product website. Current Base positioning, wallet flow, USDC minting, proportional redemption, weekly rebalancing and public fee description.
2. QINV Onchain — Terms of Service. Last updated June 25, 2026; QINDEX definitions, risk disclosures, legal entity and 5% annual management fee accrued daily.
3. QINV Onchain scope and Stellar integration planning. Internal QINV documents supplied for this whitepaper; architecture, mint/redeem, signed targets, NAV and Soroban roadmap.
4. EIP-20: ERC-20 Token Standard. Ethereum token interface standard.
5. Base documentation. Base as an EVM-compatible Layer 2 and network reference.
6. 0x Swap API documentation. DEX aggregation and smart-order routing; Base supported.
7. Uniswap v4 hooks documentation. Custom pool behavior at defined lifecycle points.
8. Chainlink Data Feeds documentation. Price feeds, timestamps, monitoring and developer responsibilities.
9. U.S. SEC — Transactions Involving Crypto Assets. Current U.S. federal securities-law context for crypto assets.
10. U.S. SEC — Application of Federal Securities Laws to Certain Types of Crypto Assets. 2026 interpretive guidance; facts-and-circumstances treatment.
11. Brazil CVM — Criptoativos: quando se aplicam as regras da CVM?. Brazilian securities-regulatory context for crypto assets.
12. ESMA — Warning on crypto-assets. EU consumer and investor risk context, including MiCA limitations.
13. Stellar developer documentation — Soroban token interface. Reference for a potential separate Stellar-native QINDEX share class.
14. Circle developer documentation — USDC contract addresses. Native USDC on Base Mainnet contract reference.