Architecture

How the whole system fits together: smart contracts on Ethereum, subgraphs on The Graph, and off-chain services for email and activity tracking.

10102 Computing Legacy is deliberately layered so that the on-chain layer is self-sufficient, and the off-chain layer is strictly additive. If the off-chain services disappeared tomorrow, every existing legacy and timelock would still function β€” you'd lose email reminders and the pretty UI, but you'd keep the plan.

The layers

1. On-chain: the core plan

Solidity contracts on Ethereum. Deployed behind upgradeable proxies owned by a Safe multisig. Verified on Etherscan and published at github.com/10102-io/computing-sc.

  • Legacy routers β€” MultisigLegacyRouter, TransferLegacyRouter (Safe owners), TransferEOALegacyRouter (plain EOAs).

  • Timelock router β€” TimeLockRouter.

  • Per-user legacy contracts β€” deployed deterministically via LegacyDeployer using CREATE2, so the address is predictable before deployment.

  • Safe integration β€” a Safe Guard tracks last-activity timestamps; a Safe Module executes activation (adding owners or transferring assets).

  • Premium contracts β€” PremiumSetting stores watcher/reminder configuration (addresses only β€” reminder emails live off-chain); PremiumRegistry records subscriptions; PremiumReminderView is a standalone read-only contract the reminder service polls for due reminder windows.

Full address list, for every deployed contract and network, lives in contract-addresses.json of the computing-sc repository.

2. Indexing: The Graph

A single subgraph per chain provides fast, reliable read access to the parts of the system that would be painful to query from raw RPC:

  • Legacy/timelock/reminders subgraph β€” indexes every event emitted by the routers and 10102-enabled Safes: creations, edits, deletions, activations, reminder configurations, and the PII-free LegacyEmailNotifyRequested notify events (as NotifyRequested) that the off-chain reminder worker consumes. The UI reads the bulk of its state from here.

Everything else is direct on-chain. Token balances for the "your assets" pickers during legacy creation are fetched via viem against the canonical TokenWhitelist contract plus per-token ERC-20 balanceOf (src/services/web3-assets-service.ts). System-wide aggregates (total value locked across all legacies, timelocks and 10102-enabled Safes) are computed by the admin panel via Multicall3 plus ERC-20 balanceOf / allowance walks against the entity set returned by the subgraph β€” see the computing-admin repository for the implementation.

The UI prefers subgraph reads for the indexed data but falls back to direct on-chain reads (via viem) for post-mutation freshness, so stale subgraph data never blocks a newly-valid action.

3. Off-chain services

Strictly additive layers that improve UX but can fail without breaking the plan:

  • Chainlink Functions β€” bridges Moralis API data into on-chain activation checks for EOA legacies (where the EVM can't natively read a wallet's last-tx timestamp).

  • Reminder worker β€” an off-chain service (Railway + Postgres) that drives email reminder evaluation and delivery. It reads PII-free notify events from the subgraph plus a read-only on-chain "due" view (PremiumReminderView), keeps recipient emails encrypted off-chain, and sends through the mail service. This replaces the retired Chainlink Automation cron and Chainlink Functions email path (decommissioned on mainnet 2026-06-02).

  • Mailjet β€” SMTP delivery for reminder emails, behind the 10102 mail proxy the worker posts to.

  • Public RPC providers + Etherscan β€” fallback read paths the UI can switch to.

Section index

A note on upgradeability

Every contract deployed by 10102 sits behind a transparent upgradeable proxy whose admin is a Safe multisig held by the 10102 team. We can patch bugs and ship improvements β€” we cannot silently drain assets or retroactively alter an existing legacy's terms. Beneficiaries, owners, allocations, and activation windows are stored in per-legacy state that upgrades leave intact. Migration to a community-governed admin is on the public roadmap.

Last updated