Performance marketing is something that’s been honed and refined in web2 marketing – especially by the F2P genre of mobile games. If the lifetime value (LTV) of a user is $5, it’s worth spending up to $5 in adspend to attract users. This is what allowed the flywheel of digital advertising and F2P to really spin up – with money that users spent in game being poured directly into advertising, which in turn drove more users. The pinnacle of this was King, the makers of Candy Crush, spending almost a half billion dollars on formats like Superbowl ads to drive user growth in 2015.

With a mobile game, the direct in and out is pretty simple – either users spend money on your app or they don’t. This is especially important as your direct costs (adspend) are also denominated in dollars.

Now with crypto it’s very different. Very few dapps directly monetize or drive revenue – instead, as a protocol you have other metrics for how you view the revenues.

The only ones that are really able to do this at scale are the crypto exchanges – Coinbase also spent almost a half a billion on ads with stunts like the moving QR code, or giveaways. Key to the discussion on moving people away from centralized alternatives is this – the ability to get the performance marketing flywheel going is key.

Since monetization is often done through a token (liquidity mining, or token sales), the objective metrics become different – especially as your expense is no longer denominated in dollars necessarily, and can be denominated in tokens.

So what marketing related expenses can you denominate in tokens?

Liquidity mining and airdrops, have been the only way to really get distribution using this superpower.

However, it's up to builders capitalize on the fact that the marketing doesn’t need to be denominated in fiat – however the genius with points is that this funnel can really be turned around and be put toward specific goals and metrics that aren't as blunt as a onetime airdrop or a masterchef contract.

Blur for instance can quantify the value that they spent bootstrapping the sell side of their NFT marketplace – and denominate it in tokens.

In other words – performance marketing is here in crypto, and it's up to the smartest builders to figure out the metrics and incentive structures to create playbooks that change crypto GTM – and points is just one side of that revolution.

One of the big themes that I think we’re starting to see shake up for 2024 is the rise of Move as both a VM and a language. This is especially as Solana seeks to adopt Move, and their next step up in programmability (Runtime v2 – great talk here from Breakpoint) is a step towards this future. The other big catalyst is the growth of Sui (which recently hit $200m in TVL), Aptos, and chains that bring a Move VM to other ecosystems (Movement Labs, Lumio by Pontem).

Move was developed by Libra/FB to be their programming language for their payments focused blockchain. However, with things not petering out as they hoped – many jumped ship and started their own startups, including Mysten Labs (Sui), Aptos Labs (Aptos) and others. It has a Rust like syntax, but it’s simpler – and as a result it’s much easier to pick up from Solidity than Rust for the first time.

Why Move? Why another language for devs to learn?

Move is the only other major smart contract programming language outside of the EVM (Solidity, Vyper, etc). This is important because one of the issues with working from an existing programming language like Rust or Javascript – you have to add more boilerplate or add in libraries in order for it to be suited for a blockchain context.

Even though many developers know these languages, the actual usability decreases when you have something that isn’t purpose built for it. While there can be work done that smoothes it out (e.g. packages like Anchor for Solana), I hold the strong belief that a smart contract specific language is important for composability where we deal with more complex interactions.

1. Global Types System

One of the painpoints with the EVM is that there are no native types. That means if you’re trying to interface from another protocol from your contract, but you don’t have their interface, you’re plain out of luck. One thing you can do is go to Etherscan, copy the interface and then interface with it.

With Move, contracts are called ‘Packages’ – borrowing from Rust terminology here, and when you ‘publish’ (aka deploy) you push up not only the bytecode, but also the metadata associated with the contracts.

As a result, you can specify dependencies as addresses, and pull the information about for use in your program – the following, from the Kuna Labs repo is a good example:

2. Native Upgradability

One of the great painpoints with the EVM is the lack of upgradability. This has resulted in hacky patterns like transparent proxies, UUPS, etc.

Just like Solana, you can directly upgrade the contract if you have the upgrade key. There are some limitations of course – the public facing API can’t be changed, only new functions can be appended, structs can’t be directly modified.

As usual – the code can be made immutable as well, but by default contracts are upgradable.

3. Inline Tests

This is probably the aspect that I wish came into Solidity the most, but you can add inline tests to Move. Just as a quick refresher, for more complex systems, in order to test specific components, we’ll often write out mocks or lens contracts to help determine the state of a particular contract. However, inlining these tests allows for more seamless test driven development (TDD).

Here are some tests that are part of the Kai Finance vaults:

4. Global Storage

One of the key things is the global storage, where instead of using a mapping, user data is stored in an address. This is in part what allows for such good performance, since only the data that you need to access is called (e.g. your token balance), instead of needing to load the entire program data into memory.

These are resources, and have a key or a store ability. The key refers to the fact that is can be stored in this global storage, and the store refers to the fact that it can hold data.

This is why you might see a bunch of addresses that are being invoked when you look at the transaction graph on an explorer – these are references to the global storage.

5. (Sui specific) Objects

Sui goes one step further with the concept of global storage and introduces the idea of objects. With objects, these have native transferability if it has a store ability.

If I were making an Ownable module, I’d create an object with key, store and transfer the object to my address. To get authentication, I would just add it as a field in a function, since no one else has access to this OwnerCap object – no need to authenticate within the function.

function setFees(_: &OwnerCap, newFee: u64)

Conclusion:

Hopefully this post goes a bit further in demystifying Move and some of the ideas explored here. While there are areas that are clunky (e.g. the VScode extension is really bad), Move is surprisingly developed out with robust docs, good design, and a helpful community.

For some good resources:

Move Book

Aptos Move Tutorial

Sui Move Intro

Contracts/backend wasn’t too difficult – just a matter of working through it and meticulously testing the business logic

But creating UIs – oh boy I was really not able to get over this issue.

It seemed like such a massive wall between creating an actual application and learning the puzzle pieces to make it work.

The issues with UI are twofold:

• lack of a good foundation to create a UI along with best practices

• death by a thousand papercuts

  • State management issues, etc

Isolated – these were workable issues, but working through a ton of these stalled any momentum with trying to move forward and make a usable React app.

The key breakthrough for me was leveraging AI to help me with learning frontend – so here is a quick overview of my process for using these AIs.

Copilot (Paid, Free if you go to school):

Copilot has two forms – the first is the autocomplete that we all know and love – and the second is the copilot chat.

With the autocomplete, you can do soft prompting by providing some context on what the component is going to do. If you’re going to have a dropdown menu in the navbar, you can add a comment, and it’ll provide a completion for that menu.

However – I do find myself using copilot chat more with UIs in particular, as Copilot often gets much quieter with completions/less useful as the codebase increases in size and complexity (as it can with UI).

Copilot chat is rumored to be GPT 3.5 turbo but finetuned on code to make it more performant. Whatever it is – responses are really quick which is awesome.

“alignment”:

However – Copilot chat is more prone to turning things down which is a huge source of frustration when this happens. It also blocks public code from being shown, which

e.g. I might ask Copilot to insert some Tailwind to ‘justify some content’ and Copilot will just refuse.

Context:

Another gripe is the lack of context – Copilot chat will focus it’s context window on wherever the user’s cursor is at time of chat, and while it supposedly can access multiple files – in practice I’ve never seen this work.

On a more practical note – this lack of context means that given the choice between chat context and code context, Copilot will prefer the chat context – so if you copy and paste some code, modify it in your code, but ask a follow up question, the response will rehash the code from the original response instead of your modified one.

The fix for both refusal or long chat histories is to click the ‘plus’ button to start a new chat or to delete the previous chat.

Rating:

Overall 7/10 – it’s definitely become a Google level replacement and theres not a ton of hallucinations. It’s a speedy boi too – very fast completions.

Phind (Free):

I discovered Phind more recently and have begun using it a lot more – Phind helps me with medium to higher level tasks.

It takes a few more seconds for Phind to respond to queries, and Phind doesn’t have text completion like there is for Copilot.

But it’s much smarter and has a better grasp for context. In other words, if Copilot chat is a like a summarized google search, Phind is like a very junior intern – it’s that good.

You can add and remove context – the context is the killer as when you start to stretch outside of the context window, the AI can’t as easily pinpoint code that you might be talking about and provide suggestions, in other words the helpfulness jumps off a cliff.

However this fine grain is helpful especially for UI work.

I might have a component within a page, and since both are in context, I can ask about interactions between the two.

It’s also more proactive about solutions – it’ll ask clarifying questions or allow you to (with a click of a button) implement the changes directly into your code.

One particularly nice feature is that it already has a bunch of popular software libraries loaded inside for context, and if it doesn’t know it can also conduct a search to serve you the answer.

Theres some parts that are rough around the edges (Unending requests, no completions) but overall I find it nice for tasks that require some more knowledge.

Rating:

Also a 7/10. Wish it had some more polish with the features and faster responses but it’s dang good at what it does and offers some really neat capabilities. I’ve also never really seen any hallucinations which is pretty interesting.

Conclusion:

To an extent I feel like relying on AI is a bit of a crutch – and that I should be more self reliant and learn the system myself – that I’m cheating myself out of a valuable experience just coding things out and learning from first principles.

This is true, AI likes to skew for more verbose completions, or provide weird/incorrect results – but AI gave me the confidence to get over my UI learning curve and help me make cool shit, and that’s something I’m grateful for.

A few days ago, a startup by the name of Ritualnet hit the scene with a monster raise – 25 million dollars at a low 9 figure valuation. We’ve already seen a few of these startups focused on coprocessing but I think it’s good to take a hard look at this coprocessing usecase – to see if there’s any meat on the bone here.

Why Coprocess?

One of the key issues with the EVM is twofold – it’s constrained by the goal to make this VM as decentralized (and thus lightweight) as possible, and the overhead of running things through the EVM itself.

On this latter point, consider an operation like addition of two numbers.

In the EVM, this is 4 operations, pushing two numbers on the stack, adding, and storing the result – contrast this to say the WASM VM where it’s just 1 operation to do this. In addition, there’s much more work done to speed up and ensure safety around say cryptography libraries in C as opposed to the Solidity implementation.

Add this up over an entire program execution, and it becomes meaningful overhead – not to mention the gas constraints involved over running in a decentralized setting.

As a fun fact, the computation involved with WASM is so much lower that Arbitrum stylus offers pricing for WASM operation in ‘ink’, 1/1000th of a wei, because wei is too big to represent the true cost of operation for these individual operations.

This is an obvious constraint for apps trying to run in this compute environment – so this is where coprocessors step in.

Coprocessors:

Coprocessors allow for external compute to be brought into EVM.

Arguably we have coprocessors already, but in a different name – keepers.

Keepers are good for routine upkeep operations for dapps

• Some of these keepers are for upkeep operations of public functions (e.g. poke contract)

• Some are for more trusted usecases (e.g. peg maintenance)

It’s this latter usecase that coprocessors try to focus on – providing guarantees for this trusted execution.

zk coprocessors focus on this need by allowing for provability of this compute – before the computation can be executed.

Areas of interest

One area that asynchronous computation shines the most is in governance.

The baseline here is not a synchronous operation, but rather a long multiday governance process. While zk can’t replicate a protocol upgrade, for routine parameter changes like LTVs or interest rate changes where this can be automated – this is particularly interesting.

Another big usecase is that of allowing for trustless snapshots. Tokens that want to enable onchain governance need to have governance built right in from the get-go – that is, having the ability to determine balances at a specific timestamp so that this can’t be manipulated via flashloans or any other mechanism.

As we start moving into directions where we see more experimentation enabled by things like Morpho-Blue, or Uniswap v4 – we’ll definitely see more room for this to grow.

Issues

Overhead

One of the key issues with the zk (which is by far the most popular approach) is that zk is expensive as overhead. There’s great work being done to make it more easier to use for devs by abstracting the complexity of circuits, but one of the pain points is around state access.

Unlike Gelato or some existing zk solutions, zk requires proof around all operations, including data retrieval from the chain itself. The current setup for Risc 0 and some others is that all the data used for the operation get passed directly to the coprocessor during the onchain job call.

Axiom, one of the leaders in zk-coprocessing, stands out in that they allow for state reads in the proofs themselves, as it also brings in the ability to read historical slots – e.g. the price of ETH USDC on the Uniswap v3 TWAP 3 days ago.

Hyperoracles adopts a similar solution, but they adopt a subgraph based solution, where dapps can pull from this zk subgraph instead, saving compute at runtime since it comes preprocessed.

Asynchonicity

The biggest issue at the end is the asynchronicity.

Dapps (especially defi) thrive on having synchronous  – it’s what allows atomic arb, or flashloans exist. The need to add asynchronous transactions not only adds to the cost of running dapps (and additional questions around monetization) – but also around how to create dapps that are built with asynchronicity in mind.

Perp based protocols (e.g. GMX, Kwenta, etc) are probably the biggest and best example of defi dapps that are asynchronous – but this is out of necessity due to the impact of oracle running. In other words if they could do without asynchronicity – they would.

Conclusion:

The hope is that in tapping into this niche of coprocessing opens up a wide design space to create novel protocols that can harness more computation to be either more expressive or increase the safety by adding key checks.

I’m sure they will – but there are some fundamental issues around data access, and synchronicity limit the usecases, and the real test will be whether buidlers actually use these coprocessors or just fallback to centralized solutions.

A question that I’m reminded of during the bull run 2020-2021 DeFi bull run was “how are the yields so high?”

The simple answer was that the governance tokens, or psuedo equity were what allowed for people to take ownership of protocols and get them at a significant discount.

The mythical death pool is the best example – the pool with the highest APY was the one with the governance token paired with an asset like ETH. The challenge here being that despite the high APY, the principal was decreasing significantly in value.

Underlying the story is that a yield trick – where people were bamboozled into comparing debt like returns to the volatility of an equity like investment.

This happens on a much smaller scale in TradFi – where boomer retail buys Exxon or other large cap high-dividend stocks for the stable returns that they provide, not realizing that the overall moves in the underlying equity move the needle much more than whatever meager dividend income there can be from a stock.

The key issue underlying this is that it’s easy grok the return profile of a bond (look at the coupon, default risk, etc), and stocks – but DeFi sits at a weird inbetween.

There’s reduced principal risk (if you don’t consider hacks), but there’s more equity like exposure.

Broadening this out – many of the largest protocols within DeFi someway or the other can be explained through this lens:

• Uniswap has the most classic story – while the UI shows triple or double digit APYs LPing on various pairs, whether its a combination of LVR/IL or LPing on shitcoins – facing significant loss on principal when all said and done.

  • Not to say that LP’ing has never been profitable (being the counterparty to so much retail flow), but the average LP is a net loser all things considered.

  • I think the Uniswap story in particular is very illuminating – these tricks predate token based incentives, and that token incentives are very much an accelerant/integral to these tricks

• Alchemix is classic – people turning what equates to a yield stripping protocol and completely throwing duration risk out of the window – to which the ALCX holders have paid dearly.

• Olympus was self explanatory – thousand percent APYs per rebase, only for people to figure out the rebase was no different than a large stock split for the majority who were staked

• Luna is probably the epitome of a misunderstanding of APYs – people farming 20% APYs to the tune of billions, without realizing that they were the yield.

• Ribbon and other structured products market a high APY for staking into a Ribbon vault – while people didn't realize on the other end they were getting slaughtered selling vol to marketmakers and losing their shirts on principal.

• Bunni, Velocimeter and others doing options tokens

  • this is almost the most naked version of this yield trick, where the use of options tokens allows protocols to increase the APY in the UI without actually meaningfully increasing inflation – simply by the virtue that unlike selling tokens outright, not all of the options tokens will be redeemed.

The list goes on and on…

Conclusion:

Rounding it out, this is not an indictment of DeFi and the innovations in particular. I do think that it’s a critical way to think about DeFi and keep an open mind of the mechanisms that take. These yield tricks are an integral part of the DeFi story and I don’t think taking these tricks out will be effective as a GTM strategy in the near to medium future. Each large stepchange in the DeFi meta can be explained using a misunderstanding of yield via these yield tricks.

I also think that part of the reason that many of these protocols have had many forks, and consequently have faded out so quickly – mainly because the game theory of the yield trick gets figured out especially as people try successive iterations of this – in other words people stop participating.

Some positive areas of directions that have resulted:

• There’s now plenty of people thinking about how to reduce LVR, and Uniswap v4 is a marvel of engineering that allows really cool mechanisms to be built to better service liquidity.

• Bond Protocol and Baseline protocol build off of the initial issues around Olympus to create unique capital bootstrapping techniques for protocols.

• Ribbon is using their firehose of option vaults to drive retail volume to their L2 derivatives exchange.

These yield games are worth playing because of the new directions that we can explore, but I do like to think we’ve almost come full circle to TradFi, which has a similar practice of selling complex structured products in the name of easy yield to HNWI and making boatloads of money.

Stay safe out there, especially from yield tricks :)

A social network scales it’s value exponentially as new users join, a phenomenon known as Metcalfe’s law. We can see a similar multiplicative rule with this idea of ‘velocity’ in crypto.

Now the concept of velocity and money isn’t new.

In a simple view of macroeconomics, the velocity of money refers to the relationship between bank reserve ratios and the amount of circulating money – since credit acts as a multiplier on the M1 (Fed 'brrr' money) to create M2 (Bank deposits, bonds) – money in the real economy.

If there is $100 in M1 and the reserve ratio is 20%, the total funds that can be lent out is $80, which can be deposited, lent out again, etc… converging to a point where the M2 is $500 ($100 in M1 + $400 in credit)

There are various other factors that make this more complex such as consumer confidence – but it’s a good lens to view how we can have more value in a system by pulling a lever without putting more money in the form of the money supply.

However, with the programmable nature of crypto and the ability to do seigniorage (aka mint new money), this opens up different ways for how this velocity can change.

One of the key insights about this velocity is that most successful products in crypto generally have a high velocity, pared with intrinsic PMF.

This is a little abstract, so I'll try to break it down:

FriendTech:

Friendtech works by allowing users to buy and sell keys against a bonding curve. The velocity of this system is high since guaranteed liquidity ensures that there is less loss external to the system.

The only fees in place are a 5% fee for the creator and a 5% fee for the platform. While liquidity isn’t lent out like it is with the economics example, this 10% total fee limits velocity since value is now leaking externally.

However, velocity is high otherwise, since participants are rolling their gains into other FT keys, or at least keeping their keys – keeping velocity high. The points system recognizes this and rewards buying of keys to keep the velocity high.

To illustrate this point further, suppose there was a competitor called CoinTech that was entirely based on coins and didn’t use a bonding curve and used AMM liquidity instead

The velocity on this system is much lower, as even though the net trading fees might be much smaller, things like dumping, premine, sniping, heavily reduce the velocity as value flows out of the system – reducing the velocity of money and the success of the overall system.

Pound for pound, the organic usage of both could be the same, but since FT has a much higher velocity – it’s able to succeed.

BTC (and ETH) vs Altcoins

BTC and ETH both have strong forms of PMF – BTC as an SoV, and ETH as the gas token.

Both have very high velocity – BTC often has the deepest liquidity and greatest amount of institutional integrations – and ETH much the same, with an entire ecosystem of LSDs around unlocking value for ETH.

While many altcoins have low PMF and low velocity, TRX, the native token of Tron is a great example of a low velocity ecosystem but a good PMF.

The PMF for Tron is strong – we’ve seen record amounts of usage from all the transactions on the platform and fees that have even surpassed Ethereum as of late.

However, a centralized supply with an extractive core team, along with significantly weaker liquidity and adoption mean that the velocity is much lower. No one is staking or building on Tron.

Perpetuals vs Options

The PMF for perpetuals is pretty obvious: being able to take extreme leverage on a small account is really attractive – especially for retail, and hedge funds looking for deep liquidity.

The velocity is also very high – the net cost of creating a new contract is low, and the UX for perps is very good, and participants often continue rolling their gains into buying more perps.

The PMF for Options is also strong: Miners and other institutional participants want to hedge their exposure.

The velocity is significantly lower compared to perps – the longer term nature of these contracts, lack of retail, and overall lower degeneracy makes for much lower velocity for options.

Conclusion:

Overall, viewing success as a factor of velocity is helpful as a frame of reference for evaluating why or what makes a crypto product successful.

Specifically,

• pinning down where the intrinsic PMF is from

  • Are people genuinely interested in chatting to influencers in a more private setting? – in the case of FT

• figuring out factors that influence velocity – and how the velocity is tied to the PMF

  • A points system in the case of FT is a key driver of velocity as it feeds into the intrinsic PMF - buying keys encourages people to talk to others

  • Social pressure around (3,3) where users don’t sell each others keys increases the wealth effect – increasing velocity

  • Taxes decrease velocity – but enough of the proceeds are being rolled back into buying more keys – offsetting this change in velocity.