I just registered as a DREP: drep1rsmldjj7vg9a9r5lqsegynzw03yyfhzdqwfs8fq3ctsk2rwjlfy I will not support burning the treasury, I will not support using the treasury to fund native VCs I will support open source tooling that will help teams and projects launch on Cardano

AFAIK the Gerolamo proposal is the lowest in ask between the alternative nodes It covers 1 year of development for 3 highly skilled FTE dedicated to the project. Among all the alternative nodes, it is the one with the highest potential in decentralising applications

I had lots of help from these nice people also, I hope the book does their work justice 🙏 @MicroProofs @rvcas @_KtorZ_ @StoicPool @YetAnotherAiGuy

I just voted no on net change because it is too high. It’s easy to put large withdrawal requests in when there is a large budget. We need to manage OUR treasury responsibly or we will end up with a more expensive Catalyst, with little to no results

v1.1.16 has some good stuff check it out

my first @aiken_eng contract on cardano. just a simple gift card where creator locks funds and mints NFT, NFT can be sent to anyone and then redeemer burns NFT to unlock the ADA. huge shout out to Rhys from @StoicPool for all the help you've given while I've been learning. if

Good afternoon!!! São Paulo theater 🎥 We should be using #nft as tickets @StoicPool

Feedback or suggestions are welcome, you can find the example on ‘/program’ repo if you want to see this idea develop over the next week or so and run the tests yourself 0 optimisations etc have been considered at this point so it’s currently quite expensive 😅

Anyway I put this idea together in a very simple example just after Christmas after reading CIP113 & CIP143 There might be a very good reason that this wouldn’t work, or some potential exploit that I didn’t think of in the couple hours I put the draft together

This can be combined with withdrawal validators or ref scripts as needed to have arbitrarily complex logic for individual redeemer cases/monetary policies and the only standing rule would be that: Sum all DEED inputs == Sun all DEED outputs

We can have multiple user accounts to enable multi threads because a user can just mint that extra account beacon, as long as we have the appropriate rules in outputs to force 2 assets: (empty asset name > 0 && pkh asset name = 1)

So if we need to blacklist accounts or we want to enable clawbacks in our particular asset, we can set those rules and tag accounts via the datum

Doing it this way means we have freedom to set datums and redeemers according to the particular programmable needs and provides a simple way for wallets to discover various user accounts according to the token registry -> this might be a negative for infrastructure 😅

The root beacon can have a matching policyid & asset name to id it as the supply beacon DEED.DEED So the initial supply mint will look like this: DEED: { “”: 100,000,000, DEED: 1, } Or more readably: DEED.”” : 100,000,000 DEED.DEED : 1

So any given utxo will be easy to find and will have all the info within it to manage spending those programmable tokens But where does the initial mint go? If it has a fixed supply, we can do so with a one shot param, but that doesn’t satisfy the location of the assets …

But what about user accounts? We can create a user account for that specific asset, which can have an asset name of the PKH, meaning they need to sign to spend from that account utxo, without having to know that credential in advance DEED.pkh

Let’s call our tokens ‘deed’ tokens Deed is script hash for the minting and locking of deed tokens PolicyID = deed Asset name is empty so the programmable token will be: DEED._

Seeing as we already have a token registry, instead of creating specific smart wallets or account addresses, why not mint account beacons for a specific asset and lock each of these accounts in the same validator? (There is probably a good reason, but humour me…)

With all this talk about programmable tokens recently on Cardano, with various designs and specs coming out, I was thinking of a simple way to implement/develop this concept that can allow more flexibility across different assets 👇

The contracts aren’t 100% finished or ready for use yet, but I am open to any suggestions or collaboration from other community members to help get this out to Cardano 💪

Another bonus for this setup allows users to separate the MultiSig management from the spending rules which frees up space in transactions