É. Urcades

Back to All Writing

July 14

On the walk to the office today, I was thinking about how it’s great that you can generally grasp what a material will be “good” or “useful” for. Certain materials take to shaping, forming, or impressing methods in a more natural manner than others.

You can build a home out of a bricks, wood, composite materials, metals, etc. and expect the house to stick around for a while. Generally speaking, a house built in this manner won’t make for a great jumping castle. Jumping castles don’t really serve well as protective domains, etc.


Two days ago, I was speaking to a few people in the office about an old idea for a smart contract called life.sol.

The basic model for this smart contract follows:

A perceived issue of many digitally-bound organizations is that they feign the capability of ‘lasting forever’.

Without something like a life to grant an organization the ‘gift’ of death, which provokes people into long-term/far-reaching action, care for others, etc., organizations are predisposed to pointless “power” accumulation, stagnation, and a fate worse than death.

Life.sol (or otherwise “smart contract”) aims to grant the gift of a lifespan (eventual death) to digital organizations or holders of digital inventories/accounts.

Life.sol is inspired from a moment in recent history where an organization (Learning Gardens) willingly succumbed to death and apparently bloomed a broader and more colorful variety of initiatives, organizations, and units after its passing.

Life.sol is a smart contract with three primary functions:

  1. First, Life is bound to an Ethereum account/wallet and watches over all contents associated with the account, tokens and contracts and otherwise
  2. Second, Life ingests a small set of non-identifying personal information such as age and geographic location and outputs a smart contract with a duration that maps to an average human lifespan. Upon Life being deployed to the EVM, the duration is turned into a counter. When the counter reaches its upper bound, Life burns all contents associated with the account it is bound to.
  3. Third, Life subdivides the previous function’s duration into fractions representing the number of years duration represents. Arbitrary functions can be set to execute at the end of each fractional segment.

I couldn’t tell you if this idea is actually useful, or good, but I think it’s interesting from a materiality perspective.

Consider the average unit of software:

How robust is this thing?

What makes a type stronger than another type?

What’s the structural integrity of the software I’m using?

What’s SHA2 made of?

Is my software’s longevity/hardness coupled to the organization that builds it?

Are arrays of u32 integers stone or dyneema?

How long can I expect a <div> to last?


While life.sol doesn’t answer these questions directly, it engenders a sort of materiality in the form of granting a time-bounding to an arbitrary unit of software (whatever’s inscribed against a number). While I might not ever know if a unit of software is like granite or moss, a unit of time can begin to grant materiality to an abstract thing, an idea, a concept, etc.

If I know something’s going to only be around for 3 minutes, I begin to understand it like I understand a daffodil in the wind.


Back to All Writing