After all the drama, who is ready for some excitement? Introducing Bullet! Bullet is an intention-based account abstraction tool for Cardano. I know that sounds like a word salad so let me just tell you the important details you care about.

I'll be working at IOHK soon. New things coming...

Cardano Scaling without a Data Availability Layer 🤔: 1) First off what is the data availability layer and why is it even useful for scaling? Data availability is often combined with L2 scaling solutions like Optimistic and Zk Rollups. Meaning what?

I’ve been seeing some confusion on what we can do between Bitcoin and Cardano. So here’s a thread to clarify/

Hey Cardano community. I have a super nice poll for everyone to vote on! Currently in Cardano if you send to a script with no datum (a piece of data about the sender) attached (whether that script was made with Aiken, Plu-ts, PlutusTx, Opshin, Helios, Scalus, etc.) it is locked forever. We were hoping to resolve that by PlutusV3, but it looks like neither CIP-69 or CIP-112 will be in it due to the ledger changes. So new scripts still won't be able to handle the lack of a datum case. So I want to ask you the community and stakeholders of this ecosystem. Would you be willing to delay the Chang hardfork (the one bringing governance) to give the ledger team time to implement a solution for this? As a bonus this feature would enable nifty smart contract wallets that are truly unique to Cardano. Please retweet and vote on this poll as much as possible. I want to use this poll to help reach a decision backed by you the community.

Wallet Draining on Cardano vs Ethereum in 3 Parts We are going to get into the gritty details of what they are and how they happen. 🧵

Gonna do a Cardano vs Ethereum thread on wallet drain attacks and why they are different and virtually nonexistent on Cardano vs Ethereum. We will also cover Defi and how to make wallets that prevent user data for listed assets on Defi from being maliciously changed.

We are entering a new era of testing on Aiken. You may have looked at other blockchain testing frameworks and wondered "What If?" Now Cardano will have some of the most robust and easy to use on chain tools. I'm excited to see what ends up being built this year!

Ok hear me out. I'm putting together a team. Before I put together that team I need Catalyst Funds. For the first milestone I'll put together a team. The next milestone we will figure out what to build. And the final milestone, we will research what to build using that team. So vote for my proposal for 800k ada.

Cardano Addresses part 1: First let’s go over the forms of Cardano addresses. First is the most common form you see in the wild Bech32. ‘The Bech32 form’ or addr1trgfg…, has some error catching for typos and indicates the network type of address to the user more easily.

I can't wait to show what I've been cooking regarding this. The goal being it's cheap and intuitive enough for all wallets to use. Normal user txs through the contract will see almost no extra cost about .02-.04 ada with added security. It also unlocks the ability for user signed intentions. I'll share the repo next week. If you are a wallet please feel free to reach out. I'm happy to go over what I'm building, how it can be incorporated, and formalizing it as a CIP.

Bullet offers the ability to rotate credentials without changing your address, Layer 2 support using the same address, placing as many trading orders as you want and only paying for those that execute on-chain, and an in-account vault to provide enhanced security for your most precious assets.

We are always making constant improvements to the Aiken compiler. Here's another small bump in reducing the script execution budget

If you are a team working on ZK-VM tech in Cardano (whether that is EVM, Plutus VM, zkMove, etc.) comment on this post and I’ll have you added to a chat to help make your life easier. Includes resources and Provers, etc. Please also retweet for visibility.

We are always continuing to improve the dev experience when using Aiken. Here is what is coming in the next version. Expects will print the line of code which failed. This will make debugging expects much simpler and user friendly. 😎

Zk-SNARKs and other curve operations, now with the dev experience of Aiken. Note: Aiken contracts built with these new builtins and types are usable on Sancho net.

Let me know if you like long form threads on a particular topic. This is similar to the address threads I did on Cardano in the past.

When can we expect this? I'm hoping to prototype the first version of bullet sometime later this month. The contract is nearly complete, offchain code and UI being worked on shortly. From there, it will be a race to battle test and put this in the hands of as many users as possible.

This will be my next dapp project after Fortuna. And I hope to make Bitcoin block information easily accessible to anyone on Cardano.

The moment you have been waiting for…

First off the main thing I’ve seen is using the BTC wallet on Cardano. Note this is not the transfer of BTC or Ordinals to Cardano or vice versa. This is mainly you can reuse your seed phrase/private key from BTC on Cardano via a Plutus wallet that checks for secp256k1 or schnorr signatures.

I'm now my worst enemy. A go developer 😱 I'll be reporting the Go command center for Cardano and be making contributions to Apollo immediately I'm sorry it had to come to this

Why doesn't it see more adoption though? The main problem is simply cost. On Ethereum, for example the cost of account abstraction is typically 4 to 5 times more expensive compared to doing the same transaction with a public private key pair account. On Cardano, my testing is showing a 1.1 to 1.2 times increase in normal user transactions. This is with the benefit of enhanced security that comes with multi-sig signing.

What is account abstraction and how is it different on Cardano? Account abstraction is a term that gets thrown around a lot, especially in Ethereum. The main idea is to have an executable script that separates user credentials from the actual address that controls user funds. In a nutshell you can cryptographically prove your identity to spend funds without being locked into a particular signing algorithm and you can rotate your credentials as needed.

Cardano Addresses Part 2: Plutus In part 1, we explored the forms an address can take when used by Cardano nodes, but Plutus smart contracts see a different structure for addresses. Let’s go over what the smart contract sees when given an address.

Just finished adding mutual recursion to @aiken_eng github.com/aiken-lang/aiken/…

How would you do so in a single utxo? With a library I made recently available. Now the root plus a merkle proof is all that’s needed to verify a block exists in bitcoin. github.com/aiken-lang/sparse…

Happy to start working at @jpgstoreNFT with @scheredev @blakelockbrown and everyone else on this awesome team.

The more I think about, the more I think L2's that are DeFi driven are a mistake! Now before you riot at me, let me go over the current and future issues and propose an alternative way of speeding up DeFi specifically. Then take your best shot at me 😏

Ever wanted to make a sparse merkle tree with log(n) insertion, deletion, member lookup, and non-member lookup? Yeah me neither, but I ended up doing it anyway. So I made a little Aiken example. I plan to add offchain and make it a lib anyone can import. Now you can store anything in a single utxo. Even 90,000,000,000 accounts is possible. The implementation link is below. Keep your eyes on Aiken. This year we will be adding massive improvements to the user experience, libraries, emitting events, and even exportable functions to help make offchain a breeze.

The best part. Using my own product to secure my own ada. I've been meaning to have extra security for my ada for some time. Now I'm building out my solution to my problem. No I don't believe hardware wallet solutions are enough and you still have a seed phrase for the hardware wallet anyway.

All accounts are kept on the L1, so your funds don't actually live on a L2 (like inside a single utxo on the L1), but rather you get a utxo per account. Then each zk-proof posted will modify each involved account utxo. This way there is no leaf state. Since the utxo pertaining to you with the state to represent you just lives directly on the L1. Thus circumventing the need for an Data Availability.

To give an update. The poll is pretty close, I spoke with CIP editors about this and came to 2 options Maybe we can still squeeze this in PlutusV3 before the HF in August-September. If not probably will be scrapped in favor of CIP-112 with the HF coming in Jan? maybe. This will require a new Plutus version PlutusV4. Hopefully too many other things don't get pushed on top of this and delay the second HF even further. HF is very unlikely to be pushed back due to the close nature of the poll. So my outlook is smart wallets with greater security and other cool features involving datumless utxo spending like intention transactions won't be until sometime early to mid next year. Oh well. Better luck with smart wallet/account abstraction next year. Life is about accepting it is what it is. This is my last comment on this topic. Now back to working on my other projects on Cardano.

Maybe consider at this point that "many" serious projects in crypto don't have a token. And instead simply support existing tokens (including meme tokens) 🤷‍♂️

Hope you enjoyed the thread. Let me know if you have any questions.

BLS was merged. Now to make a branch of the stdlib with the new Script Context type

Part 2: Wallet Draining Part 1 here: nitter.app/microproofs/status/169… So now that we understand how assets exist on a blockchain, we can get into the harrowing attacks called wallet draining.

The other dilemma holding back account abstraction is wallet adoption of account abstraction tools. This is what I hope to solve by pairing with some of the most prevalent dapps in the ecosystem today.

With this block information you could prove any transaction that happened on Bitcoin and thus prove any input or output (with some limitations due to transaction size). Though zk proofs could help breakthrough any limitations due to size.

This could allow for a uniform wallet experience that controls both ADA and BTC across 2 chains. But the assets don’t mix, you can’t sell Bitcoin on Cardano and vice-versa.

Fine you people can’t even be satisfied with a simple admin/DAO solution for allowing assets to be recovered in the case of wrong or no datum, but keeping everything else decentralized. 🫠 Jk lol So to alleviate the burning “must be decentralized at all costs” burden from your minds, I have come up with a perfectly decentralized solution only possible thanks to utxos. This solution allows sending back the assets of no datum/mismatched type datum back to the sender (even with the same datum they had before sending to your contract.) Congrats you can rest easy that you can use future protocols with 0 admin keys for any feature. “Admin key” will no longer live rent free in your head. Go forward and prosper. Ok as an aside the big secret on how to accomplish this is pretty simple. The on chain code can lookup information from the previous tx and previous previous tx by being provided the bytearray blob that when hashed matches the output reference tx hash. And obviously you are given the output index too. Note in extreme cases maybe the logic for a contract is coded badly and funds can be locked forever like division by 0. But with this user error can be minimized.

As a side note you can use multisig between Bitcoin and Cardano to have smart contract interactions via state channel L2s like Lightning or Hydra. It sounds impressive, but remember you do need to open a channel with the person/people you will be trading with.

FortunaV2 was just launched 🥳. I am going to do a little thread on it in the coming days. For now if you want to start getting mining check the link below. Happy fishing

Coming soon to Aiken 😮 cs.tufts.edu/comp/150FP/arch…

Here are some mind blowing features looking further ahead. The bullet contract itself operates on a users payment credential to control spending, but one of the unique features is the very minimal dependency it has on the staking contract. This means you can take any existing staking script and enhance it to be bullet compatible.

Now what could you do? The main 2 applications are creating trustless one way bridges or trust minimized bitcoin vaults that allow you to represent the BTC value on Cardano provided the representer has some collateral. You could also prove an Inscription exists on Bitcoin and even who is the owner. (A bit more complex)

So you can take a staking contract that allows you to rent out your voting, delegation, or other any other stake key based feature and pop it in as your bullet account stake key. Rather than sending your ada out of your account to gain extra yield, now this feature can be utilized directly while your funds remain in your wallet.

One last thing I'd like to go over is the placement of trading intentions. Unlike building transactions, you are free to offer up an intention fee in any currency for your intention to get included in a transaction that is then submitted on-chain. Now we can see fee markets play out with any currency in an abstract messaging layer above the Cardano layer 1.

To my surprise, the thread I wrote while overdosed on caffeine gained a bit of attention. So here's a funny timeline that lead to it. Here's me Usually drink no caffeine or small amounts (like white tea or occasionally matcha) Order some coffee with coconut and avocado smoothie to share with a friend Find out restaurant is not open yet and my Grab is delayed until they open and make it from scratch Friend goes off to work before the drinks arrive Left alone with coffee and smoothie Drink both while working on some Aiken code, some project name Bullet? or something Insane caffeine overdose, can't sit still Decide to make a twitter thread while pacing around in a room Post thread, lot of retweets 😵‍💫

Now the next thing you can do is verifiably store all Bitcoin blocks up to the latest one in a single utxo. You could even verifiably add on future blocks. Proof of Work is very easy to verify so doing on chain verification is not difficult.

Cardano Addresses Part 3: CBOR Serialization 1/ If you are a dev you’ve probably seen this format called JSON.

And as on-chain smart contract capabilities continue to grow, You will get access to features like automatic re-delegation if a Drep votes counter to your wishes. This would require some kind of ledger state proof to be stored in a utxo on chain or via oracle and thus be reference-able for scripts to validate against.

And of course Bullet includes support for schnorr and secp256k1 so you can reuse your ethereum or bitcoin signing keys.

We crossed the epoch boundary at block number 2016! The difficulty number has gotten 4 times harder. The difficulty target fell from 65535 to 16383. Congrats we have our first difficulty change 🎉

Check out the latest Aiken release. A bunch of good fixes to improve developer experience.

First block of FortunaV2 6b91a72246ebd5be34d21e65aabda7045fbdb4f5fdbf3e93b27727f0ad0d8c23

What about 2 way bridges? Well Bitcoin is quite limited. So we lack the ability to verify any kind of information about the Cardano ledger. So currently we are limited to multisig and federated bridges.

Funny enough it's not the script. It's the tx builder. Looking at the contracts. It's just a gross overestimation for now while tx builder logic is improved.

3) So what is in the works The first solution with no Data availability needed is Leviathan by Optim Finance team @zygomeb @OptimFi To explain in a nutshell, a Sequencer (could be a single node, BFT consensus, etc.) takes multiple user txs and aggregates them in order.

In other words account abstraction that's cheap for normal user transactions is coming to Cardano. And it will bring the capabilities to do cheaper and safer DeFi. Better DevEx too 🙂

Social media is one the places where you can tell someone the the actual answer, link to the docs with answer, paste excerpts from the docs with the answer, and still you will have people use incorrect words or terms to try to argue with you over the wrong answer. Never change guys. Midwits gotta midwit 🧠

There are 2 parts to an Optimistic rollup. The state proof (merkle roots typically) is posted to a L1 followed by a challenge period. To prevent fraudulent state proofs, the challenger uses a proof of the state from the DA layer to challenge the posted state proof if needed.

5) Another in progress solution? The next in progress solution is a long lived Hydra channel with incremental and decremental commits. The advantage here is not every state transition is posted to the L1, instead checkpoint state transitions are posted at regular intervals.

To make building easier MLabs needs one last bout of funding to get these primitives finished. They are nearly done. Shout out IOG and Charles and let’s get this finished. github.com/input-output-hk/p…

Forecast says that next epoch (Starting block number 4032) will be 4 times harder. We are at block 3425. Get ready for the difficulty spike. You all are too crazy 😂😂 $TUNA

Hope you enjoyed my long thread. I woke up and made this on a whim. This is only a light gloss over on the topic, so I'm happy to go in more details in comments or discord. Note: I use tx and transaction interchangeably.

First off the only parts that get posted to the L1 is the state transition and the small Zk-proof itself (No DA Layer needed). You have absolute confidence that the state transition is proved to follow the L2 ledger rules (provided a correct Zk-proof implementation).

If there's any technical details about Cardano you want to make threads about, I'd be happy to coordinate with you. Lately I've been doing Cardano threads on how addresses work. It gets pretty technical further in.

In Zk-rollups the posted proof proves the execution and state transitions performed on the L2. No challenge period necessary. So why the need for data availability? The Data availability is necessary to tell you what the new state is after being transitioned via the proof.

2. You can not access reference inputs that exist outside of Leviathan. Only utxos inside the Leviathan system can be referenced. If a ref input is in a Leviathan tx and then spent before the Leviathan tx is on-chain then that tx will fail and the Leviathan sequence is broken.

I have many more contracts to make 😃. I enjoy writing the Aiken compiler as much as I like writing in Aiken.

It is also technically possible for the Sequencer to combine multiple user txs into one published tx if all dApps used in each tx are composable and support that feature. Then the Sequencer posts the series of individual/batched txs to the L1 and finally prepares the next series

If like my posts or have been watching our progress on Aiken, please consider voting in Catalyst for Aiken. All funding goes toward making Aiken even more awesome 😎.

The checkpoint state transitions would include signatures by users to authorize moving and receiving assets and even allow changing datums with some extra complexity. The drawback is still the same as point 2 above. Referencing other Cardano utxos is unavailable in Hydra.

Check out this cool release with some nice features 😏

There are two main drawbacks to this approach. 1. The L1 block space needed to validate all the Leviathan transactions is basically equal to the transaction size of each transaction confirmed by the Sequencer

Since each tx is fully validated and the state transition is posted on-chain there is no need to make any data availability proofs. Smart contract validation is of course also possible since the Cardano L1 supports it. 4) What are some drawbacks?

6) A solution with a different drawback. Zk-proof L2 I'll begin with the drawback. Zk-proofs are still "new" in the cryptography world. No implementation today is really battle tested. So tread carefully! Now onto the positives.

There are some I know that are serious and with a token. But others projects I know will refuse to launch with tokens, but the products they bring are just as amazing.

Remember this before you vote on any projects that say we have the Aiken team as consultants 🫤

A Zk-rollup proof could include every tx from the L2 so far or it could only include a single tx from the L2. Both are valid transitions from the Zk-proof side. So you need the data availability to tell you what transactions were actually included in the Zk-proof.

We have some good dev ex features coming in the next Aiken version. 1. When running a multi-validator built with traces on, you get a little message telling you which validator function between the two just ran.

Add a comment to the CIP if you actually care about reducing wasted block size. Increasing block size won't reduce v1 script size waste lol.

Got an idea called iDrep First a preliminary: we label governance actions with a little tag like social, governance, technical, DeFi, etc. I'll leave the standards up to you. Next I build a script template that allows you to pick which dReps you want to copy their vote for specifc tags or alternatively perhaps you want a fallback Drep in case your primary favorite abstains on a vote or goes AWOL. Now all you have to do is fund the script with a little bit of ada run a bot in the background and voila. You have a Drep thats more personalized than any specific person. What about the ada costs per vote? Don't worry the UI can show you other people with similar tastes so you fund a shared bot that's already running (if you like) and just delegate to it instead and it votes based on the template. No humans, no organizations, just bots and an onchain script to validate tx data via tx hash to ensure proper voting. What's the net bonus vs voting myself? Well you can be a lazy bastard who lets people make choices for you the difference is you can be a little granular while maximizing laziness. Who wants to read these gov proposals that fund "MamaShitter2.0 the real deal not meme coin" anyway. Maximize laziness and put other people to work for you.

2) So then is it possible to scale without data availability? And why consider that? The reason data availability is so critical for Optimistic and Zk-rollups is that the state transition of all L2 accounts is not kept on the L1. Only a compressed proof of the state is on the L1

So, what's the other option. To spell it out simply, you post each state transition to the L1. Note the state transition doesn't just have to be for a single transaction. I will show you scaling solutions where a single state transition wraps up 100s of user transactions.

Each "Ref" transaction would carry with it a slot interval so you know your L2 transaction referenced a valid utxo from the L1 even though your L2 tx is not yet finalized. This allows for a unique solution with no DA layer needed, completely trustless validation, and L1 utxo read access.

Now why consider that? Current data availability approaches rely on new cryptography (KZG proofs) and/or other Blockchains like Celestia, Ethereum, etc. Rather than trying to be on the bleeding edge right now with potential financial risks. We can explore alternative solutions.

To make building easier we need funding to get these primitives finished. Shout out IOG to finish funding this work github.com/input-output-hk/p…

Yes. In fact I’ll add a little addendum. But I think with a with a modification to CIP-68 we can have a much better standard with only one extra NFT for metadata lookup. I’ll write a thread on this later. This way it wouldn’t require 2 NFTs per mint of the asset. 🎉

Imagine a tx that has over 100 ref inputs and just a single output and change output. The tx size would be small actually. This allow you to make a series of chained transactions that reference any utxos on Cardano while at the same time you use those references in your L2 txs.

Use cases include Smart wallets, wallets that can do 2fa, vault features (prevent wallet drainers), and intention based transactions (single transactions swaps with dexes and free limit order placements). Datumless utxos accidentally sent to a Dapp could be recovered for the user. Easier subscription services that don't require you to send funds to a contract

Now here's where things get interesting. You can include special state transactions that are produced by referencing various utxos in the L1 chain and use that in the Zk-proof as well. Suddenly your Zk-proof L2 gets access to any L1 utxo state!

So users wont even make transaction anymore? No, there are still cases where users will submit transactions. But for DeFi where high speeds, time ordered sequencing, and transaction compression is valuable then intentions plus multiple competing sequencers is my answer. Could people DDOS the Sequencers? Since the signed intention is not paid for until the transaction is on chain, you could DDOS the Sequencers right? Look to our ol' buddy Solana for DDOS solutions. One thing to factor in is account age when getting DDOSed. Repeatedly funding new accounts to "age" isn't cheap. Alternatively KYC Sequencers?? 🤢 Maybe you might not like it but think of other people. Wouldn't competing sequencers cause contention? Yes at first. Sequencers will compete to get transactions on chain vs each other. But the good news is that the contention is taken away from the user experience. Sequencers can employ bots to immediately remake transactions as needed. As the Sequencer model matures we can have an opt-in consensus layer that allows sequencers to have further trustless coordination. Not an L2 btw since the security would be independent of the L1 and no actual assets exist on this layer only an ordering to signed messages. How many intentions could fit in a tx? Does this scale? I estimate with simple intentions Sequencers could fit approximately 20-30 with well optimized smart wallet contract after PlutusV3. Going further is even possible with improvements to just the PlutusVM rendering something like 50 or so. We can go further! As ZK Proof technology improves we can minimize the bytes in a tx needed for validation and focus purely on increasing the number of inputs and outputs. Perhaps up to 200 each. Is that as far as scaling goes? No, with the maturity of ZK Proofs we can have many ZK Proof accounts spliced into a single utxo. At this step in the journey we have reached the same end point that L2 scaling solutions today strive for. While the destination is the same, I believe in a path with far less fractured liquidity along the way. nitter.app/VitalikButerin/status/… The end goal is something like "to 1 slot (ideal zk rollups with proof aggregation)" Is this similar to Leviathan? Yes it's similar, but the main distinction I make is Leviathan is siloed liquidity to offer fast finality with respect to a single sequencer group. My goal is to optimize throughput and increase the L1's overall available liquidity. The finality and speed in my proposal is more constrained by the L1's speed and finality. In the future there could be optimistic finality via Sequencers and this is not counting any improvements to the current L1 speed/finality. Thoughts? Feel free to leave your questions, criticisms, feedback, and shots 😏

First we give users smart contract wallets. This enhances security by standardizing more secure multisig setups than what a native script can do. And it allows for vaults within the wallet that can help prevent liquidity drainers. The wallet contract will also support DeFi functionality. We also allow the user to create signed intentions that allow spending from a users wallet as long as the intention is fulfilled, a nonce is spent, and any funds in the vault are not used.

github.com/aiken-lang/aiken Here is Aiken. What is Aiken? Well it’s a language and set of tools for interacting and creating smart contracts in an easy way. The goal also is to create a reverse engineering tool to reverse all these onchain contracts 😈

Keep the conversation here github.com/cardano-foundatio…

Building Aiken has been one of the funnest projects I’ve tackled. There’s more cool stuff to come past this milestone 🎊

Part 1: Assets on a Blockchain Before we even get into wallet drains, you must know how assets transfer on a blockchain. In Cardano, assets and ada exist in the value field of a UTxO at an address. That address's payment credential then constrains if the asset can move.

In the next part I will go over wallet draining attacks. And in the final part I will go over wallet signing attacks that affect your assets on Defi smart contracts.