Technical architecture · Version 1.0

BWB × Stellar
Technical Architecture

A controlled extension of BWB's operating real estate investment platform: embedded Stellar accounts, regulated Soroban offerings, BRL access, distribution attribution, and a separately governed yield and lending experience.

Network: Stellar testnet → mainnet Implementation: 1 Sep 2026 → 19 Jan 2027

1 Scope and architectural intent

BWB already operates a regulated investment and distribution platform on Base. The existing product coordinates investors, issuers, distributors, eligibility, offering lifecycles, investments, ownership records, and commission reconciliation. This program adds Stellar as a first-class execution and settlement rail without replacing the operating platform or weakening its compliance boundaries.

The design reuses BWB's provider-independent domain layer and introduces a Stellar adapter set for Privy, Abroad, Soroban, DeFindex, and Blend v2. Personal data remains off-chain. Investor authorization remains explicit. Every external transition is recorded, reconciled, and recoverable.

Extend, do not fork

Stellar enters the existing account, offering, distribution, and reconciliation domains through capability adapters.

Compliance before execution

Identity, product eligibility, allocation limits, disclosures, and authorization form sequential gates.

Minimal on-chain data

Contracts receive wallet states and business identifiers—not identity files, personal data, or private documents.

Evidence by design

Events, callbacks, state transitions, and reconciliation records create a reproducible operational trail.

2 Target system architecture

The application remains the system of orchestration. Stellar becomes a verifiable execution layer for eligible products, while specialist providers stay behind narrow integration boundaries.

Target BWB and Stellar system architecture A layered diagram showing user experiences, BWB orchestration, the Stellar integration layer, Stellar network components, and ecosystem integrations. EXPERIENCE LAYER — EXISTING BWB APPLICATION Investor workspaceOnboarding · portfolio · investments Issuer workspaceOfferings · allocation · reporting Distribution workspaceAttribution · offices · commissions Operations & complianceApprovals · monitoring · reconciliation authenticated commands · policy-aware views BWB ORCHESTRATION & DOMAIN LAYER — EXISTING, EXTENDED FOR STELLAR Identity & eligibilityKYC/KYB statesInvestor qualificationProduct access policy Offering lifecycleRules · limits · cooling-offPause · cancel · refundState transition history Investment pipelineSequential gatesAuthorization · submissionTerminal-state verification Distribution ledgerDeterministic attributionVersioned commission rulesReversals & evidence Operational controlQueues · idempotencyReconciliation · alertsAudit evidence provider-independent capability interfaces STELLAR ADAPTER LAYER — NEW Account adapterPrivy Stellar wallet Contract adapterSoroban offering controls Event adapterIndex · normalize · reconcile Identity & ramp adapterAbroad states & callbacks DeFi product adaptersDeFindex · Blend v2 STELLAR NETWORK — NEW EXECUTION RAIL Investor accountsAssets · signed authorization Soroban offering contractsEligibility · limits · lifecycle Events & settlementVerifiable terminal states STELLAR ECOSYSTEM SERVICES AbroadKYC · BRL DeFindexVault layer Blend v2Lending
Operating BWB capability New Stellar component Integrated ecosystem service
Fig. 1 — Target architecture. Stellar is introduced through adapters; BWB's regulatory workflow, distribution logic, and evidence model remain the orchestration plane.

3 Existing foundation and Stellar extension

The implementation starts from an operating product, not a greenfield prototype. Existing capabilities are preserved and extended through the same domain contracts used by the Base deployment.

Operating today · Base

Regulated investment platform

  • Investor, issuer, distributor, and operations workspaces.
  • KYC/KYB states, investor qualification, and allowlist controls.
  • Sequential investment gates and explicit authorization.
  • Offering lifecycle, cooling-off, cancellation, and refund logic.
  • Attribution, commission reconciliation, and ownership records.
  • Event-driven processing, retry queues, and idempotent webhooks.
Delivered by this program · Stellar

Stellar-native execution rail

  • Embedded Stellar wallets and user-authorized transactions through Privy.
  • Soroban contracts for eligibility, allocation, lifecycle, and refunds.
  • Stellar event indexing linked to investment and commission ledgers.
  • Abroad KYC/KYB and BRL funding states mapped to eligibility.
  • DeFindex vault and Blend v2 lending experiences in a separate product area.
  • STRIDE threat model, on-chain monitoring, and production evidence.
§
Compatibility invariant

A network-specific adapter may change how a transaction is built, signed, submitted, and observed. It may not bypass BWB eligibility, authorization, lifecycle, attribution, reconciliation, or audit rules.

4 Regulated investment transaction flow

The transaction path separates off-chain compliance decisions from on-chain enforcement. A Stellar submission is created only after every required gate passes.

Regulated Stellar investment sequence Sequence diagram from investor through BWB, Abroad, Privy, Soroban, and BWB reconciliation. Investor BWB platform Abroad Privy wallet Soroban BWB ledgers 1Authenticate and select offering 2Request KYC/KYB or current state Verified state · ramp status Sequential eligibility gatesidentity → qualification → offering state→ disclosure → allocation → amount rules 3Prepared investment intent 4Transaction envelope for explicit authorization Review and sign 5User-authorized Stellar transaction Enforce + emitrules · state · events 6Index and reconcile
Fig. 2 — Investment sequence. Rejected or expired gates stop before transaction construction. Network success is accepted only after the corresponding terminal state is independently observed and reconciled.

5 Two product rails, one control plane

Regulated real estate offerings and optional DeFi products share account, identity, authorization, monitoring, and evidence infrastructure. They do not share product economics, balances, disclosures, or performance reporting.

Separation between regulated offerings and optional DeFi products A shared control plane branches into a regulated offering rail and a separate yield and lending rail. SHARED CONTROL PLANE Privy account · Abroad verification · explicit authorization · event indexing · monitoring · reconciliation RAIL A — REGULATED REAL ESTATE OFFERINGS EligibilityCVM-aligned gates SorobanOffering controls DistributionAttribution · fees Independent records Allocation · ownership · real estate income · cooling-off · refund BWB administers the offering workflow and distribution evidence. RAIL B — OPTIONAL YIELD & LENDING DisclosureProduct-specific risk DeFindexVault operations Blend v2Supply · borrow Independent records Vault shares · collateral · liabilities · interest · utilization Eligible operators define product parameters; users authorize every action.
Fig. 3 — Product separation. Real estate income is never combined with DeFi yield, and BWB does not originate protocol credit or guarantee returns.

6 Stellar integration map

Each external dependency has a narrow responsibility and a corresponding BWB control boundary.

ComponentRoleBWB integrationSystem of record
PrivyAuthentication and embedded Stellar wallet access.Account provisioning, asset views, transaction review, and user authorization.Stellar for balances and transaction state; BWB for account linkage.
Soroban contractsProgrammable controls for regulated private offerings.Eligibility, allocation limits, pause, cooling-off, cancellation, refund, and auditable events.Contract state and emitted events, reconciled to BWB records.
Stellar data servicesNetwork query, event observation, and transaction submission evidence.Normalize network activity into idempotent investment, attribution, and commission transitions.Stellar terminal state plus BWB reconciliation record.
AbroadKYC/KYB and BRL entry/exit.Map approved, rejected, expired, and manual-review states; authenticate callbacks; reconcile BRL operations to Stellar.Abroad for provider decisions; BWB for product eligibility and reconciliation.
DeFindexVault and yield-strategy integration layer.Deposit, withdrawal, position reporting, failure handling, and reconciliation in a distinct product area.Vault position on Stellar; BWB for presentation and operational evidence.
Blend v2Lending market infrastructure.User-authorized supply or borrowing, collateral and liability reporting, and protocol-risk disclosure.Protocol position on Stellar; BWB for presentation and evidence.
Custody boundary: BWB coordinates eligibility, transaction intent, user authorization, monitoring, and reconciliation. Identity providers perform their applicable compliance operations, and user assets move through the authorized Stellar transactions—not through BWB operating accounts.

7 Security and operational model

Security controls follow the transaction lifecycle from identity decision to reconciled terminal state. The Tranche 2 threat model formalizes actors, assets, trust boundaries, STRIDE threats, mitigations, ownership, and monitoring coverage.

Authorization

Audience-specific access controls, eligibility gates, explicit wallet signatures, and least-privilege operational roles.

Data minimization

No identity documents or personal information on-chain; only necessary states, identifiers, values, and events.

Idempotency

Callbacks, submissions, and indexed events are deduplicated and applied through controlled state transitions.

Transaction integrity

Prepared intent, signed authorization, network transaction, and reconciled outcome remain separately traceable.

Operational resilience

Retries, timeouts, provider outages, pauses, reversals, refunds, and recovery procedures have explicit states.

Monitoring

Contracts, wallets, vaults, lending positions, callbacks, reconciliation gaps, and critical state changes map to owned alerts.

Trust boundaries and monitored transitions A diagram showing user device, BWB control plane, provider boundary, and Stellar network with monitored transitions. USER BOUNDARY Authenticated sessionReview · disclosure Wallet authorizationUser-approved signature Protected asset: user authority BWB CONTROL PLANE Policy engineGates · roles State machinesValid transitions Event queueRetry · dedupe ReconciliationEvidence · alerts Protected assets: rules, records, operational authority PROVIDER BOUNDARY Identity & BRLSigned callbacks DeFi protocolsPositions · protocol state Monitored: authenticity, latency, conflicts STELLAR BOUNDARY Soroban contractsRules · state · events Accounts & assetsBalances · settlement Monitored: state, failures, anomalies Every boundary crossing is authenticated, authorized, recorded, and monitored.
Trust boundary BWB-controlled component Provider-controlled component Stellar network component
Fig. 4 — Security boundaries. Sensitive runbooks and operational thresholds remain internal; reviewers receive a redacted evidence package.

8 Delivery mapping

The architecture is delivered in three controlled increments. Testnet capabilities precede mainnet deployment; production launch requires security evidence, operational ownership, and reconciliation readiness.

Tranche 1 · Foundation

Wallet, Soroban offering, distribution MVP

Privy Stellar accounts, shared transaction service, offering lifecycle controls, event indexing, attribution, and commissioning.

Tranche 2 · Integration

Security, Abroad, DeFindex, Blend v2

STRIDE model and monitoring plan, KYC/KYB and BRL test flows, vault operations, lending positions, and failure-state validation.

Tranche 3 · Production

Mainnet, hardening, reusable release

Regulated distribution launch, end-to-end operational hardening, monitoring activation, documentation, and reproducible evidence.

Mainnet release gate

No production offering launches until contract controls, integration fallbacks, alert routing, pause and recovery procedures, and end-to-end reconciliation have passed their acceptance tests.