INCEPTION

1The problem

1.1. Intermediaries and control

Receiving money, transferring, converting, paying, investing and withdrawing it usually requires several platforms. Each has its own model of identity, execution and risk, and the user has to manage the transitions between them. At every step the money is controlled by an intermediary rather than its owner: a balance on a payment service is that service's liability.

1.2. Infrastructure dependence

Even a non-custodial wallet may depend on a single backend, RPC endpoint or domain. A card product may depend on a single issuer. Conversations about money run through centralized platforms, and access to the service through a single network provider. Owning an asset and being able to use it right now are two different properties.

1.3. The competence barrier

DeFi opens access to trading, lending and liquidity, but it requires an understanding of oracles, liquidations, smart contracts and their risks. Open access is not the same as simplicity.

1.4. Capital in public

Public blockchains reveal addresses, balances and transaction history. A counterparty, an employer or a passing observer can see the size of someone's capital and the links between their accounts. This is not an abstract question of data leakage — it is a question of personal safety.

2INCEPTION — two products, one ecosystem

The answer separates ownership, network connectivity, fiat integrations, analytics and execution into independent circuits joined by a single interface. What the user sees, however, is two products rather than a list of technologies.

INCPT Chat — Your Safe Harbor. A personal, protected financial environment: the dialogue as the main screen, an embedded non-custodial wallet, reporting and private messaging (chapter 3).

INCPT Exchange — Your Open Ocean. Access to open markets: spot, derivatives, liquidity, transparent execution and on-chain settlement (chapter 4).

Which is a product and which is a component. The wallet, the AI dialogue and the messenger are capabilities of INCPT Chat, not standalone products: the ecosystem is entered through one of the two flagships. INCEPTION AI Core, the DeFi Protocol, the Privacy Layer, the security circuit and the network are technological components shared by both products.

Shared components: the user's keys and digital identity (chapter 9), INCEPTION AI Core (chapter 6), the Privacy Layer (chapter 10), private communication (chapter 11) and the resilient network (chapters 12–14). The end-to-end scenario — from a question in the dialogue to execution and a report — is described in chapter 6.

The design of the system follows from its principles: what is protected, what must never be traded for convenience, and who makes the decision. The user's control over permissions does not remove the risks of smart contracts and external counterparties. Bringing services together in one interface does not place funds under INCEPTION's single control: the user interacts with Chat and the wallet, while everything else is distributed across independent layers.

3INCPT Chat — Your Safe Harbor

INCPT Chat is a personal financial environment in which money is managed in conversation rather than by walking through tabs. This chapter describes the product; the technologies it relies on are set out in parts III and IV.

AI-First Conversational Interface. The dialogue is the main screen, not an extra tab. The user asks about their money in ordinary words: "What is my balance", "How much did I earn this month", "Show my deposits and withdrawals", "Analyse my portfolio", "How much came in from referrals", "Compare the options in DeFi", "Prepare a transfer". The first of these are enquiries, the last one prepares an operation, and the interface makes the difference visible (chapter 6). The familiar screens — accounts, history, cards, staking — stay where they are: the dialogue replaces not them, but the need to hunt for a number across sections.

Personal Financial Dashboard. The dashboard brings together, in one place, the portfolio by network and instrument, accruals and payouts, transaction history, card status and any active withdrawal restrictions. Reports are shown inside the dialogue — as cards, tables and charts, not as a separate section the user has to navigate to.

Portfolio & Wealth Management. The user sees how capital is distributed across assets, networks and strategies, the concentration and the share held in any single protocol. Analysis and preparation of operations are performed by AI Core (chapter 6): the dialogue itself signs nothing.

Deposits, Earnings & Transaction Reporting. Reporting uses one vocabulary of figures, and it is the same throughout this document: the wallet balance, the value of DeFi positions, accrued income, realized income, available liquidity and withdrawals in progress. A balance on the user's own address and a share in a Vault are different figures and are shown separately (chapter 7). The user chooses the period — a day, a month, an arbitrary interval; data is exported in a machine-readable format for their own bookkeeping. The export is informational: the tax treatment of operations is determined by the law of the user's jurisdiction. Returns are shown separately by source — staking, strategies, trading, card rewards, referral earnings — and without smoothing over loss-making periods.

Where the numbers come from. Every figure in a reply comes from authorized interfaces of the wallet and connected providers. The model phrases the answer but does not invent the data: if a figure is unavailable, it says so directly.

Agent Workspace & Referral Analytics. Some users come into the ecosystem through an agent — an adviser, a partner or a service representative. The agent workspace describes that path explicitly, instead of passing around someone else's passwords and screenshots. The agent sees only the data the client has permitted and works within the rights granted: prepare an operation, explain the terms, assemble a report. Signing stays with the client, the agent never receives keys or the seed phrase, every action is written to a log the client can read, and the granted rights are revoked in a single step. Compensation and analytics on referred clients are defined by a separate partner programme; the legal status of advisory work depends on the jurisdiction, and the workspace does not turn an agent into a licensed adviser.

Integrated Self-Custody Wallet. The wallet is built into the same environment: a local 12-word seed phrase, multichain support, basic DeFi functions; the list of assets and networks is extended weekly. The coverage target is the technically compatible assets among the CoinMarketCap top 100. Support for a token does not mean support for every network it circulates on. Keys, signing and recovery are described in chapter 9.

Private Messaging Interface. Messages, payment requests and transfers inside the dialogue live in the same application and use separate communication keys. How the channels work, and how a dialogue with AI differs from a conversation between people, is in chapter 11.

Protection and connectivity inside the product. The same environment includes financial privacy (chapter 10), a secure connection with Smart, Private and Mesh modes (chapter 13) and connectivity without the internet — Bluetooth and offline transaction signing (chapter 14). The user receives these as settings of the application, not as separate services.

User Profile & Security Settings. The profile gathers devices and sessions, permissions for AI and agents, privacy settings and the recovery procedure. The mechanics are in chapters 9 and 15.

4INCPT Exchange — Your Open Ocean

INCPT Exchange is a separate high-performance non-custodial trading infrastructure. The benchmark is a professional trading environment: spot and perpetual markets, transparent execution, a trading core connected to smart contracts, a usable terminal and a non-custodial matching and settlement architecture. This is a description of requirements, not a claim of a proprietary L1 or of performance already achieved.

Spot and derivatives. The architecture provides for spot, perpetual contracts, cross-chain exchange, collateral, liquidations and oracles; the risk circuits rely on the Risk Engine (chapter 6).

Liquidity and execution. Access to liquidity is provided by independent sources and routes. Collateral custody and settlement are on-chain; matching and part of the risk checks may run off-chain. That split is stated plainly: finality comes from the blockchain, speed from the trading core, and each layer has its own trust model.

Non-custodial trading. Funds remain under the user's keys until the moment a contract receives collateral under rules disclosed in advance.

Market transparency. The order book, the order of execution, fees and liquidation parameters are disclosed in the terminal and in the documentation.

Connection with INCPT Chat. An operation can be prepared in the dialogue and executed on the exchange: the mandate and risk limits apply identically in both products.

The strategic specialization is primary and secondary markets for real-world assets (chapter 8). Trading in regulated instruments requires separate legal infrastructure (chapter 18).

5Fiat, payments and cards

The aim is a seamless path fiat → digital asset → DeFi/trading/payment → fiat. Each step of that path is served by independent providers. The router takes into account currency, country, rate, fee, timing, limits and compliance requirements. The user sees the terms before confirming. A fiat balance is a provider's liability, not a self-custody on-chain asset.

On-ramp and off-ramp. Funding and withdrawal run through independent integrations: the user picks a route by its terms, not because it is the only one available.

Cards and payments. The payment layer brings together virtual and physical cards, compatible mobile payments, transfers, QR payments and merchant integrations.

Multi-currency accounts. Local account details and accounts in several currencies are part of the target model. Actual availability of SEPA, SWIFT, ACH, FPS and other payment rails depends on the provider and the jurisdiction, which is why the list of supported currencies and countries is published by a product specification rather than by this document.

Several independent partners reduce dependence on a single issuer, but they do not guarantee an automatic transfer of balances or a way around regulatory restrictions; how diversification is built and what it does not cover is in chapter 15.

6INCEPTION AI Core

INCEPTION AI Core is the core of the ecosystem: it answers questions about money, evaluates strategies and risk, prepares operations and carries permitted decisions through to execution. Individual trading algorithms are its inputs, not a product in their own right; the economics are described in chapter 16.

Engines and orchestration. The Core consists of independent engines, each with its own area of responsibility. A separate module, RWA Analysis, evaluates real-world asset instruments. The generative Chat is an interface — not a custodian of funds and not the sole arbiter of risk.

Four modes of operation. An informational request changes nothing in the account. A recommendation does not execute itself. Preparing an operation builds the transaction and shows its parameters. Execution requires the user's confirmation or a permission granted in advance with technical limits. The modes do not blur into one another: moving to the next one is visible in the interface.

The mandate. The user states a goal in natural language, for example: "Allocate part of the funds at moderate risk, keep a liquidity reserve and warn me if limits are breached." The system clarifies the horizon, acceptable losses, assets and constraints, offers strategy options, explains the risks and produces an investment mandate. The mandate defines permitted protocols, maximum position, leverage, liquidity, timeframes and stop conditions.

The limits of authority. The AI never receives the seed phrase and cannot override the Risk Engine. Delegated execution is the target architecture: authority is limited by time, assets, amount and operation types, revoked in a single step and written to a log. Continuous monitoring warns the user and performs only those changes the user has permitted.

Data. The Core works with authorized interfaces of the wallet, providers and protocols; the volume of data transmitted is minimized (chapter 10). The limits of the analytics and the legal status of its answers are described in chapter 18. Returns are not guaranteed.

7INCPT DeFi Protocol and Vaults

The target model includes smart-contract Vaults, on-chain accounting of shares, NAV, risk limits, a liquidity reserve and DEX-only execution. The user transfers assets into a Vault under the rules of the contract and receives shares; this differs from holding funds at a personal address.

The Vault line-up. The three Vaults differ in how funds can be accessed, not in a promised return.

• Vault A — liquid. Both the principal and the accumulated result can be withdrawn at any time, within the liquidity reserve and the rules of the contract.
• Vault B — principal locked, income free. The invested amount is locked for a term, while the accrued result is withdrawn as it accumulates.
• Vault C — full lock-up. The entire invested amount is locked for the whole term: until it ends, neither the principal nor the result is withdrawn.

The access regime determines which strategies are permissible: the longer funds are locked, the less liquid the positions a Vault can hold without putting withdrawals at risk. That is where the difference in expected result comes from — expected being the operative word: none of the regimes carries a guarantee. Lock-up periods, the size of the reserve, fees and early-exit terms are published in each Vault's specification before launch.

Accounting. In simplified form, NAV = Assets − Liabilities and Share Price = NAV / Shares Outstanding. The calculation accounts for fees, liabilities, illiquid positions and the quality of oracles.

Strategies and liquidity. The AI proposes an allocation (chapter 6), while contracts and the Risk Engine constrain execution. The liquidity reserve and the rules and timing of withdrawals are disclosed in advance. The composition and result of strategies are tracked continuously, and the report comes back to the user in the dialogue (chapter 3).

Risks. The protocol discloses administrative powers, pauses, withdrawal rules, bridge and smart-contract risks. DEX-only does not remove the risks of sequencers, operators and oracles. Control of one's own keys does not remove them either: by moving assets into a Vault or opening a position in a third-party protocol, the user knowingly accepts the risk of code, liquidity and counterparty — self-custody protects against an operator seizing funds, not against a defect in a contract. An audit is not a guarantee of security; the consolidated threat model is in chapter 15.

8RWA and tokenized assets

Specializing in real-world assets requires its own range of instruments. INCPT Bonds is a concept for tokenized debt obligations, INCPT Equity a concept for instruments of participation in capital.

Issuance and circulation. The lifecycle: issuer due diligence, legal structuring, disclosure of terms, issuance, primary placement, servicing of payments and corporate actions, permitted secondary trading, settlement and redemption.

Rights and redemption. The record of ownership is kept on-chain, but the order of payments, corporate actions and redemption is determined by the issue documents. A token does not create a legal right to a share or a bond without a valid legal construction.

Requirements. The risks of default, illiquidity and enforcement remain. Regulated participants and permissions are required where the law demands them (chapter 18). Real-world assets are not mixed either with spot trading (chapter 4) or with Vault strategies (chapter 7): they are a separate class of instrument with a legal model of its own.

9Self-custody and digital identity

INCPT Wallet generates keys and signs transactions locally. The existing model includes a 12-word seed phrase. INCEPTION's servers never receive private keys: standard on-chain operations are signed on the device.

Device-level protection. Entry to the application is closed by biometrics or a passcode, and cryptographic operations require a separate confirmation. The user can see the list of active devices and sessions and revoke any of them; session lifetime is limited. A compromised device remains a risk — neither biometrics nor session limits replace checking a transaction before signing it.

Several devices. Access from several devices is built on explicit enrolment: a new device receives rights after confirmation from an already trusted one, and the full list is visible to the user.

Recovery of access. Recovery is split into four independent circuits, and they must not be conflated.

• The wallet. Restored from the seed phrase on a new device. The seed phrase is not stored on servers and is not restored through support — there is no way around the keys by design, not by policy.
• Messaging identity. Messaging keys are not derived from the seed phrase, so they are restored separately: either from the user's own backup of the key or by confirmation from a trusted device.
• Message history. End-to-end encrypted messages do not sit on a server in readable form, so history moves across only where there is an encrypted backup or protected synchronization between the user's devices. Without one, the conversation starts from scratch on the new device — automatic recovery of history is not promised.
• Permissions for AI and agents. They are granted again after a move: no delegated authority survives a change of device silently.

The separation is deliberate: compromising one set of keys does not expose the others.

Cryptographic identity. Identity in the ecosystem is a key, not a phone number or an email address. Financial keys are separated from communication keys. Delegated authority, including limits on term and operation type, is described in chapter 6; it is available where the network supports it.

NFC Hardware Signing. The target integration allows transactions to be signed with a hardware NFC card: the application prepares the request, a secure element holds the key and returns the signature. Support for backup cards depends on the implementation. NFC by itself guarantees no protection against a substituted address or amount, blind signing or a compromised device.

Readiness for post-quantum cryptography. The architecture provides for cryptographic agility, an inventory of algorithms, hybrid communication schemes with ML-KEM, an assessment of ML-DSA signatures (NIST post-quantum standards: https://csrc.nist.gov/projects/post-quantum-cryptography), verifiable updates and key migration. Post-quantum protection of the application does not make blockchains built on ECDSA or Ed25519 quantum-resistant: the safety of on-chain assets also depends on how those networks evolve.

10INCPT Financial Privacy Layer

Your Wealth Shouldn't Be Public Information. A public blockchain reveals addresses, balances and transaction history: one known address is enough to reconstruct the size of a fortune, its sources of income and the links between accounts. The consequences are concrete — financial profiling, targeted phishing, fraud and extortion against those whose capital has become visible. The task of the Privacy Layer is to remove unnecessary disclosure, not to hide a breach of the law: Privacy for Personal Security, Not Financial Secrecy. Regulated services keep their AML, KYC and sanctions obligations.

Four planes. Privacy breaks down into four independent tasks, and solving one does not close the others. On-chain — what is visible in the network itself: addresses, amounts, links (this chapter). Network — what is visible to the connectivity provider: the node address, the timing and the fact of a request (chapter 13). Communication — what is visible in a conversation, and to whom (chapter 11). Device — what is available to whoever is holding the phone (chapter 9). A tunnel does not hide the blockchain, and fresh addresses do not protect a device.

The proxy wallet. An intermediate address separates an operation from the main holdings, but by itself it does not provide anonymity.

Zero-Knowledge. Zero-knowledge proofs are being considered for confirming rights and limits without revealing amounts — proving that a balance is sufficient, for instance, without naming it. This is an architectural goal: in supporting networks it relies on their own mechanisms, and INCEPTION has no implementation of its own.

Selective disclosure. The user must be able to prove what is needed — a balance, the origin of funds, the right to an operation — without revealing the whole history. Disclosure is initiated by the owner: for an audit, for a bank, or to satisfy applicable legal requirements. Absolute anonymity is not promised.

11INCPT Private Communication

Messaging between users is a separate circuit with keys of its own. Cryptographic identity requires no phone number or email address, end-to-end encryption applies from the first message, and communication keys are separated from financial ones and are not derived from the seed phrase.

Our own exchange, not somebody else's transport. The messenger is built as a standalone P2P exchange inside the application: identity and encryption belong to the wallet, not to an external platform. Correspondents find each other through distributed discovery, without a central directory of users. The scheme is not new — existing P2P messengers already run on a combination of distributed discovery and relays — but their capabilities do not transfer to INCEPTION automatically: every element requires its own implementation and verification.

Three delivery paths. A direct P2P connection where it is technically possible. An encrypted relay where a direct connection is unavailable — NAT, a mobile network — or the recipient is offline. A local channel over Bluetooth, and with several participants, relaying along a chain. The first two paths run through the ecosystem's internal network — Mesh Mode (chapter 13) — while the third works with no internet at all. Encryption is end-to-end on every path: relays and intermediate devices carry the data without reading it.

Capabilities. Private groups, protected file transfer, device synchronization, payment requests and transfers inside a conversation with separate authorization. Group keys, device changes, contact authentication and metadata protection are described in separate specifications. Full metadata protection is not promised: the fact and timing of a connection remain visible to anyone observing the network.

AI Chat and Private Chat are different things. A conversation between users is protected by end-to-end encryption. A dialogue with the AI is not: the request is processed by computing infrastructure. That is why the volume of data transmitted is minimized (chapter 10) and private conversations are never passed to the model. The distinction is shown in the interface, not only in the documentation.

The limits of the local channel are plain: distance, speed, battery drain and dependence on how many participants are nearby; how direct connectivity differs from relaying along a chain is set out in chapter 14. Absolute anonymity is not promised.

12INCPT Resilient Network

The network consists of three circuits: independent infrastructure — this chapter — a secure connection (chapter 13) and connectivity without the internet (chapter 14). The shared principle is one: No Single Point of Failure. No Single Point of Dependency.

The test of independence: with INCEPTION's servers switched off, a user holding the keys and a trusted client must still be able to sign a standard on-chain transaction and send it through an alternative RPC endpoint. This does not mean that cards, fiat accounts and every external service remain available.

Distributed infrastructure. The server side is distributed geographically: several regions, independent hosting providers, relay nodes, automatic failover and availability monitoring. Distribution is not the same as decentralization: while the nodes belong to a single operator they reduce the probability of downtime but do not change the trust model. Decentralization begins where the user is able to work through somebody else's infrastructure or their own — which is exactly what the test of independence checks.

Connecting to networks. For blockchains, the design provides independent RPC endpoints, user-run nodes, checks for divergence between responses and fallback channels for distributing signed applications. A P2P stack is being researched, with a distributed routing table, verifiable replicated logs, file transfer and shared records. This is neither "servers on a blockchain" nor a replacement for blockchain consensus: bootstrap, NAT traversal, relays and temporary storage of encrypted data may remain necessary.

Measurable decentralization. The properties that can be checked rather than asserted:

13Secure connection: modes, proxy and VPN

A connectivity provider can see the node address, the timing of requests and the very fact that a financial service is being contacted — even when the contents of the request are encrypted. The built-in tunnel closes that layer and works in three modes, which differ not in speed but in who is able to learn what about a connection.

Smart Mode — everyday internet. A single encrypted tunnel, automatic exit selection, redundant nodes and minimal latency. The default mode: browsing, video, ordinary applications.

Private Mode — stronger privacy. Two or more independent nodes with knowledge split between them: the first knows the source but not the destination, the last the destination but not the source. For financial applications and sensitive connections; the price is latency. Absolute anonymity is not promised: a connection is still observable at its ends.

Mesh Mode — the internal INCPT network. Requests travel through the ecosystem's own nodes: direct P2P connections where they are possible, and an encrypted relay where a direct connection is not available. For the messenger and for access to distributed INCPT services. This is not local Bluetooth transfer: Mesh Mode requires the internet, and connectivity without it is described in chapter 14.

The third mode matters for more than convenience: it gradually moves requests to ecosystem services off a single cloud provider, a single address and a single central server onto many nodes. While those nodes are few, the caveat from chapter 12 applies: the probability of downtime falls, the trust model does not change.

Our own proxies and gateways. An entry point of our own solves what distributing servers does not: the application does not contact internal services directly, a request does not reveal to a network observer which service it is addressed to, and changing a route does not require updating the client. Redundancy and failover are described in chapter 12 — the proxy adds privacy of access and control over the entry point.

VPN in the application. Switched on in the profile with a single toggle, raised automatically on connecting to an untrusted Wi-Fi network, with a choice of exit region or the route left to the system. The transport is WireGuard or a modern equivalent; the specific protocol is fixed by a specification, not by this document.

Proxy, VPN and end-to-end encryption are different things. A proxy hides which service the application is contacting and substitutes the entry point. A VPN protects the traffic of the whole device as far as the exit node. End-to-end encryption protects the contents of a message along the entire path, whatever the route. The first two decide who can see a connection, the third who can read what is inside it. None of the three makes an already published on-chain transaction private.

Scope is configured separately from the mode: wallet requests only, all device traffic, or selected services. The choice of exit node affects both the availability of providers and the applicable law. Whether such a connection is permitted in a particular country is determined by that country's law, not by a setting in the application.

14Connectivity and transactions without the internet

Connectivity drops more often than is usually accounted for: roaming, an operator outage, no coverage, an overloaded network at a crowded event. This chapter is about what remains available when there is no internet, and where the limit of the possible runs.

Bluetooth Direct and mesh relaying are not the same thing. A direct Bluetooth connection joins two devices that are near each other, with no internet and no intermediaries. Mesh relaying delivers an encrypted message through intermediate devices that do not read it — and it is precisely that which remains an architectural goal rather than a finished feature: mobile operating systems restrict background radio work, range is measured in tens of metres, battery drain is noticeable, and routing through a network of unfamiliar devices is an unsolved problem in its own right. Direct connectivity works with two devices; a chain requires that participants happen to be nearby.

Offline signing. A transaction can be built and signed with no connection: the key is on the device, and signing requires no network. All that is needed is delivery of the signed document to any node of the blockchain.

Alternative delivery. The methods differ in convenience, not in substance: Bluetooth and relaying along a chain, a QR code between two devices, NFC, a file transfer, an intermediary device; and as an architectural goal, delivery through a gateway over SMS, GSM or USSD.

What a gateway cannot do, and what it can. A gateway never receives private keys and cannot alter signed fields: editing the amount, the address or the parameters breaks the signature, and the network rejects such a transaction. It can, however, delay the transfer, lose it or refuse to broadcast it. Hence several independent gateways, verification of the transaction hash before and after transfer, broadcast status tracking, retries and a check that the parameters are valid for the specific network. The known services that give access to a network over USSD are custodial: the key belongs to the service, and the user entrusts funds to it. The target model is the opposite — the key stays with the user, and the gateway performs the broadcast and nothing else.

Until a transaction reaches the network, it has not been executed: the risks of stale parameters, a change in price and the limited validity of certain fields remain. Final confirmation comes only from the blockchain network that processed the transaction. Checking a balance, current valuations and the intelligent functions also require a connection. Resilience means that a break in connectivity stops being a loss of control — not that the network becomes optional; absolute availability is not promised.

15Security and risk architecture

The threat model covers lost keys, interface spoofing, malicious updates, compromise of RPC endpoints, oracles, bridges, smart contracts and administrative keys, abuse of permissions granted to the AI, attacks on infrastructure, market volatility, liquidations, illiquidity and provider failure.

Controls. Least privilege, multisignature and time delays for critical updates where applicable, verifiable client builds, monitoring and disclosure of the limits of recovery. Independent audits. No smart-contract audits have been completed: an audit precedes the launch of protocol features, and the publication of reports will be a separate event.

Incident response. The design provides for an emergency pause of protocol operations, revocation of delegated authority, forced termination of sessions, and disclosure of an incident naming the components affected and the boundaries of the damage.

Residual risks. Diversification reduces concentration but does not rule out correlated failures, and the failure of one provider does not mean an automatic transfer of funds to another. Privacy is bounded by the public nature of the blockchain (chapter 10), resilience by the need for a connection to settle (chapter 14), delegation by the quality of the limits the user sets (chapter 6). No measure guarantees the absence of losses.

16Business model and ecosystem economics

The economic model rests on technology services and infrastructure fees: access to trading instruments, routing and exchange, protocol functionality, premium software capabilities and integrations with independent payment providers.

Current and potential sources. Today revenue comes from wallet, exchange and payment-integration fees. Potential sources include exchange fees, DeFi protocol fees, paid AI services and subscriptions to premium capabilities. Specific fees depend on the product, the network, the counterparty and the law; revenue forecasts are not presented in this document.

Costs and sustainability. Economic sustainability requires transparent accounting of operating costs, liquidity, security and audit expenses. The user's income and the company's income are different figures: the result of a strategy, protocol fees and the operator's revenue are accounted for separately.

17The INCPT token and governance

INCPT is considered a potential utility component of the ecosystem: payment of certain fees, access to premium features, service privileges and possible governance mechanisms. The planned maximum supply is 100 million INCPT; that parameter is consistent with the documents of the current round. The precise rights, the issuing network, distribution, vesting, circulation and applicable restrictions are subject to separate confirmation: they are published in the token specification, and the terms of placement in the round documents. Holding the token does not in itself mean a share in the company, dividends, a guaranteed buy-back or growth in value. Tokenomics and sale terms are published in a separate current specification aligned with the legal documents.

Governance. Governance distinguishes between product decisions, smart-contract upgrades, Vault parameters, strategy admission, risk limits and possible voting by token holders. Critical powers require transparent roles, limits, a change log and an emergency response procedure.

The path to decentralization. Decentralization of governance is a gradual and measurable process, not a property that appears from the mere existence of a token: the scope of authority handed to holders widens as contracts and procedures become ready for it.

18Legal boundaries and risk disclosure

INCEPTION develops non-custodial software and infrastructure for access to DeFi. However, the absence of access to seed phrases does not automatically determine the legal status of exchange, order routing, portfolio management, a trading venue, payment services or tokenized securities. Each component is assessed by its actual functions and the applicable law; whether a licence is required is determined by legal analysis in each jurisdiction, not by the architecture of the product.

Third-party services. Payment and banking partners have their own terms and identification procedures. A fully decentralized protocol, an interface to it and a regulated financial service are not the same thing.

Privacy and compliance. Privacy technologies are applied within the law and are not intended to circumvent AML, KYC or sanctions requirements.

The limits of AI. The analytics rely on models and external data, both of which can be wrong. A reply from the system is not personal investment advice, and the decision about money is the user's.

The user's responsibility. Keeping the seed phrase safe, checking transaction parameters before signing, choosing limits for delegated authority and complying with the requirements of one's own jurisdiction remain with the user.

Territorial restrictions. Certain features may be unavailable in a number of jurisdictions.

The risks include loss of capital, errors in code, hacks, liquidations, defaults, absence of liquidity, network outages, provider restrictions and changes in the legal regime. There are no guarantees of return. This document is informational and is not an offer of securities or personal investment advice.

19Roadmap

The document describes the target architecture of the next 6–12 months, so the roadmap speaks of directions rather than a list of releases. No timelines are approved by this document.

What works today. A non-custodial wallet with a local seed phrase, multichain support with the list of assets and networks extended weekly, basic DeFi functions, and cards and payments through independent providers. Everything else in this chapter is a direction of development, and the document does not present it as a working feature.

1. AI-Powered Financial Experience. The dialogue as the primary interface: answers about balances, income and operations drawn from authorized sources, the personal dashboard and reporting, and preparation of operations with the user's confirmation.

2. Self-Custody & Financial Privacy. Keys on the device, hardware signing, separation of identities and addresses, metadata protection, selective disclosure at the owner's decision.

3. Decentralized Trading & DeFi. Vaults with share accounting and NAV, DEX-only execution, spot and derivatives on INCPT Exchange, issuance and circulation of tokenized real-world assets.

4. Private P2P Communication. A proprietary P2P exchange with cryptographic identity, distributed discovery of correspondents, an encrypted relay, private groups and file transfer.

5. Resilient Network & Offline Connectivity. Distributed infrastructure and gateways, a secure connection, Bluetooth connectivity, mesh relaying and offline transactions.

6. Advanced AI Wealth Management. Delegated execution within a mandate, continuous risk control, allocation of capital across strategies, portfolio analytics over a long horizon.

The directions depend on one another: private communication and the resilient network use the same P2P foundation, and delegated execution uses the risk circuits of the third direction. The hardest parts — a full mesh network and confidential transfers in supporting networks — remain architectural goals: a design reference, not a promised capability.

Publishing an architectural whitepaper does not mean every direction described has been implemented. The availability of specific capabilities — supported networks and assets, hardware signing, smart contracts, fiat services and token parameters — is described in separate product specifications that state the current status and date. Changes to the architecture are issued as new versions of this document; changes to parameters go into the changelog of the specifications.

20Long-term vision

Money and the conversation about money belong to the same person — the one who holds the keys. INCEPTION brings together two lines: Self-Custody Finance, capital under one's own keys, and Self-Sovereign Communication, connectivity that does not depend on somebody else's platform.

INCPT Chat — Intelligence, Privacy & Control. INCPT Exchange — Markets, Liquidity & Execution.

The document describes an architecture, not a promise: part of what is described works today, part is being designed, part remains an architectural goal — the directions are collected in chapter 19. What does not change: the keys stay with the user, a human makes the decision about money, and the limits are named in the same place as the capabilities.

INCEPTION — Your Private Financial World. Your Gateway to Open Markets.

AGlossary

Self-custody: the user controls the keys required to manage assets in their own wallet. Vault: a smart-contract mechanism for placing assets and accounting for shares. DEX: a trading protocol with defined on-chain or hybrid mechanisms of execution and settlement; the degree of decentralization requires verification. NAV: the value of assets less liabilities. RPC: the interface through which a client connects to a network node. P2P: direct or relayed interaction between equal nodes. RWA: a digital representation of rights related to real-world assets. Investment mandate: the set of permitted operations and risk limits defined by the user. Stealth address: a single-use receiving address derived from the recipient's public data in supporting networks. Zero-Knowledge: a proof of a statement that reveals none of the underlying data. Mesh Mode: a connection mode in which requests travel through ecosystem nodes, over direct P2P connections or an encrypted relay. Mesh network: transfer of data between devices along a chain, without a connectivity operator and without the internet. Relay: an intermediate node that passes encrypted data between participants who cannot connect directly. Offline signing: building a signed transaction with no network connection, for delivery to the network afterwards.