Supported & Planned Assets

Overview · Architecture · Agent · Smart Contracts · Release v0.1.0 · Security

Built to Compound.

COMPD is a treasury-driven protocol on BNB Chain, connecting token activity, on-chain capital allocation, autonomous strategy infrastructure, buyback mechanisms, and holder rewards within a unified financial architecture.

The protocol is designed to convert eligible treasury inflows into structured capital operations, with execution, settlement, and allocation governed by dedicated on-chain components.

COMPD brings together three primary systems:

• On-Chain Protocol — treasury accounting, strategy execution boundaries, settlement, buyback, and holder reward infrastructure.
• Strategy Agent — market observation, risk evaluation, and strategy planning for supported assets.
• Protocol Interface — visibility into treasury activity, transaction evidence, strategy operations, and protocol accounting.

The initial trading integration is focused on AMZNx, a tokenized equity asset, through supported PancakeSwap liquidity on BNB Chain.

COMPD is built around a simple principle: capital entering the protocol should be accounted for, allocated according to defined rules, and reconciled against verifiable on-chain activity.

The protocol separates financial responsibilities into distinct components rather than relying on a single unrestricted treasury wallet.

Its architecture covers treasury accounting, strategy execution, realized-profit settlement, buyback operations, and holder reward distribution.

COMPD is designed to operate through a connected financial lifecycle:

1. Token activity — trading activity and applicable token fee mechanisms generate eligible protocol inflows.
2. Treasury funding — eligible assets are received and accounted for through the protocol's treasury infrastructure.
3. Capital allocation — available capital is separated according to applicable reserve and strategy rules.
4. Strategy execution — authorized execution infrastructure interacts with supported liquidity.
5. Settlement — completed strategy outcomes are reconciled against actual asset movements.
6. Protocol allocation — eligible realized results are processed through the applicable buyback, reserve, and holder reward mechanisms.

The lifecycle depends on the relevant contracts, liquidity, funding, execution permissions, and operational conditions.

COMPD's operational lifecycle is intended to begin following the official token launch and completion of the necessary on-chain prerequisites.

Token launch and liquidity alone do not automatically guarantee strategy execution. The required contracts, integrations, capital availability, and risk controls must also satisfy their operating conditions.

Treasury capital is not assumed to exist simply because the token has launched.

The applicable fee and funding mechanisms must actually deliver assets to the designated treasury or vault infrastructure before those assets can be considered available for allocation.

COMPD's accounting architecture distinguishes available capital, reserved capital, and realized strategy outcomes.

COMPD separates user-facing observation, off-chain strategy decisions, and on-chain financial operations.

flowchart TD
    A["Official Token Launch"]
    B["Token Liquidity & Trading Activity"]
    C["Eligible Protocol Fee Inflows"]
    D["Treasury / Vault"]
    E["Kernel — Accounting & Reserves"]
    F["Strategy Agent — AMZNx"]
    G["StrategyExecutor"]
    H["PancakeSwap — BNB Chain"]
    I["Settlement"]
    J["Buyback Infrastructure"]
    K["Holder Rewards"]
    L["COMPD Interface"]

    A --> B
    B --> C
    C --> D
    D --> E
    F -.->|"Proposed strategy actions"| G
    E -.->|"Authorized capital lifecycle"| G
    G --> H
    H -.->|"Execution outcomes"| I
    I --> E
    E -.->|"Eligible allocations"| J
    E -.->|"Eligible allocations"| K
    E -.->|"Observation"| L

This diagram represents the intended protocol lifecycle. Actual asset movements and allocation paths are determined by deployed contracts and verified execution behavior.

COMPD's on-chain architecture is organized around accounting integrity, controlled execution, and separation of financial responsibilities.

The Kernel coordinates the accounting responsibilities of the protocol.

Its role is to maintain the distinction between treasury capital, strategy-related accounting, and other protocol allocations.

The Kernel's financial state must be interpreted according to actual contract transitions and asset movements.

StrategyExecutor defines the on-chain execution boundary for authorized strategy operations.

It is separate from the Agent's observation and planning processes.

An Agent decision does not independently establish execution authority. Transactions remain subject to the relevant execution permissions and contract-level requirements.

COMPD distinguishes realized strategy outcomes from unrealized changes in market value.

Settlement is intended to reconcile completed strategy activity with actual capital movements before applicable profit-related allocations are recognized.

This separation is fundamental to the protocol's accounting model.

COMPD's treasury infrastructure is designed to receive eligible protocol inflows and account for them through defined capital categories.

• Record eligible capital entering the protocol.
• Maintain relevant reserve and allocation boundaries.
• Track capital committed to authorized strategy activity.
• Reconcile returned capital and realized outcomes.
• Support downstream protocol operations under their applicable rules.

flowchart LR
    A["Eligible Fee / Funding Inflows"]
    B["Treasury Accounting"]
    C["Available Capital"]
    D["Authorized Strategy"]
    E["Realized Settlement"]
    F["Protocol Allocations"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

Accounting entries are not equivalent to physical token transfers. All capital movement and settlement must be evaluated against actual contract behavior and transaction evidence.

COMPD's initial Agent trading scope is focused on AMZNx, using compatible PancakeSwap liquidity on BNB Chain.

The initial scope is intentionally narrow, allowing the execution and risk framework to be evaluated against a specific supported asset before considering additional integrations.

BNB and WBNB serve capital and execution-routing responsibilities; they do not redefine the initial strategy as unrestricted cryptocurrency trading.

1. Market observation

The Agent evaluates available market information relevant to AMZNx, including supported on-chain liquidity and independent reference data.

2. Risk evaluation

Proposed actions are assessed against applicable execution conditions, market-data freshness, liquidity constraints, and operational safeguards.

3. Strategy planning

The Agent constructs a potential execution decision based on the supported strategy configuration.

4. Authorized execution

Eligible actions may be submitted through the configured execution boundary and compatible adapter.

5. Settlement

Completed execution results are reconciled through the protocol's settlement and accounting components.

Tokenized equity trading introduces dependencies beyond ordinary cryptocurrency swaps.

Execution safeguards must account for reliable independent reference pricing, stale data, market availability, and relevant trading restrictions.

A functioning DEX pool alone does not establish that the underlying asset can be traded safely under all market conditions.

COMPD includes dedicated infrastructure for protocol-defined buyback operations.

Buyback activity is separate from strategy planning and treasury accounting, with its own applicable funding, authorization, and execution requirements.

The availability of treasury capital or positive strategy performance does not independently guarantee that a buyback will occur.

Actual buyback execution depends on the governing contract rules, available funds, and operational configuration.

COMPD includes holder reward infrastructure intended to account for and distribute eligible protocol allocations.

Reward-related operations are separated from strategy execution to maintain clear financial responsibilities.

1. An eligible allocation is recognized under the applicable protocol rules.
2. The corresponding reward accounting or distribution mechanism processes that allocation.
3. Holder eligibility is determined using the implemented rules and relevant data.
4. Rewards become distributable or claimable according to the configured mechanism.

Holder rewards depend on actual protocol activity and applicable allocations. They do not represent a fixed yield or guaranteed return.

apps/interface/

The COMPD interface provides a user-facing layer for exploring protocol information, treasury-related observations, and available transaction evidence.

Its responsibilities include protocol presentation, dashboard views, monitoring integrations, and local development tooling.

packages/agent/

The Agent system supports observation, risk evaluation, and strategy planning for the supported trading scope.

Its responsibilities remain distinct from the authority of on-chain execution contracts.

A proposed action, simulated result, or dashboard observation should not be interpreted as a completed blockchain transaction without corresponding execution evidence.

COMPD/
├── apps/
│   └── interface/
├── packages/
│   ├── agent/
│   └── protocol/
├── docs/
│   └── ARCHITECTURE.md
├── README.md
├── SECURITY.md
└── CONTRIBUTING.md

The repository organizes interface, Agent, protocol, and supporting documentation into separate component directories.

Private operational credentials, deployment secrets, and runtime infrastructure are not part of the public documentation.

cd apps/interface
npm ci
npm run check
npm test
npm run build
npm run dev

cd packages/agent
python -m unittest discover -s tools/agent-scheduler -p test_dashboard_api.py
python -m unittest discover -s tools/agent-scheduler -p test_xstocks_agent.py

cd packages/protocol
npm install
npm run build
npm test

These commands cover local development and testing. Deployment and transaction execution require separate configuration and authorization.

Primary network: BNB Smart Chain
Chain ID: 56
Initial strategy asset: AMZNx
Initial execution venue: PancakeSwap

Before relying on any contract integration, verify the deployed address, runtime bytecode, connected contracts, permissions, and relevant transaction evidence.

Contract source, ABI exports, and local tests should be interpreted separately from verified production deployment information.

COMPD's security model emphasizes separation between financial accounting, strategy evaluation, and transaction execution.

Key considerations include:

• Execution authorization: Strategy operations must respect applicable contract permissions.
• Treasury integrity: Accounting balances and reserves must remain distinguishable from physical asset transfers.
• Settlement integrity: Realized outcomes must be reconciled against completed activity.
• External integrations: Execution adapters and liquidity venues introduce additional technical dependencies.
• Market-data reliability: AMZNx execution requires appropriate reference-data freshness and market safeguards.
• Operational security: Signing credentials, privileged configuration, and infrastructure access require controlled handling.

The existence of these architectural boundaries does not replace independent security assessment or integration validation.

See SECURITY.md for responsible disclosure and repository security guidance.

COMPD's intended operational activation follows the official token launch and the establishment of the necessary treasury, liquidity, and execution conditions.

The primary operating dependencies include:

Activation of individual components depends on their own prerequisites. These conditions describe the planned operating model rather than a guarantee that every component activates automatically at launch.

Technical contributions should follow the repository's contribution and security guidelines.

Relevant documentation:

• Contributing Guidelines
• Security Policy
• Architecture Documentation

Changes affecting accounting, execution permissions, settlement, or financial allocations should include relevant testing and technical justification.

No root first-party license is currently included.

Public availability of source code does not automatically grant permission to reproduce, modify, or redistribute first-party COMPD implementations.

Third-party components remain subject to their respective licenses and attribution requirements.

COMPD — The Compounder

Built to Compound.