This file is a briefing document for AI agents working on this repo. It complements README.md and the docs under sdk/typescript/docs.
Focus areas:
- Core Solidity contracts under
contracts/core - TypeScript SDK under
sdk/typescript
- Language / Runtime
- Solidity
0.8.34(upgradeable, OZ upgradeable patterns) - TypeScript (Viem‑based SDK)
- Solidity
- Core Domains
contracts/core– source of truth for all protocol behaviorsdk/typescript– thin, type‑safe wrappers and helpers for the core contracts
- Do not treat
contracts/andsdk/typescript/as independent systems: the SDK is an integration layer over the Solidity core.
When in doubt, derive behavior from Solidity first, then align the SDK and docs.
Key paths you should care about:
-
contracts/core/lib/EngineBlox.sol– central state machine library (SecureOperationState, tx lifecycle, RBAC, function schemas, meta‑tx, whitelists).base/BaseStateMachine.sol– upgrade‑safe wrapper that owns_secureStateand exposes shared queries and helpers.security/SecureOwnable.sol– owner / broadcaster / recovery roles, timelock configuration.access/RuntimeRBAC.sol– dynamic, non‑protected roles and function permissions, batch config.execution/GuardController.sol– guarded execution, time‑lock workflows, target whitelists.pattern/Account.sol– abstract pattern that combines all three components; basis for account‑style contracts (e.g.AccountBlox).lib/utils/SharedValidation.sol– common validation helpers and custom errors.*/lib/definitions/*.sol– definition libraries with function schemas, operation types, and default permissions.
-
sdk/typescript/contracts/core/*.tsx– class wrappers for core contracts (SecureOwnable,RuntimeRBAC,GuardController,BaseStateMachine).lib/EngineBlox.tsx– TS mirror ofEngineBloxpure helpers and constants.utils/metaTx/metaTransaction.tsx– EIP‑712 + meta‑tx helpers that must match the Solidity domain / struct hashes.utils/*– error handling, validation, interface IDs, ERC‑20 helpers.docs/– SDK and architecture docs (up‑to‑date; treat as user‑facing source of truth).
When you need to build, test, or regenerate docs, prefer these:
# Compile & size‑check contracts (Truffle / Foundry flows may coexist)
npm run compile:foundry
npm run compile:truffle:size
# Run protocol & sanity tests
npm run test:foundry
npm run test:sanity-sdk:core
# Regenerate Solidity‑based docs (NatSpec)
npm run docgenAlways keep changes compatible with existing tests; if you modify core behavior, update the relevant sanity scripts under scripts/sanity-sdk.
For any change to core behavior:
- Solidity first
- Update the relevant file under
contracts/core. - Maintain or improve NatSpec; it is the canonical machine‑readable spec.
- Update the relevant file under
- SDK second
- Update the corresponding wrapper under
sdk/typescript/contracts/core. - Ensure types in
sdk/typescript/typesand interfaces insdk/typescript/interfacesstay consistent.
- Update the corresponding wrapper under
- Docs third
- Update or add markdown under
sdk/typescript/docs, especially:api-reference.md- Component guides:
secure-ownable.md,runtime-rbac.md,guard-controller.md - Architecture docs:
bloxchain-architecture.md,state-machine-engine.md,core-contract-graph.md,account-pattern.md,getting-started.md
- Update or add markdown under
Agents should never introduce new public methods or change signatures without:
- Updating NatSpec
- Updating TS types/wrappers
- Updating affected docs
High‑level rules for agents:
- Security first
- Preserve and extend reentrancy protections (
nonReentrant, CEI). - Never weaken input validation or access control (
SharedValidation, role checks, whitelist checks). - Do not bypass state‑machine entrypoints with “shortcut” external functions.
- Preserve and extend reentrancy protections (
- Upgradeability
- Core components use OZ upgradeable patterns – no constructors on upgradeable contracts.
- Keep storage layout stable; use gaps as already defined.
- Custom errors over strings
- Prefer existing custom errors in
SharedValidationand related libraries.
- Prefer existing custom errors in
TypeScript:
- Use existing helpers (e.g.
EngineBlox, meta‑tx utils, validation helpers) before adding new ad‑hoc logic. - Keep Viem types (
PublicClient,WalletClient,Address,Hex) accurate and explicit.
Agents must not:
- Commit secrets or modify:
.env- Deployment keys or secret configs
- Hard‑code private keys, RPC URLs, or production contract addresses in source; use envs or
deployed-addresses.json. - Change CI / security enforcement to “work around” tests or linters (e.g. disabling checks, lowering coverage, skipping Slither/Semgrep).
- Remove or weaken timelock, RBAC, or whitelist checks to “simplify” flows.
If an operation requires touching live deployments or production infra, stop and request explicit instructions.
-
AI audit agents
- Start from:
contracts/core/lib/EngineBlox.solcontracts/core/base/BaseStateMachine.solcontracts/core/security/SecureOwnable.solcontracts/core/access/RuntimeRBAC.solcontracts/core/execution/GuardController.sol
- Cross‑reference:
sdk/typescript/docs/core-contract-graph.mdsdk/typescript/docs/bloxchain-architecture.mdsdk/typescript/docs/state-machine-engine.md
- Focus on invariants: role separation, timelock enforcement, meta‑tx replay protection, whitelist enforcement, upgrade safety.
- Start from:
-
AI builder agents
- Prefer building on Account‑based contracts (
contracts/core/pattern/Account.soland its implementations). - Use SDK entrypoints:
SecureOwnable,RuntimeRBAC,GuardController,BaseStateMachinewrapperslib/EngineBlox.tsxandutils/metaTx/metaTransaction.tsx
- Follow examples from:
scripts/sanity-sdk/*sdk/typescript/docs/examples-basic.mdsdk/typescript/docs/getting-started.md
- Prefer building on Account‑based contracts (
-
AI operational agents
- When wiring flows (role config, guard config, meta‑tx ops), follow the same ordering and constraints as the definition libraries:
contracts/core/access/lib/definitions/RuntimeRBACDefinitions.solcontracts/core/execution/lib/definitions/GuardControllerDefinitions.sol
- Use
deployed-addresses.jsonas the canonical source for contract addresses per network.
- When wiring flows (role config, guard config, meta‑tx ops), follow the same ordering and constraints as the definition libraries:
When you need more context:
- Read:
README.mdsdk/typescript/docs/index.mdsdk/typescript/docs/getting-started.mdsdk/typescript/docs/account-pattern.md
- Look at:
- Existing tests under
scripts/sanity-sdk - NatSpec in the relevant Solidity files
- Existing tests under
Prefer deriving intent from tests and NatSpec over guessing new behaviors. If required behavior is unclear or ambiguous, surface a question to a human rather than inventing protocol‑level semantics.