Access Control

The Steakhouse protocol uses a mesh-based access control system where only specific whitelisted contracts can interact with each other through the authorizeCaller() mechanism defined in KitchenStorage. This design ensures that no unauthorized external contract or wallet can modify protocol state or trigger privileged operations.

All internal communication happens through verified modules that cross-call each other using explicitly approved links.

Contract	Auth To Modify Storage	Can Be Called By	Key Actions
KitchenStorage	—	Safe / Timelock (setup)	Core registry of token states
KitchenFactory	✅	Kitchen	Token creation, metadata registration
KitchenBondingCurve	✅	Kitchen	Buy/sell logic, pool & supply updates
KitchenGraduation	✅	Kitchen / BondingCurve	Finalizes tokens, initiates LP locks
SteakLockers	✅	Graduation	LP lock and vesting enforcement
KitchenDeployer	✅	Factory	Deploys real ERC20 implementations
KitchenUtils	❌ (read-only)	BondingCurve / Factory	Curve and tax calculations
Kitchen	✅	User-facing	Routes calls between modules
KitchenTimelock	—	Gnosis Safe	Delayed governance execution

Security Summary

• All modules must be explicitly authorized in KitchenStorage via:

  storageContract.authorizeCaller(address(module), true);

• Unauthorized contracts and public users cannot:

  • Write balances or token data

  • Update pool states

  • Trigger graduation or creation

• Every admin module update is time-delayed (48h) via the timelock.

Authorization Synchronization

After deployment, each module calls a synchronization method to register and validate mutual access:

function syncAuthorizations() external {
    storageContract.authorizeCaller(address(this), true);
    storageContract.authorizeCaller(address(factory), true);
    storageContract.authorizeCaller(address(bondingCurve), true);
    storageContract.authorizeCaller(address(graduation), true);
    storageContract.authorizeCaller(address(creatorBasicAdvanced), true);
    storageContract.authorizeCaller(address(creatorSimple), true);
    storageContract.authorizeCaller(address(lockers), true);
    storageContract.authorizeCaller(address(deployer), true);
}

Access Control and Modules Interactions

Kitchen

The Kitchen contract acts as the central router of the Steakhouse ecosystem. It provides the primary entry point for users to create tokens, trade on bonding curves, and trigger graduations. Kitchen validates all user inputs and delegates logic to downstream modules such as:

• KitchenFactory for token creation

• KitchenBondingCurve for buy/sell handling

• KitchenGraduation for graduation and LP locking It maintains secure references to each authorized module and ensures only verified contracts can be interacted with via synchronized authorization.

---

KitchenBondingCurve

The KitchenBondingCurve contract handles all buying, selling, and pricing logic for tokens created through the system. It manages ETH inflows/outflows, token balances, and curve mathematics using KitchenUtils for helper calculations. This module communicates closely with:

• KitchenStorage, to update supply and liquidity data

• KitchenGraduation, when tokens reach their graduation cap

• Kitchen, which routes user trades into the curve All ETH operations and storage updates are strictly controlled by authorized access through the main registry.

---

KitchenCreatorBasicAdvanced

The KitchenCreatorBasicAdvanced contract provides creation logic for advanced and standard tokens. It defines how tokens with dynamic tax, max wallet, or max transaction limits are initialized on the curve. It communicates with:

• KitchenFactory, which calls it during deployment

• KitchenStorage, to record token parameters

• Treasury, for handling creation fees This module allows for versatile token setups while maintaining secure data flow through authorized links.

---

KitchenCreatorSimple

The KitchenCreatorSimple contract handles the simplified token creation flow for projects using basic bonding curves. It focuses on lightweight deployments without advanced mechanics, offering a faster path for simple launches. It communicates with:

• KitchenFactory, during token setup

• KitchenStorage, for metadata registration

• Treasury, for creation fee handling The module simplifies the process while retaining full security via storage authorization.

---

KitchenDeployer

The KitchenDeployer contract manages the deployment of real ERC-20 tokens once a project graduates from its bonding curve. It creates tax or no-tax token variants and connects them to Uniswap V2-style liquidity pools. The deployer communicates with:

• KitchenFactory, which instructs deployments

• Kitchen, for integration consistency

• KitchenStorage, for recording deployment references This module ensures token contracts are deployed securely and consistently with the ecosystem’s configuration.

---

KitchenFactory

The KitchenFactory contract is responsible for deploying new token instances on the bonding curve. It defines configuration parameters, links token metadata, and registers new tokens in KitchenStorage. The factory communicates with:

• KitchenDeployer, to deploy real ERC-20 tokens after graduation

• KitchenBondingCurve, for virtual curve integration

• KitchenGraduation, to manage graduation flow

• KitchenCreatorBasicAdvanced and KitchenCreatorSimple, which handle different token templates This module synchronizes authorizations across the ecosystem to keep all components securely connected.

---

KitchenGraduation

The KitchenGraduation contract governs the final stage of each token’s lifecycle. Once a token reaches its ETH cap, this module finalizes the bonding curve, mints or deploys real tokens, and locks liquidity using SteakLockers. It communicates directly with:

• KitchenStorage, to mark the token as graduated

• KitchenFactory, for deployment linkage

• KitchenBondingCurve, for pool finalization

• SteakLockers, to secure LP tokens It also handles the stipend and distribution flow for graduating projects.

---

KitchenStorage

The KitchenStorage contract serves as the master registry and database for all tokens, balances, and ecosystem variables. It enforces access control through authorizeCaller(), ensuring that only whitelisted modules (Factory, Curve, Graduation, etc.) can modify data. Other modules depend on it for:

• Reading and updating token states

• Tracking liquidity and supply data

• Managing authorization lists It is the backbone of the system, maintaining data consistency and preventing unauthorized writes.

---

KitchenUtils

The KitchenUtils contract provides mathematical helper functions for bonding curves, taxes, and supply limits. It is a read-only module, assisting KitchenBondingCurve and KitchenFactory with curve computations. Utils interacts with:

• KitchenStorage, for reading current token states It does not hold funds or modify data, ensuring safe and deterministic calculations.

---

SteakLockers

The SteakLockers contract manages liquidity and token locks across the ecosystem. It holds LP tokens on behalf of projects after graduation and enforces unlock schedules, partial withdrawals, and vesting. It communicates with:

• KitchenGraduation, which triggers LP locks after graduation

• KitchenStorage, for referencing token data The locker ensures liquidity safety and prevents early withdrawal, protecting both users and investors.