OnchainMagic is

• mobile first

• media focused (music, videos, graphics)

• expanding ethereum (zora / base / OP / etc)

• ENS supported

mobile first

In 2024, an estimated 56% of global internet traffic will originate from mobile devices, while desktops will contribute 39%. The remaining 5% will be attributed to emerging technologies like smart TVs and IoT devices. Why is onchain infrastructure designed first for desktop when market share is largest on mobile?

Most interfaces for onchain infrastructure are designed for desktop. Mobile experiences are painful. Switching to an external wallet app is clunky. While Zora’s desktop experience has a sleek, Apple-like feeling. I feel embarrassed collecting art on zora’s website on mobile. I see red X telling me my wallet is disconnected after I mint. I jump from zora to metamask back to zora. From there, zora sends me a signature to verify, pushing me back to metamask. Wait for the signature. Back to zora. What was I coming here to do again? I feel unloved, frustrated & rejected.

How can we build more fun interfaces on mobile-first publishing onchain? Instagram & Tiktok do an amazing job creating a clean and simple publishing interface offchain. They are a design baseline I’ve been following up to now. The design may be skumorphic to old traditions, but, as a 1-3 person team, I’m doing the best with what I’ve got. Are there better, mobile-first, models we should be examining for onchain media publishing?

media focused

In Buenos Aires, Argentina, artists have been struggling to get compensated on platforms to live a sustainable living. This problem is true globally, but I’ve been seeing the problem first-hand. Spotify pays musicians pennies on the $0.003 – $0.005 per stream on average. For musicians in cities such as Buenos Aires, Argentina, those payments are even smaller. How can we build onchain infrstructure in which there is more equitable payments for creators vs the platforms they use?

Protocol rewards on public hyperstructures are proving to be a successful model for small communities growing online & onchain. Zora pays musicians 0.000333ETH ($0.66) per collect on Free Mints from their total mint fee of 0.000777ETH. 43% of fees go directly & instantly to creators globally. What does this actually look like in practice?

I went to a concert last night where musicians in Buenos Aires earned more $$$ from 2 collectors listening at a live event than they’ve received in 2+ years publishing their music on Spotify. These musicians will come back and put more music on Zora. They will want an easy way to discover & collect music. Possibly in an interface that feels familiar, like Instagram Reels of the TikTok feed. How can we help make it as simple as possible for creators and collectors to participate in the growing marketplace for onchain media?

expanding ethereum

Ethereum mainnet is expensive. Current price to publish a contract on Ethereum mainnet is $79.75 as I write this. For musicians in Buenos Aires, that’s over half a month’s rent payment. The current options, on Ethereum, are to:

1. pay half my rent

2. publish media onchain

Any responsible parent will skip this onchain nonsense & focus on rent. The barrier to entry is too high. How can we expand ethereum to make it more accessible?

OP stack is inexpensive. Current price to publish a contract on Base or Zora mainnet is $1.11. Or, roughly cafe con leche con una medialuna. The decision becomes much easier on OP stack.

1. buy a cup of coffee

2. try out this new tool

OP stack expands Ethereum as a rollup on top of it. The costs to experiment are low & accessible to creators globally. Composability is key here. With Zora paying creators 0.000333ETH, creators only need to find 2 collectors of my free collectible for publishing costs to break even. Most musicians in Buenos Aires could survive on 777 collectors buying 1, free, piece of media each month. How can we make it as easy for musicians to get discovered onchain?

ENS supported

Online naming services are a public good. Creators know the value of being easily discovered. Being in the top 10 results on Google, or on social media, can drive major success for a creative’s work. ENS is public infrastructure trusted by musicians to interact onchain. With ENS being deployed on Ethereum mainnet, applications face a challenge when identifying creators on other chains.

This is a solved application-level challenge. Good apps already know to reference mainnet, even if the address is being used on another network. Most apps simply don’t know, or have the resources, to support ENS identity on their applications. How can we make it easier for developer-level tooling to natively support onchain identity in their applications?

closing.

Onchain Magic is currently in the early release stages in Argentina. Our goal is to produce the most fun place to create and collect on Zora when you’re on your phone. From live events to studio sessions, we’re helping musicians get paid onchain.

1. pay-2-play

   1. early access

2. free-2-play

   1. release the song on streaming platforms

3. powerups

   1. onchain => in game

Pay-2-Play

Pay to play is the traditional model of video games. Pay a one-time fee to unlock lifetime access to the game. Heno. wanted to take this model a step further by putting the unlock onchain.

Originally, we released the game behind a paywall for early access. For $7 (0.003ETH) you could buy early access to Heno.’s video game on Zora. To token-gate a video game we needed 2 things

1. a function to check if the player has unlocked the game.

2. a function to pay-to-play to unlock the game.

To check if a player has unlocked the game I wrote a fetchBalance function like this

 const fetchBalance = useCallback(async () => {
    if (!address) return
    setLoading(true)
    const balanceOf = await dropContract.balanceOf(address)
    setBalance(balanceOf.toNumber())
    setLoading(false)
  }, [dropContract, address])

This code first enforces the player has connected their wallet. Then, we lookup how many tickets the player owns with balanceOf. If the balanceOf > 0 the player has already paid to unlock the game. If the balance is 0, they haven’t unlocked the game and should be prompted to buy the early access ticket.

To allow a player to pay-to-play I wrote a mint function like this

const mint = async () => {
    setMinting(true)
    await mintWithRewards()
    await fetchBalance()
    setMinting(false)
  }

This code calls the mintWithRewards function on Zora’s Protocol. Once the player has purchased their ticket, we fetchBalance again, which updates the balance (see above for code) and unlocks the game.

The results looked like this:

Free-2-Play

Once Heno. released the song, Relief, on streaming platforms, it was time to make the game more accessible to his fans globally. That meant removing the paywall, open-sourcing the code & turning the early access tickets into power-ups.

Removing the paywall was easy. Add a big START GAME button to start the arcade game. No credit card required.

Open-sourcing the game was also pretty easy. We use Github to store the website code. I simply went to the settings in Github and changed visibility to public. Now, anyone can use the model Heno. built by downloading the open-source code here.

Powerups

Heno. wanted to reward the players who supported his vision early on. The idea he came up with was to give anyone who owns the early access ticket powerups in the video game. With 3 different tickets, he assigned power-ups to each

• heart - 10 extra lives

• camera - easier enemies

• money - $100 extra in game

These rewards are stackable. If you own a camera & a money ticket you’ll get easier enemies AND extra money in game. If you own 3 hearts, you’ll start the game with 30 extra lives. There’s other combos players can unlock by combining these tickets. I won’t give away all the combos here. Buy tickets here to unlock powerups in game.

I worked closely with DaCircus to build a way to bring items from onchain => in game. It was actually pretty challenging to figure out a way to send messages from the NextJS website I was building with the Godot video game DaCircus had built. After numerous pair-programming session together and lots of questions to ChatGPT we found a solution:

const channel = new MessageChannel()

const callGodotFunction = () => {
    const iframe = document.querySelector("#godotGame") as HTMLIFrameElement
    if (!iframe) {
      return
    }
    const spotifyMoney = deviceId ? 5 : 0
    iframe.contentWindow.postMessage(
      [heartCount, cameraCount, moneyCount, spotifyMoney, address || ""],
      "*",
      [channel.port2],
    )
}

The magic lives in postMessage function. In the NextJS website we lookup how many, and which type, of tickets the player has. We also give an option for players to connect their Spotify account to stream Relief on Spotify, which pays Heno. per stream. Once a player has connected their wallet and / or Spotify account, they click START GAME which calls the callGodotFunction (above) to start the game with powerups.

I want to take a second to highlight the importance DaCircus played in this. He built the entire game on his own. He was the designer for all assets in the game too. He was the main developer & designer on this project. I simply helped publish his game to an easy-to-use website & plugged in the web3 functionality.

Thanks for taking the time to read! If you wanna keep going, here’s some links

1. Play Relief by Heno. - play.mynameisheno.com

2. Collect the Tickets to earn Super Powers - zora.co/heno

3. Download the Code to build your own game - github/sweetmantech/Heno-Relief-Game

4. Stream Relief on Spotify - open.spotify.com

nft://8453/0xf4E5eb4C5A998E4F1f7ca2A71B6852F5C05A28c5/?showBuying=true&showMeta=true&size=small

How can we drive down the cost of the everyday user? Both the amount of money they spend, the time and the energy they spend to put moments and memories onchain. With our original use of Zora ERC721 drops on OP Mainnet cost about 0.001 ETH or about $1.50 with creators earning, 0.000444 ETH on free mints. They need to mint approximately three additions to break even.

While this is way better than Ethereum Mainnet, where the costs are like $10 - 20 to deploy a contract. We still have a lot further to go. And so, what did we get by switching to the ERC1155?

The cost to deploy a new ERC1155 is 0.0005 ETH. It's already about 50% less than deploying an ERC721 on OP mainnet. If you want to add a new story to an existing collection, it's 0.0003 ETH, which is about 25% of the cost to deploy a ERC721 on OP Mainnet. AKA a reduction of 75% from the ERC721A. And it's significantly less than the cost to deploy an equivalent ERC721 on Ethereum Mainnet.

nft://10/0xcF1C8536aa80921A472830Bd434635E845E463dd/?showBuying=true&showMeta=true

And so, at this point, if you sell one edition, you earn 0.00444 ETH

This allows our costs to be low enough for local communities to subsidize gas fees because at this point for a creator they're earning right out the gate 0.0001 ETH in revenue for a story that they would not have earned for on Instagram.

So how can we make it really easy to refill the wallet for the first time? We also rolled out auto-refill for creators. So if you're about to create a post or a story and you don't have enough energy or ETH or fuel or gas, we automatically refill your wallet.

This eliminated, one of the most challenging parts which was funding the social wallet. All of this is enabling our creators who have never used Zora before to upload content directly from live music events. What are the dashboards we need to build to measure the few specific outcomes that we're optimizing for? And if you're going to post on Instagram, why not post it as a story onchain as well?

• ERC721H is an implementation of IERC721 that introduces "Hooks", bringing additional flexibility and control to creators and collections.

• The Cre8ors contract will be a hybrid ERC721ACH with ownership of an ERC6551 smart wallet.

• We collaborated with external security consultants to verify the solidity of our approach.

• We advocate for the community to embrace this implementation to maximize creator ownership of their collections onchain IP.

CONTEXT

Building on the innovations of ERC721A (2022), which introduced significant gas savings for minting multiple NFTs in a single transaction. And then ERC721C (2023), which introduced enforceable on-chain programmable royalties, we are excited to present our latest advancement in the Non-Fungible Token (NFT) realm, ERC721H (hooks). Our vision is to push creativity to the edges and empower projects to have the option to create & expand their imagination onchain. ERC721H leverages the power of "Hooks" to bring additional flexibility and control to creators. The core objective of this standard is to maximize the creative ownership projects have of their collections. It’s fully composable with ERC721A & ERC721C in ERC721H.

PROBLEM

The primary shortcomings of the original ERC721 standard has been a lack of consistent and flexible interaction mechanisms between NFTs and other contracts, leading to constrained functionality and innovation potential.  At Cre8ors, we’re working on pushing creativity to the edges while protecting creators’ ability to manage how their IP is used, exchanged and represented onchain.

Creators have been limited to a set of options defined for cryptokitties’ original ERC721. As creativity expands, our technological interfaces need to adapt to expand the onchain canvas to fit our imaginations.

SOLUTION

The ERC721H standard seeks to address these limitations by introducing the concept of hooks that can be attached to any base ERC721 event. The hooks are programmed to execute functions or trigger events in linked contracts, thereby opening a new world of complex interactions and integrations.

USE CASES

ERC721H provides an array of potentials to make NFTs more interactive and versatile, hence expanding their functionality beyond mere digital assets. NFTs could potentially interact with DeFi contracts, social tokens, governance systems, subscription services, and even IoT devices. From conditional royalties to access control, to game mechanics, the possibilities are endless. Some examples of how we plan to leverage hooks are:

• Subscriptions

• Staking

• IP Distribution & Management

HOW IT STARTED

Zora decoupled the metadata from the ERC721. With IMetadataRenderer & the setMetadataRenderer method, creators can update the base tokenURI module in a standard ERC721 contract with anything they can imagine.

https://twitter.com/ZORAEngineering/status/1631058831164751872?s=20

This was the first step towards modularization of ERC721. Decoupling all aspects of the contract. Keeping the base contract simple. Push creativity to the edges. Give creators the keys to choose their level of customization. Give developers the infrastructure to experiment with new ideas with safe fallbacks following the shared, IMetadataRenderer, interface.

HOW ITS GOING

The ERC721H standard operates similarly to the original ERC721, but it introduces the possibility of adding custom behavior to all core ERC721 functions. A developer could inherit the ERC721H contract just like they would if they were using OpenZeppelin, customize it to their needs and deploy their ERC721H collection. The addition of hooks is performed using the virtual setMethodHook function, which can be called either in the constructor or after deployment. The hooks are easily adjustable to match the evolving requirements of the NFT collection over time.

With ERC721H, all base ERC721 methods now come with the following methods:

• beforeMethodHook - Hook firing before an ERC721 event.

• afterMethodHook - Hook firing after an ERC721 event.

• useMethodOverrideHook - determines whether to override base ERC721 event.

• methodOverrideHook - Hook to override an ERC721 event.

• methodHook - stores the Hook contract interface.

• setMethodHook - ability for creators to update hooks.

A brief code example showing the implementation of the ERC721H standard is as follows:

import {ERC721H} from "../../contracts/erc721h/ERC721H.sol"; 

contract ERC721HCollection is ERC721H { 

  constructor() ERC721H("Name of My Collection", "SYMBOL") {
    setBalanceOfHook(myBalanceOfHookInterface); 
    setApproveHook(myApproveHookInterface);    
    setSafeTransferFromHook(mySafeTransferFromHookAddress); 
  } 
}

The hooks are custom smart contracts that implement a specific interface IHook defined by the ERC721H standard. The hook functions will be executed every time an NFT is minted, transferred, or burned, offering unlimited possibilities to add custom logic or trigger other contracts.

DECENTRALIZATION

Inherent to ERC721H's design, the programmable hooks provide flexibility in shaping the degree of centralization or decentralization as needed. By linking a hook's activation to specific wallets - be it an individual, corporate, multisig, or an entire DAO of smart wallets - creators can define the range and extent of decentralization. This modular approach ensures that the control parameters are adaptable to the specific contract's governance structure and progression, thereby promoting a balance between autonomy and collective participation.

Getting Started with ERC721H

We believe that the ERC721H standard has the potential to significantly contribute to the innovation and growth of the NFT ecosystem by fostering creative management of IP. We encourage developers and creators to explore our comprehensive guides, examples, and resources available on our GitHub repository.

INNOVATE OR DIE

Times are changing. The bull run is over and with it went the old standards. What worked before should not be interpreted as what will work today. Our core mission at Cre8ors is to unlock the creative potential and financial freedom for our members and ERC721H is a small example of how we plan on delivering innovative technology to our community that constantly moves the web3 space forward.

Disclaimer*: The details and mechanisms provided in this article are preliminary and subject to changes and improvements based on ongoing development and community feedback. Kindly refer to our GitHub repository for the latest and most accurate information.*

The Cre8ors mint is on August 8@8AM ET. See you there.

ERC6551 en Música

ERC-6551 turns every NFT into a smart wallet that can own tokens and interact with dApps across the Ethereum ecosystem. - tokenbound.org

Con ERC6551, toda la música en cadena existente y nueva tiene su propia billetera. Aquí hay algunos ejemplos simples de cómo Warrobit ya puede usar ERC6551 hoy a los que no se podía acceder antes:

playlist

Enviar una canción a su cuenta de Playlist para agregarla a la Playlist. Elimine la canción de su cuenta de Playlist para que los fanáticos no la escuchen más. Cada semana, puede ingresar y administrar su Playlist agregando canciones, eliminando canciones y cambiando el orden. Imagina traer Playlists a través de OohLaLa, SpinAmp y Future Tape.

álbum

Para el último álbum de Warrobit, WARRO FASHION STAR, puede colocar cada una de las 14 pistas en Sound, Zora, Lens, etc. Luego, pueden enviar una edición de cada uno a la cuenta del álbum. El álbum, en OpenSea, muestra la última versión del álbum, que el músico puede actualizar con el tiempo. Empresas que deberían adoptar: Zora, Lens & Sound.

manojos

Warrobit puede enviar 11 ediciones de una canción, 7 ediciones de otra y 3 de una tercera a una cuenta Bundle. Cuando Warrobit vende ese paquete en Zora u OpenSea, el comprador recibe automáticamente todas las canciones dentro del paquete. El nuevo propietario puede quedarse con algunas o todas las canciones dentro del paquete. Imaginemos que el comprador envía 8 de las canciones del paquete a su cuenta personal. El propietario puede entonces revender el paquete, menos las 8 canciones que ha transferido. Empresas que deberían adoptar: OpenSea, Rarible y Zora.

Álbumes en cadena v0.0.2

OnchainAlbum.xyz es una herramienta para escuchar música de sus CD / Playlists / Álbumes / etc. construido en ERC6551. Escuche un iPod en cadena. O una mezcla. O un disco. O una Playlist. Todavía hay un 99% de ideas interesantes que aún no se han desbloqueado una vez que potenciamos la música con la misma cuenta que usamos los humanos. Esta es una nueva tecnología. Usted puede ayudar a escribir la narrativa. ¿Qué memes quieres usar para compartir las ideas de ERC6551 con los músicos?

Puede visitar nuestro progreso más reciente onchainalbum.xyz o sintonizar el grupo de trabajo ERC6551 para recibir actualizaciones de llamadas de estado semanales. Esta tecnología es de uso gratuito en acceso público.

creditos

diseño de alex paul

música de Ed, Yoshiro, Sol, Bela y David

ERC6551 in Music

ERC-6551 turns every NFT into a smart wallet that can own tokens and interact with dApps across the Ethereum ecosystem. - tokenbound.org

With ERC6551, all existing, and new, onchain music has it’s own wallet. Here’s some simple examples of how Warrobit can already use ERC6551 today that were not accessible beforehand:

playlist

Send a song into your Playlist account to add it to the playlist. Remove the song from your Playlist account so fans won’t hear the song any more. Each week, you can go in & manage your playlist by adding songs, removing song & changing the order. Imagine bringing playlists across OohLaLa, SpinAmp & Future Tape.

album

For Warrobit’s latest album WARRO FASHION STAR he can drop each of the 14 tracks on Sound, Zora, Lens, etc. Then, they can send one edition from each into the Album’s account. The album, in OpenSea, displays the latest version of the album, which the musician can update over time. Companies who should adopt: Zora, Lens & Sound.

bundles

Warrobit can send 11 editions from one song, 7 editions from another, and 3 from a third into a Bundle account. When Warrobit sells that bundle on Zora or OpenSea, the buyer automatically receives all the songs inside the bundle. The new owner can either keep some, or all, of the songs inside the bundle. Let’s imagine the buyer sends 8 of the songs out of the bundle to their personal account. The owner may then resell the bundle, minus the 8 songs they’ve transferred out of it. Companies who should adopt: OpenSea, Rarible & Zora.

Onchain Albums v0.0.2

OnchainAlbum.xyz is a tool to listen to music from your CDs / Playlists / Albums / etc. built on ERC6551. Listen to an onchain iPod. Or a mix. Or a CD. Or a playlist. There’s still 99% of exciting ideas that have yet to be unlocked once we empower music with the same account’s we humans use. This is a new technology. You can help write the narrative. What memes do you want to use in order to share the ideas of ERC6551 with musicians?

You can visit our latest progress at on chainalbum.xyz or tune in to the ERC6551 working group for weekly status call updates. This technology is free to use in publicly accessible.

credits

design by Alex Paul

music by Ed, Yoshiro, Sol, Bela & David

Nuestra hipótesis: La música es social.

Hoy, nos complace compartir con ustedes LensMaticWrapper de Riff, una solución que simplifica el uso de Web3 social para músicos y coleccionistas en el Protocolo Lens.

Esto ya está disponible en Riff.

Puedes probarlo hoy comprando música (con precios en WMATIC) y, cuando no tengas WMATIC en tu billetera, automáticamente cambiaremos esa moneda a MATIC por ti permitiendote coleccionar la canción en un solo paso.

En esta publicación, exploraremos los desafíos que enfrentan los usuarios, soluciones anteriores, nuestra hipótesis, la implementación del contrato LensMaticWrapper de Riff, los desafíos que enfrentamos y el resultado final.

WMATIC

WMATIC es un aspecto confuso de Web3 social para músicos, lo que crea fricción y puede disuadir a posibles usuarios.

La complejidad de entender y usar tokens WMATIC a menudo conduce a una experiencia menos que ideal para artistas y coleccionistas por igual.

Uniswap

Uniswap es un intercambio descentralizado que permite a los coleccionistas intercambiar tokens.

Anteriormente, los coleccionistas tenían que abandonar la plataforma actual y visitar Uniswap para cambiar sus tokens, lo que hacía que el proceso fuera engorroso y menos fácil de usar.

Un contrato Wrapper

Supusimos que un contrato wrapper podría proporcionar una experiencia más fluida al permitir a los usuarios intercambiar automáticamente y recopilar en una sola transacción sin salir de la plataforma.

Esto funcionaría con todas las publicaciones existentes en Lens y minimizaría la fricción, haciendo que Web3 social sea más accesible para músicos y coleccionistas.

El contrato LensMaticWrapper

El contrato LensMaticWrapper que hemos creado en Riff simplifica el proceso de intercambio y recolección de tokens WMATIC.

Al integrar este contrato en la plataforma, los usuarios pueden intercambiar fácilmente sus tokens y recopilar en una sola transacción simple.

Desafíos - TypedData en Lens

Durante el proceso de implementación, nos encontramos con varios desafíos.

El Protocolo Lens verifica el saldo del usuario y muestra un error si el saldo es insuficiente.

Para superar este obstáculo, tuvimos que construir nuestro propio TypedData para firmas, lo cual fue una tarea compleja.

El resultado

Con el contrato LensMaticWrapper en su lugar, los coleccionistas que no tienen suficiente WMATIC ahora pueden intercambiar automáticamente y recopilar en una sola transacción fácil.

Este proceso simplificado no solo lo hace más conveniente para los coleccionistas, sino que también mejora la experiencia del usuario en general en la plataforma.

Conclusión

LensMaticWrapper es un testimonio de nuestro compromiso en Riff de simplificar la experiencia de Web3 social para músicos y coleccionistas.

Al abordar los desafíos asociados con WMATIC y soluciones anteriores como Uniswap, hemos creado una plataforma más fácil de usar que fomenta una adopción más amplia.

A medida que continuamos explorando e innovando en este espacio, esperamos realizar avances aún más emocionantes que apoyen a la próxima generación de músicos.

¡Hagamos ruido!

Our hypothesis: Music is Social.

Today, we’re excited to share with you LensMaticWrapper by Riff - a solution that simplifies the use of Web3 social for musicians and collectors on Lens Protocol.

This is already live on Riff.

You can try it today by collecting music (priced in WMATIC) when you don’t have any WMATIC in your wallet.

We’ll automatically wrap it for you and let you collect the song in one, single, step.

In this post, we'll explore the challenges faced by users, previous solutions, our hypothesis, the implementation of the LensMaticWrapper contract by Riff, the challenges we faced, and the final result.

WMATIC

WMATIC is a confusing aspect of Web3 social for musicians, which creates friction and can deter potential users.

The complexity of understanding and using WMATIC tokens often leads to a less-than-ideal experience for artists and collectors alike.

Uniswap

Uniswap is a decentralized exchange that allows collectors to swap tokens.

Previously, collectors would have to leave the current platform and visit Uniswap to swap their tokens, making the process cumbersome and less user-friendly.

A Wrapper Contract

We hypothesized that a wrapper contract could provide a more seamless experience by enabling users to auto-swap and collect in a single transaction without leaving the platform.

This would work with all existing posts on Lens and minimize friction and make Web3 social more accessible to musicians and collectors.

The LensMaticWrapper Contract

The LensMaticWrapper contract we've created at Riff streamlines the process of swapping and collecting WMATIC tokens.

By integrating this contract into the platform, users can easily swap their tokens and collect in a single, simple transaction.

Challenges

TypedData on Lens During the implementation process, we encountered several challenges.

The Lens Protocol checks a user's balance and throws an error if the balance is insufficient.

To overcome this hurdle, we had to build our own typedData for signatures, which was a complex task.

The Result

With the LensMaticWrapper contract in place, collectors who don't have enough WMATIC can now auto-swap and collect in a single, easy, transaction.

This streamlined process not only makes it more convenient for collectors but also enhances the overall user experience on the platform.

Conclusion

LensMaticWrapper is a testament to our commitment at Riff to simplifying the Web3 social experience for musicians and collectors.

By addressing the challenges associated with WMATIC and previous solutions like Uniswap, we've created a more user-friendly platform that encourages wider adoption.

As we continue to explore and innovate in this space, we look forward to making even more exciting advancements that support the next generation of music.

Let's make some noise!

Paso uno: Calcular las ganancias del EP

Primero, tuve que determinar cuánto gané con el EP "Not yet, no?" revisando la transacción de distribución. Cada uno de los involucrados en el proyecto ganó 22.4 MATIC (aproximadamente $23). Puedes ver la transacción de distribución del EP aquí.

Paso dos: Transferir fondos al UBI Split

A continuación, envié mis ganancias (22.4 MATIC) a mi UBI Split utilizando la hyperestructura 0xSplits, que se distribuiría a mis más de 500 beneficiarios en todo el mundo. Aquí está la transacción para la transferencia de fondos.

Paso tres: Encontrar nuevos coleccionistas del EP

Para encontrar nuevos coleccionistas de nuestro EP "Not yet, no?", utilicé Alchemy Composer para cambiar la blockchain al Polygon Mainnet y modifiqué la consulta para obtener getOwnersForCollection. Después de pegar mi dirección de contrato y hacer clic en "Send Request", descubrí que teníamos 7 coleccionistas en nuestra EP.

Paso cuatro: Airdrop de tokens coleccionables

Con una lista de nuestros nuevos coleccionistas, hice un airdrop de mi token coleccionable a cada uno de ellos. Antes del airdrop, tenía 502 coleccionistas únicos de mi NFT "Sweet's Collector". Después del airdrop, el número aumentó a 508 coleccionistas únicos, incluidos 6 coleccionistas completamente nuevos que nunca antes habían coleccionado de mí. Luego tuve la oportunidad de darles la bienvenida a mi comunidad y aprender más sobre ellos. El hash de la transacción de airdrop se puede encontrar aquí.

Paso cinco: Generar una nueva lista de beneficiarios UBI

Utilicé Alchemy Composer para obtener la lista de coleccionistas de mi NFT "Sweet's Collectors", tal como lo hice antes. Luego, utilicé Google Sheets para calcular el porcentaje del 100% que cada uno de los 508 beneficiarios debía recibir. En este caso, todos recibieron un porcentaje igual del 0.1968%, con una persona recibiendo un poco más, el 0.2224%. Exporté estos datos como un archivo CSV desde Google Sheets, con la columna A enumerando las direcciones y la columna B mostrando los porcentajes que recibiría cada beneficiario.

Paso seis: Actualizar el UBI Split

Con la nueva lista de beneficiarios UBI en mano, edité el UBI Split en la interfaz de usuario de 0xSplits y cargué el archivo CSV del paso anterior. Hice clic en el botón "Validate CSV" y, una vez que la nueva lista se veía bien, actualicé el split. El hash de la transacción para actualizar el split con la nueva lista de beneficiarios UBI y porcentajes se puede encontrar aquí.

Paso siete: Distribuir y retirar para todos

Esta es mi parte favorita. Después de seleccionar distribuir el saldo disponible de 22.4 MATIC, hice clic en el menú desplegable junto al botón "Distribuir" y seleccioné la opción "Distribuir y retirar para todos". Esto hizo que los fondos se “airdropped” en las 508 billeteras a nivel mundial. Los beneficiarios vieron instantáneamente los fondos aparecer en sus billeteras, sin necesidad de firmar ninguna transacción. El hash de la transacción para la distribución y retiro para todos se puede encontrar aquí.

Paso ocho: Comunicarse con la comunidad

Por último, informé a mi comunidad que habían recibido el pago. Los músicos podían usar ese dinero para implementar su primer música nft, mientras que los coleccionistas podían usarlo como costos de gas para interactuar con sus músicos favoritos en la blockchain. Quizás algunos beneficiarios necesitaban dinero en efectivo para retirar sus fondos y pagar sus facturas. El punto es que los fondos ahora eran suyos para usar como mejor les pareciera.

Conclusión:

Este experimento UBI demuestra el poder de la web3 y la tecnología blockchain para permitir a los artistas y músicos crear nuevas formas de valor económico y compartirlo directamente con sus fans y seguidores. Al abrir nuevas posibilidades de colaboración e interacción, estamos rompiendo barreras entre creadores y sus audiencias y fomentando un mundo más inclusivo y descentralizado.

Step One: Calculate earnings from the EP

First, I needed to determine how much I earned from the EP "Not yet, no?" by checking the distribution transaction. Each of us involved in the project earned 22.4 MATIC (approximately $23). You can view the EP distribution transaction here.

Step Two: Transfer funds to the UBI Split

Next, I sent my earnings (22.4 MATIC) to my UBI Split using the 0xSplits hyperstructure, which would be distributed to my 500+ recipients globally. Here's the transaction for the fund transfer.

Step Three: Find new EP collectors

To find new collectors for our EP "Not yet, no?", I used Alchemy Composer to switch the blockchain to the Polygon Mainnet and changed the query to getOwnersForCollection. After pasting my contract address and clicking "send request," I discovered that we had 7 collectors on our drop.

Step Four: Airdrop collector tokens

With a list of our new collectors, I airdropped my collector token to each of them. Before the airdrop, I had 502 unique collectors of my "Sweet's Collector" NFT. After the airdrop, the number increased to 508 unique collectors, including 6 brand new collectors who had never collected from me before. I then had the opportunity to welcome them to my community and learn more about them. The airdrop transaction hash can be found here.

Step Five: Generate a new UBI recipient list

I used Alchemy Composer to get the collector list from my "Sweet's Collectors" NFT, just as I did before. Then, I employed Google Sheets to calculate the percentage of 100% each of the 508 recipients should receive. In this case, everyone received an equal percentage of 0.1968%, with one person receiving slightly more at 0.2224%. I exported this data as a CSV from Google Sheets, with Column A listing the addresses and Column B showing the percentage splits each recipient would receive.

Step Six: Update the UBI Split

With the new UBI recipient list in hand, I edited the UBI split in 0xSplits UI and uploaded the CSV file from the previous step. I clicked the "Validate CSV" button, and once the new list looked good, I updated the split. The transaction hash for updating the split with the new list of UBI recipients and percentages can be found here.

Step Seven: Distribute and withdraw for all

This is my favorite part. After selecting to distribute the available balance of 22.4 MATIC, I clicked the dropdown beside the "Distribute" button and selected the "Distribute & withdraw for all" option. This made it so the funds were airdropped into all 508 wallets globally. Recipients instantly saw the funds appear in their wallets, with no need to sign any transactions. The transaction hash for the distribution and withdrawal for all can be found here.

Step Eight: Communicate with the community

Lastly, I let my community know they had received payment. Musicians could use that money to deploy their first music NFT, while collectors could use it as gas costs to interact with their favorite musicians onchain. Perhaps some recipients needed gas money to withdraw their funds and pay their bills. The point is, the funds were now theirs to use as they saw fit.

Conclusion:

This UBI experiment demonstrates the power of web3 and blockchain technology to enable artists and musicians to create new forms of economic value and share it directly with their fans and supporters. By opening up new possibilities for collaboration and interaction, we're breaking down barriers between creators and their audiences and fostering a more inclusive, decentralized world.

Introduction: In this tutorial, you will learn how to create your own NFT Music Player using the Decent protocol. You will discover how to upload your music, create the player, and mint your NFT to appear on OpenSea.

1. Access the Decent Player website: https://www.decentplayer.xyz/

2. Create your own player: Follow the instructions on the page to create your own custom music player.

3. Verify your player: Make sure your player is working properly.

4. Create your contract: Follow the instructions to create your own custom contract.

5. Execute the first transaction: Create your contract in order to mint your NFT.

6. Execute the second transaction: Mint your NFT using the "mint" function.

7. Check on OpenSea: Make sure your NFT appears on OpenSea.

Conclusion: With these simple steps, you can now create your own NFT Music Player with Decent. This is the perfect path for LATAM musicians who want to launch their next NFT music drop. Good luck and enjoy your creation!

Credits:

• EL EXILIO - New Festival Token

• REPRODUCTOR DE ALEGRIA

• CC0 Player - WarpSound

Introducción

En este tutorial, aprenderás a crear tu propio Reproductor de Música NFT con el protocolo Decent. Descubrirás cómo subir tu música, crear el reproductor y acuñar tu NFT para que aparezca en OpenSea.

1. Accede a la página web Decent Player: https://www.decentplayer.xyz/

2. Crea tu propio reproductor: Sigue las instrucciones en la página para crear tu propio reproductor de música personalizado.

3. Verifica tu reproductor: Verifica que tu reproductor funcione correctamente.

4. Crea tu contrato: Sigue las instrucciones para crear tu contrato personalizado.

5. Ejecuta la primera transacción: Crea tu contrato para poder acuñar tu NFT.

6. Ejecuta la segunda transacción: Acuña tu NFT con la función "mint".

7. Verifica en OpenSea: Asegúrate de que tu NFT aparezca en OpenSea.

Conclusión

Con estos sencillos pasos, ahora puedes crear tu propio Reproductor de Música NFT con Decent. Este es el camino perfecto para los músicos de LATAM que quieran lanzar su próximo drop de música NFT. ¡Buena suerte y disfruta de tu creación!

Credits:

• EL EXILIO - New Festival Token

• REPRODUCTOR DE ALEGRIA

steps to resolve the issue

When Heno approached me with his problem, I first recreated the bug by uploading the CSV file, from sound, to run an airdrop on a testnet. This confirmed that the bug existed and that Decent.xyz was already alerting musicians of the reason for the errors.

Steps I took:

1. Recreated the bug by uploading the CSV file to run an airdrop on Goerli testnet.

2. Confirmed that the bug existed and Decent.xyz was already alerting musicians of the reason for the errors.

3. Hypothesized that the CSV file had an additional column for quantity, which was causing the error. Also has row for column labels which caused a 2nd error.

4. Created a solution by removing the extra column & row.

5. Tested an airdrop, which worked successfully.

6. Helped Heno with his problem and gave him an updated CSV to airdrop his music nfts.

Through this process I found out that the CSV file had an additional column for quantity, which was causing the error. To resolve the issue, I followed the error messages from Decent.xyz, creating a solution by removing the extra column and column labels. Tested the changes with an airdrop, which worked successfully. By doing this, I was able to help Heno with his problem, give him the solution to airdrop his nfts, while opening a new question for how we make airdrops easier for musicians in the future.

airdrops in 2023

Airdrops have become a popular method for musicians to distribute their music nfts in 2023, as it allows them to reach a wider audience and deliver utility to existing holders. However, as the music nft space continues to evolve, it's important for companies like Decent.xyz to stay on top of the latest trends, such as airdrops. It is also important to have a good communication with musicians like Heno, to understand where they're getting stuck, and how to make it easier for them to use these airdrop tools.

The problem is it’s hard to use these tools. Heno is smart, and experienced in web3 music. He’s released tons of music nfts and still needed 1:1 support. How can we make it easier for musicians, moving forward, to use airdrops?

One solution could be for Decent.xyz to do a better job communicating the requirements for the airdrop tool, or update their airdrop tool to accept new CSV formats, including the Sound format used by Heno today. This will help musicians to have a smooth experience when using the airdrop tool.

conclusion

In conclusion, it's clear airdrops are becoming a popular method for musicians to distribute their music nfts, and it is important for companies like Decent.xyz to stay on top of the latest trends. The case of Heno highlights that the CSV file format used by Sound.xyz was not compatible with Decent.xyz's Airdrop CSV feature, which caused a problem for Heno (and other musicians). The solution was to remove the extra column from the CSV file and test an airdrop, which worked successfully.

This raises an important question: Should Decent.xyz do a better job communicating requirements for the airdrop tool, or should they update their tool to accept new CSV formats, including the Sound.xyz backer format? Which will help musicians to have a smooth experience when using the airdrop tool? As it gets easier for musicians to use web3 tools, we make it easier for more musicians to to make a living & support their families in music nfts.

Please share your thoughts by reaching out to myself or Decent.xyz to voice your opinion on how we can improve their airdrop tool.

To illustrate this point, let's take a look at a hypothetical X-Men movie that we created using AI. In this film, we used AI to generate a basic plot outline and character descriptions, as well as to suggest dialogue and scene ideas. While we had to make some adjustments and fill in the gaps with our own creative input, the AI was able to provide a solid foundation for the story.

One of the characters in this film, Mr. Sinister, is a villain who believes in using genetic manipulation to create a pure and superior mutant race. This is in contrast to another character, Magneto, who believes in using force and intimidation to achieve his goals. Here is an exchange between the two characters that highlights their differences:

Magneto: "I think it's best to stick with the classic flavors. Anything too exotic just seems like it's trying too hard."

Mr. Sinister: "I disagree. I think it's important to push boundaries and try new things."

Magneto: "But sometimes it's better to play it safe and stick with what we know works."

Mr. Sinister: "Going too far can be a good thing. It's how we discover new horizons and reach our full potential."

Magneto: "Maybe, but there's a risk of losing sight of what's important and getting carried away. We need to find a balance."

This exchange illustrates the tension between the two characters and their different approaches to achieving their goals. It also highlights the importance of finding a balance between innovation and caution when it comes to using AI in the screenwriting process. On one hand, AI can be a valuable tool that helps writers generate ideas and streamline the writing process. On the other hand, it's important to leave room for human creativity and originality, and to ensure that AI is used in a way that complements and enhances our natural abilities, rather than replacing them entirely.

This is the only line of this article created by a living, breathing, human - Kah’lil

It’s important to note this was an organic relationship. MakintsMind is has no official relationship with Decent. Market conditions, as well as MakintsMind’s natural attraction to web3 music, have created a fertile ecosystem for this new organism “Onboarder” to evolve.

This approach is particularly interesting because it allows the community to not only bring new creators into web3, but also directly benefit from the success of those artists through the sales split. In this article, we will explore the benefits of incentivizing onboarders and how communities can effectively implement this strategy.

Challenge: Onboarding Musicians

Onboarding new creators into the world of music non-fungible tokens (NFTs) can be a challenging process for both the creators and the communities that are bringing them onboard. One of the main challenges is the technical aspect of using wallets like MetaMask and understanding how to navigate the various platforms available for creating and selling NFTs. Additionally, creators must also consider how to protect their musical rights on the blockchain, which can be a complex and unfamiliar process for those who are new to the technology. These challenges can make it difficult for new creators to get started in the world of NFTs and can discourage them from pursuing this exciting new opportunity. It is important for communities to provide the necessary support and resources to help creators overcome these challenges and succeed in this rapidly growing market.

Onboarders reduce the friction for new creators to ship their first music nft.

The Drop Breakdown

Here’s an example drop I saw from makintsMind onboarding a musician

• 85% - artist - provides music & cover art.

• 15% - onboarder - creates music nft, handles distribution & sales.

Onboarding Fee

When considering the 15% onboarding cut that makintsMind currently implements for new artists, it is important to consider both the time and effort required to set up a new musician's drop in web3 and the potential rewards of this approach. On one hand, 15% may seem like a significant cut for the onboarding process, especially if it requires a significant amount of time and effort to set up the drop. On the other hand, it is possible that this cut is sufficient to compensate onboarders for their time and effort, especially if the artist's drop is successful and generates significant sales.

Ultimately, whether or not 15% is an appropriate cut will depend on a variety of factors, including the specific needs and expectations of the onboarder and the artist, as well as the potential rewards of the drop. It may be helpful to assess these factors carefully and consider the potential risks and benefits of this approach before deciding whether it is the right fit for your next drop.

What do you think about “Onboarders"?”

Now that we have explored the challenges and benefits of incentivizing onboarders in the world of music NFTs, I want to hear from the community. How do you feel about this strategy for onboarding new creators? Do you think it is a fair and effective way to bring new talent onboard, or do you have concerns about the potential risks and drawbacks of this approach? I welcome your thoughts and insights on this topic, and encourage you to share your opinions and experiences with me on Twitter or Lens. By engaging in this open and honest dialogue, we can work together to find the best solutions for onboarding new creators and supporting their success in the world of NFTs.

Many mushrooms form partnerships with roots of living trees, and the resulting fungus-root is called a mycorrhiza. The mushroom's mycelium weaves itself around the root and actually alters the shape of the root. - Ministry of Forests

The collapse of FTX threw my week off. Another case of a centralized entity crashing and burning. To me, this is a reminder of the need to decentralize. DeFi is fine. Ethereum is fine. Music nfts are fine. Just the centralized, traditional, entities having issues. 🏦

Mushrooms and trees.

Walking in the forest, hug a tree, take a step back & observe. Look at how much life one tree supports. Grasses, colonies of insects, bird’s nests, and, if you’re lucky, you might even spot mushrooms poking out of the group. The mushroom absorbs water and minerals for the tree, but in return the tree gives the mushroom nutrients, too. They have a symbiotic relationship. Often, what is simple above ground, is much more interconnected & complex beneath the surface.

The tree is FTX. It grew really fast, provided many nutrients to our ecosystem, and encouraged smaller fungi to build relationships across the web3 ecosystem. However, unlike the tree in nature, FTX was not providing us healthy nutrients. Instead FTX was pumping artificial FTT tokens into the ecosystem. This was fine during the bull market, when the sun shines bright and the soil is fertile. The challenge came when the ecosystem was struggling, and needed to lean on the strength of the tree. When the mushrooms tried to rely on the nutrients from the tree of FTX, all they received was an empty FTT token. This is how one tree, and its ecosystem came crashing down. While I have empathy for those impacted, we can find paths to support ourselves, by

• self-custody - taking control of our private keys

• decentralization - replacing central points of failure with community ownership

• transparency - building in public

Self Custody

When FTX went under, they stopped withdrawals. This means your money, money you trusted to FTX, was no longer accessible. Need to buy food with it? too bad. Need to pay rent? sorry. Don’t like SBF and want to move to coinbase? tough luck. Self-custody fixes this.

When Russia invaded Ukraine, Russians were cut off from bank access, exchanges & other services. Self-custody fixes this.

If you are a digital nomad living in Argentina, your US bank account might flag your travels, preventing you from having money abroad. Self-custody fixes this.

In the wood wide web, self-custody is the default. A mushroom can’t store excess nutrients in a fungi-bank. All nutrients are stored in the mushroom, or, within reach of its roots. Humans get scared of self-custody. Our pessimism kicks in:

• what if someone robs me?

• what if I forget where I put it?

• these other guys seem trustworthy, and they tell me they can keep my important stuff safe…

Until they can’t. Custodial institutions like banks, centralized exchanges, and marketplaces seem like a safe place to store assets. But it’s not sustainable. Humans make mistakes. Centralized entities create complex organizations with double-accounting and security flaws. They’re not just code. They’re layers of chicken-scribble bureaucracy, illegible terms of service, and, of course, emotionally-driven humans to run it all. Keeping your assets in self-custody and in DeFi keeps your stuff within reach of your roots.

Are you more trustworthy to preserve the safety of your assets? Maybe not, maybe you still don’t feel ready to buy a hardware wallet, keep your seed phrase safe, and take full custody. But when is a better time to start? Start small. Buy a hardware wallet. Add a tiny amount of your assets, as you build up the knowledge and confidence to stand on your own.

decentralization

Mint Songs failed when the 2 equity holders wrote a tweet saying “we’ve started the process of winding down”. FTX failed when SBF filed for bankrupcy. Failure is not falling down, it’s refusing to get back up.

https://twitter.com/mintsongs/status/1570127200925384706?s=20&t=Zi0HvFyH55rjVNzcdqFFMQ

Decentralized networks don’t die. They might go into hibernation for awhile, but decentralized networks are antifragile: they get stronger with increased stress. Linux, Ethereum, Uniswap, etc. These are decentralized systems with no single-point of failure. When one tree feels stress, it communicates, using its network of roots, to surrounding trees, allowing other trees to be aware, respond, and support the network.

If mint songs was decentralized, I’d still be building on it. If the codebase was open & keys were owned by the community instead of Dwight / Garrett, it would still be running today. Nobody in the community wanted mint songs to die. I loved mint songs. We helped create more music nfts than anyone out there. But, when the bear market hit, the leaders got scared, laid off the entire team, and chose to die quietly instead of turning over the keys to the community as they’s promised.

Lesson Learned: do not trust humans, decentralize ownership.

Build in Public

“Building in public” is an important facet of web3. When we open-source our design process, we invite the community to scrutinize our decisions and ask questions. More eyes lead to better feedback, increased transparency, decreased reliance on any one, centralized, entity, and reinforces the decentralized network of trustlessness.

https://twitter.com/losingmyego/status/1582762866918424576?s=20&t=Zi0HvFyH55rjVNzcdqFFMQ

It’s a constant battle I have with some of my clients. Businesses have a need to make money. How can we make money if all our code is public? How can we find investors if all our proprietary technology is given away for free? How can we have a competitive edge if we are always sharing our next move, publicly, with competitors?

The biggest example I have is Ethereum. Coming up to the merge from proof-of-work to proof-of-stake, I started going to the weekly All Core Dev calls. You show up to a YouTube livestream and hear everything the Ethereum devs are working on. All Ethereum Imporovement Proposals are stored publicly on Github. You can see the live data for the Ethereum network in realtime on ultrasound money. Every part of the Ethereum network is being built in public for everyone to see. While it is only one anecdote, I believe this is how the most successful organizations will be built, moving forward, with 100% transparency & community involvement.

Final thoughts

One tree does not determine the health of the ecosystem. FTX is an example of how to not make a light bulb. I’m grateful for moments like these so I have an easy answer when people ask “why should I keep custody of my own assets?”. Luckily, I was not negatively impacted by FTX. If you were, I’m sorry. Things might looks dark now. They will get better. Lean on your family, friends & community if you need support. We are here for you. Ethereum is stronger than ever. viva la musica.

Some questions I would like to chat through

• Is it better to start maximally centralized and increase decentralization over time?

  • Or, start maximally decentralized and add centralization over time?

• How important is it to build in public?

  • In which cases is it unhealthy to build in public?

    • Are these examples of VC funding skewing incentives?

• How can we make it easier for normies to practice self-custody?

What’s an iframe?

According to w3schools:

An HTML iframe is used to display a web page within a web page.

You’ve probably already seen iframes around web3 in places like Zora / Bonfire / etc. You can take a Zora Drop, and embed it directly into your token-gated Bonfire site so collectors don’t have to leave your website to collect.

Today, we’ll be building the iframe for Adam Levy, as well as any Decent creator, to use. I’ll be open-sourcing the journey to creation to make it easier for future builders to leverage this technology in their own projects. Here’s the end user-experience (UX) we’re shooting for:

First, a creator will copy the embed code (iframe). Here’s an example of how this looks on Zora Creator.

Then, the creator will paste the embed code on their Bonfire, WordPress, or other custom website.

Getting Started

I’ve never built an iframe before. So, my first step is to create a "Hello World” iframe to make sure I understand the basics. We’re going to try:

1. Local HTML <h1>Hello World</h1>

2. HTTP endpoint https://hq.decent.xyz/editions/1/{collection-address}/iframe

Local HTML

Pretty easily I was able to setup my first iframe 🎉

Here’s the code in /pages/index.js

<h1 className={styles.title}>
    web3 iframe
</h1>

<iframe src="/MyIFrame.html" height="200" width="300" title="Iframe Example"></iframe>

And the code in /public/MyIFrame.html

<h1>Hello World</h1>

The Results:

HTTP endpoint

Having the HTML locally is a great place to start, but, for Adam Levy’s use-case, we need him to be able to use the iframe without having to save the HTML code locally on his WordPress site. I’ll update the existing page architecture to include a /iframe route to support the same HTML we want to render. Let’s see if we can get the same iframe with the src property pointing to an HTTP endpoint instead of locally stored HTML.

/pages/index.js

<h1 className={styles.title}>
    web3 iframe
</h1>

<iframe src="http://localhost:3000/iframe" height="200" width="300" title="Iframe Example"></iframe>

/pages/iframe.js

<h1>Hello World</h1>

result:

Adam Levy - Project Requirements

For Adam Levy’s project, I need to build the iframe so it supports his design specifications. The design specs include:

• Follow on Lens button.

• Buy Decent NFT <--- main goal.

• Enter Token-Gated Vault.

The Design Specifications

(apologies for the low-resolution: working with that I’ve been given)

The Architecture

In addition to Adam Levy’s use-case, we also want to extend this functionality for ANY project dropping on Decent. I’ll divide this into 2, nested, iframes:

1. Buy Now iframe- for ANY creator on Decent.

   1. Current Price

   2. Buy Now Button

2. Adam Levy iframe - made w/ 💛 for Adam

   1. includes the first iframe

   2. also includes the rest of Adam’s design specifications.

Decent iframe for any Creator

We have a repository for the existing Decent HQ codebase. I’ll open a pull-request to add an /iframe route to all Decent minting pages. This will include the basic HTML components, with Decent styling, for any creator to embed collecting functionality on their own website.

Before that, I’ve been writing code all day. Gonna go for a sunset hike, let these ideas percolate, and then come back with fresh eyes. brb. 🗻

Okay I’m back with a fully functioning iframe embed. This iframe can be generated for ANY existing Decent Edition page by appending /iframe to the route (example below). In Decent’s case, we’re using NextJS. However, this will work with any HTML framework. If you’re confused remember an iframe is simply embedding a website into another website. You can add ANY website url into the src property of an iframe and you’ll successfully embed the website on your custom site.

example iframe

<iframe
      src="https://minting-studio-kaf8ekx61-decent-webapp.vercel.app/420/Editions/0x91a738dd4B3344137E1fA9651746Dba2bcC05073/iframe"
      height="500"
      width="500"
      title="Iframe Example"
></iframe>

Here’s a code snippet of the src you see above (NextJS / ReactJS).

Adam Levy customized iframe

Final task is to create a more expanded iframe to match Adam Levy’s design specifications. The biggest change needed will be to token-gate the UI with Adam’s Lens collectible. Collectors must first own Adam’s follower NFT on Lens prior to being able to claim his digital collectible on Decent. I’ll pick this up tomorrow. Gonna catch some zzzz’s. 😴

Introduction

a dm from abram 📬

One day I opened Twitter to find a message from Abram, co-founder of the 0xSplits hyperstructure. It was a message to see if I was interested in hearing more about a special project. They were building a new technology called “Liquid Splits”. This sounded cool. I could build my first implementation of Liquid Splits while, at the same time, partnering on a music nft for the merge. I was instantly sold. Abram connected me to Jonathan. We hopped on a call and started building together.

Building

liquid splits to reward nft holders

Liquid Splits is a new tool only possible with blockchain technology. It was first introduced by the 0xSplits team in Headless Chaos, a headless band of 77 artists.

https://twitter.com/0xSplits/status/1532735333607022592?s=20&t=L7fErwGHsfJcf5XWOTZZGA

I was able to learn a lot about the original implementation from the article by 0xSplits (found here). With Headless Chaos, the Liquid Split was deeply connected with the Headless Chaos smart contracts.

My goal was to create a standalone, modular, implementation of Liquid Splits. So any musician could use liquid splits in existing music nft platforms like Catalog, Zora, Sound, etc. So, with the help of Will from 0xSplits (MAJOR help btw), we published the Liquid Split module on ThirdWeb. It’s a no-code tool to publish the Liquid Split contract for you to use 100% free & preserves your ✨creator sovereignty✨.

1. Pick what chain you want your liquid split on.

   1. Ethereum / Polygon / Optimism / Arbitrum / Binance / etc.

2. Enter the nft contract address that will control the Liquid Split.

3. Enter the [tokenIds] who’s holders will be recipients on the split.

https://thirdweb.com/sweetman.eth/LiquidSplit

1 token = 12 songs

Jonathan Mann took the lead on how we would represent 12 songs in 1 token. He explored Music Players similar to Outsider Collective where the animation URL is an HTML page hosted on IPFS. He also looked at a more dynamic approach similar to ChillPill’s The Decentralized Living Album On The Blockchain. Jonathan wrote up a great thread while we were making this album.

https://twitter.com/songadaymann/status/1568741813829369856?s=20&t=Kxnd0j5mbbSahWfwBmEXlQ

pricing changes at the merge

At first, this didn’t seem possible. Then I was confident it was possible. Soon after I ran tests making me think it was computationally unfeasible. Then I found a simple way to make it work. Thanks to M1guel for the simple application of EIP-4399.

https://twitter.com/m1guelpf/status/1529107845089722374?s=20&t=Kxnd0j5mbbSahWfwBmEXlQ

backdoors = none

Non-upgradeable contracts with limited mechanisms to change the rules after the contract has been deployed. Once you learn the rules, you can trust they won’t change. The rules are simple, so it’s easy for anyone to play. We built a simple system to ensure our art lives for at least as long as Ethereum does. preserved in quality as the creator intended.

The Sale

2 days before

We used bordels calculation of TTD to determine when the sale would start. We predicted 2 days out from the merge and shipped the contract onto Ethereum mainnet.

• publicSaleStart: 1663051884

• Tuesday, September 13, 2022 6:51:24 AM GMT

2**64

As mentioned earlier, a solidity contract can check whether the transaction is being executed on proof-of-work or proof-of-stake by checking whether block.difficulty > 2**64 if true the merge has happened (EIP4399). I created a method called _activatePostMerge to update the price & publicSaleEnd time once the merge occured. Automatic contract changes based on the merge. This was a first for me.

2 days after

The contract automatically set the sale end time in the function (above). Nobody on the team knew when the sale would end. It all happened with rules enforced onchain.

• publicSaleEnd: 1663397111

• Saturday, September 17, 2022 6:45:11 AM GMT

Post-Merge

Withdrawals: where everything went wrong

5.6 ETH is stuck in the contract. I can’t call the withdraw function. It’s failing, even if I increase the gas-limit. Did I just mess everything up?

Transfer has a native gas-limit of 2,300.

Gnosis safe is a proxy contract that requires more than 2,300 gas to receive ETH. Otherwise, you get an out of gas error. This is an issue, because I used transfer, which has a limit of 2,300.

EIP2929 has a mechanism called access lists which seemed like a potential solution.

https://mobile.twitter.com/gakonst/status/1367418971117477888

I built a simple app so Jonathan Mann could use EIP2929 to withdraw with one click. Things were looking up. Metamask pops up, no warnings of failure. I didn’t execute the transaction, because I like seeing the number get bigger in the Merge Contract balance. But, I trusted everything would be fine.

I was wrong. It didn’t work. I spent another 24-48 hours in high-stress wondering if I got 5.6 ETH stuck in a contract. The metaphor “pulling my hair out” could not have felt more literal.

Then I looked back at this tiny, forum post by the Gnosis Safe team.

I started typing a message to Jonathan Mann, wondering if he could use the Song A Day DAO multi-sig to execute the withdrawal transaction. That’s when I had another idea:

Create a new contract that warms up the Gnosis Safe and withdraws the Merge.

So I wrote up a contract to test my theory. Shipped it straight to Ethereum mainnet. No unit tests. No testnet deployments. I’m at the end of my options so this has got to work.

The transaction goes through. 5.6 ETH in funds are distributed successfully. The liquid split is updated with new nft holder recipients. Everyone is paid. Mission success. 🥳✨

Statistics

• # of music nfts: 95

• # of collectors: 85

• # of transactions: 107

• total earnings: 5.6 ETH

  • creator / musician: 2.56 ETH

  • ethereum core devs: 1.42 ETH

  • liquid split: 1.42 ETH

  • myself (the music nft engineer): 0.28 ETH

Takeaways

1. Never use transfer to move ETH in solidity.

   1. if (1 address): always use call to account for gas uncertainties.

   2. if (2+ addresses): always use 0xSplits toolkit. No need to recreate the wheel. Top-tier tech is available for free. No need to recreate the wheel. Start here:

2. Unit Tests - essential for shipments on Ethereum Mainnet.

   1. I prefer Forge: test solidity code with solidity tests.

      1. used by Zora & 0xSplits.

   2. You can also use Hardhat.

3. This project was successful.

   1. A+ execution from the team.

   2. Slight hiccups & learning opportunities for me to apply in future projects.

Great work to everyone involved. I’m proud to be working with some of the most intelligent people & teams in the world. Thank you to the 0xSplits team, Song A Day Mann, Song a Day DAO, Austin, Alan, Zev, Superphiz, the Ethereum Core Devs and everyone else who was a part of bringing The Merge Album to life. This project is very special to me. ✨🐼✨

1. Platform (Catalog / Sound)

2. Creator-owned contract

   1. Platform factory contract (Manifold / Zora)

   2. Unique custom contract (Domino / Infinati)

The lifecycle of a music nft is pretty standard:

https://twitter.com/sweetman_eth/status/1554249242822205440?s=20&t=cFtxB2ClkfP0VZUIBPRL1Q

Metadata is the foundation

What differentiates a music nft from any other ERC721 token? Metadata. Marketplaces, like OpenSea & Zora, display your token by calling the tokenURI method defined in the EIP721 standard:

And the EIP721 metadata standard only includes 3 attributes

1. name

2. description

3. image

That’s it. From here we get more opinionated. Most people want more data than just name, description & image. But, that’s all that’s defined in the Ethereum standard, how would we add more attributes?

OpenSea standardized metadata

OpenSea is the biggest nft marketplace. As a result, when people create nfts, they’ll inevitably ask:

• how does my nft look in OpenSea?

OpenSea’s Metadata Standards expand upon the EIP721 standard by indexing the following additional attributes:

• image_data

• external_url

• attributes

• background_color

• animation_url

• youtube_url

OpenSea is a very generic marketplace. It’s clear the tokenURI method is important for representing non-funglible tokens in the metaverse. However, are the standards defined by OpenSea sufficient to represent music nfts?

Music NFTs

How will music nfts be consumed in the metaverse? We don’t need to speculate, we can already see music nfts being indexed and integrated into platforms such as SpinAmp. This is the ideal vision for music, free to consume across the metaverse and valuable to own. SpinAmp is just one example, but demonstrates the need for standardized music metadata.

in the metaverse, music nfts will only be as good as their metadata.

Back to the original question: What differentiates a music nft from any other ERC721 token?

The Value of Platforms

If you’re reading this article, you’re probably interested in migrating off platforms onto your own smart contracts. While we often demonize platforms as centralizing forces in a decentralized ecosystem, platforms add a lot of value to the music nft ecosystem. A few examples:

• onboarding - platforms make it easy for new musicians.

• standardizing - platforms create industry standards.

When I was an engineer at mint songs, we worked closely with Catalog to defined a standard music metadata schema to serve as the foundation for music nfts in the metaverse:

https://gist.github.com/bretth18/df8358c840fa94946ec212f753e290dd

This new standard expands upon OpenSea’s standards to include attributes such at:

• genre

• bpm

• losslessAudio

• mimeType

• 30+ other attributes.

This is just the beginning. Now that platforms have defined a baseline for music metadata, we, as a decentralized community get to decide:

• is this metadata sufficient?

• how can we improve music metadata further?

• how can we start at our metaverse expectations of how music nfts will feel and work backwards?

• how can we decentralize access to the creation of music nfts?

The First Music Hyperstructure: Metadata

Let’s summarize the key points so far:

• metadata is the foundation for a music nft.

• there is no hyperstructure to support the minting / indexing of music nfts in a decentralized way.

To help make it easy for music nft projects to add the standardized music metadata, I released an npm package:

https://twitter.com/sweetman_eth/status/1553535916492443653?s=20&t=u1Op7hSBhYEE2Jejt6twlA

This was my starting place, now the question is, how can we make it as easy as projects to plug into the standard metadata for music nft:

• minting

• indexing

This first post is going to outline the initial hyperstructure we built:

music nft hyperstructure: minting nfts with music metadata.

From here on out many of the ideas are based on the original Hyperstructures article. Jacob given me a lot of inspiration here and I wanna tip my hat to the foundation he created. I highly recommend reading the original to get a deeper understanding of Hyperstructures.

• it’s worth noting the music hyperstructure is built on top of Zora V3.

  • all music nfts are listed on Zora V3 for increased discoverability / indexing.

Definition

Hyperstructure - Crypto protocols that can run for free and forever, without maintenance, interruption or intermediaries (Jacob). Hyperstructures take the form of protocols that run on blockchains. Something can be considered a hyperstructure if it is:

• Unstoppable: the protocol cannot be stopped by anyone. It runs for as long as the underlying blockchain exists.

• Free: there is a 0% protocol wide fee and runs exactly at gas cost.

• Valuable: accrues value which is accessible and exitable by the owners.

• Expansive: there are built-in incentives for participants in the protocol.

• Permissionless: universally accessible and censorship resistant. Builders and users cannot be deplatformed.

• Positive sum: it creates a win-win environment for participants to utilize the same infrastrastructure.

• Credibly neutral: the protocol is user-agnostic.

Unstoppable

Traditional music infrastructure like record labels and distribution platforms require a trusted intermediary to maintain and operate it - without it the infrastructure will degrade and/or stop operating altogether. These operators are organizations, either privately owned or state controlled—and require both profits, labor and/or subsidies to serve their purpose over time.

Even platforms like Catalog / Mint Songs / Sound require a whitelist to publish music nfts on their contracts. These whitelists typically require manual updates. If these platforms die (or funding runs dry), their infrastructure could, in theory, become unusable.

The music hyperstructure has been deployed on 4 different chains (including ETH & Polygon Mainnet) & requires zero maintenance. It will run, unstoppably, as long as Ethereum is producing blocks.

See the full list of verified contracts here.

Free

Hyperstructures can be simultaneously free forever to utilize and extremely valuable to own. This is possible because of their unstoppability. There is no cost to maintain and keep the protocol operational forever. Once deployed, it will work exactly as it’s designed with no degradation. Gas costs are still paid by the user of the protocol.

The music hyperstructure is:

• free to utilize: musicians can mint music nfts for free, with zero platform fees.

• valuable to own: Record labels / distributors and other music nft organizations (ChillPill / Squad of Knights / VolDAO) hold a lot of value by aggregating music nfts in their, curated, music nft ecosystem.

Valuable

Music hyperstructures can simultaneously be free to use and also extremely valuable to own and govern.

I work with a lot of music nft projects. When 10k pfp projects, focused on music, make promises, they often include roadmaps including:

• exclusive music nft minting for token holders.

Before, these music nft projects had to hire an engineer and spend multiple weeks building out these smart contracts / minting UI. By using the music hyperstructure nft projects like Squad of Knights & Chill Pill can not only add minting quickly, but can easily set a platformFee to drive financial value back to the projects who are onboarding more musicians into the music nft ecosystem.

• free to use here.

• valuable to own by

  • calling createCuration to deploy your custom factory and add platformFee.

  • aggregating music nft data.

  • governing the curation mechanism.

Expansive fees

Music hyperstructures have Expansive Fees—built-in incentives that can be utilized by anyone adding value in a codified manner on top of the protocol.

There are 2 sets of expansive fees built into the music hyperstructure:

1. platformFee - new fee type. ✨

   1. paid to the platform minting the music nft.

2. findersFee inherited from Zora V3.

   1. paid to the finder of a buyer.

![ZORA V3 Finder's Fee

](https://images.mirror-media.xyz/publication-images/C-xO_T1lpjb2nBOMlmN4M.png?height=1280&width=2000)

Permissionless

Music hyperstructures do not contain permissions. There are 2 implications of this:

• gatekeepers - everyone can use it without prejudice.

• upgrades - no upgrades can be made to the underlying core principles.

The music hyperstructure is fully permisionless at the base level. Curators / platforms / musicians can use the music hyperstructure to create custom curation mechanisms. This enable permissionless minting / curation.

curation is a public good.

Credibly Neutral

The codebases powering music hyperstructures are totally open. No need to give credit when you integrate music hyperstructures into your own apps. The key distinction between permissionless & credibly neutral is:

• permissionless - ability to use the protocol.

• credibly neutral - no need to credit original writers.

I like CC0 as a foundation for credible-neutrality:

CC0 enables scientists, educators, artists and other creators and owners of copyright- or database-protected content to waive those interests in their works and thereby place them as completely as possible in the public domain, so that others may freely build upon, enhance and reuse the works for any purposes without restriction under copyright or database law. - source

Wanna use a music hyperstructure? You don’t need to ask permission:

• use it now.

• fork the code.

• build your own. ✨

Positive-sum

Most music ecosystems are extractive:

• Record Labels

• Streaming Platforms

By being free forever, there’s no incentive to fork the exact functionality. However, there is value in creating a differentiated solution with additional functionality.

• Fees allow participants to directly profit by driving value to the ecosystem.

By being unstoppable, there’s no risk of hyperstructures rug-pulling you.

• use the system without operational risks from building or maintaining it.

By being permissionless, the rules of music are guaranteed to be unchanging, forever.

• create music with a standardized set of unchanging rules.

Combine these to get a vibrant ecosystem of independent actors. Each competing in their own self-interest, to create a cohesive, sustainable, and profitable music community for all participants.

Building a Hyperstructure

Taking Jacob’s original version of a hyperstructure, here’s what we built:

• Hyperstructures are made to power millions of interfaces, not just one: the music nft hyperstructure is generic. Made to be used by 10k nft projects, Music NFT platforms, and individual musicians.

• Use fees as a way to expand the ecosystem, not extract from it: The demo app, found here, shows an implementation of the protocol without fees: 100% free for musicians & curators. Other participants can turn fees on to directly profit from the value they’re adding to the ecosystem.

• Take a protocol-first building approach: 👁💛🧑‍💻 (we love coders) you can find all code to get started using the music hyperstructure here:

  • UI. 🌈

  • Smart Contracts. 📜

  • npm package. 📦

• Building liquidity: liquidity is built at the curator / creator level. When you use the music hyperstructure, you create a creator-owned smart contract allowing you to build your own liquidity of music nfts.

• Ownership where possible, governance where only necessary: creators own their contracts. There is ZERO ownership mechanisms in the underlying hyperstructure. The goal with music nft hyperstructures is a decentralized, composable, music ecosystem. We push all ownership to creators & curators.

• There is a long build cycle: costs are high to deploy additional versions of the music hyperstructure on Ethereum mainnet. Changes will have long design periods, multiple iterations on L2 blockchains, and multiple rounds of community-led feedback before changes are deployed to Ethereum mainnet.

Societal Infrastructure

Given the centralized nature of the music ecosystem in its current form, as well as the decentralized and unstopable nature of blockchains, we have the opportunity to create a more equitable system for creators. We have the opportunity to build a system that:

• gives creators ownership of their art.

  • ERC721 standardizes asset ownership.

  • music metadata standardizes the industry.

• increases discoverability without sacrificing ownership.

  • Zora / OpenSea / SpinAmp / etc are examples of discovery mechanisms.

• speeds up payment rails.

  • no more waiting months to get paid out by streaming platforms.

Every single piece of music technology will be rebuilt, from the ground up, with these new rules in mind. No more extractive behaviors. More opportunities for musicians to earn a sustainable living from their art, as well as growing opportunities for other actors to participate in financially productive ways as well.

💿 viva la musica 🫡

References

• hyperstructures - by jacob.

• CC0 - by creative commons.

• How to Get Rich - by naval.

• EIP721 - by William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs.

• OpenSea Metadata Standards - by OpenSea.

• npm i onchain-music-metadata - by sweetman.eth.

• music metadata standard - by Brett Henderson.

1. 👁 💛 💿 - built with creators in mind.

2. 100% open-source code.

3. MIT license - cc0 technology.

I made a goal to publish a package for music NFT metadata (on-chain).

https://twitter.com/sweetman_eth/status/1552786690149961728?s=20&t=8v_MRPBJtOYYo3DOirItnQ

Here’s the steps I followed:

1. create Github repo.

2. npm init.

3. npm login.

4. npm publish.

5. Import the package into your new music NFTs. 🥳

Create Github Repo

To create a Github repo head over to your repositories on Github and create a new repository.

Some details I like to include in my repos:

• MIT license - cc0 philosophy. Anyone can use this code.

• Public - cc0 philosophy. Anyone can clone this code.

Once your Github repo is created, open a terminal and clone your project locally with

git clone <your-repo-url>

npm init

Now that we’ve created our Github repo let’s initialize the npm package. This is the first time I’ve ever initialized an npm package so forgiv me if these instructions are unclear: I’m still learning myself.

I’m going to use hardhat as the base deployment method for this project so I’ll set up the base contracts structure with npx hardhat init.

After setting up my base contract to be included in my NPM package (contracts/)nChainMusicMetadata.sol) I initialize the npm package with

npm init

Publish the NPM Package

It’s typically recommended to test your packages before deploying but my goal is to ship this as fast as possible & iterate with tests later.

1. npm login - logs you in to the NPM package management system.

2. npm publish --access=public - publishes your package publicly for others to use.

running npm publish --access=public published my npm package successfully!

You can view the NPM package I published here.

Import your Package

Now I want to test to make sure the package works. To test, I’ll spin up a separate hardhat repo (following the steps I listed in the “npm init” section). Once I create the new repo, I’ll try installing the package I just created with

npm i onchain-music-metadata

Here’s how it looks to inherit my OnChain Music Metadata contract:

• contract MyMusic is OnChainMusicMetadata

Support

I am an independent smart contract engineer. I have a few different options for you to support me as a creator:

• 0.0001 ETH - This article is an NFT. It would really help if you collected this NFT to support my writing of future articles. ✏️

• Free - follow me on Twitter here. 💬

• Free - share this article to help propagate the meme. 🦠

• more coming soon. 🌛