Beyond Tokens: The Era of Onchain Points
Points are sweeping across the crypto ecosystem, following their catalyzing role in the launch of Blast ($800m TVL on launch), increased Rainbow usage, and many DeFi projects in the Solana ecosystem. This raises the question: are “points” merely a gimmick to spur speculative adoption for early users, or could they present a sustainable new primitive for consumer crypto apps? Drawing from experience in helping develop various points systems over the past year, and now launching a platform dedi...
Bountycaster
Bountycaster is a new service for creating and completing paid bounties online, leveraging cryptocurrency, decentralized social networks, and AI. Bountycaster leverages the Farcaster network for identity and content. Users sign in with their Farcaster account and post bounty descriptions to the Farcaster network. On the backend, Bountycaster monitors posts to Farcaster, and uses AI to parse the bounty content. The service elegantly interweaves four powerful new technologies in a simple way:Bo...
Measuring the Success of Mirror Crowdfunding
Four months ago, our team launched Mirror Crowdfunding. We have had a number of successful campaigns - attracting a median participation of 54 backers per project, and raising a total of over 134 ETH ($351,400 at time of writing) for books, essays, software, newsletters, and public goods. This essay is a critical exploration of the success of Mirror Crowdfunding so far. I also argue that a rare combination social exchange underlies these campaigns - generalized and productive.What is a Mirror...
CTO of Mirror
Beyond Tokens: The Era of Onchain Points
Points are sweeping across the crypto ecosystem, following their catalyzing role in the launch of Blast ($800m TVL on launch), increased Rainbow usage, and many DeFi projects in the Solana ecosystem. This raises the question: are “points” merely a gimmick to spur speculative adoption for early users, or could they present a sustainable new primitive for consumer crypto apps? Drawing from experience in helping develop various points systems over the past year, and now launching a platform dedi...
Bountycaster
Bountycaster is a new service for creating and completing paid bounties online, leveraging cryptocurrency, decentralized social networks, and AI. Bountycaster leverages the Farcaster network for identity and content. Users sign in with their Farcaster account and post bounty descriptions to the Farcaster network. On the backend, Bountycaster monitors posts to Farcaster, and uses AI to parse the bounty content. The service elegantly interweaves four powerful new technologies in a simple way:Bo...
Measuring the Success of Mirror Crowdfunding
Four months ago, our team launched Mirror Crowdfunding. We have had a number of successful campaigns - attracting a median participation of 54 backers per project, and raising a total of over 134 ETH ($351,400 at time of writing) for books, essays, software, newsletters, and public goods. This essay is a critical exploration of the success of Mirror Crowdfunding so far. I also argue that a rare combination social exchange underlies these campaigns - generalized and productive.What is a Mirror...
CTO of Mirror

Subscribe to Graeme

Subscribe to Graeme
Share Dialog
Share Dialog
>300 subscribers
>300 subscribers
My head's clearly been stuck in the Publication contract for the last few days, since I've been implementing that.
There's a lot that I like about the Publication contract paradigm, but it's not derisked yet as a feature. Currently, the cost to register on Mirror with the Publication contract would be around $100 on Mainnet, which is a lot of money relative to some other options.

I can decrease the cost of this deployment by using a pattern whereby only the storage is deployed per user, and everything else delegates back to a single "implementation" contract. I will almost certainly do this! Uniswap does not do this for new token pairs, which makes it expensive to add new tokens.
But the feature isn't derisked yet; we need to start playing with it and seeing how it feels to use Mirror with a real Ethereum protocol behind it, rather than a database for storage. This will feel weird; some things won't be as fast, and then the suggestion by others could be to speed it up by caching on the backend. We can do that, but first it makes sense to lean into the web3 aspects of this feature and get people excited about all of the net-new economic actions that it enables.
In other news, we've been working on NFT integrations for the frontend. John Palmer, a designer in our network, wants to write a blog post and create an NFT from it. He also wants to try crowdsourcing the funding of this article/NFT. This is interesting. I proposed that we do it this way:
Deploy a contract that can hold an ERC721 (ERC721-receiver)
Also make it an ERC20 token that can mint
Add a method called fund() that pulls a given amount of USDC from a user's account, and mints an equal number of tokens for that user.
Allow the contract to bid for and accept ownership of the NFT
Allow the contract to sell the NFT
Allow users to burn their tokens and withdraw a proportional amount of USDC in the contract
This would mean that users are contributing USDC into the contract in exchange for fractional ownership of the NFT. Once the NFT has been sold, the total USDC will be greater than the number of outstanding tokens minted by the contract, and those who contributed will be able to withdraw their profits.
John and Denis seem quite excited about this idea. I think it's interesting in so far as it's a prototype for something that the Publication contract might be able to do in the future -- i.e. crowdfund something like an article, or an education course. If it weren't for that, I wouldn't want to consider this for a once-off event, since it'll likely take a considerable amount of effort to make sure that there isn't a security vulnerability in the contract (ah, DAO-hack anyone?)
My head's clearly been stuck in the Publication contract for the last few days, since I've been implementing that.
There's a lot that I like about the Publication contract paradigm, but it's not derisked yet as a feature. Currently, the cost to register on Mirror with the Publication contract would be around $100 on Mainnet, which is a lot of money relative to some other options.

I can decrease the cost of this deployment by using a pattern whereby only the storage is deployed per user, and everything else delegates back to a single "implementation" contract. I will almost certainly do this! Uniswap does not do this for new token pairs, which makes it expensive to add new tokens.
But the feature isn't derisked yet; we need to start playing with it and seeing how it feels to use Mirror with a real Ethereum protocol behind it, rather than a database for storage. This will feel weird; some things won't be as fast, and then the suggestion by others could be to speed it up by caching on the backend. We can do that, but first it makes sense to lean into the web3 aspects of this feature and get people excited about all of the net-new economic actions that it enables.
In other news, we've been working on NFT integrations for the frontend. John Palmer, a designer in our network, wants to write a blog post and create an NFT from it. He also wants to try crowdsourcing the funding of this article/NFT. This is interesting. I proposed that we do it this way:
Deploy a contract that can hold an ERC721 (ERC721-receiver)
Also make it an ERC20 token that can mint
Add a method called fund() that pulls a given amount of USDC from a user's account, and mints an equal number of tokens for that user.
Allow the contract to bid for and accept ownership of the NFT
Allow the contract to sell the NFT
Allow users to burn their tokens and withdraw a proportional amount of USDC in the contract
This would mean that users are contributing USDC into the contract in exchange for fractional ownership of the NFT. Once the NFT has been sold, the total USDC will be greater than the number of outstanding tokens minted by the contract, and those who contributed will be able to withdraw their profits.
John and Denis seem quite excited about this idea. I think it's interesting in so far as it's a prototype for something that the Publication contract might be able to do in the future -- i.e. crowdfund something like an article, or an education course. If it weren't for that, I wouldn't want to consider this for a once-off event, since it'll likely take a considerable amount of effort to make sure that there isn't a security vulnerability in the contract (ah, DAO-hack anyone?)
No activity yet