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 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
@ChristopherSeuc@masatoalexander You’re right on point there 💪 it’s good to do a mix for balance as each hand position recruits muscles differently, but wide overhand is more lats
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 you want to check it out, site is here:
https://t.co/xhQFpvOqx5
code is here:
https://t.co/fnf0eOMD7a
@jonahkoch@bobasfk@elraulito Better to look at the Aiken course done with CF as this is PlutusV2, but this does cover transaction building too so still helpful
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
👇
@elraulito Totally agree
Yeah it requires handling assets instead of having a ref input or separate account script per user, either way some calculation is required offchain.
I’m going to build out examples of 113 & 143 to compare complexity & efficiency so we can understand tradeoffs 🙏
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)
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