IDFI Documentation

Current Access Model

• Private infrastructure: IDFI EX is currently intended for controlled internal development and operational validation.
• No public deposits: public customer funds are not currently accepted into the IDFI EX operating-capital domain.
• No public trading: the current infrastructure does not provide public customer trading access.
• No public liquidity admission: public liquidity providers and unrelated third-party capital are not part of the current CORE-HPP model.
• Controlled authority: access to internal operational functions does not by itself create capital, market or execution authority.

Capital & Execution Security

• Protocol-owned capital: the current CORE-HPP model is designed around protocol-controlled operating capital rather than public or unaffiliated third-party capital.
• Capital separation: treasury capital remains distinct from capital admitted into the operating accounting domain.
• Bounded capacity: available capital does not automatically become executable market capacity. Capacity remains subject to accounting, market depth, inventory and operational risk controls.
• Asset-local inventory: supported assets are designed to operate within independent inventory domains without unrestricted cross-asset borrowing or silent balance substitution.
• Execution separation: a market-action candidate does not independently authorize wallet, settlement or transaction execution.
• No silent resizing: candidate notional and asset identity must remain consistent through applicable control layers.

Market-Control Security

• Market actions must represent a legitimate economic purpose.
• Self-trading and synthetic-volume targeting are not permitted design objectives.
• Market capacity must remain within independently bounded risk and inventory limits.
• Stale market data, excessive spread, excessive price deviation, insufficient executable depth or incomplete control state are designed to prevent a market-action candidate from receiving approval.
• Invalid or incomplete control conditions are designed to fail closed rather than create execution authority.

Contract & Impersonation Security

IDFI users and observers should independently verify all public on-chain information before interacting with any digital asset or external market.

• Always verify contract addresses through official IDFI documentation and recognized blockchain explorers.
• Beware of similarly named assets, typo-tokens, unofficial pairs and impersonation accounts.
• IDFI does not recognize unlisted third-party contracts or unofficial pairs as protocol-authorized deployments.
• Existing external market information should be independently verified on-chain before interaction.
• Future contract deployments, if any, will be documented only after deployment and verification.

Credential & Communication Security

• IDFI will never request private keys, seed phrases or wallet recovery credentials through direct messages.
• Private keys and signing credentials must never be treated as public operational data.
• Unsolicited requests involving wallet credentials, token transfers or unofficial investment arrangements should be treated as suspicious.
• Official project information should be verified through IDFI documentation and verified communication channels.

Security Principles

• Isolation: capital, accounting, inventory, market capacity and execution authority remain explicitly separated.
• Least Authority: access to one control domain does not automatically grant authority over another.
• Bounded Risk: market activity cannot exceed approved capacity and applicable inventory constraints.
• Traceability: internal control decisions are designed to remain attributable and auditable.
• Fail Closed: invalid, stale, inconsistent or incomplete control state does not create market or execution authority.

Current Security Scope

The current development phase is focused on validating IDFI EX accounting, capital isolation, inventory, market-data and risk-control layers. Security architecture will be reviewed again before any broader operational access, public-facing functionality or additional on-chain deployment is considered.

Documentation Status

• Current architecture reference: this documentation page describes the present IDFI EX infrastructure model and current development position.
• Earlier whitepaper: existing whitepaper material documents an earlier stage of IDFI's architecture and development assumptions.
• Current development focus: protocol-owned capital, capital isolation, bounded market capacity, asset-local inventory controls and private market infrastructure.
• Public functionality: public deposits, public trading and public liquidity participation are not currently enabled.

Existing Whitepaper

The existing IDFI whitepaper was prepared during an earlier development phase and includes concepts associated with the project's original on-chain market and ecosystem design.

Some concepts, planned assets, liquidity models or development assumptions described in earlier material may no longer represent the current development strategy.

The existing whitepaper is therefore retained as historical project documentation rather than presented as the authoritative specification of the current IDFI EX architecture.

Current Architecture Documentation

The current IDFI EX architecture is documented through the technical and operational sections of this documentation page.

• IDFI EX Architecture: isolated private market infrastructure with explicitly separated capital, capacity and execution-control domains.
• Controlled Capital / CORE-HPP: protocol-owned operating capital subject to explicit accounting and ownership boundaries.
• Safe Capacity & Risk Controls: market capacity bounded by available operating capital, executable depth, inventory limits, market conditions and operational risk limits.
• Market Infrastructure: internal market-control logic designed around legitimate economic purpose, bounded candidates and fail-closed controls.
• Asset-Local Inventory: independent inventory domains without unrestricted cross-asset borrowing or silent balance substitution.
• Security & Operational Controls: separation of accounting state, capital ownership, market capacity and execution authority.

Current Documentation Principle

Where earlier project material and current documentation differ, the current documentation should be used to understand IDFI's present development scope and architecture.

This does not retroactively alter historical on-chain deployments or historical project records. It distinguishes earlier design assumptions from the infrastructure currently under development.

Future Whitepaper Revision

A future whitepaper revision may be prepared after the IDFI EX infrastructure reaches sufficient technical and operational maturity. No publication date is currently announced.

Any future revision should reflect implemented and validated architecture rather than planned functionality that has not yet reached the required development stage.

Document Verification

Official IDFI documentation and future whitepaper revisions, if any, should be obtained only through official IDFI channels. Users should independently verify contract addresses, network information and on-chain deployments before interacting with digital assets.

Completed Foundation

• IDOLL deployment: IDFI's first public on-chain digital asset was deployed on BNB Smart Chain.
• External market experience: the IDOLL / USDT PancakeSwap V3 market provided practical operational experience with on-chain liquidity, market behavior and automated market operations.
• Market-data visibility: IDOLL market information became independently observable through public blockchain and market-data infrastructure.
• IDFI EX core infrastructure: foundational exchange, accounting, market-control and internal infrastructure components have been developed and validated through staged testing.

Current Development Phase — Private Infrastructure

Current work is centered on the isolated IDFI EX private market architecture.

• Protocol-owned operating-capital boundaries.
• CORE-HPP accounting and capital-isolation controls.
• Safe Capacity and bounded market-action controls.
• Asset-local inventory domains.
• Self-trade prevention and synthetic-volume protections.
• Market-data, traceability and fail-closed control paths.
• Separation between market-action candidates and independent execution authority.

Current Operational Boundaries

• Public deposits: not enabled.
• Public trading: not enabled.
• Public liquidity participation: not enabled.
• Unaffiliated external capital in CORE-HPP: not enabled.
• IDOLL protocol liquidity expansion: paused.
• IDOLL active protocol market operations: paused.
• Additional IDFI-issued token deployments: not currently scheduled.
• New smart-contract development: not part of the current infrastructure phase.

Next Validation Stage

The next development stage is intended to move from architectural control validation toward controlled operational readiness.

• Validate production capital-accounting handoff boundaries.
• Validate supported major-asset inventory domains individually.
• Validate market-data freshness, executable depth and pricing inputs.
• Validate bounded market decisions under realistic operating conditions.
• Validate operational monitoring, reconciliation and recovery procedures.
• Preserve separation between capital availability, market capacity and execution authority.

Future Evaluation Gates

The following areas may be evaluated only after the private infrastructure reaches sufficient technical and operational maturity. They are not current launch commitments.

• Controlled operational use of supported major digital assets.
• Formal infrastructure or ecosystem relationships where technically and operationally appropriate.
• Additional network support where a clear operational requirement exists.
• Reassessment of IDOLL protocol-supported market activity after the required infrastructure and risk controls mature.
• Broader access models only after separate technical, security, operational and applicable regulatory review.
• Future smart-contract or digital-asset development only after a separate architecture and risk review.

Roadmap Principles

• Milestones before dates: development stages are advanced through validation rather than fixed public deadlines.
• Implemented before announced: future documentation should distinguish validated functionality from concepts under evaluation.
• Safety before expansion: additional assets, networks or access models must not bypass existing accounting, inventory and risk boundaries.
• Organic market activity: synthetic-volume targets and self-trading are not development objectives.
• Controlled capital: capital availability alone does not create market or execution authority.

Changelog

Material changes to IDFI's public development position will be reflected in the official documentation as the infrastructure evolves.

• Current phase: documentation aligned with the IDFI EX isolated private market architecture.
• Public liquidity-provider participation removed from the current infrastructure model.
• Additional IDFI ecosystem token deployments removed from the current development schedule.
• IDOLL retained as the project's existing on-chain asset and historical market deployment, with protocol-supported market operations currently paused.
• Roadmap converted from expansion-oriented scheduling to validation-gated infrastructure development.

Roadmap Notice

This roadmap describes the project's current development direction and should not be interpreted as a guarantee of future functionality, asset deployment, network expansion, public access or a specific implementation date. Material changes will be documented through official IDFI channels.