Overview

This section provides a high-level overview of Inception's smart contract system. It introduces the architectural structure and roles of major components, offering a conceptual map for understanding how different modules interact.

Inception’s architecture is modular, with each contract group handling a specific piece of functionality — such as vault creation, restaking, tokenized reward flow, or configuration. This separation of concerns allows for flexibility, upgradability, and ease of auditing.

Architecture Map

Vaults

Vaults tokenize user deposits and route funds through strategy-specific adapters. Each vault adheres to a standard interface and interacts with:

• Adapters: Execute protocol-specific logic (e.g., EigenLayer)

• Asset Handlers: Validate supported tokens

Vaults

Restaking Pools

Restaking pools accept deposits and coordinate delegation to restaking services or validator networks. They may interact with off-chain actors through Go bindings and are intended to manage shared security participation.

Restaking Pools

Rate Providers

These contracts provide up-to-date valuation of vault tokens or restaked assets. Each rate provider is tailored to a specific asset or protocol and used for accounting and integrations.

Rate Providers

Airdrop

The airdrop contract handles permissioned token distributions. It verifies eligibility and processes claims, with configurations controlled off-chain.

Airdrop

Bridge

The bridge module is responsible for coordinating multi-chain deployment. It includes network-specific configurations and tracks proxy-based contract deployments. It does not include its own on-chain bridging mechanism.

Bridge

Reward Wrappers (not isolated)

Reward logic appears embedded within vault adapters and restaking implementations. There is no standalone reward-wrapper module, but reward flows are handled via adapter patterns and possibly within integrations.

Notes

• All contracts are written in Solidity and deployed using Hardhat with OpenZeppelin proxies.

• Off-chain coordination (e.g., validator actions) is supported via generated Go bindings.

• Each module is independently upgradable and auditable.

Refer to the individual module pages for detailed behavioral documentation and integration notes.