Re-assurance market re-make

Sam Onat Yilmaz
3 min readNov 23, 2021


How I would build a decentralized re-assurance market

This is my first public post about how I would build an app. At Bloccelerate we have a traditional question we ask ourselves weekly “What company would I start this week?” Because of this tradition, I had a psychological infrastructure that encouraged me to consider different value propositions and how we would go on to build applications. Instead of making such posts only internally, I will now look to mention one or two of these publicly.

I am guilty of not contributing to this weekly tradition due to my other exciting work tasks, from recruiting investment associates, to running due diligence and advising CEOs. Did I mention I make introductions to prospective companies to help them mature and I meet present and future investors? Yeah oh well, such is the output life of a venture fund with a unique boutique technique, and why I am getting paid the big bucks.

On to the thing:

The premise of the app relies on how Insurance and Reassurance is effectively shifting risk, sharing risk. We start with the target audience of the market: Once an insurance company has the policy it may like to further buy re-assurance on it. This means, in a somewhat oversimplified manner, the insurance company is willing to pay a portion of the premium they receive in return to some other company pledging a pool of capital to cover any downstream payouts the insurance company may be forced to make.

Knowing that this is how insurance and re-assurance (insuring an insurance company so to speak) works, our app would need to:

  1. Create insurance policies with specific, measurable and trustless parameters that are easy to validate.
  2. Allow liquidity providers and value pledgers to select particular risks they are willing to underwrite or a particular insured. This should be structured as a marketplace where a serious buyer can see first glance relevant information and search insurance policies that seek re-assurance
  3. Risk underwriters should be able to gather information about the insured, about possible events that would trigger the payment, and historical data about these, amount of interest/premium they would collect over staked value, and how this may be subject to change with different severity events.
  4. There should be different tiers of risk and reward in each pool. The first money into a pool that remains until the end of the policy period for at least say, X months after commitment, for example,, should be in a position to earn more than capital not committed for as long.
  5. Upon creation of the insurance policy, the capital backing it or the capital pledged into it should be easy to add or remove from the pool (except for the initial money that was the underwriter).

I have not talked about which chain to use, what oracle to use, who should be first insured or insurer, how the premium rates would be calculated at the outset of a pool, or the tokenomics of such an app, though we have thought about them. If you ever find you are building an app of this kind, I would love to sync up, geek out, and BUIDL.



Sam Onat Yilmaz

I built my first Web3 company in 2014. As a GP @ Bloccelerate, now I back the most audacious Web3 builders solving the existential problems in the space.