Existing Stellar Mainnet MVP
Oynk has an existing Soroban settlement MVP deployed on Stellar Mainnet at:CDTDCQ2Y6OASQVJGOFBA2EHP3AV7N6FFULJNEFGMORLYMNHECX7OO2W6
The contract was deployed on July 11, 2026, through this transaction.
On September 3, 2026, an updated WASM artifact (d16b5f8a2b9971e2ea45bf0737731ed6348bd83b7c30fde275589f69ea132bc9) was uploaded and the contract was upgraded.
The deployed WASM was verified against the artifact built from source commit 60489c3. Source code, tests, and deployment evidence are available in the settlement-aggregator-protocol repository. The original July WASM remains recorded as historical provenance without source verification.
The MVP has completed three mainnet settlement lifecycles totaling 4,360 USDC in unique settlement principal (500, 1,500, and 2,360 USDC). Each settlement is counted once, excluding duplicate counting of escrow funding and subsequent claims.
These transactions demonstrate the existing settlement contract’s functionality. They are not presented as evidence that the complete proposed provider-routing and payment-orchestration system has already been implemented.
1. Executive Summary
Oynk is a permissioned liquidity discovery and settlement coordination network built around Stellar and Soroban. Businesses submit payment requests, and eligible liquidity providers compete to fulfill them based on supported corridors, exchange rates, fees, and available capacity. Oynk selects and locks an accepted quote, coordinates the required payment legs, and reconciles settlement evidence. Rather than replacing banks, payment service providers, or decentralized exchanges, Oynk connects these services through a unified payment infrastructure. The architecture consists of five layers:- Experience Layer: Business applications, payment interfaces, provider consoles, and operational dashboards.
- Control Plane: Identity, authorization, compliance policies, provider eligibility, competitive quotes, rate locks, payment orchestration, and authoritative transaction references.
- Provider and Liquidity Layer: Qualified liquidity providers, banking and payout partners, Circle CCTP for cross-chain USDC transfers, and Soroswap for optional asset conversion.
- Settlement Layer: Oynk’s existing Soroban protocol, extended with stronger escrow controls, authorization, claims, refunds, disputes, and auditable settlement events.
- Visibility and Reconciliation Layer: Blockchain indexing, payment-state tracking, provider evidence, PostgreSQL records, monitoring, reconciliation, and reporting.
Development Scope
The existing platform provides application, identity, compliance, and blockchain-observability foundations alongside a separately deployed Soroban settlement MVP. The proposed SCF development will integrate Anchor Platform, implement the provider and quote engine, add CCTP and Soroswap liquidity routing, harden Soroban settlement, and deliver unified payment reconciliation, security controls, and monitoring. All grant-funded milestones are scoped to Stellar Testnet. Any independently funded mainnet deployment or commercial operation remains outside the SCF-funded deliverables.Settlement Integrity
Oynk distinguishes blockchain execution from verified commercial settlement. A confirmed blockchain transaction proves that an onchain operation occurred. It does not independently establish customer authorization, provider eligibility, fiat payout completion, or fulfillment of every payment obligation. A payment is considered complete only when its required onchain and offchain settlement evidence has been validated and reconciled.2. Goals and Non-Goals
Goals
- Provide payment applications with a consistent, idempotent payment lifecycle across multiple liquidity providers and corridors.
- Enable provider discovery, eligibility checks, competitive quotes, rate locking, and liquidity-capacity management.
- Integrate Stellar Anchor Platform for standardized authentication, customer information, cross-border payments, and quotes through SEP-10, SEP-12, SEP-31, and SEP-38.
- Support cross-chain USDC liquidity routing into Stellar through Circle CCTP.
- Enable optional asset conversion into settlement USDC through Soroswap.
- Coordinate payment obligations, escrow, claims, refunds, and disputes through Oynk’s Soroban settlement protocol.
- Enforce identity, authorization, compliance, corridor limits, and transaction policies before value-changing operations.
- Maintain exact monetary accounting and consistent references across providers, Anchor transactions, blockchain transfers, and settlement records.
- Provide durable monitoring, reconciliation, audit trails, and recovery from partial failures.
- Keep liquidity providers modular so they can be added, suspended, or replaced without redesigning application integrations.
Non-Goals
Oynk does not replace regulated banking services, local licensing, sanctions compliance, provider due diligence, or legal obligations. Oynk does not operate its own decentralized exchange or cross-chain bridge. Soroswap provides asset conversion, while Circle CCTP facilitates supported native USDC cross-chain transfers. Onchain settlement does not independently prove that an offchain fiat payout occurred. Fiat settlement confirmation requires evidence from authorized providers and must be reconciled separately. The SCF-funded implementation is limited to testnet development and validation. Live fiat payouts and mainnet commercial settlement are outside the grant-funded milestone scope.3. System Context
3.1 SCF Integration Scope at a Glance
Oynk combines provider coordination, liquidity routing, and programmable settlement into a unified payment lifecycle. Each component has a distinct responsibility.3.2 Payment Authorization and Wallet Connectivity
Oynk separates wallet access from business authorization. Participants may use supported Stellar wallets or compatible account-access methods to authorize blockchain transactions. However, wallet ownership alone does not establish eligibility to participate in Oynk’s payment network. Before accepting a payment or settlement instruction, Oynk validates:- Organization identity and assigned permissions.
- Applicable KYC/KYB and compliance requirements.
- Supported corridors, currencies, and provider eligibility.
- Transaction limits, available liquidity, and rate-lock validity.
- Transaction-specific authorization and settlement conditions.
3.3 Integration Boundaries
Anchor Platform: Provides standardized Stellar ecosystem interfaces. Oynk’s business server implements the application-specific rules, provider coordination, and commercial workflow. Circle CCTP: Transfers native USDC between supported blockchain networks. It does not perform fiat settlement or currency exchange. Soroswap: Executes supported asset conversions on Stellar. It does not manage Oynk’s provider obligations or determine commercial payment completion. Soroban: Enforces onchain settlement conditions and records contract events. It does not independently verify offchain fiat payouts. Oynk: Coordinates provider eligibility, competitive quoting, rate locks, payment orchestration, authorized fiat evidence, and reconciliation across these components.3.4 SCF Development Boundary
The grant-funded work covers integration development, Soroban contract hardening, automated testing, security remediation, monitoring, and end-to-end validation on Stellar Testnet. Independent production deployment and live commercial operations are outside the SCF-funded scope.3.2 End-to-End Integration Flow
Oynk coordinates provider discovery, competitive quoting, liquidity routing, and settlement through a unified payment lifecycle. The expected payment lifecycle is:- Initiate payment: An approved business submits a payment request through Oynk.
- Validate eligibility: Oynk checks organization permissions, customer requirements, corridor availability, transaction limits, and provider eligibility.
- Discover liquidity: Eligible providers submit competing quotes based on supported corridors, currencies, available capacity, rates, and fees.
- Accept quote: Oynk validates the selected quote, records the agreed terms, and creates a time-bound rate lock.
- Route liquidity: Settlement funding is prepared through direct Stellar USDC, Circle CCTP, or Soroswap conversion, as applicable.
- Execute settlement: Oynk’s Soroban protocol enforces authorized settlement obligations, escrow funding, claims, refunds, and disputes.
- Reconcile payment: Oynk correlates Anchor transactions, provider evidence, liquidity transfers, Soroban events, and internal ledger records.
- Confirm completion: A commercial payment is marked complete only after all required onchain and offchain obligations are satisfied.
3.3 Provider, Corridor, Quote and Rate-Lock Engine
Oynk maintains a configurable provider registry supporting multiple payment corridors, currencies, transaction limits, available liquidity, and provider-specific eligibility requirements. The engine will implement:- Provider profiles, supported corridors, currencies, transaction limits, and available capacity.
- Eligibility filtering based on compliance, operational status, corridor support, and liquidity availability.
- Competitive quote collection and comparison using exchange rates, fees, and destination amounts.
- Firm quote acceptance with immutable terms and defined expiry.
- Capacity reservation, rate-lock release, and rejection of expired or duplicate acceptances.
- Auditable provider assignment and payment-state transitions.
3.4 Stellar Anchor Platform Integration
Oynk integrates Stellar Anchor Platform with its business server to support standardized authentication, customer information, cross-border payment workflows, and quotes.
The Oynk business server will implement authenticated callbacks, schema validation, stable transaction references, idempotent processing, and valid state transitions.
Sensitive customer information and banking records remain offchain.
Anchor transaction creation or status updates do not independently establish fiat payout completion. Oynk requires authenticated provider evidence and reconciliation before confirming commercial finality.
Completion test: Demonstrate SEP-10 authentication, SEP-12 customer requirements, SEP-38 firm quotes, and SEP-31 transaction creation and tracking. Verify payment-reference mapping, callback idempotency, invalid-state rejection, and automated integration tests.
Scope: SEP-24 is excluded from the current grant-funded integration scope.
3.5 Circle CCTP Liquidity Routing
Circle’s Cross-Chain Transfer Protocol enables Oynk to route native USDC from supported blockchain networks into Stellar for settlement funding. The integration will implement:- Supported source and destination network validation.
- Native USDC transfer initiation and tracking.
- CCTP message identification, attestation tracking, and destination mint verification.
- Stable association with Oynk payment or provider-treasury references.
- Duplicate-processing protection, delayed-transfer handling, and recovery procedures.
- Transfer reconciliation using authoritative blockchain transaction records.
3.6 Soroswap Asset Conversion
Oynk integrates Soroswap as an optional liquidity route for converting supported Stellar assets into settlement USDC. The integration will implement:- Supported asset and network validation.
- Swap quote retrieval and route selection.
- Quote expiry, maximum slippage, minimum output, and price-impact controls.
- Transaction execution and output verification.
- Attribution of converted funds to the corresponding payment or provider account.
- Reconciliation of swap transactions, fees, and resulting settlement balances.
3.7 Soroban Coordination and Settlement Protocol
Oynk already has a functional Soroban settlement MVP. The grant-funded work will harden and extend this implementation rather than recreate it. The Soroban protocol manages:- Exact USDC settlement commitments and escrow accounting.
- Authorized participant roles and provider obligations.
- Settlement deadlines, claims, cancellations, refunds, and disputes.
- Contract authorization, replay protection, and valid state transitions.
- Versioned settlement events and auditable contract operations.
- Controlled upgrades, emergency restrictions, and governance permissions.
3.8 Cross-Integration Identifiers and State Ownership
Each payment receives a stablepayment_id used to correlate activity across Oynk, liquidity providers, Anchor Platform, CCTP, Soroswap, and Soroban.
Native identifiers are preserved rather than inferred from transaction amounts or timestamps.
State ownership
Oynk: Commercial payment state, provider assignment, rate locks, policy decisions, and reconciliation. Anchor Platform: Standardized SEP transaction and customer-workflow state. Circle CCTP and supported blockchains: Cross-chain USDC transfer evidence and minting state. Soroswap and Stellar: Executed asset conversions and resulting asset balances. Soroban: Onchain escrow, settlement obligations, and contract-state transitions. Authorized fiat providers: Offchain collection and payout evidence. A successful operation in one component cannot independently mark the complete commercial payment as settled.Reconciliation requirements
Oynk reconciles each required payment leg using exact monetary values, authoritative transaction references, and validated state transitions. Reconciliation must distinguish completed settlement principal from fees, refunds, duplicate transfers, and internal treasury movements. Missing, inconsistent, or delayed evidence results in a pending or exception state rather than an unsupported completion claim.3.9 Integration Security and Production Readiness
Oynk applies security and operational controls across the complete payment lifecycle.Security requirements
- Organization authorization, role separation, and transaction-specific permissions.
- KYC/KYB, sanctions, corridor, and provider-policy enforcement.
- Exact monetary accounting without floating-point arithmetic.
- Authenticated callbacks, replay protection, and idempotent transaction processing.
- Provider eligibility, liquidity-capacity checks, and rate-lock expiry enforcement.
- CCTP network, recipient, transfer, and destination-mint verification.
- Soroswap asset validation, slippage protection, and minimum-output enforcement.
- Soroban authorization, escrow invariants, upgrade controls, and emergency restrictions.
- Durable event indexing, reconciliation, audit logs, monitoring, and recovery procedures.
Security review and remediation
Oynk will conduct adversarial testing and contract upgrade validation, apply for an independent external security audit through the SCF Audit Bank, and remediate applicable audit findings. The external audit is funded separately through the Audit Bank. The Build Award’s security allocation covers engineering time for vulnerability remediation, contract fixes, regression testing, and verification.Testnet release requirements
The grant-funded release must demonstrate:- Reproducible deployment of the integrated testnet infrastructure.
- Successful end-to-end payment workflows across supported integrations.
- Automated security, integration, failure-recovery, and reconciliation tests.
- Monitoring for settlement failures, escrow discrepancies, delayed transfers, and unauthorized changes.
- Documented security findings, remediation results, operational procedures, and known limitations.
- Reviewer-accessible contract references, transaction evidence, test results, and technical documentation.
4. Repository and package architecture
Oynk is a pnpm workspace with strict package ownership.
Shared models belong in
@oynk/shared. Business rules and authorization remain in @oynk/api. Presentation packages consume shared contracts and never import API internals. Future Soroban contracts should have a clearly owned Rust workspace, deterministic tests, generated bindings, deployment manifests, and source-to-bytecode verification.
5. Implemented runtime architecture
The API validates environment configuration at startup. It exposes liveness, readiness, public activity, synchronization, authentication, and compliance routes. When enabled, synchronization runs after startup and on a configured interval. Production scaling should extract indexing into dedicated workers instead of coupling scheduled work to an API instance.6. Experience and presentation layer
The public web application provides Oynk’s website and settlement-activity dashboard. The dashboard separates gross blockchain movement from reference-paired estimated settlement, shows inflows and outflows, exposes sync timestamps and timeline activity, and links on-chain observations to explorers. The authenticated console supports business and settlement-partner signup, email verification, password-plus-OTP sign-in, organization selection, role-specific shells, and business-compliance draft entry. Payment, payout, settlement, provider, liquidity, corridor, terminal, reconciliation, webhook, API-key, and full internal review destinations are not complete transactional products. They remain empty, disabled, or informational until their server APIs and authorization contracts exist. Business logic must not migrate into React components. UI authorization improves usability but never replaces server enforcement.7. Identity, tenant, and authorization model
Users and organizations
Users and organizations are distinct records. A user can hold organization memberships; a session selects one active organization and receives the corresponding role and resolved permission list. Organization types are:BUSINESSSETTLEMENT_PARTNERINTERNAL
SANDBOX, TEST, and LIVE platform modes separate environments and operational authority.
Authentication flow
Passwords use scrypt with per-password salts. OTP and session secrets are stored as keyed hashes using an environment pepper. OTPs have expiry, attempt limits, and resend cooldowns. Sessions expire, can be revoked, and carry a distinct CSRF secret. Return paths are constrained to safe local paths. Authentication rate limiting is process-local today and must move to shared gateway or datastore enforcement before horizontal scaling.Authorization
Roles map to fine-grained permissions for payments, payouts, terminals, settlements, liquidity, compliance, organization management, members, developer tooling, audit, indexing, applications, and account activation. Every sensitive server route must authenticate the session, resolve the active organization, require the correct permission, and enforce CSRF for cookie-authenticated state changes.8. Compliance architecture
The implemented business profile flow validates legal name, registration information, ISO country codes, incorporation date, tax identifier, website, industry, business description, address, expected volume, expected transactions, and source of funds. A save operation atomically updates the organization, upserts the profile, and records an audit event. The target control plane adds:- KYC/KYB and beneficial-owner verification
- Sanctions and politically exposed person screening where required
- Transaction monitoring and case management
- Corridor, currency, asset, provider, and amount/frequency eligibility
- Evidence retention and Travel Rule exchange where applicable
- Versioned decisions linked to payments and assignments
9. Target payment control plane
The control plane is authoritative for customer intent and business lifecycle. It owns:- Idempotent payment creation
- Exact origin and destination amounts
- Currency, asset, chain, recipient, and corridor validation
- Quote requests, fees, rate locks, expiry, and slippage
- Compliance and limit decisions
- Provider eligibility, capacity, selection, and assignment
- Funding instructions and deadlines
- Settlement, payout, evidence, exception, refund, and dispute state
- Stable payment, settlement, corridor, and leg references
- Auditable state transitions
10. Proposed end-to-end payment lifecycle
Completion requires all required legs and evidence. Quote acceptance, funding, provider evidence, on-chain claims, and retries must be idempotent. Expired quotes require requoting. Partial funding requires an explicit top-up, partial acceptance, cancellation, or refund rule. Provider failure can trigger reassignment, refund, or dispute only through defined transitions.11. Provider network architecture
Providers are modular participants, not implicitly trusted extensions of Oynk. Each production profile needs legal/KYB status, beneficial ownership, corridor and currency eligibility, supported assets and rails, banking capability, operating hours, limits, liquidity or collateral policy, pricing, service levels, evidence requirements, contacts, suspension state, and exit procedure. Assignment filters by eligibility before comparing capacity, price, completion history, concentration, and operational risk. Provider performance should measure verified acceptance, completion time, quote reliability, evidence quality, exception and dispute rates, reconciliation gaps, and availability. Fiat connectors should expose idempotent create, status, evidence, cancel, and reconcile operations behind provider-specific adapters. A provider callback is untrusted input until authenticated, validated, deduplicated, and correlated to the correct assignment.12. Stellar and Soroban target architecture
Stellar is the proposed asset settlement rail. Soroban is the proposed programmable policy boundary for referenced settlement state. Customer identity, provider due diligence, quote calculation, route selection, compliance reasoning, and detailed fiat evidence remain off-chain. Before implementation, Oynk must decide network selection, asset and issuer allowlists, trustline requirements, token contract identity, contract ownership, upgrade governance, authorization graph, storage and event schema, fee sponsorship, sequence handling, timebounds, partial funding, dispute authority, emergency pause, recovery, and data retention. RPC URLs, issuers, network passphrases, contract IDs, explorers, and signers must be environment-specific validated configuration. Testnet and mainnet identifiers must never mix.13. Proposed Soroban settlement contract
State machine
Minimum record
Contract invariants
- Settlement identifiers cannot be reused with different terms.
- Only the configured network-scoped asset and permitted amount can fund a request.
- Claim and refund are mutually exclusive terminal outcomes.
- State transitions are monotonic except where an explicitly specified dispute path applies.
- Each transition verifies the necessary Soroban authorization entries.
- Repeated submissions are idempotent or fail without changing value.
- Deadline behavior is based on documented ledger-time semantics.
- Checked integer arithmetic prevents overflow, underflow, and precision drift.
- Stored state and emitted events exclude names, phone numbers, bank data, credentials, and raw compliance evidence.
Events and indexing
Events should be versioned and cover creation, funding, claim enablement, claim, refund initiation, refund, dispute, resolution, pause, and migration where applicable. The future indexer stores network, contract ID, ledger, transaction hash, event position, topic/version, settlement reference, decoded payload, and ingestion checkpoint. Event identity must be deterministic so replays do not duplicate business records.14. Stellar asset and transaction model
An asset allowlist is keyed by network and canonical identity. Classic Stellar assets require code and issuer. Soroban token use requires the verified contract address and its relationship to the underlying asset. Symbols are display values only. Before building a transaction, Oynk validates network/passphrase, asset identity, decimals, exact scalar conversion, trustline or authorization prerequisites, issuer controls, recipient address, settlement state, and signer authority. A dedicated submitter should:- Build the intended operation from immutable, versioned instructions.
- Simulate Soroban execution.
- Enforce resource and fee limits.
- Collect the minimum required authorization.
- Add bounded time conditions and network/contract domain binding.
- Persist submission intent and transaction identity under an idempotency key.
- Submit once and recover status after timeouts rather than blindly resubmitting.
- Wait for the defined successful ledger and contract result.
- Correlate the indexed event to the authoritative settlement reference.
15. Smart accounts and delegated authorization
The planned smart-account layer supports narrow authority rather than unlimited hot keys. A policy may combine a Stellar G-account or contract principal, passkey-backed user authorization, short-lived session delegates, per-action and per-asset limits, recipient constraints, rolling spend limits, expiry, invocation counts, nonces, recovery, and revocation. Phone numbers can aid discovery or recovery but are not cryptographic authorization.Low-connectivity flow
This is one-sided low-connectivity authorization, not fully offline settlement. The merchant must reach the network, and offline users cannot observe recent revocation or competing submissions. Policies require narrow caps, short expiry, atomic nonce consumption, secure key storage, domain separation, clear wallet signing UX, and explicit maximum exposure.16. Current blockchain visibility plane
Synchronization coordination
An in-process flag prevents overlapping work locally. A fixed PostgreSQL advisory lock prevents concurrent API or CLI processes from executing the global sync. Every run receives a UUID and durable start/end time, mode, state, counts, error count, and per-chain outcome. Partial success is retained.BSC indexing
The BSC indexer observes configured wallets against allowlisted ERC-20 contracts. Current assets are USDT, USDC, and BTCB. It calculates a safe tip by subtracting confirmation depth, rewinds recent blocks on later runs to reconcile reorganizations, and advances a cursor keyed by normalized wallet and contract. Log ranges adapt to RPC constraints: the indexer begins with a configured chunk, retries temporary failures, reduces rejected ranges down to a minimum, and grows after repeated successes. Delays and jitter reduce provider pressure. Block timestamps are cached within a run. Deterministic transfer identities and upserts make rewind and replay safe.Solana indexing
The Solana indexer observes configured owner, associated-token-account, token-account, and manual sources. It fetches signatures, loads parsed transactions, and derives USDT/USDC movement from pre/post token balances. Failed transactions remain visible withFAILED status but cannot be paired.
The current signature limit bounds each source scan. Production still needs durable historical pagination/checkpoints, comprehensive source discovery, Token-2022 coverage, and an automatic durable-failure reprocessor. Reliable archival RPCs are required for material backfills.
Pairing and settlement semantics
The current matcher processes confirmed, unpaired inflows and selects an available confirmed outflow using same-asset preference, amount proximity, and time proximity. PostgreSQLNUMERIC performs amount comparison. Both legs are locked and updated within one database transaction.
These pairs are labeled HEURISTIC with confidence 0.5000. They support investigation only and are excluded from authoritative reference-paired settlement. Future payment orchestration must write explicit payment, settlement, corridor, origin-leg, and destination-leg references.
17. Exact value and metrics
Raw token integers, decimals, normalized decimal strings, and operational USD values are retained. Monetary calculations must use integer or exact decimal representations. Current operational valuations are:
BTCB’s value is not live or historical pricing. Metrics are operational indicators, not accounting statements.
- Gross transfer volume: all confirmed observed legs plus recorded off-chain movement.
- Inflow and outflow: wallet-relative direction.
- Estimated settled volume: conservative smaller value of
REFERENCE-paired legs plus off-chain records. - Unmatched volume: movement not included in authoritative pairing.
- Settlement count: reference-paired settlements plus off-chain records.
- Last indexed time: synchronization-run time, not transaction time.
18. Implemented PostgreSQL model
Future migrations need requests, quotes, acceptances, assignments, funding instructions, compliance decisions, payout evidence, disputes, refunds, Stellar network/asset configuration, Soroban submissions, contract events, and reconciliation outcomes. Historical migrations remain immutable.
19. API boundaries
Current public and operational endpoints
GET /health/live: process liveness.GET /health/ready: configuration and PostgreSQL readiness.GET /api/dashboard: metrics, timeline, and recent activity filtered byALL,BSC,SOLANA, orOFFCHAIN.GET /api/dashboard/syncandGET /api/sync/status: in-process synchronization status.POST /api/dashboard/sync: administrator-key-protected, process-limited async synchronization.GET /api/sync/runs,/api/sync/runs/{id}, and/api/sync/failures: operational records requiring deployment access policy.
20. Trust boundaries and security model
- Credentials prove identity; organization membership and permission checks grant authority.
- Browser checks never replace API authorization.
- Provider evidence is authenticated external input, not self-proving completion.
- Chain consensus proves ledger state, not off-chain identity or payout truth.
- RPC responses and webhook payloads are untrusted and validated before persistence.
- Public reporting minimizes personal and commercially sensitive data.
- Signing material, API keys, session tokens, OTPs, signed payloads, and private evidence are never logged.
- Mainnet and testnet configuration, identifiers, signers, and state remain strictly partitioned.
21. Soroban threat model
22. Reliability, scaling, and observability
Reliability baseline
- Deterministic identities and database uniqueness
- BSC confirmation depth and reorg rewind
- Contract-specific BSC checkpoints
- Adaptive range sizing and bounded RPC retry
- PostgreSQL advisory locks
- Durable run and failure records
- Partial-result preservation
- Health/readiness endpoints
- Graceful API and database shutdown
Scale path
Move indexing out of the API into workers partitioned by chain and source under durable leases. Preserve deterministic uniqueness and transactional checkpoint rules. Batch writes only after correctness and query-plan measurement. Introduce server-side pagination for large activity datasets and aggregates only when observed load requires them.Required telemetry
Every run should expose run ID, chain, source, range/page, attempts, reductions, insert/update counts, cursor movement, safe-tip lag, duration, and classified errors. Alerts should cover stalled cursors, aging failure backlog, repeated reorg replay, RPC latency/rate limits, partial runs, database pool saturation, stale readiness, unexpected auth failures, Soroban event lag, unresolved contract states, and control-plane/chain divergence.23. Deployment architecture
API, workers, web, console, docs, and database migrations are independent deployment units. Use HTTPS, restricted database networking, non-root runtimes, resource limits, health probes, centralized logs, primary/secondary RPCs, controlled migrations, and tested point-in-time recovery. Soroban deployment records should include environment, network, source revision, WASM hash, verified contract ID, deployment ledger/transaction, administrator and upgrade policy, configuration version, and audit version.24. Disaster recovery and reconciliation
PostgreSQL requires encrypted backups, point-in-time recovery, defined RPO/RTO, retained migration history, and recurring restoration tests. Preserve control-plane, provider, compliance, submission, event, evidence, and audit records according to policy. Derived blockchain data can be rebuilt from verified checkpoints and bounded backfills, but RPC archival availability cannot be the sole backup. After restoration, reconcile database state against BSC safe tips, Solana signatures, future Stellar ledgers, Soroban contract state/events, provider evidence, and control-plane terminal states before reopening value-changing operations.25. Testing architecture
Current platform
- Unit-test address normalization, cursor identity, exact decimals, password/OTP/session controls, validation, route authorization, range adaptation, pairing semantics, and metrics.
- Use deterministic BSC log and parsed Solana transaction fixtures.
- Integration-test migrations, duplicates, rewind, atomic checkpoints, advisory locks, partial runs, readiness failure, permission denial, CSRF, rate limits, and recovery against PostgreSQL.
- Run bounded staging backfills against archival RPC providers.
Future Stellar/Soroban platform
- Unit-test every state transition and authorization branch.
- Property-test exact amounts, terminal-state exclusivity, nonce uniqueness, limits, and deadlines.
- Fuzz contract inputs, authorization trees, events, and upgrade/migration paths.
- Integration-test simulation, signing, submission, timeout recovery, fee/resource limits, event replay, and reconciliation.
- Test malicious tokens/contracts, unauthorized signers, stale payloads, duplicate submissions, network mismatch, provider failure, refund/claim races, disputes, pauses, and recovery.
- Complete independent contract and application audits and retest remediations.
26. Current limitations
- No Stellar client, Horizon/RPC integration, asset configuration, transaction submitter, or event indexer exists in this repository.
- A Soroban MVP is deployed at
CDTDCQ2Y6OASQVJGOFBA2EHP3AV7N6FFULJNEFGMORLYMNHECX7OO2W6. Its current live WASM matches the public artifact built from source commit60489c3, with upload and upgrade evidence recorded through thesettlement-aggregator-protocolsubmodule. Generated application bindings and independent security review remain incomplete. - No authoritative payment, quote, provider-assignment, payout, refund, or dispute lifecycle exists.
- Compliance supports a business draft foundation, not complete screening or review operations.
- Solana historical pagination, retry processing, Token-2022, and source coverage are incomplete.
- Live safe-tip chain lag is not surfaced to users.
- Heuristic pairing is non-authoritative.
- Operational read endpoints need stronger deployment authorization.
- Current automated coverage and production telemetry are insufficient for funds-at-risk production.
27. Delivery phases
- Harden current foundations: complete Solana coverage and retries, chain-lag telemetry, operator access, test fixtures, worker separation, and recovery drills.
- Specify and harden Stellar/Soroban: use the mainnet MVP as evidence while freezing asset identity, state machines, authorization, events, upgrades, privacy, fee policy, and threat model for its successor.
- Build test environment: implement the hardened contract, clients, signer/submitter, event indexer, explicit references, and reconciliation.
- Implement payment orchestration: add requests, rate locks, provider capacity/assignment, compliance gates, fiat adapters, evidence, refunds, disputes, and full APIs.
- Conduct security review: execute property/fuzz/integration testing and independent contract/application audits.
- Run controlled pilot: restrict providers, corridors, assets, amounts, and exposure with human monitoring and independent reconciliation.
- Operate production: require governed upgrades, production key management, redundant infrastructure, formal corridor approval, SLOs, on-call ownership, and tested incident response.
28. Production-readiness gates
Visibility and platform
- Bounded Solana history, source discovery, Token-2022, and retry worker complete.
- Redundant archival RPC providers and measured failover operational.
- Chain and contract lag visible with actionable alerts.
- All operational endpoints use durable, least-privilege authorization.
- PostgreSQL migrations, backups, PITR, and restoration drills verified.
- End-to-end duplicate, replay, reorg, outage, and partial-run tests pass.
- Shared rate limiting, secret rotation, CORS, audit, and retention policies deployed.
Payment and provider control plane
- Authoritative requests, quotes, assignments, evidence, payouts, refunds, disputes, and reconciliation implemented.
- Exact amount handling and idempotency verified across every external boundary.
- KYC/KYB, screening, corridor, limit, monitoring, and case policy approved.
- Provider due diligence, capacity tests, service levels, suspension, and exit processes complete.
- Legal and licensing eligibility confirmed for every production corridor and product.
Stellar and Soroban
- Network, assets, state machine, authorization graph, events, deadlines, upgrades, pause, and recovery frozen.
- Contract, client, submitter, event indexer, and reconciliation implemented and tested.
- Property, fuzz, invariant, replay, timeout, adversarial, and migration suites pass.
- Independent audits completed and all critical/high findings closed and retested.
- Signing material protected by production key management and least privilege.
- Deployment artifacts, source, WASM hash, contract IDs, and configuration independently verified.
- Pilot limits, monitoring, incident ownership, rollback, and communications rehearsed.