Smart Contract Design & Security
The Checks Platform smart contracts are built with a modular, upgradeable architecture to accommodate the rich feature set while maintaining the highest standards of security and transparency.
Architecture
At the core of the Checks Platform is an implementation of the Diamond Proxy Standard (EIP-2535).
This means the platform is composed of a single proxy contract (the Diamond) that forwards calls to multiple facet contracts, each facet encapsulating a set of related functions:
One facet for NFT Check core logic
One for managing token-bound accounts
One for yield strategy functions
And so on
This architecture allows virtually unlimited contract size and functionality under one contract address, and permits adding or upgrading modules over time without changing the external interface.
Benefits of the Diamond Pattern
Modularity: Facets are independent contracts that can even be reused across deployments
Shared Storage: Storage is shared in the Diamond contract
Standardized Interface: EIP-2535 provides a standardized interface for facets enumeration and upgrades
Community Support: Well-audited community implementations and tools for inspection are available
Upgradeability: New features can be added without disrupting existing functionality
Architecture Evolution
The architecture is designed such that each major feature is a module and the system can evolve by replacing or adding modules, all while the NFT Checks (and their token accounts) remain intact at the same contract addresses.
For example, new features like a novel lending model or support for a new oracle can be introduced by deploying a new facet and updating the Diamond's function table with the DAO governance.
Token-Bound Account (ERC-6551) Integration
Each NFT Check is implemented as an ERC-721 token that can own assets by virtue of the ERC-6551 standard. The platform deploys the official ERC-6551 registry on each supported chain, or uses the existing one if available, to get deterministic account addresses for NFTs.
Implementation Approach
Account Creation: When an NFT Check is minted, the registry is queried to derive the token-bound account (TBA) address associated with that NFT (based on the NFT's contract address and token ID).
Proxy Deployment: If no account contract exists yet, the registry's factory is invoked to deploy a minimal proxy account for that NFT.
Fund Transfer: The NFT's owner (or the platform's contract on their behalf) can then transfer funds or other tokens into that account.
Smart Logic Execution: The NFT's smart logic can later call functions from its associated account. For example, to release funds, the NFT Check contract instructs the TBA to transfer assets to the beneficiary's address.
Benefits of ERC-6551
Isolation: Each check's collateral is isolated, ensuring assets remain secure even if the core protocol is upgraded or paused
Ownership: Assets within each NFT's account remain separately owned by the NFT holder
Interoperability: ERC-6551 requires no changes to the ERC-721 standard and works across various platforms
Deterministic Addresses: NFT account addresses can be known in advance and audited
All NFT Check transactions involving assets (deposits, withdrawals, yield operations) go through these token-bound accounts, providing a clear separation of funds per check.
Security Considerations
Security is paramount given the platform holds and controls funds through smart contracts. Multiple layers of security are in place:
Audits
All smart contracts (the Diamond core and facets, Check Token, and any auxiliary contracts like strategy vaults) will undergo thorough external audits by reputable firms before mainnet launch.
Given the novel combination of features (ERC-6551 with Diamond proxies, etc.), auditors will specifically review cross-module interactions and the upgrade proxy to prevent vulnerabilities like storage collision or unauthorized upgrades.
Audit reports will be published for transparency. Additionally, critical facets (like the funds release logic) may be formally verified or at least have extensive invariant testing.
Diamond Proxy Governance
The upgrade mechanism is gated by a contract owned by the community governance (initially a secure multisig, eventually the DAO). Any addition or replacement of facets will either require a governance vote (if after launch) or a time-locked multisig action (in early phases).
This ensures no single party can rush an upgrade that might be malicious – token holders or a security council will review and approve changes.
Furthermore, the Diamond adheres to EIP-2535's Loupe interface, allowing anyone to query which facets and functions are active at any time, ensuring transparency of the code currently governing the system.
Access Control
The platform uses role-based access where appropriate:
Certain functions (like pausing the system in an emergency, or registering a new strategy module) might be restricted to an admin role initially
The admin role could belong to a timelock contract controlled by governance
All user-facing actions (minting checks, transferring, claiming funds) are entirely permissionless for users
The token-bound accounts themselves are owned by the NFT holders – meaning only the NFT owner or the Checks Platform (via the NFT's logic) can initiate actions with those accounts. This is enforced by the ERC-6551 account standard which typically checks that the caller is the NFT contract and that the NFT is owned by the party initiating the action.
Fail-safes
An emergency pause mechanism is implemented to temporarily halt critical operations (like releasing funds or creating new checks) if a severe bug or exploit is detected. This is a standard OpenZeppelin Circuit Breaker pattern.
Key fail-safe aspects include:
In a paused state, user funds remain safe in their TBAs, but new actions are prevented
Only the governance/administration can unpause after the issue is resolved
If an upgrade is pushed that the community disagrees with, the governance can vote to roll it back or disable certain facets
As a fail-safe for users, because each NFT's assets are in a separate account, users can always choose to individually withdraw funds from the TBA to their own wallet if the platform governance is compromised
Standard Compliance and Testing
The platform builds on audited standards (ERC-721 for NFTs, ERC-6551 reference implementation for accounts, ERC-4626 for yield, etc.) to minimize reinventing the wheel.
Extensive unit and integration tests are written, including simulations of complex scenarios (vesting with oracles, cross-chain transfers, etc.). The combination of multiple standards is carefully tested to ensure security and reliability.
Testing includes:
Ensuring an NFT's account cannot be created more than once
Verifying that upgrades to facets cannot alter state unexpectedly
Edge cases like leap second in a vesting schedule
Oracle failure in escrow (ensuring funds don't get stuck forever)
Reentrancy safety on all external calls
Audit of Strategies
Any external protocol integration introduces external risk. The platform mitigates this by:
Using battle-tested protocols (Aave, Compound)
Using ERC-4626 adapters for those protocols, which standardize interactions
Setting limits on strategy contract access – for example, a yield strategy cannot move user funds arbitrarily; it can only deposit and withdraw from whitelisted protocols
Implementing containment strategies to limit damage if a yield source is compromised
Enabling quick governance actions to cut off a bad strategy
Summary
The Checks Platform's design emphasizes modularity (for flexibility) and provable security (for trust). Using the Diamond standard and token-bound accounts, it achieves upgradeable complexity while isolating user assets.
Combined with rigorous security reviews and conservative governance controls, the platform strives to give users confidence akin to or greater than traditional financial escrow, underpinned by transparent smart contracts.
Last updated