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:
- First, Life is bound to an Ethereum account/wallet and watches over all contents associated with the account, tokens and contracts and otherwise
- 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.
- 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.