Observability & Audit Logs

Operator and jurisdiction

BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC. LEI: 254900IX2F2KCWNSSS64

Research and execution stack

BASIS execution and routing research is supported by Base58 Labs as a Research Partner. The BHLE stack is built for sub-50μs latency, 100K+ OPS, and proprietary routing infrastructure. Trust is grounded in deterministic execution, math constraints, and state machine risk controls.

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

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

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.

Metrics

Traces

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	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

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

• Fixed pools can be unstaked only after the lock-up period ends

• Unstake is full-position only and auto-MAX by design

---

4. Asset-specific monitoring expectations

Asset flow	Deposit method	Withdrawal expectation	Monitoring requirement
BTC	copy the unique BASIS-assigned address	typically 30 minutes to 1 hour	confirmation count, mempool visibility, final wallet credit, delayed-transfer alerting
ETH	connect a Web3 wallet	typically 1 to 6 minutes	chain confirmation, gas status, wallet signature context, final settlement
SOL	connect a Web3 wallet	typically 1 to 6 minutes	slot confirmation, tx finality, final wallet settlement
PAXG	connect a Web3 wallet	typically 1 to 6 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

{
  "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

1

Detect 🔎

Automated alerts fire when latency, exposure, settlement timing, reconciliation drift, or dependency health moves outside expected bounds.

2

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.

3

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.

4

Communicate

Users receive clear status updates through platform status surfaces and support channels. Silence during incidents is unacceptable.

5

Reconcile

After recovery, all affected execution, wallet, and staking records are rechecked for ledger completeness and accounting consistency.

6

Review

A formal post-incident review should preserve timeline, root cause, impact, remediation, and control improvements.

---

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

Booster reference

• 14D: +10%

• 30D: +20%

• 90D: +50%

• 180D: +100% (2×)

These selections and their resulting lock windows should be fully auditable.

---

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.