GDPR segregation plan - Bitwise Onchain Dev & Ops

Executive summary

opsdb currently mixes high-sensitivity customer identity and authentication data with operational and pseudonymous validator and financial data in a single database boundary. This forces strict access control on all services and data in the database regardless of their sensitivity. To allow wider access to operational data, we need to segregate the database into two boundaries:

keep low-risk and pseudonymous operational data in coredb
keep direct identifiers, credentials, and high-risk free-text or file content in a sensitive database boundary
expose only minimal join-safe identifiers to most runtime services

Data classification definitions

Class A data can directly identify a user or customer, enable account access, or contain unbounded sensitive content.
Class B data is not directly identifying on its own, but is linked to customer IDs or pseudonymous data or commercially sensitive.
Class C data is public chain or reference data.

`opsdb` inventory and sensitivity

Table	Primary contents	Classification	Notes	Accessing services and host box	Surfacing requirements
`t_users` (identity profile fields)	`f_name`, `f_email`, `f_email_verified`, `f_timezone`, `f_created`	A	Direct customer identity and contact profile	`attestantd`, `reportd`, `acli`
`t_users` (authentication/control fields)	`f_webauthn_credentials`, `f_allow_registration`, `f_acting_for`	A	Authentication and delegated-access controls	`attestantd`, `acli`
`t_users` (`f_fee_rate` JSONB)	Fee/tax percentages by source/asset and validity windows (`FeeRateConfig`)	A/B	Commercial terms; not direct identity, but commercially sensitive	`reportd`, `acli`	BAM for accounting and revenue projections
`t_users` (`f_invoice_configs` JSONB)	Invoice options (`InvoiceConfig`): tax title/number/description, contact addresses, payment preferences	A	Customer billing metadata	`attestantd`, `reportd`, `acli`
`t_users` (`f_periodic_reports` JSONB + comms flag)	Report schedule and preferences (`PeriodicReport`): recipients/cc, subaccounts, assets/sources, timing/frequency/theme, plus email notification flag	A	Contains contact emails for reporting preferences	`attestantd`, `opsd/reports`
`t_users` (`f_mev_relay` JSONB + UI/account metadata)	Per-customer relay config (`CustomerRelayConfig`: relay ID, grace, min value) plus `f_currency`, `f_ui_scope`, `f_theme`, `f_enc_pubkey`	B	Mostly account and operational metadata; no direct identity in the relay JSON itself	`attestantd`, `opsd`, `acli`
`t_user_tokens`	User bearer/API tokens, scope, expiry	A	Secret credential material	`attestantd`, `acli`
`t_user_files`	User files and metadata	A	File content can include PII and financial documents	`opsd/reports` (writes reports), `attestantd` (reads), `acli`
`t_audit`	User operation logs, IP, payload JSON, errors	A	IP and payload content are privacy-sensitive	`attestantd` (write/read), `acli` (read)	Attestant compliance team
`t_customer_financials`	Customer financial ledger	B	Financial and operational accounting data	`opsd`, `opsd/reports`, `attestantd`, `reportd`	C1 for reporting (subaccount grouping)
`t_near_financials`	NEAR financial ledger plus epoch metadata	B	Same model as financials with NEAR enrichments	`nearfinancialsd`, `reportd`; `reportd` `nearfinancialsd`
`t_customer_validators`	Customer-validator assignments, states, balances, proposer config (JSON), rocketpool and EigenLayer validator metadata (JSON)	B	Customer-linked pseudonymous data	`opsd`, `opsd/reports`, `attestantd`, `feerd`, `lidod`, `summaryd`, `acli`	C1 for reporting (subaccount grouping, fee recipient addresses)
`t_customer_epoch_metrics`	Per-customer epoch performance metrics	B	Commercially sensitive customer performance	`opsd`, `attestantd`, `acli`
`t_proposer_config_histories`	Historical proposer config by customer/subaccount	B	Contains customer-linked operational config	`opsd`, `opsd/reports`, `attestantd`, `feerd`, `acli`	C1 for reporting (historical fee recipient addresses)
`t_rejected_validators`	Rejected validator pubkeys by user	B	Customer-to-validator linkage	`services/eth2` flows via `attestantd` and `opsd`
`t_customer_rocketpool_node_operators`	Rocket Pool operators linked to customer	B	Addresses are public on-chain; the linkage is sensitive	`opsd`, `attestantd`	To be deprecated
`t_customer_eigenpods`	Eigenpods linked to customer	B	Same pattern	`attestantd`, `services/eigenlayer`
`t_customer_starknet_delegators`	Starknet delegators linked to customer	B	Same pattern	`starkd`
`t_customer_solana_delegators`	Solana delegators linked to customer	B	Same pattern	`solanad`, `summaryd`
`t_customer_near_delegators`	NEAR delegators and validator address linked to customer	B	Same pattern	`nearfinancialsd`, `summaryd`
`t_unassigned_validators`	Unassigned validator pool metadata	B	Mostly operational inventory data	`opsd`, `opsd/reports`, `acli`	C1 for reporting (all validator keys in the pool)
`t_eth_mev_relays`	Relay catalog: name/url/pubkey	C	Public-facing reference set	`attestantd`, `acli`
`t_chainmeta`	Chain constants, genesis data, and deposit contract metadata	C	Public chain metadata	`attestantd`, `services/eth2`
`t_metadata`	Internal key/value JSON metadata	N/A	Mostly operational	`attestantd`, `opsd`, and DB versions

Access flow diagram

The following Sankey diagram shows the service-to-table access flow represented by the table above.

If the embedded diagram does not render, open opsdb_sankey_access_flow.html directly.

Target architecture overview

The current opsdb serves two concerns at once: high-sensitivity customer and account workflows, and lower-sensitivity operational workflows.
The target architecture separates those concerns into two database boundaries and places services according to the highest-sensitivity data they require.
coredb becomes the new operational database, holding mainly Class B and Class C data, together with only the minimum internal identifiers needed to join operational records.
core box hosts that lower-sensitivity operational boundary. Services moved there should not need direct access to names, emails, authentication material, audit logs, reporting-recipient data, or file contents.
The existing high-sensitivity boundary remains the home for direct identity, authentication, account-control, audit, reporting-contact, and file-content workflows.
Initially, that sensitive boundary can remain in the current opsdb, and later be reduced into a dedicated sensitive database as the migration progresses.

Data exposure on `core` box

core box should expose only coredb and the services that need that data.
The exposed dataset should be limited to Class B and Class C information, plus minimal join-safe internal identifiers such as customer IDs where operational linking is still required.
This includes customer-linked operational data such as Customer IDs, subaccounts, validator assignments, proposer config history, performance metrics, customer financial ledger data, unassigned validator pool data, and customer-to-on-chain linkages such as eigenpods, and delegated addresses.
It also includes public or low-confidentiality reference data such as MEV relay metadata, chain metadata, and other internal service metadata.
core box will not expose direct identity or account-control data such as names, emails, auth credentials, audit/IP logs, invoice contact details, periodic report recipient lists, or user file contents.
Report generation, account management, authentication, and other workflows that require direct identifiers should remain outside core box and continue to use the sensitive boundary (in client box).

Migration phases

Phase 0: move non-sensitive tables and dependent flows to `coredb`

Stand up coredb on a separate core box.
Run coredb in parallel with the existing opsdb.
Migrate whole tables that are already non-sensitive or acceptable to expose on core box, together with the read and write paths that depend on them.
Ensure all services on core box that need these datasets can read coredb before any cutover.

Phase 1: move sensitive tables into a dedicated sensitive boundary

Create a separate sensitive database boundary for Class A tables and other high-risk content.
Move services that rely only on coredb to the core box.
Remove duplicated non-sensitive data from the legacy opsdb once the new paths are live.
Leave account management, reporting-contact, authentication, audit, and file workflows on the sensitive side.

Phase 2: split `t_users` by data class

Split the current t_users table into purpose-specific tables aligned to sensitivity.
t_users keeps identity profile fields and authentication/control fields.
t_users_reporting stores invoice configuration and periodic report data.
t_users_config stores non-sensitive account and runtime configuration data.
Expose only the minimum identifiers and configuration needed by services running on core box.

Phase 3: move services according to final data requirements

Move the opsd/reports service, which is responsible for periodic reports, into reportd.
Move the remaining opsd services to the core box once they depend only on coredb and t_users_config.
Keep any service that still requires Class A identity, authentication, audit, reporting-contact, or file data on the sensitive side until it is split or redesigned.