Overview

Our robust suite of policy rule types allows for highly customizable and precise control over your application's access and permissions. You can choose from various rule types such as Collections, ERC20 Tokens, Native Tokens, POAPs, and Allow Lists, each serving distinct use cases in the blockchain ecosystem.

A unique feature of these rule types is the ability to configure them to be either satisfied or not satisfied, allowing for both inclusion and exclusion scenarios. This flexible approach provides the capability to create precise conditions for policy enforcement.

Furthermore, the policy rules can be configured according to three primary evaluation strategies - All, Any, or Some. In an 'All' strategy, every rule set within the policy must be satisfied. 'Any' requires at least one rule to be met for the policy to pass, providing a more lenient approach. The 'Some' strategy provides an even higher degree of flexibility, allowing a certain number of rules to be satisfied. For instance, if you have four rules and set the policy to 'Some: 2', then at least two out of the four rules must be met for the policy to pass.

This level of control and adaptability allows you to create highly specific and accurate rule sets for managing access and permissions within your blockchain applications, enhancing security and user management efficiency.

Policy Model

The Policy object has the following properties:

• name: A string that represents the name of the policy.
• chain: A reference to the ChainInput object. The properties of ChainInput are not included in your snippet.
• ruleEvaluation: A string that indicates how the rules in the policy should be evaluated. It can be one of ALL, ANY, or SOME.
• minRules: A number that might be indicating the minimum number of rules that need to be met in the policy.
• rules: An array of PolicyRule objects.

The PolicyRule object has the following properties:

• order: A number that indicates the priority of this rule.
• type: A string that specifies the type of the rule. This can be one of COLLECTION, ERC20, NATIVE_TOKEN, ALLOW_LIST, or POAP.
• satisfiesRule: A number that represents whether the rule is satisfied or not. A value of 0 means the rule should not be satisfied, whereas a value of 1 means the rule should be satisfied.
• data: This property is an object that can take on various shapes depending on the value of the type property.

Rules Types

COLLECTION

Collections are specifically designed to accommodate Non-Fungible Tokens (NFTs), adhering to both ERC-721 and ERC-1155 standards. When you define a collection, you are essentially verifying whether a user possesses an NFT from the specified collection contract.

The collection type permits you to specify additional conditions that must be fulfilled. These could include aspects such as a specific balance, the holding period of an NFT, restricted Token Ids, or particular attributes the NFT must embody.

The object includes the following properties:

• contractAddress: A string representing the contract address.
• tokenIds: An array of numbers or strings that represent token IDs.
• balance: A number representing the balance.
• holdingTime: An object that specifies the holding time. This object has:
  • unit: A string representing the unit of time for the holding period. The possible values are "minutes", "hours", "days", "weeks", "months", "years", and "since".
  • value: A number or a string that represents the value of the holding time.
• attributes: An array of objects each representing a specific attribute. These objects each have:
  • name: A string that represents the name of the attribute.
  • values: An array of strings that represent the values of the attribute.

ERC20

Token contracts are built to facilitate fungible tokens, complying with the ERC-20 standard. When you define a token contract, you're essentially verifying whether a user holds tokens from the specified contract. The focus here is on the token balance a user holds in the contract.

The object includes the following properties:

• contractAddress: A string representing the contract address.
• balance: A number representing the balance.

NATIVE_TOKEN

Native token contracts are designed to govern the operation of the native tokens of any given blockchain, such as ETH for Ethereum or MATIC for Polygon. When you define a native token policy, you're essentially verifying whether a user possesses the required amount of the blockchain's native token.

The native token policy allows you to specify one primary condition that must be fulfilled - a specific balance of native tokens. The emphasis is solely on the balance of native tokens a user holds, which represents their stake or participation in that particular blockchain network.

The object includes the following properties:

• balance: A number representing the balance.

ALLOW_LIST

Allow List policies are specifically designed to permit access only to a select group of wallet addresses. This approach is particularly useful when you need to restrict access or grant special permissions to specific users.

When you define an Allow List, you are essentially creating a list of wallet addresses that are allowed to perform certain actions or access certain features. This could range from participation in exclusive events, early access to new features, to unique opportunities within your blockchain application.

In an this policy rule, the validation process checks if a user's wallet address is part of the defined list. Only those addresses that are on the list will be considered valid and allowed to proceed with the requested action. This policy rule provides an effective method for maintaining exclusivity and control over certain aspects of your application.

The object includes the following properties:

• walletAddresses: An array of strings that represent wallet addresses.