🤞Token promises
With the increased interest of social tokens, I have found myself going back and reading this article over and over again trying to better grasp how crypto defines relationship based values such as trust, forgiveness, grace and redemption. Are social tokens bound to byzantine style dealings rooted in transactional relationships where all social interactions needed to be explicitly stated up-front?
In less esoteric terms, talking with creators with larger followings there is a pattern of hesitancy to launch tokens because of the downside risk. If “blockchains never forgot” and there is no room for forgiveness in crypto, experimentation becomes very calculated and expensive. Coupled with increasing gas prices, the stakes get higher to get it right on the first try. This leads everyone holding their breath in a wait and see posture hoping someone else figures it out.
There is an interesting second order effect I see emerging from this — secrecy and projects working in “stealth”. The range of intentions range from trying to maintain a mystique of having figured things out to talking at high level generalities to maintain “thot leadership”. Bucking this trend, this posts aims to explain tokenized “promises”.
The blockchain never forgets, so promises provide a low stakes space for future virtual commitments to be abandoned if things don’t work out. There is nothing to forgot if nothing ever happened. Promises use the same cryptographic techniques that powers blockchains — lets dive in to a simple construction.
Let’s assume there is a vault contract that is already deployed on-chain with a `createValult` method that takes in a counterfactually generated token address, a playbook contract address and a struct for the playbook parameters. The vault can also verify that there is no bytecode behind the counterfactual address by calling `extcodesize`. The playbook address can be confirmed by looking at a “playbook” TCR to confirm it has been registered and that the parameters are valid. This assumption allows funds to be locked up on-chain.
Let’s also assume a simple Layer2 payment channel construction but any arbitrary L2 construction can be used (we go in to the specifics here — TODO). The critical aspect of this assumption relies on the payment channel to act as IF the token contract WAS deployed. This “Layer2 first” deployment strategy not only allows issuance and distribution to happen off-chain but also provides increased scalability, usability without incurring transaction fees.
Now, the counterfactually token address can have rules only allowing for the contract to be successfully deployed if the rules referenced by the vault contract are met. The rules are the set of promises that need to be fulfilled in order for the token to exist.
The core of this approach also rearranges who pays for what when. Instead of charging the sender in a “push” transaction to initiate a transaction, fees are paid for by the “receiver” upon settlement in a pull interaction. This is a subtle but important distinction because it lowers the risk of initiating a transfer and transaction fees are only paid IF there is an incentive to settle.
In traditional online audience/community building, there is a tension between growth and monetization. This is exasperated in crypto because growth requires up-front monetization, an added friction during the critical bootstrap phase of a community. With promises, monetization can predictably happen only WHEN certain on-chain metrics are met.
