Home

Welcome to the Ithildin wiki!

Currently implemented and planned strategies for detecting patterns

Pattern	Description	Status
Ownership	This pattern aims at restricting functions to specific addresses. For example the owner of the contract is specified in the constructor and only that account is allowed to access a function and change the contract's state.	✔️ Stable
Role Based Access Control	This patterns aims at restricting function execution to addresses that belong to a specific role group. The addresses are added to a role goup, usually by an account with elevated priviliges (an admin), and when a restricted function is called the address is first looked up in the respective collection before allowing the caller to continue with the execution. Works well with OpenZeppelin's AccessControl library.	✔️ Stable
X-Confirmation	This pattern protects functions from being executed unless a condition related to the current block number is met. For example one might want to wait for a certain number of blocks to have passed before a transaction is marked as valid or confirmed.	📏 Evaluation Needed
Hash Lock	This pattern aims at providing authentication when the account is not known in advance. A secret is fixed off-chain and hashed, and the hash gets submitted to the contract. Later, the holder of the secret can submit it to the contract, the contract checks the secret's hash against the stored one, and if they match the protected logic gets executed.	📏 Evaluation Needed
Multiple Authorization	Multiple Authorization is an access control pattern that aims at restricting a code segment that can only be accessed when enough signatures are present. This means that enough stakeholders have to authorize the action before the function's execution can proceed. Identifying this pattern is not trivial, and this strategy may thus lead to false positives.	📏 Evaluation Needed