Ensuro - Blockchain-based, licensed, reinsurance

Ensuro is a blockchain-based protocol that manages the capital to support insurance products.

It allows liquidity providers (LPs) to deposit capital (using stablecoins) that will fulfill the solvency capital requirements of underwritten policies. This capital will be deposited in different pools (eTokens) that are linked to different risks. The capital will be locked for the duration of policies and will report profits to the LPs in the form of continuous interest.

On the policy side, the policies are injected into the protocol by Risk Modules. Each Ensuro partner is represented by a Premiums Account contract, which accumulates the pure premium of that partner. Connected to a given Premiums Account you can have several risk modules, each representing different products or lines or businesses.

Each risk module has three responsibilities: policy injection, pricing and policy resolution. The pricing responsibility, that includes not only pricing new policies but also validating and pricing replacements and cancellations, is delegated to an Underwriter contract that is plugged into the RiskModule.

Each policy sold and active is a risk or potential loss, a random variable that goes from 0 (no losses) to the maximum payout defined in the policy. The solvency capital to cover these risks comes from two sources:

• pure premiums: the part of the premium that's equal to the estimated mean of the risk random variable (expected losses), paid by the policyholder.
• scr: the rest of the solvency capital (unexpected losses), required to be able to cover the risks with a given confidence level, is locked from the eTokens.

Contracts

Access Control / Governance

The protocol uses the Access Managed Proxy design pattern. Under this design pattern, the access control logic of permissioned methods is not defined in the code with modifiers (like onlyOwner or onlyRole). Instead, the contracts are expected to be deployed behind anAccessManagedProxy that will delegate the access control configuration to an AccessManager contract. For gas usage reasons, we might have skipped methods that are defined at deployment time, that don't call the AccessManager contract and just pass through the call as a standard proxy. In js/ampConfig.js, there's the recommended setup for these skipped methods, but make sure to verify against the actual deployed contracts.

Check this presentation at DeFi Security Summit 2025 for a complete explanation of this design pattern.

Regarding the specific access control configuration, check our docs for the actual manifest of access control rules.

Upgradability

Ensuro contracts are upgradeable, meaning the code can be changed after deployment. We implement this following the UUPS pattern where the contract used is a proxy that can be redirected to a different implementation.

The main reason to do this is to be able to fix errors and make minor changes in the protocol.

We will never deploy upgrades to live contracts without prior notice to the users, especially if it implies a change in the behavior. The permission for executing upgrades will always be subject to timelocks and delegated either to Ensuro's board and/or to a Security Council.

Have in mind that the new versions of the contracts might or might not be covered by the same audit processes as the initial ones. See our audit applicability matrix to check which audit applies to the currently deployed contracts.

Development

For coding the smart contracts, the approach we took was prototyping initially in Python (see folder prototype), and later we coded in Solidity. The tests run the same test case on both the Python prototype code and the Solidity code. To adapt the Solidity code that is called using ethproto, we have some glue code implemented in tests/wrappers.py.

Not all the core logic is implemented in the Python prototype, but most of it.

Without Docker

You can also run the development environment without using Docker, just Python (>=3.12) and Node v22 are required as pre-requisites.

Initial setup:

# Setup a virtualenv
python3 -m venv venv
source venv/bin/activate
# Install python dependencies
pip install -r requirements.txt
pip install -r requirements-dev.txt
# Install javascript dependencies
nvm use  # To change to node v22
npm install

Then, you can run the tests with:

# Start a local node
npx hardhat node

# Run python tests
pytest

# Run js tests
npx hardhat test

Using docker

The development environment is prepared for running inside a Docker container defined in the Dockerfile. Also, you can launch the Docker environment using invoke tasks, but before you need to run pip install inv-py-docker-k8s-tasks to install a package with common tasks for coding inside Docker. Then, with inv start-dev, you should be able to launch the Docker environment. Then you can run specific tasks:

• inv test: runs the test suite
• inv shell: opens a shell inside the Docker container

Also, the Docker container is prepared to run hardhat. This will be used probably for deployment scripts and perhaps some additional tests.

Code Audits

• Audit by Quantstamp - 2022-09-26 through 2022-10-20: AuditReport
• Audit by SlowMist - 2021-09-29: AuditReport
• Process Quality Review by DefiSafety - 2024-03-18: Process Quality Review
• Audit by Quantstamp - 2025-11-24 through 2025-12-03: AuditReport

Change log

We don't have a change log file, but the best source for the log of changes is the Releases Page. Besides that, check Changes v3 for an outline of the main changes done from version 2.x to version 3.0.

Contributing

Thank you for your interest in Ensuro! Head over to our Contributing Guidelines for instructions on how to sign our Contributors Agreement and get started with Ensuro!

Please note we have a Code of Conduct, please follow it in all your interactions with the project.

Authors

• Guillermo M. Narvaja

License

The repository and all contributions are licensed under APACHE 2.0. Please review our LICENSE file.