01 / SYSTEM OVERVIEW
Purpose and system boundaries
EQUITY is framed as a market-focused protocol in which defined ecosystem activity may produce resources for a protocol treasury, and approved treasury policy may direct a portion of those resources toward supported tokenized equity exposure.
The protocol is not described as a broker, exchange, investment adviser, bank or direct issuer of public company shares. The term exposure is used deliberately: legal title, beneficial ownership, redemption rights, dividend treatment and bankruptcy remoteness depend on the selected tokenized instrument, issuer, custodian, jurisdiction and contractual structure.
Design objectives
- Make treasury inflows, policy decisions and allocations independently auditable.
- Separate accounting state from execution, custody and market-data providers.
- Constrain every allocation with explicit limits, approvals and emergency controls.
- Represent stale, incomplete or disputed data without presenting it as live truth.
- Minimize privileged operations and make administrative actions observable.
Non-goals
This document does not define a guaranteed yield, algorithmic peg, redemption promise, synthetic stock entitlement, automatic dividend pass-through, public launch date or permissionless access model. Those claims require separate technical, legal and operational validation.
02 / REFERENCE ARCHITECTURE
Layered by responsibility
The proposed architecture uses narrow modules so a failure in market data, execution or presentation cannot silently redefine treasury ownership or protocol accounting.
Activity layer
Records eligible protocol events and attributes them to an accounting period.
Accounting layer
Normalizes inflows, fees, liabilities, reserves and distributable resources.
Policy layer
Evaluates limits, approved instruments, concentration and liquidity constraints.
Execution layer
Creates approved orders through an integrated venue or regulated provider.
Custody layer
Holds resulting assets and exposes independently reconcilable balances.
Reporting layer
Publishes timestamped positions, status and provenance without fake live values.
Trust boundaries
On-chain records, off-chain execution records and custodian statements are distinct evidence domains. No single API response should be treated as proof of solvency. A production implementation should reconcile protocol liabilities and controlled assets using independently sourced records, deterministic identifiers and signed snapshots.
Failure containment
Market-data outages should pause valuation-dependent actions without blocking basic accounting. Execution failures should preserve approved intent for review but never be reported as filled. Custody discrepancies should place affected instruments into a restricted state until reconciliation is complete.
03 / CAPITAL LIFECYCLE
From activity to reconciled exposure
Every unit of treasury value should move through a traceable state machine. A user-facing portfolio entry is the final reporting result, not the source of truth.
| State | Required evidence | Exit condition |
|---|---|---|
| Observed | Eligible event ID, source, timestamp and amount | Event passes validation and finality policy |
| Recognized | Accounting entry and classification | Period controls accept the entry |
| Available | Settled resource net of liabilities and reserves | Allocation window opens |
| Approved | Policy decision, limits and authorized signers | Execution instruction is created |
| Executed | Venue order ID, fills, fees and timestamps | Settlement is confirmed |
| Custodied | Custodian position and ownership record | Independent reconciliation succeeds |
| Reported | Signed snapshot with provenance and freshness | Superseded by a newer snapshot |
04 / TREASURY ACCOUNTING
Deterministic accounting before allocation
Allocation begins only after resources are recognized, settled and netted against explicit obligations. The policy engine consumes accounting outputs; it does not invent balances.
gross_resources(t)
- protocol_operating_costs(t)
- accrued_liabilities(t)
- required_reserves(t)
- unsettled_commitments(t)
= allocatable_resources(t)
target_amount(asset_i, t)
= allocatable_resources(t) × approved_weight(asset_i, t)Ledger requirements
- Double-entry records with immutable transaction identifiers and explicit reversal entries.
- Separate books for operational resources, reserves, committed orders and settled positions.
- Decimal precision defined per accounting asset; no floating-point arithmetic for value-bearing state.
- Period close rules that prevent retroactive mutation without a visible restatement.
- Source references linking each summarized balance to underlying events.
Illustrative allocation
Percentages shown on the public site are interface examples. They do not represent a current mandate, portfolio, recommendation or promise. A production policy would define minimum order sizes, turnover ceilings, concentration limits, cash buffers and rebalance thresholds.
05 / ASSET FRAMEWORK
Eligibility is a governed decision
A ticker alone is insufficient. Each supported exposure requires an approved instrument record describing issuer, legal structure, custody path, venue, liquidity, market data and jurisdictional constraints.
Instrument integrity
Verify issuer, underlying reference, issuance controls, redemption mechanics and token contract provenance.
Market quality
Assess liquidity, spread, market hours, venue concentration, slippage and suspension behavior.
Custody
Document wallet or account control, segregation, recovery, transfer restrictions and insolvency treatment.
Compliance
Map eligible participants, jurisdiction, sanctions controls, transfer restrictions and reporting duties.
Data quality
Define authoritative price sources, corporate-action handling, timestamps and stale-data thresholds.
Operational fit
Confirm settlement workflow, minimum sizes, fees, reconciliation support and incident contacts.
| Status | Meaning in EQUITY interfaces |
|---|---|
| PROPOSED | Specified in this document but not represented as deployed infrastructure. |
| PREVIEW | Visible in the interface using illustrative, non-live data. |
| SUPPORTED | Eligible under a future approved policy; not a claim of current holdings. |
| COMING SOON | Presented as roadmap intent with no delivery or availability guarantee. |
06 / EXECUTION, CUSTODY & RECONCILIATION
No fill without evidence
A future execution adapter should be replaceable, idempotent and unable to exceed policy authorization. Custody balances must be verified independently from order acknowledgements.
Execution controls
- Every order references a unique approved allocation intent and cannot exceed its remaining amount.
- Idempotency keys prevent duplicated orders during retries or network uncertainty.
- Pre-trade checks enforce approved asset, venue, side, notional, slippage and concentration limits.
- Partial fills remain explicit; canceled or rejected quantities return to an uncommitted state.
- Execution reports retain venue timestamps, fee components and original provider payload hashes.
Reconciliation controls
At minimum, reconciliation compares internal positions, venue fills, settlement records and custodian balances. Differences are classified by timing, fees, corporate actions, transfer state or unexplained variance. Unexplained differences should trigger an allocation freeze for the affected instrument rather than an automatic balancing entry.
07 / PROPOSED CONTRACT INTERFACES
Minimal on-chain authority
If smart contracts are introduced, they should record constrained intent and verifiable state while keeping provider-specific execution logic behind audited adapters. The following interface is illustrative only.
interface ITreasuryPolicy {
function proposeAllocation(
bytes32 instrumentId,
uint256 maximumNotional,
uint64 validAfter,
uint64 validUntil,
bytes32 policyHash
) external returns (bytes32 intentId);
function authorizeIntent(bytes32 intentId) external;
function cancelIntent(bytes32 intentId, bytes32 reason) external;
function pauseInstrument(bytes32 instrumentId) external;
}
// Proposed events
event AllocationProposed(bytes32 indexed intentId, bytes32 indexed instrumentId);
event AllocationAuthorized(bytes32 indexed intentId, address indexed authorizer);
event AllocationCancelled(bytes32 indexed intentId, bytes32 indexed reason);
event InstrumentPaused(bytes32 indexed instrumentId, address indexed operator);Contract invariants
- An expired, canceled or paused intent cannot be executed.
- Cumulative execution cannot exceed the authorized maximum notional.
- Role changes and emergency actions emit indexed events.
- Upgrades, if permitted, require delay, explicit authorization and public implementation hashes.
- External calls follow checks-effects-interactions and use narrowly scoped allowances.
Signing model
Production administration should use threshold authorization with distinct proposer, approver, executor and emergency roles. Key custody, signer independence, rotation and recovery procedures are operational security requirements, not merely contract settings.
08 / SECURITY MODEL
Assume every boundary can fail
Security is defined by controls that reduce blast radius, preserve evidence and support safe recovery—not by claiming that compromise is impossible.
| Threat | Primary control | Safe response |
|---|---|---|
| Compromised operator key | Threshold signing, limits, delay and role separation | Revoke role, pause affected adapter, rotate keys |
| Manipulated price input | Multiple sources, deviation bounds and freshness checks | Disable valuation-dependent execution |
| Duplicate execution | Idempotency key and cumulative fill invariant | Reject replay and reconcile external state |
| Custody discrepancy | Independent balance reconciliation | Freeze instrument and investigate variance |
| Malicious upgrade | Timelock, quorum and published implementation hash | Cancel queued change or activate emergency pause |
| Frontend compromise | Signed releases and human-readable transaction checks | Disable transaction entry and publish incident notice |
Incident severity
Severity should be based on potential loss, integrity impact, scope and recoverability. Critical incidents include unauthorized transfer capability, material accounting divergence, compromised upgrade authority or loss of custody access. Response plans should identify decision owners, evidence retention, communication channels and recovery gates.
09 / GOVERNANCE & CHANGE CONTROL
Policy changes must be legible
Governance should expose exactly what is changing, when it becomes effective, which risk limits it affects and how the change can be canceled before execution.
Controlled parameters
- Eligible instrument registry and instrument-specific status.
- Maximum portfolio weight, order notional, turnover and venue concentration.
- Reserve requirement, allocation cadence and minimum liquidity threshold.
- Approved adapters, custodians, price sources and stale-data windows.
- Signer sets, voting thresholds, timelocks and emergency permissions.
Change lifecycle
A proposed change should include machine-readable parameters, a human-readable rationale, simulation results and a content hash. After approval, a delay allows independent review. Execution must verify that the queued hash matches the exact applied payload. Emergency action should be able to reduce risk quickly, but should not silently expand authority.
10 / DATA & OBSERVABILITY
Provenance before presentation
Every displayed figure should carry a source, observation time, processing time, unit, methodology version and freshness status. Missing data should remain missing rather than being interpolated as fact.
{
"snapshot_id": "content-addressed identifier",
"as_of": "ISO-8601 timestamp",
"portfolio_status": "preview | reconciled | stale | restricted",
"accounting_asset": "configured unit",
"positions": [{
"instrument_id": "registry identifier",
"quantity": "decimal string",
"valuation": "decimal string or null",
"price_source": "source identifier or null",
"reconciled_at": "ISO-8601 timestamp or null"
}],
"methodology_hash": "versioned policy digest"
}Operational signals
Monitoring should cover ledger imbalance, stale market data, failed orders, settlement aging, reconciliation differences, policy rejections, privileged calls and provider availability. Alerts require severity, owner, escalation path and a measurable recovery objective.
Public reporting
Public interfaces should distinguish allocation targets from settled positions and last-known values from current values. A timestamp without provenance is insufficient. Historical snapshots should remain retrievable so corrections and methodology changes are visible.
11 / TESTING & DEPLOYMENT
Evidence-driven release gates
A production release should advance through deterministic tests, adversarial review and operational rehearsals. Deployment is a controlled state transition, not merely a successful compilation.
Unit and property tests
Accounting conservation, authorization, expiry, replay protection, rounding and limit enforcement.
Integration tests
Provider timeouts, partial fills, duplicated callbacks, stale prices and reconciliation differences.
Fork and simulation tests
Upgrade compatibility, role migration, liquidity assumptions and adverse execution scenarios.
Security review
Threat model, static analysis, dependency review, independent audit and remediation verification.
Operational rehearsal
Signer loss, provider outage, custodian discrepancy, paused asset and public incident communication.
Release verification
Artifact hashes, environment separation, configuration review, monitoring and rollback readiness.
Proposed implementation phases
- Specification: resolve legal structure, providers, accounting rules and risk policy.
- Read-only prototype: ingest sandbox data and publish clearly labeled non-production snapshots.
- Controlled pilot: execute bounded test allocations with independent reconciliation and manual approvals.
- Hardening: audits, failover, monitoring, incident exercises and governance delay.
- Production readiness: launch only after legal, security, custody and operational acceptance criteria pass.
12 / RISKS, ASSUMPTIONS & DISCLOSURES
Exposure introduces layered risk
Tokenized equity instruments can combine market, issuer, custody, smart-contract, venue, liquidity, legal, regulatory, oracle and operational risks. Technical controls cannot eliminate these dependencies.
Principal risk categories
- Market risk: reference assets may lose value or become unusually volatile.
- Tracking risk: a tokenized instrument may diverge from its stated reference asset.
- Issuer risk: enforceability and redemption depend on the instrument issuer.
- Custody risk: assets or keys may be frozen, lost, compromised or subject to insolvency proceedings.
- Liquidity risk: positions may not be executable at expected size or price.
- Regulatory risk: access, transferability or operation may change by jurisdiction.
- Technology risk: contracts, bridges, providers, interfaces or data pipelines may fail.
- Governance risk: authorized actors may make poor, delayed or malicious decisions.
Current assumptions
This document assumes that any future implementation will select legally and technically suitable providers, complete applicable compliance work, publish verified deployment addresses and document user eligibility before enabling value-bearing actions. None of those assumptions should be interpreted as completed work.