# Covest InSaaS Protocol Whitepaper v1.1: [InSaaS Protocol Whitepaper](https://docsend.com/view/dk28w36taj56h6hg) ### Overview The Insurance as a Service Protocol or "InSaaS Protocol" opens up a world of possibilities for insurance liquidity and risk management. By leveraging the power of blockchain technology, we are able to create a transparent and efficient platform for individuals and companies alike to tokenize their risk portfolios and participate in the risk market. With the InSaaS Protocol, insurance firms no longer hold a monopoly on risk-carrying solutions. Instead, we provide a level playing field where anyone can innovate and create novel insurance products. By widening participation in the risk market, we hope to bring new ideas and fresh perspectives to the industry. Our team at Covest Labs is dedicated to making this vision a reality. We are committed to building a platform that is both user-friendly and technologically advanced, ensuring that the InSaaS Protocol becomes the go-to destination for insurance liquidity and risk management. With the InSaaS Protocol, we are ushering in a new era of insurance innovation and accessibility. Join us on our journey to create a more equitable and dynamic risk market. ### Product Onboarding The InSaaS protocol carries out the following steps for onboarding each insurance product: 1. **Risk identification**: The first step in performing a risk assessment is to identify the potential risks that the insurance policy will cover. This may include risks related to the insured assets, property, or individual, as well as external risks such as natural disasters or market conditions. During this step of the process, Covest Labs team will work closely with the "Distributor Partner" to conduct an analysis of the historical data associated with the insurance product that is going to be provided to the end users. The next step is to determine the terms of the coverage as well as the exclusions that apply to each kind of product. 2. **Expected claim and loss probability evaluation**: Once the risks have been identified, the next step is to assess the likelihood of each risk occurring. This may involve analyzing historical data and trends. The next step is to determine the potential impact of each identified risk. This may include the potential financial loss, as well as any non-monetary impacts such as damage to assets, property, or injury to individuals. Based on the loss probability evaluation and the potential impact of each risk, the Covest Labs team can determine the expected claims for the new insurance product. This information will be used to set the appropriate premiums and ensure that each insurance pool has the necessary financial resources to cover any potential claims. 3. **Claim mechanism evaluation**: The Covest Labs team will evaluate the claim mechanism for each new insurance product to ensure that the claim process is clear, effective, and efficient. This will improve the customer experience and increase satisfaction. The Covest Labs team will also take into account the risk assessment process and incorporate a buffer to prevent fraudulent claims or errors in the claim process. The Covest Labs team will review the documentation, test the process, evaluate its effectiveness and efficiency, make recommendations for improvements, and communicate the updated process to all stakeholders. 4. **Monitor and review the risk assessment**: The risk assessment process is an ongoing effort that requires regular monitoring and review. The Covest Labs team is dedicated to ensuring that our risk assessment process is effective and up-to-date. We track the dynamics of our programs in real-time and make adjustments as needed to ensure that they are performing as expected. Overall, the Covest Labs team is committed to providing a thorough and effective risk assessment process that helps us to manage and mitigate risks for our customers. By regularly monitoring and reviewing our programs, we can ensure that they are performing as expected and provide our customers with the protection they need. # InSaaS Architecture The InSaaS protocol aims to provide innovative solutions for managing risks in the real world by building a reliable risk capture model, a controllable underwriting process, and an accurate claim procedure. To achieve this, the protocol has developed a number of models to enable these capabilities. One such model is the "Basic Signed Quote Model", which is composed of both off-chain and on-chain components. The off-chain component of the model involves gathering and analyzing data about the risks being insured, such as information about the policyholder and the risks being insured. This information is used to generate a quote for the policy, which is then signed by the policyholder and sent to the on-chain component of the model. The on-chain component of the model involves the use of smart contracts to manage the issuance and administration of the insurance policy. This includes the management of premiums, claims, and other policy-related activities. The on-chain component of the model is designed to ensure the transparency, security, and efficiency of the insurance process. ## Basic Signed Quote Model {% content-ref url="/pages/4Q7LJJxvXwA0UT8Pi3RD" %} [Basic Signed Quote Model](/covest-insaas-protocol/insaas-architecture/basic-signed-quote-model) {% endcontent-ref %} # Basic Signed Quote Model
Basic Signed Quote Model consist of four key functions for external users to engage with its protocol: buying insurance policies, redeeming insurance policies, requesting claims, and receiving claim payouts. External users can be divided into two groups: individuals and businesses. Individuals are individuals or entities that buy insurance policies for themselves, while businesses are individuals or entities that issue policies for others on their behalf. The maximum number of policies that any single user is allowed to buy or issue may be limited based on their risk capacity limit. To facilitate its operations, InSaaS protocol will use both on-chain and off-chain systems. Off-chain operations, such as product pricing, will be carried out using open-source code and inputs that will be made available on the blockchain. On-chain confirmation will be used to verify that the model was correctly executed. On-chain operations will involve storing policy data, claim-related records, and reinsuring risks to risk carriers, with the value and timestamp of each action recorded on the blockchain. This will enable insurance carriers to track their risk exposures, capital balances, and claim evidence in real-time. Any modifications made to the model or the input parameters will be managed by the governance mechanism. In the future, additional research will be done to find trust-minimizing alternatives for complex computing, with the final objective of removing this dependency. The InSaaS protocol's primary goal is to ensure the long-term viability of each insurance pool by matching it with a risk carrier whose pricing structure can withstand the risks associated with the particular pool. To achieve this, the protocol will use a claim mechanism that is designed to prevent potential fraud claims and will also have a governance mechanism in place to manage any modifications to the model or input parameters. InSaaS protocol also oversees the solvency aspect of each insurance pool by ensuring that the risk carrier maintains sufficient reserve capital to remain solvent and pay claims associated with the pool of risks that have been transferred to it. The risk carrier can be anyone interested in taking on risk, including individuals or enterprises, and the ratio of risk transfer can vary from 0 to 100 percent depending on the pool's risk management strategy. All risk carriers must sum up to 100 percent in order to bear the overall risk exposure. The Insurance smart contracts, the Upfront smart contracts, and the Risk Carrier smart contracts all work together to form the backbone of the protocol's insurance functionality. The four main components of insurance-related smart contracts are the Pool Manager, Policy Manager, Pricing Manager, and Claim Manager. All information and settings relevant to a certain pool are the responsibility of the Pool Manager. All purchased and issued policies must be managed by the Policy Manager. The Pricing Manager must ensure the accuracy of policy prices and redemption values. The Claim Manager's job is to process any claims that have been filed. The Upfront Manager is the brains behind all smart contracts initiated at the beginning. All up-front payments to associated parties must be managed via the Upfront Manager. The Validator ecosystem includes the Validator Aggregator and the Validator Staking smart contracts. Each pool's validators' stats are monitored and used by the Validator Aggregator to determine who gets chosen. Validator Staking is in charge of managing the staking capabilities of all validators in each pool. The Risk Carrier ecosystem comprises the Risk Carrier Registry, Risk Carrier Router, and Risk Carrier Controller, all of which are implemented as smart contracts. Services connected to risk carriers are handled by these arrangements. # InSaaS Components The InSaaS protocol consists of several components that operate as the core insurance system. These components include: * Governance: The governance component is responsible for setting the rules and policies of the InSaaS protocol, including the collateralization ratio and the selection of validators. {% content-ref url="/pages/OJy2Pnrk4pBEnbFgKcoI" %} [Governance](/covest-insaas-protocol/insaas-components/governance) {% endcontent-ref %} * Risk Assessment: The risk assessment component is responsible for evaluating the risks associated with each policy and determining the appropriate premiums and solvency capital requirements. {% content-ref url="/pages/SPjFTrzu1AFRaQoIIRhw" %} [Risk Assessment](/covest-insaas-protocol/insaas-components/risk-assessment) {% endcontent-ref %} * Claim Assessment: The claim assessment component is responsible for reviewing and processing claims made by policyholders. This includes verifying the validity of the claim and determining the appropriate payout amount. {% content-ref url="/pages/JvmprC4oL8fW7cBjAnfQ" %} [Claim Assessment](/covest-insaas-protocol/insaas-components/claim-assessment) {% endcontent-ref %} * Validator Selection: The validator selection component is responsible for selecting validators to participate in the claim assessment process. Claim validators are responsible for verifying the validity of claims and ensuring the integrity of the claim assessment process. {% content-ref url="/pages/e9IFk4cXaUEC2s7Ypaq2" %} [Validator Selection](/covest-insaas-protocol/insaas-components/validator-selection) {% endcontent-ref %} * Risk Carrier: The risk carrier component is responsible for undertaking the risks transferred to the InSaaS protocol and maintaining the solvency capital needed to pay claims. The risk carrier can be anyone who is interested in taking on risk, including individuals or enterprises. {% content-ref url="/pages/cOcMCK44vFWMd0bADXoe" %} [Risk Carrier](/covest-insaas-protocol/insaas-components/risk-carrier) {% endcontent-ref %} In summary, the InSaaS protocol is a decentralized insurance protocol that enables policyholders to transfer risk to a third party and receive protection in the event of losses. It relies on a network of claim validators to ensure the integrity of the claim assessment process and a risk carrier to undertake the transferred risks and pay claims. # Governance The "Governance Board" is a decentralized board of trustees responsible for monitoring each InSaaS's insurance pool and ensuring that it is being run in an equitable and transparent manner. The interests of all parties are considered thanks to the decentralized nature of the governing mechanism. The governance mechanism for each insurance pool within the InSaaS protocol would be responsible for managing and making decisions regarding any modifications to the model or input parameters specific to that pool. This could include decisions related to risk management strategies, risk carrier ratios, and solvency requirements. The governance mechanism may be composed of various stakeholders, including policyholders, risk carriers, and validators, who can participate in decision-making processes through voting or other forms of participation. The specific governance structure and decision-making processes may vary depending on the specific needs and requirements of the insurance pool. In addition to the insurance pool-specific governance mechanisms, the InSaaS protocol may also have a global governance structure in place to oversee the long-term development and management of the protocol. This global governance structure could include a board or council responsible for making strategic decisions and setting the overall direction of the protocol. The global governance structure may be responsible for making decisions related to the onboarding of new insurance pools or products to the protocol, as well as any other matters that impact the entire protocol. This could include decisions related to protocol updates, changes to smart contract functionality, and other matters that impact the overall functioning of the InSaaS protocol. If there are decisions that need to be made regarding a specific insurance pool and they cannot be resolved within that pool's governance mechanism, the global governance structure may be responsible for making the final decision. This could be done through voting or other forms of participation by the relevant stakeholders. During the first phase, the overall control of the global governance structure will be with the founding team of InSaaS protocol. This is because it allows us to scale up the product in the right direction and make decisions quickly and efficiently. # Risk Assessment Our decentralized approach to risk assessment also means that we are not beholden to any single underwriter or other centralized authority. Instead, we rely on a collective understanding of risk and the expertise of our board of trustees to make informed decisions about the insurance products offered on our platform. This allows us to provide our customers with the best possible coverage at the most competitive prices. At the heart of the InSaaS protocol is a commitment to assessing risk in a way that is both thorough and reliable. Unlike many other decentralized insurance players, the InSaaS protocol does not rely on staking power of specific underwriter or dynamic calculation based on capital reserve to evaluate the risks associated with a given insurance product. Instead, the InSaaS protocol uses a tried and true method that has been used in the traditional insurance industry for decades. The process begins with the identification of risks. This involves carefully analyzing the potential sources of loss for a given insurance pool and determining how likely it is that these losses will actually occur. Once the risks have been identified, the next step is to evaluate the probability of loss for each one. This is done by considering a wide range of factors, including the severity of the potential loss and the likelihood that it will occur. Once the probability of loss has been determined for each risk, the next step is to estimate the expected claim impact. This involves estimating the total amount of money that will be paid out in claims for a given insurance pool, taking into account the probability of loss for each individual risk. This allows the governance board to determine the overall risk profile of the pool and to set premiums accordingly. To further mitigate risk, the InSaaS protocol employs a number of additional techniques, including the prevention of risk congestion. One way the governance board does this is by setting a capacity limit for each insurance pool on the protocol. This ensures that the total amount of insurance coverage for a given pool does not exceed a predetermined limit, reducing the likelihood of a catastrophic loss and helping to prevent the pool from becoming overcrowded. Additionally, the governance board regularly reviews and monitors the risk profile of each pool to ensure that it remains within acceptable limits. This allows the protocol to identify potential issues early on and take steps to address them before they become a problem. By continuously monitoring and managing risk in this way, the protocol are able to provide the users with the peace of mind that comes from knowing that their coverage is reliable and secure. # Claim Assessment When evaluating claims on blockchain, there are two different approaches. An oracle, which may be an off-chain information source or an intermediary, can be used to trigger parametric insurance events as a first alternative. Crowd-sourcing is another alternative; information may be received from the general public, and assertions can be finalized by a voting system. The use of a parametric trigger-based cover in conjunction with an oracle presents a number of restrictions and challenges, including the potential for oracle failure, a restricted product variety, and unsatisfied requirements. This may lead to undesirable outcomes for the client, especially in situations in which customers have suffered a loss notwithstanding the fact that the trigger has not been formally met. In order to avoid the issue that was described, it will be required to have backup claims processing systems. In addition to this, the data have to be of a sufficient level of detail to enable the development for public usage. The Internet of Things (IoT) is expected to bring a significant increase in the number of possible data oracles in the not too distant future; yet, these devices are not yet generally accessible nor are they reliable enough.
Therefore, InSaaS established the mechanism for claim evaluation by combining the oracle approach and the crowd-sourcing approach together into a single process. Any individual or entity is able to participate as one of our claim assessors; this could be an off-chain API that gets data from any kind of event or device, or it could be a manual assessment performed by a Third-Party Administrator (TPA) that has been registered with the protocol. These types of assessments perform to vote against or support the result that comes for other claim participants. Claim will only be paid out based on the outcome of the consensus, and there will be a grace period of 14 days after the conclusion of the claims process during which anyone may challenge the result of the claims.
When the InSaaS protocol receives a claim application, the "Claim Manager" contract uses an aggregator function to select claim validators from the pool of eligible validators. After the selection process, the chosen claim validators review the request and offer a claim adjustment amount, which represents the approved amount of compensation for the claim. For instance, a ratio of 0 indicates a claim denial, 100% indicates complete reimbursement, and any other ratio between 0 and 100 indicates partial compensation. After the claim validators submit their approved amounts, the claim voters, who are validators that were not chosen to participate in the claim assessment but are still staked in the selected product pool, vote on the outcome using their MI Tokens as staked power. If the consensus threshold, which is typically set at 75%, is reached, the end of the evaluation determines whether the consensus is "Accepted" or "Rejected". However, if the result does not reach consensus within the expiry period, which may vary depending on the settings of each pool, the approved amount is reviewed by the governance board's sole discretion in order to provide the final outcome. InSaaS protocol will trigger the claim payout if the outcome is "Accepted", otherwise no payout is trigger. Then, protocol will forward the claim to the grace period stage in order to prepare for the claim challenge, and all data will be made available on the website. Overall, the claim assessment process in the InSaaS protocol involves the selection and review of claim validators, the voting of claim voters, and the final determination by the governance board or a successful challenge. It is designed to ensure that claims are properly evaluated and that policyholders receive fair and accurate compensation for their losses. # Validator Selection
A claim validator is a crucial component of every insurance pool in Covest protocol, as it is responsible for verifying the validity of claims submitted by policyholders. As an incentive, every single claim assessor i.e. claim validator who performs claim assessment will receive a service fee for each and every assessment that they conduct. If the consensus mechanism is going to be successful, there has to be an incentive for people to validate, and there also needs to be a significant disincentive in place to discourage people from making false validations. For example, policyholders who buy an insurance product with a low incidence rate may be able to get a high coverage at a decent cost. After that, they work together with the claim validator to get the payout. Then, they give the claims validator part of the claim amount and keep the rest for themselves. A solution to this problem is to require claims validator to have a major interest in the overall pool's performance, creating a strong deterrent to act dishonestly. This can be accomplished by requiring a stake in the form of Mutual Interest Tokens (MI Tokens). Mutual Interest Tokens (MI Tokens) are tokens that are created in exchange for a person who contributes funds as mutual insurance reserves for a certain product pool, and they are utilized as collateral. Eventually, those who own MI Tokens will receive profit-sharing in the form of a dividend, which includes earnings from insurance service margin revenue. MI Tokens are designed to tie owners' token funds to the pool's performance and long-term viability as collateralized value, posing a strong disincentive to cheating or generating revenue from insurance services without having to run any business operation. to be deposited. The stake is placed for a set amount of time, after which it is refunded if the claims are evaluated fairly. ## Validator Score In the matter of selecting the person who will evaluate the claim as "Claim Validator", a number of factors should be taken into consideration, including the capacity of the validator, its reputation and the use of a random function on the blockchain. $$ Score = (Capacity \* w\_1) + (Reputation \* w\_2) + (Randomness \* w\_3) $$ In this equation, the variable **`Score`** represents the overall score that is assigned to each claim validator. This score is calculated by adding together the values of three factors: **`Reputation`**, **`Capacity`**, and **`Randomness`** ### **Capacity Factor** One important factor to consider is the **capacity factor** of the claim validator. The selected validator should have the necessary resources and expertise to handle the volume of claims that are likely to be submitted to the insurance pool. This could include factors such as the availability of trained personnel, amount of the task at hand, the ability to handle large amounts of data, and the availability of necessary infrastructure and technology. The claim capacity factor is a measure of the amount of resources that a claim validator has available to process claims. It is represented by the variable **`Capacity`** and takes a value between 0 and 1, with higher values indicating a greater capacity to process claims. The weight **`w1`** determines the relative importance of this factor in the overall score. To calculate the available claim capacity, you can use the amount of MI Tokens that a claim validator has staked as a measure of the resources they have available to process claims. You can then subtract the amount of claims that the validator is currently processing from this total to get the available claim capacity. For example, if a claim validator has staked 1,000 MI Tokens and is currently processing claims worth 500 MI Tokens, their available claim capacity would be 500 MI Tokens. $$ Capacity = \frac{validatorNetStaked - validatorOnHoldStaked}{totalPoolStaked} $$ **`validatorNetStaked`**is the total amount of MI Tokens that the claim validator has staked deduct the amount of the penalty for that claim validator. **`validatorOnHoldStaked`** is the amount of MI Tokens that the claim validator is currently using to process claims. **`totalPoolStaked`** is the total amount of MI Tokens staked in the insurance pool. This equation takes into account both the amount of resources that the claim validator has available to process claims (`validatorNetStaked - validatorOnHoldStaked`) and the overall size of the insurance pool (`totalPoolStaked`). By dividing the available claim capacity by the total pool size, the formula ensures that the score is normalized and can be compared across different claim validators. It's important to note that the available claim capacity is just one factor that can be used to determine a claim validator's overall score. Other factors, such as the validator's reputation and the quality of their claim assessments, may also be taken into account. In addition to capacity, the reputation of the claim validator on the blockchain should also be taken into consideration. The selected validator should have a proven track record of successfully validating claims on the blockchain, and should be well-regarded by other participants in the network. This can help to ensure that the validation process is efficient and effective, and that policyholders can trust the results of the validation process. ### **Reputation Factor** The reputation factor is represented by the variable **`Reputation`**, which can take a value between 0 and 1, with higher values indicating a better reputation. This factor is given a weight of **`w2`** , which means that it will contribute a certain proportion to the overall score. To calculate the reputation factor based on the accumulative point for successful claim assessments and penalties from claim challenges, you can use the following formula: $$ reputation = \frac{(validatorEarnedPoint - validatorIncurredPenalty)}{totalPoolPoint} $$ **`validatorEarnedPoint`** is the total point received for successfully assessing claims for specific claim validator. **`validatorIncurredPenalty`** is the total penalty received from claim challenges for specific claim validator. **`totalPoolPoint`** is the maximum pool point that is already distributed to all claim validators at that moment in time. It's important to note that the values of **`validatorEarnedPoint`**, **`validatorIncurredPenalty`**, and **`totalPoolPoint`** can be adjusted to suit the specific needs of each pool for the Covest protocol. For example, you may choose to set the **`totalPoolPoint`** to a higher value to give more weight to the reputation factor, or you may choose to set the **`validatorIncurredPenalty`** to a lower value to make it less impactful on the reputation factor. ### Random Factor The random factor, represented by the variable **`Randomness`**, is used to reduce bias in the claim assessment process. This factor can take on a value between 0 and 1 and is given a weight of **`w3`**, indicating that it will contribute a certain proportion to the overall score. The inclusion of the random factor helps to ensure that the claim assessment process is not influenced by any biases or prejudices that may exist within the system or among the individuals involved in the assessment. By introducing an element of randomness, the system can better account for the inherent uncertainty and subjectivity that exists in the process of assessing claims. This can help to increase the fairness and objectivity of the assessment process, as well as the overall accuracy of the results. ### Score Calculation To calculate a claim validator's score, the values for each of these parameters are multiplied by their corresponding weight and then added together. This score might then be compared to the scores of other potential claim assessors to decide which ones should be chosen as claim validators. Using this equation, it is feasible to objectively analyze the eligibility of each node to serve as a validator and select the nodes that are most suited to the particular claim case's criteria. The claim assessor or claim validator who is not selected as the case's validator will be transferred to the position of claim voter, who will vote against the claim assessment. # Risk Carrier
In the InSaaS protocol, the risk carrier is responsible for maintaining the reserve capital that is needed to remain solvent and pay claims associated with the pool of risks that have been transferred to it. The risk carrier can be anyone who is interested in taking on risk, including individuals who are willing to bet against certain types of risk or enterprises that operate to manage specific types of risk. The ratio of risk transfer, or the percentage of risks that are insured for each risk carrier, can vary from 0 to 100 percent and is determined by each pool based on its own risk management strategy. However, all risk carriers must sum up to 100 percent in order to bear the overall risk exposure. The main objective of the risk carrier is to ensure that the pool has sufficient capital to cover losses associated with the transferred risks. This capital is calculated based on the solvency ratio, which is determined by the governance board and represents the amount of capital needed to cover potential losses up to a certain confidence interval (e.g., 99.5 percent). The solvency capital required for the risk carrier comes from these sources: **Pure premiums**: Pure premiums are the expected cost of an insurance policy, calculated based on the probability and severity of potential losses. They represent the amount of premium that policyholders are required to pay in order to cover the expected losses associated with their policy. To calculate pure premiums, risk carriers use actuarial data and statistical models to estimate the likelihood and cost of potential losses. This process, known as actuarial science, involves analyzing data about past losses and using probability theory and statistical analysis to model the likelihood of future losses. The resulting estimates of expected losses are used to set the price of insurance policies in a way that accurately reflects the risks being insured. **Gross premium**: The gross premium, which is the total amount of premium collected by the risk carrier, serves as a buffer for the risk carrier. This is because the gross premium includes not only the pure premium, which is the expected cost of the policy based on the probability and severity of potential losses, but also additional charges and fees levied by the risk carrier. By including these additional charges and fees in the gross premium, the risk carrier is able to build up a buffer of extra capital that can be used to cover unexpected or large losses. This helps to ensure that the risk carrier has sufficient capital to meet its obligations to policyholders, even in the event of unexpected or large losses. **Solvency capital requirement (SCR)**: The solvency capital requirement (SCR) is a measure of the capital that a risk carrier must hold in order to meet its obligations to policyholders over the next 12 months with a 99.5 percent probability. This means that the risk carrier has a limited chance (less than once in 200 cases) of falling into financial ruin. The SCR is calculated based on the expected losses and other risks faced by the risk carrier, and is used to ensure that the risk carrier has sufficient capital to pay claims in the event of unexpected or large losses. To meet its SCR, a risk carrier may need to obtain additional capital from external sources, such as external liquidity providers. This is in addition to the premiums paid by policyholders, which are used to cover the expected losses associated with the policies. By maintaining an appropriate level of SCR, a risk carrier can help to protect itself and its policyholders from the financial consequences of unexpected or large losses. The risk carrier relies on the on-chain registry and on-chain routing provided by the "RiskCarrier Manager" contract in order to operate effectively. The on-chain registry keeps track of all risk carriers and their risk transfer ratios, while the on-chain routing helps to distribute risk among risk carriers according to their respective capacities. Overall, the risk carrier plays a crucial role in managing risk and ensuring the solvency of the InSaaS protocol. It helps to transfer risk to a trustworthy party, enabling each insurance pool to better manage its own risk and providing policyholders with the reassurance that their claims will be covered if the unexpected occurs. # InSaaS Smart Contracts v1.0.4 # Policy States This section provides information on the data structures and processes used to manage insurance policies on the platform. It covers the `PolicyData` struct, which contains comprehensive policy details such as the policyholder's address, policy currency, policy ID, and other important information, as well as the `PolicyStatus` enum that tracks the status of each policy. ### PolicyData ```solidity struct PolicyData { address policyholder; address currency; string policyId; string externalReferenceId; string documentHash; uint40 coverageStart; uint40 coverageEnd; uint40 claimRequestUntil; uint256 premium; uint256 sumInsured; uint256 accumulatedClaimReserveAmount; uint256 accumulatedClaimPaidAmount; uint256 redeemAmount; bool cancelled; } ``` The `PolicyData` struct that defines various data related to the management of insurance policies. Here is a summary of the information included in this struct: * `policyholder`: The address of the policy holder. * `currency`: The address of the currency used for the policy. * `policyId`: A unique identifier for the policy. * `externalReferenceId`: An optional external identifier for the policy. * `documentHash`: The hash of the policy document. * `coverageStart`: The start time of the policy coverage in seconds. * `coverageEnd`: The end time of the policy coverage in seconds. * `claimRequestUntil`: The deadline for policy holders to submit claims in seconds. * `premium`: The premium amount for the policy, represented as a decimal. * `sumInsured`: The total amount of insurance coverage for the policy, represented as a decimal. * `accumulatedClaimReserveAmount`: The total amount of claims for the policy that are pending approval or rejection, represented as a decimal. * `accumulatedClaimPaidAmount`: The total amount of claims for the policy that have been approved and paid, represented as a decimal. * `redeemAmount`: The amount that the policy holder has already redeemed, represented as a decimal. * `cancelled`: A boolean flag indicating whether the policy has been cancelled. If true, the policy is no longer active. ### PolicyStatus ```solidity enum PolicyStatus { NotInsured, Pending, Active, Cancelled, Expired } ``` The `PolicyStatus` enum defines the possible states of an insurance policy. Here is a detailed explanation of each status: * `NotInsured`: This status is assigned to a policy if the policy ID does not exist, indicating that the policy is not insured. * `Pending`: This status is assigned to a policy if the coverage start date is in the future, meaning that the policy is pending and has not yet become active. * `Active`: This status is assigned to a policy if the coverage start date is in the past and the coverage end date is in the future, indicating that the policy is active and coverage is currently in effect. * `Cancelled`: This status is assigned to a policy if the policyholder cancels the policy by redeeming it. This typically happens before the coverage end date. * `Expired`: This status is assigned to a policy if the policyholder does not redeem the policy before the coverage end date, indicating that the policy has expired and is no longer active. Each status is assigned based on the current state of the policy, which can be determined by checking the coverage start and end dates and whether the policy has been cancelled or redeemed.
# Claim Case States This section provides information on the data structures and enum types used in a smart contract designed to manage insurance claims. The smart contract includes different structures such as `ClaimData` , `ClaimStatus`, and `ClaimRules` that define the different states, rules, and data used in the claim processing. These structures and types provide the necessary information and rules to manage insurance claims efficiently. ### ClaimData ```solidity struct ClaimData { string policyId; string documentHash; uint40 claimSubmittedAt; uint40 claimExpiresAt; uint256 claimId; uint256 claimRequestedAmount; uint256 claimApprovedAmount; address currency; address claimValidator; } ``` `ClaimData` is a struct that contains information about a claim. It includes the following parameters: * `policyId`: The policy id. * `documentHash`: The hash of the claim document. * `claimSubmittedAt`: The claim submitted time in seconds. * `claimExpiresAt`: The claim expires time in seconds. * `claimId`: The claim id. * `claimRequestedAmount`: The claim amount that is requested by the policy holder. * `claimApprovedAmount`: The claim amount that is approved by the claim validator. * `currency`: The currency address. * `claimValidator`: The claim validator address. These parameters provide information about the policy, claim submission, expiration, amount, currency, and validator. ### ClaimStatus ```solidity enum ClaimStatus { NotSubmitted, Submitted, Voting, Cancelled, Accepted, Rejected, Expired } ``` `ClaimStatus` is an enum type that defines the different states that a claim can have. These states provide information about the current status of a claim. The different states are: * `NotSubmitted`: The claim is not submitted, if the claim id does not exist. * `Submitted`: The claim is submitted, if the claim is submitted by the policy holder and the claim validator has not voted yet. * `Voting`: The claim is voting, if the claim validator has voted, after that the claim will open for voting by voters. * `Cancelled`: The claim is cancelled, if the claim is cancelled by the policy holder. * `Accepted`: The claim is accepted, if the claim is accepted by the consensus or the governance that finalizes the claim. * `Rejected`: The claim is rejected, if the claim is rejected by the consensus or the governance that finalizes the claim. * `Expired`: The claim is expired, if the claim is not finalized before the claim request until. It means the claim expires at less than the current time, and the status of the claim id is submitted or voting. ### ClaimRules ```solidity struct ClaimRules { uint8 claimAssessmentPeriod; uint8 claimConsensusRatio; uint256 rewardPerClaimAssessment; uint8 validatorRewardRatio; uint8 voterRewardRatio; uint256 claimAmountPerOnHoldStaking; uint256 pointPerClaimAssessment; } ``` `ClaimRules` is a struct that defines the rules for assessing claims. It includes parameters such as: * `claimAssessmentPeriod`: The claim assessment period in days. * `claimConsensusRatio`: The claim assessment consensus ratio in percentage. The value must be less than or equal to 100. * `rewardPerClaimAssessment`: The reward per claim assessment. * `validatorRewardRatio`: The reward ratio for the validator. The value must be less than or equal to 100. The value of `validatorRewardRatio` + `voterRewardRatio` must be less than or equal to 100. * `voterRewardRatio`: The reward ratio for the voter. The value must be less than or equal to 100. The value of `validatorRewardRatio` + `voterRewardRatio` must be less than or equal to 100. * `claimAmountPerOnHoldStaking`: The claim amount per on-hold staking. * `pointPerClaimAssessment`: The point per claim assessment. These parameters are used to calculate the rewards for the claim validator and voter, the claim amount per on-hold staking, and the point per claim assessment. # Operator # Pool Manager Insurance Smart Contract ### currency ```solidity function currency() external view returns (address) ``` Get the currency address. | Name | Type | Description | | ---- | ------- | ---------------------------- | | \[0] | address | The address of the currency. | ### poolId ```solidity function poolId() external view returns (string) ``` Get the pool id. | Name | Type | Description | | ---- | ------ | ------------ | | \[0] | string | The pool id. | ### poolName ```solidity function poolName() external view returns (string) ``` Get the pool name. | Name | Type | Description | | ---- | ------ | -------------- | | \[0] | string | The pool name. | ### decimals ```solidity function decimals() external pure returns (uint8) ``` Get the decimals of the pool. | Name | Type | Description | | ---- | ----- | ------------------------- | | \[0] | uint8 | The decimals of the pool. | ### verifier ```solidity function verifier() external view returns (address) ``` Get the verifier address. | Name | Type | Description | | ---- | ------- | ------------------------------------------------------------------- | | \[0] | address | The address of the verifier that provides the verification service. | ### riskCarrierManager ```solidity function riskCarrierManager() external view returns (address) ``` Get the risk carrier manager address. | Name | Type | Description | | ---- | ------- | ---------------------------------------- | | \[0] | address | The address of the risk carrier manager. | ### upfrontManager ```solidity function upfrontManager() external view returns (address) ``` Get the upfront manager address. | Name | Type | Description | | ---- | ------- | ----------------------------------- | | \[0] | address | The address of the upfront manager. | ### validatorManager ```solidity function validatorManager() external view returns (address) ``` Get the validator manager address. | Name | Type | Description | | ---- | ------- | ------------------------------------- | | \[0] | address | The address of the validator manager. | ### setCurrency ```solidity function setCurrency(address _addr_) external ``` Set the currency address. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `CurrencyChanged` - Emitted when the currency address is changed successfully. | Name | Type | Description | | ------ | ------- | ---------------------------- | | *addr* | address | The address of the currency. | #### CurrencyChanged ```solidity event CurrencyChanged(address currency) ``` This event is emitted when the currency address is changed. | Name | Type | Description | | -------- | ------- | --------------------- | | currency | address | The currency address. | ### setPoolName ```solidity function setPoolName(string _poolName_) external ``` Set the pool name. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `PoolNameChanged` - Emitted when the pool name is changed successfully. | Name | Type | Description | | ---------- | ------ | -------------- | | *poolName* | string | The pool name. | #### PoolNameChanged ```solidity event PoolNameChanged(string poolName) ``` This event is emitted when the pool name is changed. | Name | Type | Description | | -------- | ------ | -------------- | | poolName | string | The pool name. | ### setPoolId ```solidity function setPoolId(string _poolId_) external ``` Set the pool id. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `PoolIdChanged` - Emitted when the pool id is changed successfully. | Name | Type | Description | | -------- | ------ | ------------ | | *poolId* | string | The pool id. | PoolIdChanged ```solidity event PoolIdChanged(string poolId) ``` This event is emitted when the pool id is changed. | Name | Type | Description | | ------ | ------ | ------------ | | poolId | string | The pool id. | ### setVerifier ```solidity function setVerifier(address _addr_) external ``` Set the verifier address. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `VerifierChanged` - Emitted when the verifier address is changed successfully. | Name | Type | Description | | ------ | ------- | ------------------------------------------------------------------- | | *addr* | address | The address of the verifier that provides the verification service. | #### VerifierChanged ```solidity event VerifierChanged(address verifier) ``` This event is emitted when the verifier address is changed. | Name | Type | Description | | -------- | ------- | --------------------- | | verifier | address | The verifier address. | ### setRiskCarrierManager ```solidity function setRiskCarrierManager(address _addr_) external ``` Set the risk carrier manager address. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `RiskCarrierManagerChanged` - Emitted when the risk carrier manager address is changed successfully. | Name | Type | Description | | ------ | ------- | ---------------------------------------- | | *addr* | address | The address of the risk carrier manager. | #### RiskCarrierManagerChanged ```solidity event RiskCarrierManagerChanged(address riskCarrierManager) ``` This event is emitted when the risk carrier manager address is changed. | Name | Type | Description | | ------------------ | ------- | --------------------------------- | | riskCarrierManager | address | The risk carrier manager address. | ### setUpfrontManager ```solidity function setUpfrontManager(address _addr_) external ``` Set the upfront manager address. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `UpfrontManagerChanged` - Emitted when the upfront manager address is changed successfully. | Name | Type | Description | | ------ | ------- | ----------------------------------- | | *addr* | address | The address of the upfront manager. | #### UpfrontManagerChanged ```solidity event UpfrontManagerChanged(address upfrontManager) ``` This event is emitted when the upfront manager address is changed. | Name | Type | Description | | -------------- | ------- | ---------------------------- | | upfrontManager | address | The upfront manager address. | ### setValidatorManager ```solidity function setValidatorManager(address _addr_) external ``` Set the validator manager address. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `ValidatorManagerChanged` - Emitted when the validator manager address is changed successfully. | Name | Type | Description | | ------ | ------- | ------------------------------------- | | *addr* | address | The address of the validator manager. | #### ValidatorManagerChanged ```solidity event ValidatorManagerChanged(address validatorManager) ``` This event is emitted when the validator manager address is changed. | Name | Type | Description | | ---------------- | ------- | ------------------------------ | | validatorManager | address | The validator manager address. | # Pricing Manager Insurance Smart Contract ### getPricingMerkleRoot ```solidity function getPricingMerkleRoot() external view returns (bytes32) ``` Get the pricing merkle root. | Name | Type | Description | | ---- | ------- | -------------------------------------------------------------- | | \[0] | bytes32 | The merkle root of the pricing data of the insurance products. | ### setPricingMerkleRoot ```solidity function setPricingMerkleRoot(bytes32 _merkleRoot_) external ``` Set the pricing merkle root. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `PricingMerkleRootChanged` - Emitted when the pricing merkle root is changed successfully. | Name | Type | Description | | ------------ | ------- | -------------------------------------------------------------- | | *merkleRoot* | bytes32 | The merkle root of the pricing data of the insurance products. | #### PricingMerkleRootChanged ```solidity event PricingMerkleRootChanged(bytes32 merkleRoot) ``` This event is emitted when the pricing merkle root is changed. | Name | Type | Description | | ---------- | ------- | ---------------- | | merkleRoot | bytes32 | The merkle root. | ### verifyMerkleProof ```solidity function verifyMerkleProof(bytes32[] _proof_, string _pricingReference_, uint256 _premiumRate_) external view returns (bool) ``` Verify the merkle proof of the pricing data. | Name | Type | Description | | ------------------ | ---------- | --------------------------------------- | | *proof* | bytes32\[] | The merkle proof of the pricing data. | | *pricingReference* | string | The reference of the insurance product. | | *premiumRate* | uint256 | The pricing data. | | Name | Type | Description | | ---- | ---- | --------------------------------------------------- | | \[0] | bool | True if the merkle proof is valid, false otherwise. | # Policy Manager Insurance Smart Contract ### createHashIssuePolicy ```solidity function createHashIssuePolicy(HashIssuePolicyParams _issueData_) external view returns (bytes32) ``` Create hash that verifier will sign and give it to user for issue policy. *Generates a hash of the parameters required for the verifier to sign the message and provide the signature to the user for issuing the policy.* | Name | Type | Description | | ----------- | ----------------------------------------------- | ---------------------------------------------------- | | *issueData* | [HashIssuePolicyParams](#hashissuepolicyparams) | The parameters of the issue policy are to be hashed. | | Name | Type | Description | | ---- | ------- | --------------------------------------------------------------------------------------------------------------------- | | \[0] | bytes32 | The hash of the required parameters, which can then be used to generate a signature for the user to issue the policy. | #### HashIssuePolicyParams ```solidity struct HashIssuePolicyParams { address policyholder; string policyId; string externalReferenceId; string documentHash; uint40 coverageStart; uint40 coverageEnd; uint40 claimRequestUntil; uint256 premium; uint256 sumInsured; uint40 signatureValidUntil; } ``` ### createHashRedeemPolicy ```solidity function createHashRedeemPolicy(HashRedeemPolicyParams _redeemData_) external view returns (bytes32) ``` Create hash that verifier will sign and give it to user for redeem policy. *Generates a hash of the parameters required for the verifier to sign the message and provide the signature to the user for redeeming the policy.* | Name | Type | Description | | ------------ | ------------------------------------------------- | ----------------------------------------------------- | | *redeemData* | [HashRedeemPolicyParams](#hashredeempolicyparams) | The parameters of the redeem policy are to be hashed. | | Name | Type | Description | | ---- | ------- | ---------------------------------------------------------------------------------------------------------------------- | | \[0] | bytes32 | The hash of the required parameters, which can then be used to generate a signature for the user to redeem the policy. | #### HashRedeemPolicyParams ```solidity struct HashRedeemPolicyParams { string policyId; uint8 redeemRate; uint8 riskCarrierRatio; uint40 signatureValidUntil; } ``` # Claim Manager Insurance Smart Contract ### getClaimRules ```solidity function getClaimRules() external view returns (ClaimRules) ``` Get the claim rules. | Name | Type | Description | | ---- | ----------------------------------------------------------------------------------------- | ---------------- | | \[0] | [ClaimRules](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimrules) | The claim rules. | ### setClaimRules ```solidity function setClaimRules(ClaimRules _cr_) external ``` Set the claim rules. Requirements: * `msg.sender` - The caller must have the role of `SUPER_MANAGER_LEVEL`. Events: * `ClaimRulesChanged` Emitted when the claim rules are changed successfully. | Name | Type | Description | | ---- | ----------------------------------------------------------------------------------------- | ---------------- | | *cr* | [ClaimRules](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimrules) | The claim rules. | #### ClaimRulesChanged ```solidity event ClaimRulesChanged(ClaimRules claimRules) ``` This event is emitted when the claim rules are changed. | Name | Type | Description | | ---------- | ----------------------------------------------------------------------------------------- | ---------------- | | claimRules | [ClaimRules](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimrules) | The claim rules. | ### getClaimLength ```solidity function getClaimLength() external view returns (uint256) ``` Get the claim length. | Name | Type | Description | | ---- | ------- | ----------------- | | \[0] | uint256 | The claim length. | ### createHashSubmitClaim ```solidity function createHashSubmitClaim(HashSubmitClaimParams _claimData_) external view returns (bytes32) ``` Create hash that verifier will sign and give it to user for submit claim policy. *Generates a hash of the parameters required for the verifier to sign the message and provide the signature to the user for the submit claim policy.* | Name | Type | Description | | ----------- | ----------------------------------------------- | ----------------------------------------------------------- | | *claimData* | [HashSubmitClaimParams](#hashsubmitclaimparams) | The parameters of the submit claim policy are to be hashed. | | Name | Type | Description | | ---- | ------- | ---------------------------------------------------------------------------------------------------------------------------- | | \[0] | bytes32 | The hash of the required parameters, which can then be used to generate a signature for the user to submit claim the policy. | #### HashSubmitClaimParams ```solidity struct HashSubmitClaimParams { string policyId; string documentHash; uint256 claimAmount; uint40 signatureValidUntil; } ``` # Policyholder # Policy Manager Insurance Smart Contract # issuePolicy
User begins the process by requesting an insurance quote that takes into account the risk drivers of the request. After that, the user receives a request signed by the off-chain service including the price and the Merkle proofs. The Merkle proofs help establish a trust mechanism for the off-chain and on-chain ecosystem. The user may then pass the pricing and the associated data as parameters, together with the accepted token standard, to the "Policy Manager" contract using the "Issue Policy" operation of the smart contract. Following this, the "Policy Manager" contract will verify with the "Price Manager" contract by using Merkle proofs as a verification process. In the event that the price verification is successful, the token will be transferred from the "Policy Manager" to the "Risk Carrier Manager" in the ratio specified by the pricing parameter for the risk carrier role. The "Risk Carrier Manager" then interacts with the external service provider. Then, the claims assessor, claims validator, claims voter, and governance boards have all been compensated for their services, and the upfront fee will be distributed among them. After all, the "Policy Manager" Contract will be updated to reflect the newly drafted policy. The function returns a boolean value indicating whether the policy purchase was successful or not. It also emits an `PolicyIssued` event, which includes information about the policy that was issued. ## issuePolicy ```solidity function issuePolicy( IssuePolicySignQuotedParams _ipsq_) external returns (bool) ``` The `issuePolicy()` function allows a user to issue a signed insurance policy with quoted premiums. The function takes one parameter: * `IssuePolicySignQuotedParams`: A struct that contains information about the policy being issued. This includes the policy ID, pricing reference, external reference ID, document hash, coverage start and end dates, claim expiration date, premium, sum insured, premium rate, risk carrier ratio, and other data such as the v, r, s values, and Merkle proof of the policy pricing. The function returns a boolean value indicating whether the policy issuance was successful or not. It also emits a `PolicyIssued` event, which includes information about the policy that was issued. Requirements: * `nonReentrant` The function must not be reentrant. * `whenNotPaused` The function must not be paused. Events: * `PolicyIssued` Emitted when the policy is issued successfully. **Parameters**
NameTypeDescription
ipsqIssuePolicySignQuotedParamsThe parameters of the policy to be issued.
**Return Values** | Name | Type | Description | | ---- | ---- | ------------------------------------------ | | \[0] | bool | True if the policy is issued successfully. | ### IssuePolicySignQuotedParams ```solidity struct IssuePolicySignQuotedParams { string policyId; string pricingReference; string externalReferenceId; string documentHash; uint40 coverageStart; uint40 coverageEnd; uint40 claimRequestUntil; uint256 premium; uint256 sumInsured; uint256 premiumRate; uint8 riskCarrierRatio; uint40 signatureValidUntil; uint8 v; bytes32 r; bytes32 s; bytes32[] proof; } ``` The `IssuePolicySignQuotedParams` struct is a structure that represents the parameters required to issue a signed insurance policy with quoted premiums. The struct includes the following fields: * `policyId`: A unique identifier for the policy. * `pricingReference`: The reference used for pricing the policy. * `externalReferenceId`: An external identifier for the policy. * `documentHash`: The hash of the policy document. * `coverageStart`: The start time of the coverage period. * `coverageEnd`: The end time of the coverage period. * `claimRequestUntil`: The time until which the policy holder can request a claim. * `premium`: The premium amount of the policy. * `sumInsured`: The sum insured amount of the policy. * `premiumRate`: The premium rate of the policy. * `riskCarrierRatio`: The ratio of risk that will be transferred to the risk carrier for this policy, with a maximum value of 100. * `signatureValidUntil`: The date until which the verifier's signature is valid. * `v`: The `v` value from the signed message that is used for signature verification. * `r`: The `r` value from the signed message that is used for signature verification. * `s`: The `s` value from the signed message that is used for signature verification. ### PolicyIssued ```solidity event PolicyIssued( address policyholder, string policyId, uint40 coverageStart, uint40 coverageEnd, uint40 claimclaimRequestUntil, uint256 sumInsured ) ``` The `PolicyIssued` event is triggered when a new insurance policy is issued. The event includes the following parameters: * `policyholder`: The address of the user who is buying the policy. * `policyId`: The unique identifier for the policy. * `coverageStart`: The timestamp at which the policy's coverage begins. * `coverageEnd`: The timestamp at which the policy's coverage ends. * `claimRequestUntil`: The timestamp at which the policy's claims request cannot be filed. * `sumInsured`: The amount of coverage provided by the policy. # redeemPolicy
The process starts when the user requests the off-chain service for a redeem quote value. Most of the time, the redeem value will be less than the insurance premium fee that the user paid the first time they bought the policy, since some fees and some coverage duration have already been paid for. After the user gets the redemption value along with the merkle proofs, they use the "Redeem Policy" operation of the smart contract to call the "Policy Manager" contract with the associated data as parameters. After that, the "Policy Manager" contract will verify with the "Pricing Manager" contract's redeem value by using merkle proofs as a verification process. If the redemption value check is successful, the "Policy Manager" contract will trigger the "RiskCarrier Manager." The "RiskCarrier Manager" then interacts to the external service provider to refund the fund. The token will then be sent from external service provider to the "Policy Manager" in the ratio set by the redemption value parameter for the risk carrier role. The "Policy Manager" contract will stamp that the policy has been canceled. The user can finally receive their money back in an amount corresponding with the token's redemption value according to the accepted token standard. ## redeemPolicy ```solidity function redeemPolicy(RedeemPolicyParams _redeemData_) external returns (bool) ``` The function **`redeemPolicy`** allows a user to redeem an insurance policy. The function takes a single parameter: * `RedeemPolicyParams`: A struct that contains information about the policy being redeemed. This includes the policy ID, redeem rate, risk carrier ratio, and signature valid until date. It also includes the v, r, and s values that are used in Ethereum transactions. The function returns a boolean value indicating whether the policy redemption was successful or not. It also emits a `PolicyRedeemed` event, which includes information about the policy that was redeemed, such as the policyholder's address, policy ID, redeem amount, and risk carrier ratio. The risk carrier ratio appears to be the percentage of the redeem amount that is being transferred back to the policyholder. Requirements: * `nonReentrant` The function must not be reentrant. * `whenNotPaused` The function must not be paused. Events: * `PolicyRedeemed` - Emitted when the policy is redeemed successfully. **Parameters** | Name | Type | Description | | ------------ | -------------------------------- | -------------------------------------------- | | *redeemData* | [RedeemPolicyParams](#parameter) | The parameters of the policy to be redeemed. | **Return Values** | Name | Type | Description | | ---- | ---- | -------------------------------------------- | | \[0] | bool | true if the policy is redeemed successfully. | ### RedeemPolicyParams ```solidity struct RedeemPolicyParams { string policyId; uint8 redeemRate; uint8 riskCarrierRatio; uint40 signatureValidUntil; uint8 v; bytes32 r; bytes32 s; } ``` The `RedeemPolicyParams` struct is a data structure used to pass a set of parameters to the redeemPolicy() function. The struct consists of the following fields: * `policyId`: The ID of the policy being redeemed. * `redeemRate`: The rate at which the policy is being redeemed. This is typically a percentage of the total policy value. * `riskCarrierRatio`: The ratio of the policy's risk being transferred back to the policyholder. This is typically a percentage of the policy's redeem amount. * `signatureValidUntil`: The date until which the verifier's signature is valid. * `v`: The `v` value from the signed message that is used for signature verification. * `r`: The `r` value from the signed message that is used for signature verification. * `s`: The `s` value from the signed message that is used for signature verification. The RedeemPolicyParams struct is used to pass all of the necessary information about redeeming a policy to the redeemPolicy() function. The function will use this information to calculate the redeem amount and transfer the appropriate amount back to the policyholder. ### PolicyRedeemed ```solidity event PolicyRedeemed( address policyholder, string policyId, uint256 redeemAmount, uint8 redeemRate, uint8 riskCarrierRatio ) ``` This `PolicyRedeemed` event is emitted when a policy is redeemed. The event includes the following parameters: * `policyholder`: the address of the policyholder who is redeeming the policy. * `policyId`: the unique identifier for the policy being redeemed. * `redeemAmount`: the amount being redeemed from the policy. * `redeemRate`: the rate at which the policy is being redeemed. * `riskCarrierRatio`: the percentage of the redeem amount that the risk carrier is required to transfer back to the policyholder. # Others ### isPolicyExist ```solidity function isPolicyExist(string _policyId_) external view returns (bool) ``` Get is the policy exist. | Name | Type | Description | | ---------- | ------ | -------------- | | *policyId* | string | The policy id. | | Name | Type | Description | | ---- | ---- | --------------------------------------------- | | \[0] | bool | True if the policy is exist, false otherwise. | ### getPolicyStatus ```solidity function getPolicyStatus(string _policyId_) external view returns (PolicyStatus) ``` Get the policy status. | Name | Type | Description | | ---------- | ------ | -------------- | | *policyId* | string | The policy id. | | Name | Type | Description | | ---- | ----------------------------------------------------------------------------------------- | ------------------ | | \[0] | [PolicyStatus](/covest-insaas-protocol/insaas-smart-contracts/policy-states#policystatus) | The policy status. | ### getPoliciesStatus ```solidity function getPoliciesStatus(string[] _policyIds_) external view returns (PolicyStatus[]) ``` Get the policies status. | Name | Type | Description | | ----------- | --------- | ------------------------------------------- | | *policyIds* | string\[] | The parameter that contains the policy ids. | | Name | Type | Description | | ---- | --------------------------------------------------------------------------------------------- | -------------------- | | \[0] | [PolicyStatus\[\]](/covest-insaas-protocol/insaas-smart-contracts/policy-states#policystatus) | The policies status. | ### getPolicyData ```solidity function getPolicyData(string _policyId_) external view returns (PolicyData) ``` Get the policy data. | Name | Type | Description | | ---------- | ------ | -------------- | | *policyId* | string | The policy id. | | Name | Type | Description | | ---- | ------------------------------------------------------------------------------------- | ---------------- | | \[0] | [PolicyData](/covest-insaas-protocol/insaas-smart-contracts/policy-states#policydata) | The policy data. | ### getPoliciesData ```solidity function getPoliciesData(string[] _policyIds_) external view returns (PolicyData[]) ``` Get the policies data. | Name | Type | Description | | ----------- | --------- | ------------------------------------------- | | *policyIds* | string\[] | The parameter that contains the policy ids. | | Name | Type | Description | | ---- | ----------------------------------------------------------------------------------------- | ------------------ | | \[0] | [PolicyData\[\]](/covest-insaas-protocol/insaas-smart-contracts/policy-states#policydata) | The policies data. | # Claim Manager Insurance Smart Contract # submitClaim
In a typical submit claim operation, the user first submits the data and claim evidences to an Off-chain API, which encrypts the bundle of data before storing all of the encrypted claim evidence in an IPFS service. User may send claim request to "Claim Manager" contract after receiving IPFS hash. Afterwards, the "Claim Manager" contract to initiate a claim case and establish a claim reserve to reserve potential claim paid, while concurrently invoking the "Validator Manager" contract to select a claim validator for the claim case based on the selection criteria of the "Validator Manager" contract. When the claim validator is chosen, the claim case will be stamped with the claim validator's contract address. After that, the "Claim Manager" contract will notify the claim validator about the claim job that should be performed. ## submitClaim ```solidity function submitClaim(SubmitClaimParams _claimData_) external returns (bool) ``` The `submitClaim()` function allows a user to submit a claim for an insurance policy. The function takes one parameter: * `SubmitClaimParams`: A struct that contains information about the claim being submitted. This includes the policy ID, document hash, claim amount, signature valid until date, and signature components v, r, and s. The `submitClaim()` function returns a boolean value indicating whether the claim submission was successful or not. It also emits a `ClaimSubmitted` event, which includes information about the claim that was submitted, such as the policy ID, claim ID, validator address, claim amount, and document hash. Requirements: * `nonReentrant` The function must not be reentrant. * `whenNotPaused` The function must not be paused. Events: * `ClaimSubmitted` Emitted when the claim is submitted successfully. **Parameters** | Name | Type | Description | | ----------- | --------------------------------------- | --------------- | | *claimData* | [SubmitClaimParams](#submitclaimparams) | The claim data. | **Return Values** | Name | Type | Description | | ---- | ---- | -------------------------------------------- | | \[0] | bool | True if the claim is submitted successfully. | ### SubmitClaimParams ```solidity struct SubmitClaimParams { string policyId; string documentHash; uint256 claimAmount; uint40 signatureValidUntil; uint8 v; bytes32 r; bytes32 s; } ``` The `SubmitClaimParams` struct represents the parameters required to submit a claim for an insurance policy. The struct includes the following fields: * `policyId`: A unique identifier for the policy associated with the claim. * `documentHash`: The hash of the claim document. * `claimAmount`: The amount of the claim. * `signatureValidUntil`: The date until which the verifier's signature is valid. * `v`: The `v` value from the signed message that is used for signature verification. * `r`: The `r` value from the signed message that is used for signature verification. * `s`: The `s` value from the signed message that is used for signature verification. ### ClaimSubmitted ```solidity event ClaimSubmitted( string policyId, uint256 claimId, address validator, uint256 claimAmount, string documentHash ); ``` The `ClaimSubmitted` event is emitted when a claim is submitted successfully. The event includes the following parameters: * `policyId`: The ID of the policy associated with the claim. * `claimId`: The ID of the claim that was submitted. * `validator`: The address of the validator who selected from the submitted claim. * `claimAmount`: The amount of the claim that was submitted. * `documentHash`: The hash of the claim document. The `ClaimSubmitted` event is emitted when a user submits a claim successfully. It includes information about the claim that was submitted, including the policy ID, claim ID, validator address, claim amount, and document hash. # Others ### cancelClaim ```solidity function cancelClaim(uint256 _claimId_) external returns (bool) ``` Cancel a claim. Requirements: * `nonReentrant` The function must not be reentrant. * `whenNotPaused` The function must not be paused. Events: * `ClaimAssessmentConsensusReached` Emitted when the claim is canceled successfully. | Name | Type | Description | | --------- | ------- | ------------- | | *claimId* | uint256 | The claim id. | | Name | Type | Description | | ---- | ---- | ------------------------------------------- | | \[0] | bool | True if the claim is canceled successfully. | #### ClaimAssessmentConsensusReached ```solidity event ClaimAssessmentConsensusReached(uint256 claimId, ClaimStatus status) ``` This event is emitted when the claim is consensus. | Name | Type | Description | | ------- | ------------------------------------------------------------------------------------------- | ----------------- | | claimId | uint256 | The claim id. | | status | [ClaimStatus](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimstatus) | The claim status. | ### getClaimData ```solidity function getClaimData(uint256 _claimId_) external view returns (ClaimData) ``` Get the claim data. | Name | Type | Description | | --------- | ------- | ------------- | | *claimId* | uint256 | The claim id. | | Name | Type | Description | | ---- | --------------------------------------------------------------------------------------- | --------------- | | \[0] | [ClaimData](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimdata) | The claim data. | ### getClaimsData ```solidity function getClaimsData(uint256[] _claimIds_) external view returns (ClaimData[]) ``` Get the claims data. | Name | Type | Description | | ---------- | ---------- | -------------- | | *claimIds* | uint256\[] | The claim ids. | | Name | Type | Description | | ---- | ------------------------------------------------------------------------------------------- | ---------------- | | \[0] | [ClaimData\[\]](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimdata) | The claims data. | ### getClaimStatus ```solidity function getClaimStatus(uint256 _claimId_) external view returns (ClaimStatus) ``` Get the claim status. | Name | Type | Description | | --------- | ------- | ------------- | | *claimId* | uint256 | The claim id. | | Name | Type | Description | | ---- | ------------------------------------------------------------------------------------------- | ----------------- | | \[0] | [ClaimStatus](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimstatus) | The claim status. | ### getClaimsStatus ```solidity function getClaimsStatus(uint256[] _claimIds_) external view returns (ClaimStatus[]) ``` Get the claims status. | Name | Type | Description | | ---------- | ---------- | -------------- | | *claimIds* | uint256\[] | The claim ids. | | Name | Type | Description | | ---- | ----------------------------------------------------------------------------------------------- | ------------------ | | \[0] | [ClaimStatus\[\]](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimstatus) | The claims status. | # Claim Assessor # Claim Manager Insurance Smart Contract
Claim payout operation begins with the claim validator, who is responsible for approving the claim amount and providing approved amount data associated with the claim case to the "Claim Manager". The claim voter will then be notified by the contract and the claim reserve value will be recorded. The claim's status will shift from the voting phase to the finalized phase once the claim voter vote has been concluded and a consensus has been reached. If the risk subsidy ratio is 50 percent for each risk carrier, for example, the contract will submit a claim to the risk carrier service after the claim payment request is fulfilled, requesting payment of 100 USD. The agreed-upon split is 50/50, with each risk carrier taking responsibility for 50 USD. Once the payment from the risk carrier service has been paid to the "Claim Manager," the "Claim Manager" will then update the claim case status and the amount that has been paid out in claims. Finally, the token's claim payout value will be paid to the user in an amount that corresponds the approved claim amount according to the accepted token standard. ### submitAssessment ```solidity function submitAssessment( uint256 _claimId_, uint256 _claimApprovedAmount_, bool _isAccepted_ ) external returns (bool) ``` "The `submitAssessment` function allows a validator to submit an assessment for an insurance claim. The function takes three parameters: the claim ID, the approved amount for the claim, and a flag indicating whether the claim is accepted or rejected. {% hint style="info" %} The caller must be a validator in the claim case, which means that they are a validator staked in the selected product pool and have been chosen to participate in the assessment of the claim. {% endhint %} Upon successful submission of the assessment, the function emits the `ClaimAssessmentSubmitted` event. If the validator reward needs to be increased, the function will also emit the `ClaimAssessmentRewardIncreased` event. When the consensus on the assessment of a claim is reached, the function will emit the `ClaimAssessmentConsensusReached` event, indicating that the claim assessment process is complete, and the payout to the policy holder can be initiated. Additionally, if the consensus is reached, the function will also emit the `ClaimAssessmentPointIncreased` event, signifying that the validator's point will be increased. The function returns a boolean value, with `true` indicating that the assessment has been submitted successfully." Requirements: * `nonReentrant` - The function must not be reentrant. * `whenNotPaused` - The function must not be paused. Events: * [`ClaimAssessmentSubmitted` ](#claimassessmentsubmitted)- Emitted when the assessment is submitted successfully. * [`ClaimAssessmentRewardIncreased` ](#claimassessmentrewardincreased)- Emitted when the claim validator reward is increased successfully. * [`ClaimAssessmentConsensusReached` ](#claimassessmentconsensusreached)- Emitted when the consensus on the assessment of a claim is reached. This event signifies that the claim assessment process is complete and the payout to the policy holder can be initiated. * [`ClaimAssessmentPointIncreased`](#claimassessmentpointincreased) - Emitted when the consensus on the assessment of a claim is reached. This event signifies that the claim assessment process is complete and the point will increased to the validator of the claim. **Parameters** | Name | Type | Description | | --------------------- | ------- | ------------------------------------------------------------------------------------------- | | *claimId* | uint256 | The claim id. | | *claimApprovedAmount* | uint256 | The approved amount of the claim that the validator has approved. | | *isAccepted* | bool | The validator is a flag that indicates whether the submitted claim is accepted or rejected. | **Return Values** | Name | Type | Description | | ---- | ---- | ------------------------------------------------- | | \[0] | bool | True if the assessment is submitted successfully. | #### ClaimAssessmentSubmitted ```solidity event ClaimAssessmentSubmitted( uint256 claimId, address validator, uint256 claimApprovedAmount, bool isAccepted ) ``` This event is emitted when the assessment is submitted successfully. | Name | Type | Description | | ------------------- | ------- | ------------------------------------------------------------------------------------------- | | claimId | uint256 | The claim id. | | validator | address | The validator address who selected from the submitted claim. | | claimApprovedAmount | uint256 | The approved amount of the claim that the validator has approved. | | isAccepted | bool | The validator is a flag that indicates whether the submitted claim is accepted or rejected. | ### voteAssessment ```solidity function voteAssessment( uint256 _claimId_, bool _isAccepted_ ) external returns (bool) ``` "The `voteAssessment` function allows a claim voter, who is a validator staked in a selected product pool but was not chosen to participate in the assessment of a claim, to vote on the assessment. The function takes two parameters: the claim ID and a boolean flag indicating whether the claim is accepted or rejected. {% hint style="info" %} The caller must be a claim voter, which means that they are a validator staked in the selected product pool but were not chosen to participate in the assessment of the claim. {% endhint %} Upon successful voting, the function emits the `ClaimAssessmentVoted` event. If the claim voter reward needs to be increased, the function will also emit the `ClaimAssessmentRewardIncreased` event. When the consensus on the assessment of a claim is reached, the function will emit the `ClaimAssessmentConsensusReached` event, indicating that the claim assessment process is complete, and the payout to the policy holder can be initiated. Additionally, if the consensus is reached, the function will also emit the `ClaimAssessmentPointIncreased` event, signifying that the validator's point will be increased. The function returns a boolean value, with `true` indicating that the vote has been submitted successfully." Requirements: * `nonReentrant` - The function must not be reentrant. * `whenNotPaused` - The function must not be paused. Events: * [`ClaimAssessmentVoted`](#claimassessmentvoted) - Emitted when the assessment is voted successfully. * [`ClaimAssessmentRewardIncreased` ](#claimassessmentrewardincreased)- Emitted when the claim voter reward is increased successfully. * [`ClaimAssessmentConsensusReached`](#claimassessmentconsensusreached) - Emitted when the consensus on the assessment of a claim is reached. This event signifies that the claim assessment process is complete and the payout to the policy holder can be initiated. * [`ClaimAssessmentPointIncreased`](#claimassessmentpointincreased) - Emitted when the consensus on the assessment of a claim is reached. This event signifies that the claim assessment process is complete and the point will increased to the validator of the claim. | Name | Type | Description | | ------------ | ------- | --------------------------------------------------------------------------------------- | | *claimId* | uint256 | The claim id. | | *isAccepted* | bool | The voter is a flag that indicates whether the submitted claim is accepted or rejected. | | Name | Type | Description | | ---- | ---- | --------------------------------------------- | | \[0] | bool | True if the assessment is voted successfully. | #### ClaimAssessmentVoted ```solidity event ClaimAssessmentVoted(uint256 claimId, address voter, bool isAccepted) ``` This event is emitted when the assessment is voted successfully. | Name | Type | Description | | ---------- | ------- | --------------------------------------------------------------------------------------- | | claimId | uint256 | The claim id. | | voter | address | The voter address. | | isAccepted | bool | The voter is a flag that indicates whether the submitted claim is accepted or rejected. | #### ClaimAssessmentRewardIncreased ```solidity event ClaimAssessmentRewardIncreased(uint256 claimId, address caller, uint256 reward) ``` This event is emitted when the assessment is voted successfully. | Name | Type | Description | | ------- | ------- | -------------------------------------------------------------------------- | | claimId | uint256 | The claim id. | | caller | address | The caller's address means the validator's address or the voter's address. | | reward | uint256 | The reward amount that given to the voter. | #### ClaimAssessmentConsensusReached ```solidity event ClaimAssessmentConsensusReached(uint256 claimId, ClaimStatus status) ``` This event is emitted when the claim is consensus. | Name | Type | Description | | ------- | ------------------------------------------------------------------------------------------- | ----------------- | | claimId | uint256 | The claim id. | | status | [ClaimStatus](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimstatus) | The claim status. | #### ClaimAssessmentPointIncreased ```solidity event ClaimAssessmentPointIncreased(uint256 claimId, address validator, uint256 point) ``` This event is emitted when the claim is consensus. | Name | Type | Description | | --------- | ------- | ------------------------------------------------------------ | | claimId | uint256 | The claim id. | | validator | address | The validator address who selected from the submitted claim. | | point | uint256 | The point amount that given to the validator. | # Governance Board # Claim Manager Insurance Smart Contract ### finalizeAssessment ```solidity function finalizeAssessment(uint256 _claimId_, bool _isAccepted_) external returns (bool) ``` "The `finalizeAssessment` function allows the governance board to finalize the assessment for an insurance claim. The function takes two parameters: the claim ID and a boolean flag indicating whether the claim is accepted or rejected. {% hint style="info" %} The function can only be called after the claim has expired and has not yet reached consensus. {% endhint %} Upon successful finalization of the assessment, the function emits the `ClaimAssessmentConsensusReached` event, indicating that the claim assessment process is complete, and the payout to the policy holder can be initiated. Additionally, the function will emit the `ClaimAssessmentPointIncreased` event, signifying that the validator's point will be increased. The function returns a boolean value, with `true` indicating that the assessment has been finalized successfully." Requirements: * `nonReentrant` - The function must not be reentrant. * `whenNotPaused` - The function must not be paused. * `msg.sender` - The caller must have the role of `GOVERNANCE_BOARD_LEVEL`. Events: * `ClaimAssessmentConsensusReached` - Emitted when the assessment is finalized successfully. * `ClaimAssessmentPointIncreased` - Emitted when the consensus on the assessment of a claim is reached. This event signifies that the claim assessment process is complete and the point will increased to the validator of the claim. | Name | Type | Description | | ------------ | ------- | -------------------------------------------------------------------------------------------------- | | *claimId* | uint256 | The claim id. | | *isAccepted* | bool | The governance board will flag that indicates whether the submitted claim is accepted or rejected. | | Name | Type | Description | | ---- | ---- | ------------------------------------------------- | | \[0] | bool | True if the assessment is finalized successfully. | #### ClaimAssessmentConsensusReached ```solidity event ClaimAssessmentConsensusReached(uint256 claimId, ClaimStatus status) ``` This event is emitted when the claim is consensus. | Name | Type | Description | | ------- | ------------------------------------------------------------------------------------------- | ----------------- | | claimId | uint256 | The claim id. | | status | [ClaimStatus](/covest-insaas-protocol/insaas-smart-contracts/claim-case-states#claimstatus) | The claim status. | #### ClaimAssessmentPointIncreased ```solidity event ClaimAssessmentPointIncreased(uint256 claimId, address validator, uint256 point) ``` This event is emitted when the claim is consensus. | Name | Type | Description | | --------- | ------- | ------------------------------------------------------------ | | claimId | uint256 | The claim id. | | validator | address | The validator address who selected from the submitted claim. | | point | uint256 | The point amount that given to the validator. | # Contract Integration If policyholder is a smart contract If the policyholder is a smart contract, the contract must implement certain functions to interact with an insurance contract for the purposes of issuing, redeeming, and submitting claims for policies. ### onPolicyIssued ```solidity function onPolicyIssued(address operator, address from, string policyId) external returns (bytes4) ``` This function will called by the insurance contract (policy manager facet) when the policy is issued and the caller is contract. *The selector can be obtained in Solidity with `IInsuranceIssuer.onPolicyIssued.selector`.* | Name | Type | Description | | -------- | ------- | --------------------- | | operator | address | The operator address. | | from | address | The from address. | | policyId | string | The policy id. | | Name | Type | Description | | ---- | ------ | ------------------------------------------------------ | | \[0] | bytes4 | The bytes4 of the selector of onPolicyIssued function. | ### onPolicyRedeemed ```solidity function onPolicyRedeemed(address operator, address from, string policyId) external returns (bytes4) ``` This function will called by the insurance contract (policy manager facet) when the policy is redeemed and the caller is contract. *The selector can be obtained in Solidity with `IInsuranceIssuer.onPolicyRedeemed.selector`.* | Name | Type | Description | | -------- | ------- | --------------------- | | operator | address | The operator address. | | from | address | The caller address. | | policyId | string | The policy id. | | Name | Type | Description | | ---- | ------ | -------------------------------------------------------- | | \[0] | bytes4 | The bytes4 of the selector of onPolicyRedeemed function. | ### onClaimSubmitted ```solidity function onClaimSubmitted(address operator, address from, string policyId) external returns (bytes4) ``` This function will called by the insurance contract (claim manager facet) when the policy is submitted and the caller is contract. *The selector can be obtained in Solidity with `IInsuranceIssuer.onClaimSubmitted.selector`.* | Name | Type | Description | | -------- | ------- | --------------------- | | operator | address | The operator address. | | from | address | The caller address. | | policyId | string | The policy id. | | Name | Type | Description | | ---- | ------ | -------------------------------------------------------- | | \[0] | bytes4 | The bytes4 of the selector of onClaimSubmitted function. | # Covest Warranty
#### Welcome to Covest Warranty: Empowering Warranty Management At Covest Warranty, we are dedicated to revolutionizing the way warranty management is handled. We understand that managing warranties can be complex and time-consuming for businesses. That's why we've developed Covest Warranty, a state-of-the-art backend system that streamlines and enhances warranty management processes, powered by the Covest InSaaS Protocol. #### What is Covest Warranty? Covest Warranty serves as the core backend system for warranty management, leveraging the advanced capabilities of the Covest InSaaS Protocol. It is designed to simplify and optimize the entire warranty lifecycle, from product registration to claims processing. Our platform is built with cutting-edge technology to provide businesses with a comprehensive and efficient solution for managing warranties. #### How does it work? Covest Warranty seamlessly integrates into your existing infrastructure, acting as a centralized hub for warranty-related operations. Our system automates and digitizes various warranty processes, including warranty registration, tracking, claims management, and analytics. By leveraging the power of the Covest InSaaS Protocol, Covest Warranty ensures transparency, security, and efficiency in warranty management. #### Why choose Covest Warranty? 1. Streamlined Warranty Management: Covest Warranty eliminates manual and paper-based processes, reducing administrative burdens and ensuring accuracy and consistency in warranty management. Our platform automates workflows, minimizes errors, and enhances overall operational efficiency. 2. Improved Customer Experience: With Covest Warranty, businesses can provide their customers with a seamless and hassle-free warranty experience. From easy product registration to streamlined claims processing, our system enhances customer satisfaction and loyalty. 3. Comprehensive Analytics: Covest Warranty offers powerful analytics and reporting capabilities, providing businesses with valuable insights into warranty performance. This data-driven approach enables proactive decision-making, cost optimization, and the ability to identify trends and patterns for product improvement. 4. Customizable and Scalable: Covest Warranty is a flexible and scalable solution that can be tailored to meet the unique needs of your business. Whether you are a small startup or a large enterprise, our platform can adapt to your requirements and grow alongside your business.
#### Experience the Future of Warranty Management with Covest Warranty Join us on the journey to transform warranty management. Covest Warranty, powered by the Covest InSaaS Protocol, empowers businesses to streamline processes, enhance customer satisfaction, and make data-driven decisions. Discover the advantages of our cutting-edge backend system and revolutionize the way you manage warranties. Discover the Covest InSaaS Protocol—an exciting breakthrough in insurance innovation and accessibility! Dive into the full documentation to unlock a world of possibilities. Join us in revolutionizing the insurance industry! Read the full docs now. {% content-ref url="/pages/i727ybcOMKXMfZegtAbZ" %} [Covest InSaaS Protocol](/) {% endcontent-ref %} To learn more about Covest Warranty and how it can benefit your business, get in touch with our team today. {% embed url="" %} # Key Components
1. **Digital Insurance**: Covest Warranty offers a seamless, paperless, and streamlined process for insurance management. It eliminates manual tasks, reduces paperwork, and automates various warranty-related processes for enhanced efficiency and customer satisfaction. 2. **Blockchain System**: The platform leverages blockchain technology to deliver transparency, immutable ledger-based data storage, ease of integration, and a shared data environment. It ensures the integrity and security of warranty-related information while providing a collaborative space for authorized stakeholders. 3. **Data Science**: Covest Warranty employs real-time deep data analysis and provides insightful precision. Through advanced data analytics, it enables businesses to gain valuable insights into warranty performance, customer behavior, and operational efficiency for data-driven decision-making. # System Overview
Covest Warranty is a comprehensive warranty management system built on the Covest InSaaS Protocol. The platform leverages the power of blockchain technology and smart contracts on an EVM-based chain to provide a transparent, efficient, and secure solution for warranty management. #### **Key Components**: 1. **Customer Portal System**: The customer portal provides a user-friendly interface for customers to access and manage their warranties. Customers can register products, submit claims, track the status of their claims, and view policy details through the portal. * **My Claim Management**: This module within the system enables efficient management and processing of warranty claims. It includes functionalities such as claim submission, assessment, approval, and settlement. * **My Policy Management**: The policy management module allows administrators to define and manage warranty policies. It includes features like policy creation, customization, pricing, and terms and conditions configuration. * **KYC Management**: The system incorporates KYC (Know Your Customer) management capabilities to ensure compliance with regulatory requirements. It enables the verification and management of customer identities and helps prevent fraud and unauthorized access. 2. **Admin Portal System**: The admin portal offers a comprehensive dashboard for administrators to manage and oversee warranty operations. Administrators can monitor policy performance, process claims, perform risk assessments, and handle other administrative tasks. * **Policy Control Management**: This component allows administrators to have control over policy-related settings, including coverage limits, deductibles, claim processes, and policy renewals. * **Risk Control Management**: The risk control management module enables administrators to assess and manage the risk associated with warranty coverage. It includes risk evaluation, underwriting processes, and risk mitigation strategies. * **DLT Control Management**: DLT (Distributed Ledger Technology) control management ensures the smooth operation and integrity of the blockchain-based warranty system. It includes managing network nodes, consensus mechanisms, and maintaining the decentralized nature of the system. * **Claim Control Management**: Claim control management focuses on efficiently handling warranty claims. It involves workflows, documentation, authorization, and ensuring prompt and accurate claim settlements. * **Finance Control Management**: This module provides financial control and management capabilities. It includes features such as premium calculations, payment processing, financial reporting, and reconciliation. * **KYB Control Management**: KYB (Know Your Business) control management ensures compliance with regulatory requirements related to business entities involved in the warranty ecosystem. It includes verification and management of merchant and partner identities. 3. **APIs & SDKs**: Covest Warranty offers APIs and SDKs (Software Development Kits) to facilitate integration with external systems and enable developers to build custom applications and extend the functionality of the warranty system. * **Off-chain Computation**: Certain computations or data processing tasks are performed off-chain to optimize performance and reduce transaction costs. Off-chain computation modules handle complex calculations or data-intensive operations efficiently. * **Tx Signer**: The transaction signer module securely signs and validates warranty-related transactions, ensuring data integrity and preventing unauthorized modifications. * **Encryption Engine**: The encryption engine component ensures the confidentiality and security of sensitive warranty-related data. It employs encryption algorithms to protect data from unauthorized access. * **IPFS Service**: The system utilizes IPFS (InterPlanetary File System) to store and retrieve warranty-related documents, providing decentralized and resilient storage. 4. **Insurance Smart Contract on an EVM-Based Chain**: The core of the system is the smart contract running on an EVM-based blockchain. It enables the execution of warranty-related transactions, ensuring transparency, immutability, and trust in the warranty management process. By leveraging the Covest Warranty platform, businesses can enhance their warranty management processes, optimize operational efficiency, reduce costs, mitigate risks, and foster trust among customers and partners. Whether it's managing claims, policies, KYC requirements, risk assessment, finance control, or interactions between customers, merchants, and administrators, Covest Warranty provides a comprehensive solution that drives efficiency and transparency in the warranty ecosystem. # Core Features # Contract Management ### Contract Portfolio Overview The warranty management system provides a user-friendly dashboard for a comprehensive overview of warranty contracts. It includes key metrics, summaries, and a detailed contract list with information like names, dates, parties involved, and contract values. Real-time notifications and an activity log ensure timely updates and a comprehensive history of warranty contract activities. The system offers customizable data display and filtering options. Users can personalize their views and focus on specific criteria such as warranty contract type, status, or date range. Collaboration features enable effective team communication. Additionally, the system provides export and reporting capabilities, facilitating data extraction and generating reports for analysis, sharing with stakeholders, and compliance purposes. These features streamline warranty contract management, promoting efficiency, organization, and informed decision-making.
### Contract: Customer The customer section in the system displays crucial data, such as the customer's name, ID, contact information, and address, facilitating effective identification and communication. For more comprehensive details and preferences, users can access the customer's off-chain profile or associated records.
### Contract: Product The product section offers in-depth information about a specific item that is covered by Covest Warranty. Users can access comprehensive details, including the brand, model, serial number, and other relevant specifications of the product.
### **Contract: Coverage** To access comprehensive coverage details and essential information regarding the coverage: This section provides comprehensive information about the coverage package. Users can find details such as the package name, duration of coverage, start date, and end date. This information helps users understand the specific coverage period and its corresponding terms and conditions.
### Contract: Add Link Document This section allows users to add and associate multiple documents to a contract. Users can upload and attach various files, such as PDFs, Word documents, or images, to the contract record. Each uploaded document will undergo hashing to generate a unique checksum hash for verification purposes.
### DLT Management To enhance the safety, transparency, and verifiability of information, the DLT management system incorporates blockchain technology. This ensures that the data imported into the Contract Management System (CMS) is securely stored on a decentralized and tamper-resistant ledger. As part of this process, a checksum hash is generated for various types of data, including customer information, product data, coverage data, and related link document files. This checksum hash serves as a verification mechanism, allowing authorized users to validate the accuracy and integrity of the off-chain information. By comparing the calculated checksum with the on-chain value, users can verify that the off-chain data remains unaltered, providing an additional layer of security and trust. By utilizing blockchain technology, the CMS ensures that the stored data is resilient against tampering and unauthorized modifications. This decentralized approach grants authorized users access to a transparent and immutable record of information, enhancing data integrity and reinforcing the trustworthiness of the system.
# Warranty Certificate ### Covest Warranty: Blockchain-backed Certificate Covest Warranty utilizes the power of blockchain technology to provide customers with a secure and tamper-proof certificate. This certificate serves as a transparent record of the warranty contract and includes comprehensive coverage details. By incorporating blockchain, Covest Warranty enhances the security and trustworthiness of its warranty certificates. Customers can rely on the integrity of their warranty protection, knowing that their certificate is securely stored and tamper-proof. The blockchain-backed certificate provides reliable and transparent proof of coverage, reinforcing customer confidence in Covest Warranty's commitment to exceptional warranty services.
# Claim Management ###
### Claim Management The CMS (Contract Management System) includes a comprehensive claim management feature that ensures efficient processing and authorization of claims. All claim statuses, claim values, sum insured, and document hashes are stored on-chain, providing transparency and immutability. Sensitive data, however, is stored off-chain for enhanced security. When it comes to claim validation and approval, there are two possible scenarios. Firstly, the system can automate the claim validation process, utilizing predefined rules and algorithms to verify the claim against the specified criteria. This automation streamlines the claim processing, allowing for quick and accurate validation. Alternatively, a company supervisor, such as a branch supervisor, can be authorized within the CMS to manually review and approve claims. This human validation process ensures an additional layer of scrutiny and allows for the exercise of discretion in complex or exceptional cases. To maintain control and oversight, only authorized company or branch supervisors have the authority to approve claims within the CMS. This ensures that claims undergo proper evaluation and validation by qualified individuals, guaranteeing adherence to company policies and procedures. By integrating claim management into the CMS, companies can streamline and automate claim processing while maintaining the necessary oversight and authorization from qualified supervisors. This comprehensive approach optimizes the efficiency and accuracy of the claim management process, providing a robust and secure platform for handling and authorizing claims.
### Claim: Detail In the claim management process, supervisors within the CMS have the capability to access and review the details of claim requests submitted by customers. This feature enables supervisors to gather essential information and perform a primary estimation of the damage reported by the customer. Supervisors can access the claim details, which may include relevant information such as the nature of the claim, supporting documentation, incident descriptions, and any additional evidence provided by the customer. This comprehensive view empowers supervisors to evaluate the claim and make an initial assessment of the reported damage. By having access to the claim details, supervisors can effectively analyze the information provided by the customer and initiate the necessary actions for processing the claim. This primary estimation of the damage helps supervisors determine the next steps in the claim resolution process, such as requesting further documentation or assigning a field inspector for a more detailed assessment. The ability for supervisors to review claim details within the CMS ensures a thorough understanding of each claim, facilitating efficient decision-making and ensuring that claims are handled appropriately from the initial stages. This feature enables supervisors to provide accurate and timely responses to customers, enhancing the overall customer experience and streamlining the claim management process.
### Claim: Product In the claim management process, product information plays a crucial role in assessing whether repair or replacement is necessary. The product details provided by the customer are utilized to evaluate and determine the appropriate course of action. When reviewing a claim, the product information is used to assess the feasibility of repair or replacement. The CMS utilizes the details such as the brand and model of the product to identify and consider options for repair or replacement. The goal is to provide customers with new, similar items of the same brand and model, or products with comparable qualities. By leveraging the product information, the CMS ensures that customers receive appropriate solutions that align with the original product's specifications and quality. Whether it involves repairing the item to its original condition or providing a suitable replacement, the product details enable the claim management process to deliver an outcome that meets the customer's expectations. The utilization of product information within the claim management process enhances accuracy, efficiency, and customer satisfaction. By considering the specific brand, model, and comparable qualities, the CMS aims to resolve claims effectively and provide customers with satisfactory resolutions for their products.
DLT Manangement: Claim Data Storage The DLT (Distributed Ledger Technology) section within the CMS ensures secure and transparent storage of claims information, enhancing the integrity of the claim process. By leveraging DLT Management, data is recorded immutably, providing a trustworthy and accurate record of each claim. Claims information, including associated documentation, is stored on the distributed ledger, ensuring tamper-proof and transparent data management. The use of DLT guarantees data integrity, preventing unauthorized alterations and ensuring the reliability of the recorded information. Additionally, checksums are applied to claim documents, further enhancing data security and enabling verification of document integrity. Through the adoption of DLT Management, the CMS establishes a robust and transparent system for storing and retrieving claims data. This enhances the security and transparency of the claim process, instilling confidence in stakeholders and facilitating efficient claim resolution.
# Customer Portal ### Customer Portal: Accessing Contract and Claim Information The Customer Portal is a user-friendly platform that allows customers to conveniently access and track their contract and claim information. Customers can quickly retrieve real-time updates on contract status, review contract details, and access digital copies. Additionally, they can monitor claim progress, view supporting documents, and stay informed about actions taken. The Customer Portal provides a centralized platform for managing account information, updating contact details, and communicating with support teams. This self-service portal empowers customers with greater control and informed decision-making throughout their contract and claims journey.
# API Documentations
In this section, you will find comprehensive documentation and example code for integrating with our GraphQL API. GraphQL is a powerful query language that allows you to efficiently retrieve data from our system and perform various operations. #### **Docs and Example Code** We provide detailed documentation that explains the schema, types, and available queries and mutations in our GraphQL API. You will find information on how to structure your GraphQL queries, the available fields and arguments, and how to retrieve the desired data from our system. Additionally, we offer example code snippets that demonstrate how to interact with our GraphQL API using popular programming languages and frameworks. These examples serve as a reference to help you understand the syntax and structure of GraphQL queries and mutations when integrating with our API. By following our documentation and utilizing the example code, you can effectively integrate our GraphQL API into your applications and workflows, leveraging the power of GraphQL to retrieve data efficiently and perform operations seamlessly. Explore our GraphQL API integration pages to access the complete documentation and example code, empowering you to seamlessly integrate with our system and unlock the full potential of our API. Visit the full documentation for Covest Warranty's GraphQL API here: {% embed url="" %} # API Diagrams # Create Order Flow
For merchants, the "**Create Order Flow"** involves several steps: **Merchant Step 1:** Login Merchants initiate the process by logging in using their username and password. This authentication step verifies their credentials and generates a token for subsequent API requests. **Merchant Step 2**: Get Quote Premium After successful login, merchants retrieve a quote premium for the desired product. They send a query to the API with parameters such as SKU number, base price, and net price. The API returns detailed information about the product, including its ID, type, category, price, premium package options, and other relevant data. **Merchant Step 3**: Create Order Once the quote premium is obtained, merchants proceed to create the order. They send a mutation to the API, providing necessary parameters such as customer ID or details, product ID or details, coverage start date, package option ID, serial number, and document IDs (if applicable). The API processes the mutation, creating the order and returning important details such as the order ID, policy ID, premium amount, coverage dates, creation timestamp, status, customer information, product information, package details, and package option details. In addition, if integrated with a blockchain, merchants can include further steps to interact with the blockchain layer. This may involve retrieving transaction hashes, block numbers, or other relevant data associated with the order creation. By following these steps, merchants can seamlessly create orders within the system. The login process ensures secure authentication, obtaining the quote premium provides accurate pricing information, and creating the order captures all necessary details.The integration with the blockchain layer adds transparency and immutability to the transaction data, enhancing trust and traceability in the redemption process. Please note that the provided flow assumes a general process and may require adjustments to align with specific implementation details and requirements. Explore our GraphQL API integration pages to access the complete documentation and example code, empowering you to seamlessly integrate with our system and unlock the full potential of our API. Visit the full documentation for Covest Warranty's GraphQL API here: {% embed url="" %} # Redeem Order Flow
For merchants, the "Redeem Order Flow" involves the following steps: **Merchant Step 1**: Login Merchants initiate the process by logging in to the Covest API using their username and password. This step verifies their credentials, and upon successful login, the API generates an authentication token and returns it to the merchant. **Merchant Step 2**: Redeem Order Once authenticated, merchants proceed to redeem an order. They send a request to the Covest API, specifying the order ID that needs to be redeemed. The API processes the request and returns a redeem success result, indicating a successful redemption. In addition, if integrated with a blockchain, merchants can include further steps to interact with the blockchain layer. This may involve retrieving transaction hashes, block numbers, or other relevant data associated with the order redemption. By following these steps, merchants can seamlessly initiate the redemption process through the Covest API. The integration with the blockchain layer adds transparency and immutability to the transaction data, enhancing trust and traceability in the redemption process. Please note that the provided flow assumes a general process and may require adjustments to align with specific implementation details and requirements. Explore our GraphQL API integration pages to access the complete documentation and example code, empowering you to seamlessly integrate with our system and unlock the full potential of our API. Visit the full documentation for Covest Warranty's GraphQL API here: {% embed url="" %}