# Observability & Audit Logs {% hint style="info" %} Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64)). Research Partner: Base58 Labs contributes execution research, systems modeling, and risk design. {% endhint %} {% hint style="warning" %} Accounting and asset model The interface may display balances and performance in USDT as an internal accounting and USD-equivalent reference unit. USDT is not a deposit or withdrawal asset. Deposits and withdrawals use native assets only: * BTC via a unique BASIS-assigned deposit address for each account * ETH, SOL, and PAXG via a connected Web3 wallet such as MetaMask Swaps are same-token 1:1 only: * BTC → stBTC * ETH → stETH * SOL → stSOL * PAXG → stPAXG {% endhint %} A system that cannot explain its behavior under stress is not trustworthy. Observability is the discipline of instrumenting the platform so operators and users can understand why the system behaved as it did, when it changed state, and how outcomes were reconciled. For BASIS, observability must cover: * execution precision inside BHLE * structural alpha capture workflows * wallet and staking state transitions * deterministic risk controls * post-trade and user-balance reconciliation *** ## 1. The three pillars of observability {% tabs %} {% tab title="Logs" %} Logs are granular, timestamped records of discrete events. Typical examples: * `ORDER_SENT` * `ORDER_ACKNOWLEDGED` * `FILL_PARTIAL` * `STATE_TRANSITION_NORMAL_TO_BSCB` * `RECONCILIATION_PASSED` * `BTC_DEPOSIT_CONFIRMED` * `SWAP_BTC_TO_STBTC_COMPLETED` * `UNSTAKE_SETTLED_TO_STAKING_WALLET` Logs support forensic review, root-cause analysis, and audit trails. {% endtab %} {% tab title="Metrics" %} Metrics are aggregated numerical views of system health over time. Typical examples: * p50, p95, p99 routing latency * venue API latency * quote acceptance rate * fill ratio * reconciliation error count * withdrawal processing time by asset * state machine transition frequency * open exposure by asset and venue Metrics power dashboards, thresholds, and automated alerts. {% endtab %} {% tab title="Traces" %} Traces show the full lifecycle of a single workflow across components. A BASIS trace may follow: 1. market data intake 2. signal evaluation 3. eligibility gate decision 4. order submission 5. venue acknowledgement 6. fill and reconciliation 7. wallet or staking ledger update For user operations, a trace may follow deposit detection, confirmation, wallet credit, swap, stake, reward accrual, unstake, and withdrawal. {% endtab %} {% endtabs %} BASIS uses all three pillars to maintain professional operational awareness across execution, accounting, and user funds movement. *** ## 2. What must be observable The platform should capture enough detail to reconstruct both technical and economic outcomes. | Domain | Required telemetry | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Market data and quoting | raw ticks received, normalization results, quote construction, eligibility gate outcomes, reason codes for pass or reject | | Order lifecycle | venue, asset, order size, limit or market instruction, acknowledgement, partial fill, full fill, cancel, reject, retry | | Execution quality | route selection, latency by hop, slippage distribution, fill quality, deterministic fallback activation | | Risk and state machine | all transitions between Normal, BSCB, DMM, trigger source, threshold value, exposure snapshot, margin status, liquidation guard alerts | | Reconciliation | balance deltas, fee application, PnL attribution, ledger finalization, discrepancy detection, operator resolution notes | | Infrastructure | queue depth, service saturation, packet loss, time synchronization health, dependency failures, recovery events | | User wallet activity | deposit detection, confirmation count, Funding Wallet credit, withdrawal request, approval trail, broadcast, completion | | Staking activity | same-token 1:1 swap event, stToken credit, booster selection, lock start, lock end, reward accrual, unstake settlement | | Support and account actions | authentication events, security setting changes, support case creation, account-level risk flags | *** ## 3. User-facing actions that must be auditable Observability is not limited to internal trading systems. User actions must also be reconstructable from source event to final ledger state. | Action | What must be recorded | User-visible result | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | BTC deposit | BASIS-assigned deposit address, transaction hash, confirmation state, minimum deposit rule check of 0.0001 BTC, Funding Wallet credit | Assets | | ETH deposit | connected wallet address, signature or authorization context, onchain tx hash, confirmation state, Funding Wallet credit | Assets | | SOL deposit | connected wallet address, tx hash, confirmation state, Funding Wallet credit | Assets | | PAXG deposit | connected wallet address, tx hash, confirmation state, Funding Wallet credit | Assets | | Same-token swap | source asset, destination stToken, 1:1 conversion, swap fee of 0.01%, timestamp, wallet movement from Funding Wallet to Staking Wallet | Assets, Stake | | Stake | pool type, asset, amount, booster term, lock schedule, final accepted position size | Stake | | Reward accrual | real-time accrual rate, reward balance in same stToken, ledger snapshots, accrual interruptions if any | Stake | | Unstake | full-position only validation, fixed-pool lock expiry validation, unstake request, settlement amount, auto-credit to Staking Wallet as stToken after the mandatory 7-day unstaking buffer | Stake, Assets | | Withdrawal | asset, destination, withdrawal fee of 0.05%, security checks, broadcast status, completion timestamp | Assets, Support | | Referral network rewards | attribution event, eligibility logic, ledger posting, settlement state | Referral | {% hint style="success" %} Wallet model * Funding Wallet holds native assets for deposit and withdrawal * Staking Wallet holds stTokens for staking and rewards * Rewards accumulate in real time as the same stToken * On unstake, the claimable amount is auto-credited to the Staking Wallet as stToken after the mandatory 7-day unstaking buffer * Fixed pools can be unstaked only after the lock-up period ends * Unstake is full-position only and auto-MAX by design {% endhint %} *** ## 4. Asset-specific monitoring expectations | Asset flow | Deposit method | Withdrawal expectation | Monitoring requirement | | ---------- | -------------------------------------- | -------------------------- | -------------------------------------------------------------------------------------- | | BTC | copy the unique BASIS-assigned address | typically 10 to 60 minutes | confirmation count, mempool visibility, final wallet credit, delayed-transfer alerting | | ETH | connect a Web3 wallet | typically 1 to 10 minutes | chain confirmation, gas status, wallet signature context, final settlement | | SOL | connect a Web3 wallet | typically 1 to 10 minutes | slot confirmation, tx finality, final wallet settlement | | PAXG | connect a Web3 wallet | typically 1 to 10 minutes | token transfer confirmation, contract event parsing, final wallet settlement | Any deviation from expected processing windows should trigger internal alerts and user-visible status updates. *** ## 5. Audit logs and integrity requirements Audit logs are a higher-assurance subset of platform logs. They must be tamper-evident, time-accurate, and reviewable. ### Core properties 1. Append-only storage\ Historical entries must not be mutable in place. 2. Cryptographic integrity\ Each record should be chained to the previous record, making unauthorized edits detectable. 3. Time synchronization\ Clock accuracy is mandatory. With BHLE operating at sub-50μs latency, timestamp drift can invalidate reconstruction. 4. Access control\ Role-based access controls must govern who can view, export, or annotate audit data. 5. Dual-scope retention\ Operational telemetry and formal audit records may have different retention classes, but both must follow documented policy. 6. Provenance\ Every material state change should identify source service, responsible actor or system identity, and before/after values. ### Minimum immutable fields ```json { "event_id": "a8a3d5f1-8f67-4c27-9f68-0f24f8f5f2b1", "trace_id": "trc_01HVQ0R6N2Y9", "recorded_at_utc": "2026-03-12T10:22:48.184291Z", "service": "wallet-ledger", "event_type": "SWAP_ETH_TO_STETH_COMPLETED", "account_id": "acc_7f24", "asset_in": "ETH", "asset_out": "stETH", "amount_in": "2.50000000", "amount_out": "2.50000000", "fee_rate": "0.0001", "wallet_from": "Funding Wallet", "wallet_to": "Staking Wallet", "state_before": "pending", "state_after": "settled", "decision_reason": "same-token-1-to-1-swap", "hash_prev": "0x8f1d...", "hash_self": "0x12ac..." } ``` *** ## 6. Why this matters for BASIS execution Observability is not only about uptime. It is also about proving execution quality under load. For BASIS, that includes: * measuring route selection quality across proprietary routing infrastructure * proving state machine transitions happened at the correct thresholds * verifying risk controls blocked invalid actions deterministically * showing reconciliation matched execution outcomes to ledger outcomes * confirming structural alpha capture logic behaved within mathematical constraints If a system claims execution precision, its logs, metrics, and traces must support that claim. *** ## 7. Incident response workflow {% stepper %} {% step %} **Detect 🔎** Automated alerts fire when latency, exposure, settlement timing, reconciliation drift, or dependency health moves outside expected bounds. {% endstep %} {% step %} **Diagnose** Operators inspect metrics, traces, and immutable logs to isolate the root cause, scope affected accounts, and determine whether a state-machine transition is required. {% endstep %} {% step %} **Contain 🛡️** If needed, the system can shift into a protective state such as BSCB or DMM, reduce exposure, restrict certain flows, or halt non-essential actions. {% endstep %} {% step %} **Communicate** Users receive clear status updates through platform status surfaces and support channels. Silence during incidents is unacceptable. {% endstep %} {% step %} **Reconcile** After recovery, all affected execution, wallet, and staking records are rechecked for ledger completeness and accounting consistency. {% endstep %} {% step %} **Review** A formal post-incident review should preserve timeline, root cause, impact, remediation, and control improvements. {% endstep %} {% endstepper %} *** ## 8. User verification surface Users should be able to inspect key events directly in the dashboard: * Stake * Assets * Referral * Support * Account At a minimum, the interface should expose: * transaction hashes where applicable * timestamps and final states * wallet movement between Funding Wallet and Staking Wallet * applied fees * lock schedules and booster terms * unstake settlement status * withdrawal progress {% hint style="info" %} Booster reference * 14D: +10% * 30D: +20% * 90D: +50% * 180D: +100% (2×) These selections and their resulting lock windows should be fully auditable. {% endhint %} *** ## 9. Standard of trust A trustworthy platform is not one that claims perfection. It is one that can show, with deterministic evidence, what happened, when it happened, why it happened, and how final balances were derived. For BASIS, observability and auditability are part of the control plane itself: * deterministic execution * math-constrained decisioning * state machine risk controls * tamper-evident logs * reconciled user balances * measurable BHLE performance That is the minimum standard for a platform handling execution, staking, and native-asset fund flows. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.basis.pro/technical-architecture/observability.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.