PORTAL Architecture

🔹 1. Ecosystem Architecture: Multiple MiniApps and a Unified Core

1.1. Philosophy of "One Core — Many Interfaces" The architecture of PORTAL POINT is initially designed as an ecosystem, not a single application. Its fundamental principle is the separation of the universal, immutable logic core (Portal Core) from specialized, adaptable user interfaces (Telegram MiniApps). This allows different projects, communities, and brands to create their own unique entry points for users, utilizing a common, proven infrastructure for tokenization and economy.

1.2. Interaction Diagram of Multiple MiniApps with Portal Core The following diagram illustrates how a multitude of independent applications interact with a single technological core through clear protocols.

┌────────────────────────────────────────────────────────────────────┐
│                  ECOSYSTEM: MULTIPLE MINIAPPS                      │
├────────────────────────────────────────────────────────────────────┤
│  ┌─────────────┐    ┌─────────────┐          ┌─────────────┐      │
│  │   MiniApp   │    │   MiniApp   │   ...    │   MiniApp   │      │
│  │    #1       │    │    #2       │          │    #N       │      │
│  │  (Project A)│    │ (Project B) │          │ (Project Z) │      │
│  └──────┬──────┘    └──────┬──────┘          └──────┬──────┘      │
│         │                  │                        │             │
│         └──────────────────┼────────────────────────┘             │
│                            │                                      │
│               All applications connect via a UNIFIED API          │
│                            │                                      │
│                    ┌───────▼───────┐                              │
│                    │   API GATEWAY  │                              │
│                    │  PORTAL POINT  │                              │
│                    │  (Orchestrator)│                              │
│                    └───────┬───────┘                              │
│                            │                                      │
└────────────────────────────┼──────────────────────────────────────┘
                             │
    ┌────────────────────────┼───────────────────────────────────────┐
    │         THREE FUNDAMENTAL LAYERS OF THE PORTAL PLATFORM        │
    ├─────────────────────────┬──────────────────┬───────────────────┤
    │                         │                  │                   │
    │  1. TELEGRAM + TON      │  2. STELLAR      │  3. POLYGON +     │
    │  ───────────────────────┼──────────────────┼────────────────   │
    │                         │                  │                   │
    │  • Many Interfaces      │  • One Logic Core│  • One Marketplace│
    │  • Isolated Payments    │  • Central       │  • Shared         │
    │    (Each app - its own  │    Registry      │    Liquidity     │
    │     frontend and TON    │  (Portal Core)   │  (Rarible)       │
    │     payment flows)      │                  │                   │
    │                         │                  │                   │
    │  ┌──────────────────┐  │  ┌────────────┐  │  ┌────────────┐  │
    │  │ >10 Independent  │  │  │  PORTAL    │  │  │  Rarible   │  │
    │  │ Telegram MiniApps├──┼──►  CORE      ├──┼──►  Protocol  │  │
    │  │ • App_A          │  │  │  Registry  │  │  │  (Polygon) │  │
    │  │ • App_B          │  │  │            │  │  │            │  │
    │  │ • App_C ...      │  │  └────────────┘  │  └────────────┘  │
    │  └──────────────────┘  │        ↓         │        ↓         │
    │        ↓               │  Source of Truth │    Trading &     │
    │  Payment & UI Layer    │  & Global State  │    Collecting    │
    └────────────────────────┴──────────────────┴───────────────────┘
                             │                  │                   │
                             └──────────────────┼───────────────────┘
                                                │
                                    ┌───────────▼───────────┐
                                    │       THE USER        │
                                    │   (Unified Account)   │
                                    │                       │
                                    │ • TON: Entry/         │
                                    │   Payments in any app │
                                    │ • Stellar: Unified    │
                                    │   Assets & Reputation │
                                    │ • Polygon: Unified    │
                                    │   NFT Portfolio       │
                                    └───────────────────────┘

1.3. Engineering Implementation: A Protocol, Not Just a Platform

1.3.1. Standardized API Gateway:

• All MiniApps interact with the ecosystem through a single, documented REST API/WebSocket gateway.

• This gateway handles application authentication, rate limiting, and routes requests to the Portal Core.

• A MiniApp receives only:

  • A session_token for signing user actions.

  • Access to read-only data (balances, world metadata) via cached APIs.

  • The ability to initiate pre-signed transactions for the user.

1.3.2. The Role of Portal Core as the "Source of Truth" (Single Source of Truth):

• The central registry on Stellar (Soroban) stores the global state:

  • Which PORTAL Worlds exist and who owns them.

  • Which Telegram MiniApps are registered and their app_id.

  • Which access models (Grabber Keys) are active for each world.

  • A unified cross-application user identifier, linking different Telegram accounts to a single Stellar wallet (G...).

• This prevents conflicts, double issuance of assets, and ensures data consistency across all applications.

🔹 Security and Isolation via Multi-Signature:

• Critical actions (registering a new world, issuing new asset types) require signatures from a quorum of Portal Point validators.

• Each MiniApp operates in a sandbox:

  • Has limits on request frequency and the volume of generated transactions.

  • Has no direct access to users' private keys or core contracts.

  • All financial flows pass through a single, auditable TON → XLM conversion gateway.

  🔹 Multi-Blockchain Synergy for Scalability:

• TON/Telegram: Handles UI peak loads (millions of users). Each new MiniApp scales horizontally leveraging Telegram's infrastructure.

• Stellar: Handles financial and logical integrity. High throughput (3000+ TPS) and low cost allow thousands of MiniApps to interact with the core simultaneously without overloads or high fees for users.

• Polygon: Ensures unlimited creative growth and liquidity. Regardless of which MiniApp an asset was created in, its collectible mirror enters the common liquid pool of the Ethereum ecosystem via Rarible.

🔹 Advantages of the Architecture for MiniApp Creators

• Zero Blockchain Complexity: Developers do not need to understand Soroban, Stellar, or smart contracts. They work with a familiar REST API.

• Instant Economy: Upon launch, an app already has a ready-made system of tokens (XLM, $PORTAL), NFTs, payments (TON), and a marketplace (Polygon/Rarible).

• Access to Cross-App Audience: A user who enters through one MiniApp, with their assets and reputation, can be identified in another (with their consent), opening opportunities for cross-promotion and cooperation.

• Focus on UX, Not Infrastructure: Teams can concentrate on the unique game mechanics, design, and narrative of their application, rather than building a blockchain backend.

🔹 Example of an Ecosystem Scenario

• The "Space Rangers" application (a gaming MiniApp) issues an NFT key for access to a unique quest.

• The "Galactic Museum" application (an educational MiniApp) detects this NFT on the user's Stellar account through the shared Portal Core Registry.

• The Museum automatically grants the key holder access to an exclusive 3D tour of the "Rangers" ship, using the same clawback mechanism for verification.

• The user lists the NFT key for sale on Rarible (via its mirror on Polygon), and royalties from the sale are automatically distributed between the creators of both applications according to the rules programmed in the smart contract of the "Cosmos" world.

🔹 2. Engineering Logic of the Ecosystem

Operating Principle:

1. Each MiniApp is an independent front-end project with its own design, narrative, and audience.

2. All MiniApps connect to the unified API Gateway Portal Point, which is the single entry point to the blockchain infrastructure.

3. The API Gateway provides security, limits, and translates requests to the Portal Core Registry on Stellar.

4. The Portal Core Registry acts as:

   • A unified rights registry (which partner owns which world)

   • A unified application registry (which MiniApps are legally connected)

   • A single source of truth about users, their assets, and reputation

2.1. Multi-Blockchain Synergy in the Ecosystem

┌─────────────────┬──────────────────────┬──────────────────────┬────────────────────────┐
│   COMPONENT     │      TON LAYER       │     STELLAR LAYER    │    POLYGON LAYER       │
├─────────────────┼──────────────────────┼──────────────────────┼────────────────────────┤
│ ROLE IN ECOSYSTEM│ MASS ENTRY          │ CORE & SECURITY      │ LIQUIDITY & GROWTH     │
│                 │ (User Acquisition)   │ (Core & Security)    │ (Liquidity & Growth)   │
├─────────────────┼──────────────────────┼──────────────────────┼────────────────────────┤
│ FOR MINIAPP     │ • UI/UX Freedom      │ • Ready-made Economy │ • Ready-made Marketplace│
│                 │ • TON Payments       │ • Secure Logic       │ • Access to Ethereum   │
│                 │ • Telegram           │ • User Data          │   Liquidity            │
│                 │   Infrastructure     │ • Access Mechanics   │                        │
├─────────────────┼──────────────────────┼──────────────────────┼────────────────────────┤
│ FOR USER        │ • Convenient Entry   │ • Unified Account    │ • Unified Market for   │
│                 │ • Familiar Payments  │ • All Assets in One  │   All NFTs from All    │
│                 │ • Different Interfaces│   Place              │   MiniApps             │
│                 │   for Different Content│ • Cross-Reputation  │ • Simple Trading       │
├─────────────────┼──────────────────────┼──────────────────────┼────────────────────────┤
│ SCALABILITY     │ Horizontal Scaling   │ 3000+ TPS,           │ EVM Ecosystem,         │
│                 │ Through              │ Predictable Fees     │ Low Gas Fees,          │
│                 │ Telegram Infrastructure│ (~0.000001 XLM)      │ Compatibility with     │
│                 │                      │                      │ Rarible, OpenSea       │
└─────────────────┴──────────────────────┴──────────────────────┴────────────────────────┘

2.2. Key Engineering Decisions

2.2.1. Isolation and Security:

• Each MiniApp operates in a sandbox with limited API quotas.

• Critical operations (world registration, issuing new asset types) require multi-signature from Portal Point validators.

• Financial flows of all MiniApps pass through a single, auditable TON → XLM gateway.

2.2.2. Unified User Account:

• A user registers a single binding: Telegram ID ↔ Stellar account (G...).

• This binding is stored in the Portal Core Registry and is accessible (with the user's permission) to all legitimate MiniApps.

• No matter in which MiniApp a user acquires an asset (Grabber Key, NFT), it lands on THEIR Stellar account and becomes visible in all connected applications.

2.2.3. Cross-App Interaction Mechanism:

USER in MINIAPP_A:
1. Acquires NFT "Key to the Ancient Temple"
2. NFT is saved to their Stellar account

MINIAPP_B (related archaeological game):
1. Requests user assets via the API Gateway
2. Detects the NFT "Key to the Ancient Temple"
3. Automatically grants access to hidden content
4. Uses the clawback mechanism to mark usage

2.3. Advantages of the Architecture

For MiniApp Creators:

• Zero Barrier to Entry into Web3: No need for in-house blockchain developers.

• Instant Readiness: Upon launch, payments (TON), economy (Stellar), and marketplace (Polygon) are already available.

• Access to a Shared Audience and Cross-Promotion with other projects in the ecosystem.

For Users:

• A Single Wallet for all projects in the ecosystem.

• Portability of Assets between different games and applications.

• Cumulative Reputation for activity in any MiniApp.

For the Portal Point Ecosystem:

• Network Effect: Each new MiniApp increases the value of the entire platform.

• Resilience: The failure of one application does not affect the operation of others.

• Standardization: All projects develop within a single technological paradigm.

This architecture turns Portal Point from a platform into a protocol—an open standard for creating interconnected digital economies, where interface diversity is combined with the unity of the basic infrastructure and rules of the game.