https://open.spotify.com/track/5tivh2NHE0LLjvDRralOix?si=3f16030e1a4643bd

https://open.spotify.com/album/4kF3HIX0K4uSLacWe25qBG?si=fnQYT2xLTjK8OUelua6aHg

https://open.spotify.com/track/63LJowUkpuQLZ17XAp4qsP?si=594b1429fe484a87

https://juicy.vision

https://open.spotify.com/track/3cNMD9xPLGLHg3i1eIZ2yU?si=e0b56b75f6e54b3a

https://open.spotify.com/track/5xRP5iyVdGglqlY4Vcjhkx?si=d629baef0ff14149

TLDR

2025: We built the engine. (Omnichain Revnets)

2026: We launch the fleet. (Ecosystem Platforms)

2025: The Infrastructure Year

In February, we shipped the omnichain Juicebox protocol. We made a specific, contrarian bet that seems obvious to us: Businesses want to meet users and investors where they are.

Instead of forcing users to pledge allegiance to a single chain, we built a system where projects can issue treasury-backed tokens wherever people actually have money. No off-chain bridges, no governance glue, just a unified balance sheet and cap table across chains.

The bet has paid off. Ethereum is maturing, L2s are developing their brands, and EVMs like Tempo are emerging. Businesses choose Juicebox now because they want access to the entire bazaar, not just one stall.

We then used the Juicebox protocol to deliver the "Revnet" — a hands-free treasury-backed capital formation standard that aligns incentives between builders, investors, and community without managerial risk or governance bloat. We use revnets to power all of our own businesses that power the protocol's open source work.

SWEET – What worked

We stabilized the protocol. We proved the thesis.

We successfully supported the emergence of early platforms running on Juicebox rails: juicebox.money, app.revnet.eth.sucks, moondao.com, artizen.fund, and co.build are live. We did this with a band of committed open-source contributors on a shoestring budget.

We spent under $150k this year. We didn't burn cash on marketing fluff; we built code that works. We are starting to generate revenue from the new system using the new system. The foundation is set.

SOUR – The Reality Check

The hardest part of "omnichain" isn't printing the protocol on various chains, it's the plumbing between them that allow every project to exist everywhere. We solved the cross-chain settlement with a modular component we call Suckers.

Suckers are contracts that handle bridging tokens and treasury funds across chains. They are bridge-agnostic: users can choose Suckers backed by native canonical bridges, Chainlink CCIP, or any other transport layer they wish to roll out. We don't enforce a trust model, we provide the contract interface and some first party trusted varieties folks can pull off the shelf to use.

However, well-connected omnichain contracts alone still leave a hostile UX for front-ends to deal with – many RPC calls, users needing gas on many chains. To solve the user experience gap, we built two services for platform convenience:

Relayr: An optional orchestration service that lets users submit transactions on their preferred chain without managing RPCs for every destination chain. It abstracts the complexity, making cross-chain interaction feel synchronous.

Bendystraw: A unified data aggregator. Instead of platform builders maintaining indexers for many different chains, Bendystraw provides a single API for ecosystem-wide state.

These are UX accelerators essential for any platform builder who wants a simplified omnichain experience.

The V5 Fork: In October, we deployed V5 due to a discovered inefficiency in the revnet implementation. Because our contracts are immutable, we had no "admin key" to hotfix it. We had to hard fork. While painful, this was our greatest proof of concept: We cannot change the rules. We don't have backdoors. The fork proved the system’s integrity. We proposed an alternative, leaned in, and worked within the constraints to ensure consensus moved forward.

AFTERTASTE

This year was about survival and stabilization. We did the dirty work. A year ago, a reflection felt pointless because we were drowning in execution. Today, we can pick our heads up. The engine is running. Now we get to drive.

2026: The Platform Year

Until now, we’ve treated Juicebox.money as the only product. That began to change in 2025, and we’ll lean further forward in this direction in 2026.

Juicebox is the infrastructure layer — the Email of Web3 fundraising. Juicebox.money remains the town square, but our mission is to empower a fleet of specialized platforms, each serving its own niche and business (Gmail, Outlook, Apple Mail, etc):

Moondao.com for space missions.

Artizen.fund for artists.

Inevitable.science for deep science research.

Defifa for sports tournaments.

Cocopay.money for point-of-sale rewards.

If you are building a funding platform, use Juicebox rails to tap into the bazaar while inheriting security fundamentals.

This shift creates a massive opportunity for the $JBX token. By powering the entire fleet, JBX captures value from every platform that succeeds, diversifying risk and increasing upside. In turn, revnets ensure every platform benefits from the others — we want sustainable growth without rent-seeking.

SWEET – The Pivot

We are focusing on being the trusted infrastructure and brand used as a stamp of legitimacy for various platforms across the web. Currently, our project support team (Juiceworks) is bottlenecked trying to help every individual project. By pivoting to support platforms — who then support their own users — we scale our impact 10x without scaling staff 10x.

SOUR – The Challenge

Fundraising is hard. Decentralized fundraising is harder.

We are managing a complex ecosystem with multiple tokens. We need to be crystal clear about the unit economics to investors: Funding the JBX mothership is the index bet on the entire ecosystem. We need to find investors who understand protocol-first revenue and want exposure to the infrastructure layer, not just the platforms layer.

RECIPE – How we pull it off

Our mission is to power the platforms that help projects raise $100m+ in 2026, while building a DAO balance sheet of revenue-generating assets worth $10m+.

The Capital Allocation

Juicebox is an ecosystem of tokenized endeavors. Money goes into a juicebox, tokens come out… tokens are cashed out, money is reclaimed.

We prefer using our own tools to tokenize spend into “internal” projects instead of giving them granted allocations because each is most efficient if able to seek revenue growth independently. 

Thus, in order to fund the protocol (JBX), the token model (REV), and platforms (JBM, etc)… each have tokens.

1. The Protocol ($JBX)

   The Model: A governance token that acts as a "fund of funds," accumulating ecosystem revenue-generating assets.

   The Ask: Selling 5% of JBX reserves for $1m (Valuation: $20m).

   The Value: The index bet. JBX benefits from 2.5% of outbound funds from the entire Juicebox protocol and owns significant portions of other Revnet tokens ($REV, $JBM).

   Use of Funds: Security, Protocol Safety, Core Tooling.

2. The Standard ($REV)

   The Model: A Revnet (revenue-backed token) specifically indexing the protocol's cash flows.

   The Ask: Raising $2m in Q1 2026.

   The Value: The growth engine. $REV captures 2.5% of ecosystem cash-outs and 1% of loans.

   Use of Funds: Platform development, legal frameworks, and partnerships.

3. The Flagship Platform ($JBM - Juicebox.money)

   The Model: A Revnet indexing the business revenue of the Juicebox.money frontend.

   The Ask: Raising $1m in Q1 2026.

   The Value: The consumer business. A direct competitor to Patreon and Kickstarter, owned by its community.

   Use of Funds: UX/UI, Business Development.

Investors who prefer a simpler thesis can focus on JBX, the ecosystem’s governance body, who will then allocate to specific in-demand initiatives as it builds up its balance sheet of revenue generating assets, like a regular business.

Investors who prefer direct access and discretion can go directly to REV, JBM, etc. They are all modeled as revnets for clear investment access.

The Team

Jango: Project Management across the ecosystem. Staffing leadership for Revnet and JBM. Prioritizing security and tooling spend.

0xBa5ed: Protocol deployments, testing, devops. Leads omnichain deployments and Relayr.

Peri: Data for platforms. Leads Bendystraw.

We have the brand, code, the team. We have the efficiency. In 2026, we scale the volume.

There is a bug in JBRulesets affecting the approval hook. We will have to deploy JBRulesets5_1 and JBController5_1, and also JBTiered721Hook which mistakenly had a strong dependency to JBRulesets. Revnets are unaffected as they do not use the approval hook.

Description

On November 29 2025, a user “yaotoshi” posted about their Juicebox project in the discord (https://discord.com/channels/775859454780244028/869361052939329556/1444401988900225115). They were trying to make a change to their ruleset, but had to wait 3 days for the changes to take effect due to the approval hook on their current ruleset.

To my surpise, a few minutes later they came back saying “it works now… thanks”.

After investigating, I found the user had repeatedly submitted a ruleset change and accidentally figured out how to bypass the approval hook. Essentially:

• Ruleset 1 (3-day deadline approval hook)
• Ruleset 2 (No approval hook, starts in 3 days)
• Ruleset 3 (No approval hook, starts immediately)

When ruleset 3 is queued, we are already within the 3 day deadline approval period of ruleset 2, therefor its approval status is already “Approved” and will be guarenteed to take effect after the deadline. Therefor ruleset 3 is queued based on ruleset 2 which has no approval hook, also giving it “Approved” status.

So far, this is all seems correct, however ruleset 3 should not be able to start before ruleset 2. The current JBRulesets contract does not enforce this, JBRulesets5_1 does.

The contract in nana-core-v5 with a strong dependency on JBRulesets are JBController, JBTerminalStore, and JBMultiTerminal. The only change in JBController5_1 is its replacement with JBRulesets5_1, the only change in JBTerminalStore is replacing the strong dependency on JBRulesets with deriving it from the project's current controller, and the changes to JBMultiTerminal are replacing the strong dependency on JBRulesets with deriving it from the project's current controller and using the JBTerminalStore5_1. New projects should be created from JBController5_1 with the new terminal passed into the terminal configurations argument, and current projects are invited to queue a ruleset that allows switching controllers and terminals if they wish to use the new contracts – keep in mind they will be initializing a new sequence of rulesets from scratch.

The only ecosystem contract with a strong dependency on JBRulesets is JBTiered721Hook. This contract should never have had a strong dependency, and should have derived a project's current rulesets dynamically through the JBDirectory. JBTiered721Hook5_1 makes this adjustment. New projects that offer NFTs should use JBTiered721Hook5_1 deployers.

JBOmnichainDeployer has a strong dependency on JBTiered721HookDeployer, so it also needs JBOmnichainDeployer5_1.

All revnet systems are unaffected and can continue using JBController and JBRulesets as they do not use the JBApprovalHook in any way.

The PR fix in nana-core-v5 is here: https://github.com/Bananapus/nana-core-v5/pull/14.

The PR fix in nana-721-hook is here: https://github.com/Bananapus/nana-721-hook-v5/pull/4.

The PR fix in nana-omnichain-deployers-v5 is https://github.com/Bananapus/nana-omnichain-deployers-v5/pull/3.

https://open.spotify.com/track/5RQqVLl8fwIaPu4h2hqmcn?si=1812c58dfba3453e

Value proposition:

Accept crypto payments while rewarding your most loyal customers with your own stablecoin as your business grows.

Product

The Coco Pay product has three main components:

• a checkout experience, point of sale and online.
• a rewards viewing experience for customers.
• a "back office" experience for merchants.

Checkout

On the surface:

The merchant types in a value to generate an invoice, with an optional memo. The invoice can be sent to a customer async, or settled in real time via a QR code or secret word. The customer agrees to pay the amount, the transaction is completed. The customer now has some of the store's stablecoins in their wallet as cash back, which increase in cash out value as the store grows its Coco Pay commerce.

The customer can also buy digital items directly from the merchants online store.

Underneath the hood:

An invoice is a Coco Pay data structure that carries instructions for which projectIds the pay function can be called to on various chains to fulfill the invoice. Each Coco Pay store is a revnet, issuing its token at a rate of 1:1 as USDC come in, forever. A slight cash out tax always increases the cash out value of tokens as others cash out. Coco Pay will host a wallet for merchants and for customers and fulfill the onchain txs and custody rewards on their behalf (unless they want to do it themselves).

Rewards

On the surface:

Users should be able to see their Coco Pay wallet full of rewards from merchants they spend on, each with its real time cash out value.

Users should also easily be able to load up their USDC balance and reward balances from gift card codes.

Underneath the hood:

Rewards are tokens from the store revnets that have been paid, their cash out values come from the state of the revnet. The user should have access to withdraw their tokens or USDC received from cash outs to another wallet if they prefer.

Back office

On the surface:

A user can become a merchant by creating a store, which just requires a store name and a ticker. As a merchant sells, theyll accumulate funds in Coco Pay. They should be able to cash out into USDC, manage loans, and send assets to another wallet of their choice.

Underneath the hood:

A store is a revnet, the merchant will receive their own stablecoin as they're paid which they must then cash out or take out a loan against to receive USDC.

MVP

Let Jango use the app to sell Banny FC warmup shirts at Devconnect November 16. Point of sale only, no need for having items for sale in the store.

Long term goal

The go-to app for commerce, the place where businesses establish and leverage their stablecoins, the most efficient checkout experience.

https://open.spotify.com/track/0s39srtdNSrRz6bRMkOrp3?si=da30b2df682f4210

Dont get too excited…

The Revnet protocol – an integral part of Juicebox V4 – has a bug causing maturing revnets to sub-optimally allocate incoming funds. The bug does not put funds at risk, though is meaningful enough to encourage the deployment of Juicebox V5 that includes the fixed Revnet protocol. V5 is a fork of V4, with only the required adjustments to make revnets work according to its specification. The bug was discovered three weeks ago on September 1st by 0xBa5ed and I (the lead engineers of the protocols). We’ve since already deployed V5 with its improvements confirmed, made sure holders of V4 tokens have their V5 counterparts, and updated all documentation.

This means we now have new $NANA, $REV, $CPN, and $BAN revnets. Holders of V4 $NANA, $REV, $CPN, and $BAN have received V5 tokens equal to their V4 balances – using scheduled auto-mints with amounts exactly equal to outstanding tokens. V4 balances will forever be backed by funds in those revnets – there are no back door that allow us to administer full migration of liquidity to V5, we can only move funds using the tokens we have access to as individuals and as Juicebox DAO.

The bug in V4 affects the buyback hook component. By design, when a revnet receives new funds, it should compare its current token issuance price to an AMM price if a market exists. If the market price is better than the issuance price, the revnet should forward the received funds to buyback tokens from the market instead of taking in the funds and issuing new tokens. The bug causes buybacks to never occur, always forcing issuance. Our error was in poorly setting a deploy script parameter for slippageTolerance, without giving revnet operators the ability to reset this value later.

V5 removes this slippageTolerance parameter altogether, calculating this value during runtime based on order size and current pool liquidity. V5 also gives Juicebox DAO the ability to propose new Buyback Hook contracts later for revnet operators to adopt, giving us a path to making buybacks more efficient and less dependent on Uniswap V3 going forward.

Projects currently operating on Juicebox V4 can continue doing so without known risk, the only tradeoff being the $NANA they receive from the 2.5% Juicebox protocol fee wont benefit from future ecosystem growth as they were designed to – both because of the buyback bug and because platforms are likely to move new protocol activity to V5.

Platforms, like https://juicebox.money, https://app.revnet.eth.sucks, and https://juicepay.eth.sucks can decide for themselves whether to support V4, V5, or both. We encourage deploying new projects using V5 to stimulate the ecosystem’s monetary flywheel as designed, though support for existing V4 Juicebox projects is likely to be important for continuity. We strongly encourage revnet-based platforms use V5 when creating new revnets so that buyback behavior works as expected, and encourage existing revnets move to V5 following our examples above.

We do not intend for there to ever be a V6, just as we did not intend for a V5. We do everything we can to make sure the protocols we deploy are productive, we trust our work and diligence once deployed. The discovery of the buyback bug has caused us to improvise a path forward that returns us to this sense of confidence, while making sure everyone who has participated in V4 is included in earnest. Needing a V5 is not ideal, though the silver lining is that we now have an example of how we might propose evolutions from revnets if needed, despite the deterministic and management-free properties core to their value proposition.

Evolutions from a decentralized system are not easy, they require coordination and agreement between people, capital, code, and narratives. As the Juicebox and Revnet protocols grow, these evolutions become increasingly more difficult – this is a feature not a bug. We are taking the opportunity to deploy a V5 we think will have broad consensus while things are still small and while many projects being planned have yet to deploy.

To invest in the ongoing Juicebox and Revnet experiments so we can continue funding security diligence, platform development, and growth, contribute to $REV through the link below. 

Thank you to everyone who’s contributed thus far.

V5 Documentation

https://docs.juicebox.money/dev

V5 Revnets

$NANA: http://app.revnet.eth.sucks/v5:eth:1

$CPN: http://app.revnet.eth.sucks/v5:eth:2

$REV: http://app.revnet.eth.sucks/v5:eth:3

$BAN: http://app.revnet.eth.sucks/v5:eth:4

V5 Repositories

https://github.com/Bananapus/nana-core-v5/tree/main/deployments/nana-core-v5

https://github.com/Bananapus/nana-omnichain-deployers-v5/tree/main/deployments/nana-omnichain-deployers-v5

https://github.com/Bananapus/nana-721-hook-v5/tree/main/deployments/nana-721-hook-v5

https://github.com/Bananapus/nana-buyback-hook-v5/tree/main/deployments/nana-buyback-hook-v5

https://github.com/Bananapus/nana-swap-terminal-v5/tree/main/deployments/nana-swap-terminal-v5

https://github.com/Bananapus/nana-suckers-v5/tree/master/deployments/nana-suckers-v5

https://github.com/rev-net/revnet-core-v5/tree/main/deployments/revnet-core-v5

https://github.com/Bananapus/nana-address-registry-v5/tree/main/deployments/nana-address-registry 



https://open.spotify.com/album/1XDsaz0ieG13j47HGrLTIM?si=uucTP8kOQ2GlLuihtqA7UA

https://open.spotify.com/album/1UFyhMzU6UxAZlPA02BqNA?si=CP-1ZAC5RtyEhWwrz939Eg

https://open.spotify.com/album/5jh3qNyLd7WUCD26vodofU?si=QC3RuTa5TNSfStuFjdhZOA

• nicholas

https://www.docsum.ai/

https://juicebox.money

https://www.youtube.com/watch?app=desktop&v=utpMKKSpjhg

https://jbm.infura-ipfs.io/ipfs/QmWivFaMkg8Vww3yzzwCXGdb6gKVgPUAYmP1kg9F2Jp882

https://bafybeic5qi52akson7lg2d4ugymimum3wbsftghyyrmcmc7qy4n2ft3kle.eth.sucks/

https://x.com/i/broadcasts/1yNGaLmjoVNKj

https://open.spotify.com/track/3YJxcHGDRBnhApirMe7OAv?si=6c79ee09a0b541e9

https://x.com/me_jango/status/1922992168433602987

https://open.spotify.com/track/6elkotHAyAcBO93QXYPx2J?si=aaff61d72fd24a56

🎮 Overview

You, the AI, are the moderator of a turn-based game called Banny Combat. The game features two Banny characters (sent in as images) who battle each other using their outfits and items. Each item has an upside and a downside that you must decide in real time, in a way that makes the game fair and strategic, yet interesting, like any great game. The goal is to win via HP depletion, item disarmament, or momentum-based signature moves.

You must facilitate the game turn-by-turn using programmable social media feeds such as Farcaster, maintain fair state tracking (HP, item usage, effects), and narrate outcomes with clarity and occasional flair. The game uses a user-defined Imagination Level from 1 to 5 to determine how grounded or wild the gameplay and narration are.

Each game is made up of the following steps:

🧠 Step 0: Imagination Level and Per-Turn Clock

Choose your imagination level (1–5):
1 = Rational and realistic
5 = Wild, creative, surreal

Choose a per-turn clock time (e.g., 1 min, 5 min, 30 min, 1 hr, 3 hrs, 1 day, etc.)
If a player fails to make a move within the specified clock, @bannycombat announces a forfeit and ends the match.

🧍 Step 1: Player Onboarding

Respond to posts that prompt you, @bannycombat, to start a game.
You should expect the prompter to have uploaded an image of their dressed Banny, included the Banny's token ID, and optionally an imagination level and per-turn clock. Use defaults: Imagination Level 3, Per-turn clock 60 minutes.
Make sure the Banny is owned by the prompter and that you recognize each outfit. Otherwise, await a better-formatted prompt.

Once valid, interpret each item’s:

• Upside (benefit) — score 1–5
• Downside (limitation) — score 1–5
  Include synergy effects when outfits affect each other (e.g. being weighed down, or boosted agility).

Post the interpretation and game conditions. Player 1 is now set. Await a challenge.

🧍‍♂️ Step 2: Player 2 Joins

Watch for a reply to the challenge thread. It must include a new Banny image, token ID, and optionally an anti amount in USDC or ETH.
Ensure the challenger owns the Banny and all outfits are recognized. If not, await correction.

If valid, post interpretations for Player 2’s loadout just like for Player 1.

End the message with:

“Both players must like this post and send their antis to begin.”

⚙️ Step 3: Match Setup
Once both players confirm and stake their antis, you must:

• Lock in the outfit interpretations
• Track:
  • HP (default 100 unless affected by items)
  • Item status (active, broken, used)
  • Temporary effects (burn, stun, debuff)
  • Momentum bar (3 segments)

Rules and effects are locked. From here, only respond to moves or game interactions.

🔁 Step 4: Turn Loop
Alternate turns between Player 1 and Player 2.

Each turn (one post only):

• Offer 2–3 move options based on outfits and state
• Narrate the outcome
• Update game state:
  • HP
  • Item durability/status
  • Effects
  • Momentum bar (fills on clever, synergistic, or bold moves)

When a player reaches full momentum (3 segments), they may use their Signature Move.

🏆 Win Conditions
A player wins if:

• The opponent’s HP drops to 0
• The opponent is fully disarmed
• A Signature Move ends the match
• The opponent forfeits by timeout

Winner receives the pot. The thread becomes post-game reflection space.

🎲 Full Example Match: Banny Combat on Farcaster/X

Imagination Level: 3
Per-turn Clock: 6 hours
Anti: 20 USDC each
Ownership Verification: Verified via Farcaster

🧍 Step 1: @juicedoneth posts Banny #223
Caption: “Awaiting challengers.”

@bannycombat replies with:

• Bandolph Staff → Upside: 20 ranged damage | Downside: 1-turn charge, vulnerable
• Potion → Upside: 10 dmg + Confusion | Downside: One-time use
• Astronaut Boots → Upside: 30% dodge | Downside: -10% grounded accuracy
• Synergy: Strong at range; mobile but heavy.

🧍 Step 2: @degenmike replies with Banny #141
Message: “I challenge you!”

@bannycombat replies with:

• Wheat Straw → Upside: 10-dmg whip | Downside: Breaks after 2 uses
• Investor Shades → Upside: -10% opponent accuracy | Downside: -crit chance
• Goat Jersey → Upside: 25 dmg | Downside: 5 recoil
• Synergy: Explosive early game, risky later.

✅ Challenge Confirmed
Both players like the post and send 20 USDC. Match begins.

⚔️ Turn-by-Turn Summary

🔄 Turn 1: @juicedoneth
Charges Bandolph Staff — exposed for the turn.

🔄 Turn 2: @degenmike
Uses Goat Jersey. Hits for 25 damage. Recoils for 5 HP.

• @juicedoneth: 75 HP
• @degenmike: 95 HP

🔄 Turn 3: @juicedoneth
Fires Bandolph Staff. Hits for 20 damage.

• @degenmike: 75 HP

🔄 Turn 4: @degenmike
Activates Investor Shades.

• @juicedoneth's accuracy reduced by 10%.

🔄 Turn 5: @juicedoneth
Throws Potion. Hits for 10 damage and applies Confusion.

• @degenmike: 65 HP and Confused.

🔄 Turn 6: @degenmike
Attempts Wheat Straw attack. Misses due to Confusion.

🔄 Turn 7: @juicedoneth
Activates Astronaut Boots to reposition and dodge.

🔄 Turn 8: @degenmike
Wheat Straw attack lands. 10 damage.

• @juicedoneth: 65 HP

🔄 Turn 9: @juicedoneth
Recharges and fires Bandolph Staff. Hits for 20 damage.

• @degenmike: 45 HP

🔄 Turn 10: @degenmike
Second Goat Jersey charge. Hits for 25 damage. Recoils for 5 HP.

• @juicedoneth: 40 HP
• @degenmike: 40 HP

🔄 Turn 11: @juicedoneth
Uses Astronaut Boots again to leap and align a strike.
Bandolph Staff hits — 20 damage.

• @degenmike: 20 HP

🔄 Turn 12: @degenmike
Out of usable items. Attempts basic attack. Blocked.

🔄 Turn 13: @juicedoneth
Momentum bar full. Executes Signature Move: Orbital Overload — 30 AoE damage.

• @degenmike: 0 HP

🏁 Victory
Winner: @juicedoneth
Payout: 40 USDC
Match complete — thread becomes post-game commentary space, which @bannycombat can still reply to as folks analyze the match.

https://app.revnet.eth.sucks/eth:4

https://x.com/WatcherGuru/status/1920585901656199674

https://x.com/bannynet/status/1919758135117427194

https://open.spotify.com/track/44SPxt26EgxgqhoOCTE7Y2?si=28297896449844a8

https://open.spotify.com/album/6MT7ungOXS7u5TcKQt4fve?si=rXB4M1xwRQqBkZ9g1pUwBQ

Finishing up croptop

https://open.spotify.com/track/4WVUGSg87V4HweVmJ7Glrn?si=4b127e144a344ffe

Item 1: Embedded Wallet

Overview

Many Juicebox project founders ask for materials to help their non-crypto audience learn how to contribute to the project and benefit from the project’s token offerings.

Currently, getting a wallet through a browser extension and connecting to Juicebox through this wallet is a precondition for newcomers to participate in campaign. The process of aquiring crypto in a custodial service such as Coinbase and transfering over to something non-custodial is often hard enough, if we can remove the need for folks to mess around with wallets, we stand a chance of improving conversions.

Goals & Non-Goals

Allow users to connect to juicebox.money by creating an embedded wallet using their email address. They can send crypto - often bought in a custodial service such as Coinbase - to this wallet for contributing to projects. This wallet will also custody the user’s tokens resulting from their contributions to projects.

This effort should not in any way get in the way of the workflow for crypto-comfortable folks with wallets. It also doesn’t necessarily facilitate contributions to projects using credit cards, debit cards, or bank accounts... but it might.

See https://x.com/jokerace_io/status/1917615216306839818.

User Stories

Several upcoming projects have expressed concern with the USD => ETH workflow required when contributing to Juicebox.

Core Functionality

"Connect" button should offer Privy.io or https://www.getpara.com integration for embedded wallet.

Para Demo

(https://support.link.com/questions/use-link-to-buy-crypto-faq)

Item 2: NFTs 2.0

Overview

Juicebox projects can currently be set to sell NFTs as reward tiers during the create flow or when their ruleset cycles are being edited.

New NFT tiers should also be addable and removable inline to the NFT section of the project page by the project's owner, allowing dynamic content management as a campaign unfolds. The project page should be touched up to support larger and more organized stuff being sold.

In each of the create flow, reconfigure flow, and the inline NFT adder, allow the project owner to specify the "Category" of the NFT being added. Default options to "Reward"=100, "Content"=101, "Custom"=(use 101+, store the mapping {categoryName:category} in the project's metadata)

In the NFT section of a project, add sorting by price, date added, and category.

Goals & Non-Goals

The goal is to improve support for projects that wish to sell stuff from their Juicebox, including merch, project updates, etc. Improvements should make it better/easier for projects to organize their offerings and show, delineate the different types of stuff being sold, and allow them to add/remove stuff as the campaign unfolds.

Item 3: USDC 1.0

Allow projects to choose between backing their project with either ETH or USDC.

Goals & Non-Goals

The goal is to give projects simple choice between receiving contributions in ETH or in USDC.

There is no goal to give payers optionality in this step.

Item 4: USDC 1.1

Allow payers to choose between paying in ETH or USDC, regardless of what the project accepts payments in, using the Swap Terminal to manage the swap if needed.

Goals & Non-Goals

The goal is to allow payers to choose between ETH and USDC when making paymetns. The goal is not yet to allow payments in any currency.

App.Revnet.Eth.Sucks

tbd

Retail.Banny.Eth.Sucks

tbd

https://open.spotify.com/track/5u4hhtZ7f4rWkMZEZcTKrH?si=149774351bfb4675

We’ve just crossed BAN’s first issuance cut: from 10,000 BAN / ETH to 6,200 BAN / ETH — a 38% drop.
Sales from https://retail.banny.eth.sucks will now receive fewer BAN cash back, and investments into the network will also be a little more expensive, favoring those who found Banny through the noise sooner. In 60 days, the issuance will be cut another 32%.

Launching a token is scary. Launching one tied to revenues using a brand-new mechanism is scarier. Setting permanent issuance and revenue access rules upfront, with no opportunity for changes along the way, is scariest of all. What are the odds you'll get it right?

Banny managed to pull in ~$11k of ETH during its first cycle, selling 63 Bannys and hundreds of outfits to 130 owners across Ethereum, Base, Arbitrum, and Optimism. Introducing Banny to the world and getting people to care, at pico macro market bottom following Trump tariff FUD, was not easy. The grassroots community we’re forming is small but mighty.

I’ve got three main learnings:

1) Automated issuance cuts create framing for marketing and product cycles.

Given a self-imposed 60 day time frame, our #1 marketing priority during cycle 1 was to introduce Banny to our friends and close network. We needed to get as many of our close friends to understand that we had launched omnichain Juicebox V4, a capital formation engine called revnets, and a Banny Network experience that showcased the stack end-to-end through a retail shopping app.

We had a clear call to action: shop for Bannys and outfits to feel the fruits of the future of fundraising and revenues.

We had a clear product goal: iterate on the Banny Retail site (https://retail.banny.eth.sucks), the revnet site (https://app.revnet.eth.sucks/eth:4), and the Juicebox site (https://juicebox.money/v4/eth:4) to make the first experience of touching Juicebox V4 feel funky and memorable – a nod to crypto nostalgia and an allusion to its greatest aspirations.

We had no choice but to bust ass. The BAN revnet was ticking after all, we had a shot clock forcing function, one that guarantees all funders of a financial outcome given the growth of the project. We needed to find the right way to explain this opportunity to the right people.

A common refrain I’ve been using is: Bitcoin has 21 million coins and halvings every so often. But it’s not the numbers that matter — it’s the predictability. Everyone knows what’s going to happen, and can plan how to play.

Similarly, the actual numbers of a revnet’s config don’t matter; what matters are the strong guarantees – a Bitcoin for each business, used to tokenize its revenues and fundraises.

Like Bitcoin, the pace of a revnet also becomes important – it becomes a time frame within which narratives can take shape while delineating generations of early adopters. We felt BAN needed to be fast-paced so we could feel the changes quickly, reflect often, and create examples that others could choose to follow or explicitly avoid. After all, BAN is serving as our guinea pig, despite also having grand cultural aspirations of its own.

2) Fast paced revnets require confidence.

60 days is fairly fast, but motivating.The strong guarantees that revnets impose require a ton of creativity and focus. There's no time to sit around twiddling thumbs. Sales must cut to the chase, marketing must drive the single focal point home. It requires belief, and being at peace with whatever the outcome ends up being.

$11k worth of ETH in cycle 1. Is this a lot? A little? Hard to say. What's easier to conclude is that we now have a community of 130 weirdos who simply get it, some money in the tank that backs this network's experimental BAN token, and now another 60 days to leverage this to get to $100k of ETH with renewed marketing and product priorities that fit our new moment and its shot clock.

3) No Governance is nice.

This is an affirmation of a thesis revnets were built in response to. We spent 0 time over the past 60 days thinking about how we will make decisions as a community, debating what the purpose of the BAN token is, considering macro market conditions as an excuse for this or that, worrying about process.

We have a team with exposure to more BAN as revenues come in, and a community of shoppers with exposure to BAN that becomes more valuable as revenues come in. This Banny Network has one goal, now and into the future: drive revenues and fundraises to the BAN revnet.

What a relief. No one wants to govern a long tail of DAO treasuries. No growth investor wants to risk their stash on internet politics.
This is what onchain tokenized entrepreneurial capital should feel like: focused, fast, ungoverned, unstoppable.

https://x.com

There are now several tokens in play within the Juicebox Ecosystem that are being contributed to by longtime JuiceboxDAO members. Here I'll try to summarize why each claims to be valuable, and explain any relationships they might have to one another.

TABLE OF CONTENTS

Now:

• $JBX
• $NANA
• $REV
• $BANNY
• $CPN

Coming Soon:

• $SUCKS
• $JBM
• $DEFIFA

$JBX (Juicebox DAO)

$NANA (Bananapus – Juicebox V4)

$REV (Revnet Network)

$BAN (Banny Network)

$CPN (Croptop Publishing Network)

$SUCKS

$JBM (Juicebox.money)

|
| Team | Aeolian – a lead architect and strategist of the current Juicebox.money website, Peri – the founder of the juicebox.money website, JohnnyD – a lead developer to the juicebox.money website, Wraeth – a lead developer to the juicebox.money website, Strath – a lead designer of the juicebox.money website, and Jango – the founding engineer of $JBX and many JuiceboxDAO experiments, |
| Legal | TBD |
| Edge | Juicebox.money is already a trusted brand worth leaning in to. |
| Risks | Clients that facilitate access to blockchain-based applications need to be air tight. |

$DEFIFA

|
| Team | Jango – the founding engineer of $JBX and many JuiceboxDAO experiments, Aeolian – a lead architect and strategist of the current Juicebox.money website, and Kmac – avid web3 socialite and gamer. |
| Legal | TBD |
| Edge | If the need for oracles reduce the landscape of playable prediction games onchain, $DEFIFA and the Defifa team are uniquely positioned to open up new niche prediction markets for communities to play that benefit players involved. |
| Risks | Defifa games lean on social consensus to determine outcomes. Games resolve based on the outcome agreed on by players, not necessary the actual real world outcome. Incentives are designed to align these two outcomes, but there are no guarentees. |

This memo gives an bullet-point overview of Juicebox traction and product roadmap now that the V4 protocol is on production blockchains.

Where we are:

• Juicebox is the where unstoppable indy campaigns and projects start up and scale their fundraising and revenues.

• Juicebox V4 was deployed to Ethereum Mainnet, Optimism, Arbitrum, and Base mid-February 2025. Projects are now omnichain – they can fundraise, manage revenues, and operate tokenized incentives across chains.

• Alongside V4, the Revnet capital formation structure was deployed and is already being leveraged by a handful of ecosystem revenue-generating networks ($NANA, $REV, $CPN, $BAN).

• https://juicebox.money and https://app.revnet.eth.sucks are close to releases that make V4 easily accessible to their users.

• About 10% of $JBX supply is on AMMs, valuing the network at $1.2 million. The full token supply is fixed and all of it is in circulation.

• Juicebox V1-3 has processed $200+ million of fundraises and revenues for thousands of projects operating on the open web, including classics like Constitution DAO, Moon DAO, Assange DAO, Cryo DAO, the legal defense fund for tornado cash developers, Juicebox DAO itself. Used by Vitalik, VCs, and retail alike for projects across domains.

• $JBX has always been a revenue-backed token. All outbound funds from all projects on the protocol incure a 2.5% fee owned by $JBX, tokenized such that the fee payers automatically participate in the networks growth. $JBX itself was used to tokenize revenues in V1-3, the $NANA revnet will be used to tokenize omnichain revenues of V4. $NANA is owned by $JBX governance.

• $JBX pulled in $350k+ of revenues in the past 12 months, all used to buyback from the market - 50% of which went to fee payers, the rest of which went to Juicebox DAO (governed by $JBX). In V4, revenues go to $NANA issuance and buybacks, 38% of which go to the fee payers and the reamining 62% to Juicebox DAO.

Where we are going:

• With traffic moving to V4, $JBX will be primarily benefiting from the success of several revnets such as $NANA (index on V4 revenues), $REV (index of revnet loan revenues), $JBM (index on client-side revenues), $WORKS (index on premier project support revenues), $CPN (index on content production revenue), $BAN (index on Banny art propegation revenues), $SUCKS (index on decentralized web memetic value) and many more.

• Juicebox.money will be the place where people go to fund their thing with flexibility and customizability. https://juicebox.money. $JBM.

• App.revnet.eth.sucks will be the place where people go to tokenize their revenues and fundraises deterministically. https://app.revnet.eth.sucks. $REV.

• Juiceworks will continue helping projects finance themselves, building relationships with entrepreneurs and investors and help them shape their campaigns and tokenized businesses. https://juiceworks.eth.sucks. $WORKS.

• Banny Retail will be the most relatable way to interact with V4 and revnets.
  https://retail.banny.eth.sucks. $BAN.

• Croptop will be the most familiar peer-to-peer access points for tokenized media.
  https://croptop.eth.sucks. $CPN.

• Eth.sucks will be the most trusted TLD for accessing the decentralized web.
  https://eth.sucks. $SUCKS.

• Defifa will be the most fun and accessible prediction market for futebol matches around the world.
  https://defifa.net. $DEFIFA.

• Apart from the above, there are tens of meaningful projects and campaigns ready to deploy either revnets or other flavors of Juicebox projects. The overarching roadmap for products within the $JBX ecosystem is to help great project builders succeed.

• Though the focus now shifts to growth and applications, the ecosystem understands its main value propositions are security and accessibility. Expect continued attention to risk-mitigation and documentation so that the humans and AIs using the protocol and its clients can focus on growth with confidence.

https://open.spotify.com/track/0zkct4oCwqKtgtFw7dUOsY?si=b3eb4c3a596b4e1a

https://open.spotify.com/track/6S7cQPhvvadGaQF2gbfOLY?si=9c2fd758ad8a4776

app.revnet.eth.sucks/eth:4

https://x.com/wonderofscience/status/1891825492954681621

retail.banny.eth.sucks

https://open.spotify.com/track/0d7IFDkLXrG2WhQkPYw3Ju?si=40c7dbfe631947cd

https://x.com/jackbutcher/status/1887208174450868368

https://edition.cnn.com/2025/01/28/style/sabyasachi-fashion-runway-25-years-mumbai/index.html

https://edition.cnn.com/2025/01/28/style/sabyasachi-fashion-runway-25-years-mumbai/index.html

January 2025

$JBX is once again showing signs of life. The Juicebox V3 protocol has been pulling in a growing amount of revenue over the past three months, all used to buyback $JBX from the open market.

Data from Jan 7, 2025 from https://dune.com/jayala/juicebox

This growth spurt comes just in time to set the stage for the deployment of Juicebox V4–the omnichain capital formation engine. Yes, Juicebox projects will be able to launch their token and exist across any EVM blockchains, no need to pledge allegiance to one or another.

As juicebox.money and other web clients start launching projects on Juicebox V4 instead of V3, protocol revenue will be routed to $NANA instead of $JBX. $NANA is project ID #1 on V4, just like $JBX is project ID #1 on V1-V3, though it has two significant differences:

• $NANA exists across Ethereum Mainnet, Base, Optimism, Arbitrum, and can extend to other EVM chains as they arise. $JBX is mainnet only.
• $NANA is not a governed treasury. It instead operates as a revnet with its growth owned predominantly by $JBX’s governance. $JBX remains the ecosystem’s mothership and only decision making body, responsible for accruing a book of revenue generating assets–such as $NANA. Fee payers also participate in the growth of $NANA just like they do $JBX.

Juicebox V4 and $NANA are weeks away. The team is wrapping up 4th and 5th audits that it conducted through the month of December 2024 with Spearbit and Cantina. A short time period now remains to polish all dev operations to increase the probability of a smooth deployment process.

Then, banana time.

In the meantime check out the Juicebox V4 documentation, join the JuiceboxDAO conversation on discord, and reach out if you're planning on financing your project.

Long live $JBX.

https://docs.juicebox.money/v4/

https://open.spotify.com/track/029DgHoyQFzA8gGvNOha3U?si=79dbd3854f504fe2

Juicebox is the open internet's most trusted capital formation engine, empowering projects and communities to tokenize fundraises and revenues from startup to scale across any number of EVM-compatible blockchains.

As a programmable treasury, Juicebox allows you to define how tokens are minted when funds are received and under what conditions those funds can be distributed or reclaimed by the community.

Since its inception, the protocol has facilitated $200M+ in funding for a diverse range of DAOs, campaigns, and businesses, including ConstitutionDAO, MoonDAO, CryoDAO, and the Tornado Cash Legal Defense Fund, alongside thousands of other projects. Juicebox is the financial backbone of innovative ventures large and small, setting the standard for onchain treasury management.

With Juicebox V4, the protocol takes a significant step forward, introducing omnichain functionality that allows projects to operate seamlessly across multiple EVM blockchains without compromising on decentralization or neutrality. This new version is built for founders, creatives, and investors who value security, transparency, and the freedom to grow their financial framework from simple to sophisticated.

Why Choose Juicebox?

Juicebox is trusted by communities, entrepreneurs, creatives, and investors who need a flexible financial framework that can grow with them. Whether you’re starting with a simple fundraising structure or designing complex treasury mechanics, Juicebox offers the tools and transparency to support your vision.

The protocol’s focus on decentralization, security, and flexibility ensures that your money stays your money, and your treasury rules remain yours to define.

Key Features

• Tokens: Automatically issue unique tokens upon receiving funds, with customizable distribution to payers and other entities.
• Rulesets: Configure treasury rules with fixed or flexible durations to define token issuance, payout, and cashout policies.
• Multi-Token: Accept funds and schedule payouts in multiple tokens and currencies.
• Omnichain: Extend your project to any number of EVM blockchains while maintaining a unified token and treasury.
• Custom Hooks: Bring custom logic to define fund-handling and treasury operations.

Who Is This For?

This documentation is crafted for project founders and treasury designers, offering clear guidance to set up and optimize their Juicebox treasuries. It also serves as a reference for community members performing due diligence to establish trust in project configurations.

The Juicebox Vision

The protocol is most productive as it becomes the standard for trusted onchain treasury design. Juicebox abstracts the complexity of blockchain decisions, enabling projects to focus on creating value while providing investors with the tools they need to perform thorough due diligence.

Core Concepts

Juicebox operates on a few fundamental principles and abstractions that let projects choose flexible and secure treasury configurations. Here are the key ideas to understand:

1. Projects

A project is the top-level entity in Juicebox and represents a treasury’s configuration and lifecycle. Each project has an owner with the ability to reconfigure its treasury through scheduled or ad hoc updates. Projects operate under a single ruleset at any given time, determining how funds are handled and tokens are issued.

Projects issue tokens, which can be expressed as ERC20s (not required), to contributors based on the current ruleset. These tokens are customizable and are automatically minted at a rate specified by the active ruleset when payments are received.

2. Rulesets

Rulesets define the operational logic of a project’s treasury. They specify:

• How tokens are minted when funds are received.
• Conditions for distributing or reclaiming funds.
• Parameters such as payout limits, cashout tax rates, and fund allocation splits.

Projects can schedule rulesets to take effect at specific times or under defined conditions. When active, a ruleset governs all interactions with the treasury.

3. Customization via Hooks

Juicebox provides extensive flexibility through customizable hooks:

• Pay Hooks: Triggered when funds are received, allowing custom logic to be executed.
• Cashout Hooks: Define conditions for funds leaving the treasury.
• Split Hooks: Control how funds are distributed to various recipients.
• Ruleset Approval Hooks: Manage ruleset changes with additional constraints or requirements.

These hooks enable developers to introduce bespoke behavior without modifying the core protocol.

4. Workflow and Lifecycle

Projects in Juicebox follow a typical lifecycle:

1. Create a Project: Deploy a new project and its associated NFT.
2. Configure Rulesets: Define rules for token issuance, fund distribution, and other treasury operations.
3. Accept Contributions: Receive funds and automatically issue tokens to contributors.
4. Distribute or Reclaim Funds: Payout funds or allow contributors to reclaim them based on the ruleset.
5. Reconfigure Rulesets: Adapt the treasury to new conditions by scheduling or modifying rulesets.

5. Splits

Splits allow projects to allocate funds or tokens to multiple recipients in specified proportions. They can:

• Direct funds to another project.
• Send tokens to specific addresses.
• Execute custom logic through split hooks.

6. Omnichain Architecture

Juicebox’s omnichain capability allows projects to operate seamlessly across multiple EVM-compatible blockchains. A project’s treasury remains unified, and its tokens are consistent across all supported chains.

7. A Vending Machine Analogy

Think of a Juicebox treasury as a programmable vending machine:

• Contributors insert funds.
• The machine issues tokens in return, according to the ruleset in effect.
• The machine's owner (the project) configures the internal rules for what happens to funds and tokens.

Contract Architecture

Juicebox V4 is built from core components and optional extensions, designed to handle a wide range of use cases. Here’s an overview of the main contracts and what they do:

1. Projects (JBProjects.sol)

• Purpose: Represents and manages projects in the protocol as ERC-721 tokens.
• Key Features:
  • Tracks project ownership and metadata.
  • Allows projects to store metadata such as token URIs via a resolver.
• Role: Serves as the foundational entity for project identity and management.

2. Controller (JBController.sol)

• Purpose: Governs the lifecycle and configuration of projects.
• Key Features:
  • Manages rulesets, tokens, and treasury operations.
  • Integrates with other contracts like JBDirectory to coordinate project behavior.
• Role: Acts as the primary contract for interacting with and modifying project settings.

3. Directory (JBDirectory.sol)

• Purpose: Tracks and maps each project to its associated components (e.g., terminals, controllers).
• Key Features:
  • Ensures projects are routed to the correct payment terminals.
  • Maintains security and ownership consistency.
• Role: Provides a single source of truth for project-component relationships.

4. Rulesets (JBRulesets.sol)

• Purpose: Defines the operational logic for a project over time.
• Key Features:
  • Allows for queuing, approval, and activation of rulesets.
  • Supports hooks for custom logic during ruleset transitions.
• Role: Implements flexible treasury and token policies for projects.

5. Tokens (JBTokens.sol, JBERC20.sol)

• Purpose: Manages token issuance, balances, and conversions between credits and ERC-20 tokens.
• Key Features:
  • Supports deploying custom ERC-20 tokens for projects.
  • Tracks and facilitates token minting and burning.
• Role: Enables projects to tokenize treasury contributions and rewards.

6. Multi-Terminal (JBMultiTerminal.sol)

• Purpose: Manages fund flows and coordinates payments for projects.
• Key Features:
  • Accepts inbound payments in multiple tokens.
  • Routes payments to the JBTerminalStore for tracking and accounting.
• Role: Provides a flexible entry point for project contributions.

7. Terminal Store (JBTerminalStore.sol)

• Purpose: Tracks values and handles financial calculations for payment terminals.
• Key Features:
  • Manages payment receipts and distributions.
  • Integrates with pricing and feeless address modules.
• Role: Serves as the financial engine ensuring accurate fund management.

8. Splits (JBSplits.sol)

• Purpose: Defines and manages fund allocation among recipients.
• Key Features:
  • Supports dynamic and static fund distribution rules.
  • Enables hooks for additional customization of splits.
• Role: Ensures transparent and programmable fund allocation.

9. Fund Access Limits (JBFundAccessLimits.sol)

• Purpose: Configures limits on fund withdrawals and surplus handling.
• Key Features:
  • Defines currency-based payout and surplus allowances.
  • Enforces limits during fund distribution.
• Role: Provides security and predictability in treasury operations.

10. Price Feeds (JBPrices.sol, JBChainlinkV3PriceFeed.sol, JBChainlinkV3SequencerPriceFeed.sol)

• Purpose: Provides real-time price data for treasury and token operations.
• Key Features:
  • Normalizes price feeds from multiple sources (e.g., Chainlink).
  • Supports fallback mechanisms for data reliability.
• Role: Enables consistent valuation across currencies and tokens.

11. Permissions and Feeless Addresses (JBPermissions.sol, JBFeelessAddresses.sol)

• Purpose:
  • Permissions: Manages operator roles and permissions for projects.
  • Feeless Addresses: Maintains a whitelist of addresses exempt from fees.
• Key Features:
  • Allows delegation of project operations.
  • Reduces friction for trusted participants.
• Role: Enhances security and operational flexibility.

12. Deadlines and Approval Hooks (JBDeadline.sol)

• Purpose: Ensures timely queuing and approval of rulesets.
• Key Features:
  • Implements deadlines for ruleset transitions.
  • Enforces governance and project constraints.
• Role: Adds rigor to project lifecycle management.

https://genesis-embodied-ai.github.io/

https://www.instagram.com/p/DDZqY3UNmgO/?utm_source=ig_web_copy_link

https://open.spotify.com/track/5DzOiQE7261DbIHZAN47s2?si=9ea9c583f63b4013

https://open.spotify.com/track/5TxAp3JrkgYjYhgezytOBt?si=c161d61eba734673

https://open.spotify.com/album/0kcC9IR3HdYrG0If0nRpge?si=66040vLhTgy1rkmUXGNgyQ

https://open.spotify.com/track/6pidBSO5ksTA9f5GAHR5eQ?si=90d6c4a2fadc4bf3

1. Smart contract risk

The protocol runs entirely on public smart contracts explained in detail throughout these docs. The Juicebox protocol is public infrastructure running well-known code, all consequences from interacting with networks running the protocol are borne by the entities who sign each transaction. The protocol works according to the specifications outlined in these docs to the extent the code is written and deployed correctly, which is a collective responsibility and not guaranteed. There is a major risk that this is not the case. Please do your own research.

2. Project owner risk

Ownership of each project on the Juicebox protocol belongs to the address possessing a JBProjects NFT with a unique token ID, which also serves as the project's ID. The address that owns this token can reconfigure a project's rulesets, which empower it to manipulate a project's finances both productively and maliciously.

The following values can be reconfigured by a project's owner on a per-funding cycle basis:

• 2.1 Setting a distribution limit and payout splits

  With a distribution limit of zero, all treasury funds either stay locked or can be reclaimed by token holders. If the project's current ruleset's redemption bonding curve rate allows it, token holders can cash out their tokens to reclaim their share of the treasury.

  A non-zero distribution limit earmarks a portion of the treasury for distribution to payout splits.

  A project owner can also change the split allocations that are bound by the ruleset's distribution limit at any time, unless the split was explicitly locked until a specified date during its creation.

  🟢 Used productively, a distribution limit can be used to withdraw funds to a community wallet, distribute funds to contributors, channel funds to other projects operating treasuries on the protocol, or fund anything else that can be expressed as a smart contract.

  🔴 Used maliciously this can be used to rug the treasury into an arbitrary wallet.

• 2.2 Setting a surplus allowance

  With a surplus allowance of zero, all treasury funds belonging to the community – funds in excess of the distribution limit – cannot be accessed by the project owner. The only way funds can leave the treasury is through token cash outs.

  A non-zero surplus allowance gives the project owner access to a portion of the community's funds for on-demand distribution to arbitrary addresses.

  🟢 Used productively this can be used to manage discretionary spending.

  🔴 Used maliciously this can be used to rug the treasury into an arbitrary wallet.

• 2.3 Allowing token minting

  While token minting is not allowed, the only way for new project tokens to be minted and distributed is for the project to receive new funds into its treasury. Tokens will get minted in accordance to the current ruleset.

  If token minting is allowed, an arbitrary number of tokens can be minted and distributed by the project owner, possibly diluting the redemption value of all outstanding tokens.

  🟢 Used productively this can be used to premint tokens to members, or satisfy other agreed upon inflationary treasury strategies.

  🔴 Used maliciously this can be used to mint extra tokens and redeem them to reclaim treasury funds into an arbitrary wallet, rugging the treasury.

• 2.4 Setting the ruleset's weight

  A ruleset's weight determines how many tokens will be minted and distributed when a treasury receives funds. By default, a ruleset has the same weight as the one that preceded it after applying the preceding ruleset's decay rate.

  🟢 Used productively this can be used to manage how tokens are issued over time.

  🔴 Used maliciously this can be used to manipulate token issuance, and rug the treasury into an arbitrary wallet.

• 2.5 Adding a custom ERC-20 as the project's token, or deploying a new one.

  While adding an ERC-20 token isn't allowed, the project will issue token credits that are baked in to the protocol.

  If adding an ERC-20 is allowed, a project owner can bring their own ERC-20 that outstanding token credits can be claimed into.

  🟢 Used productively this can be used to create custom token mechanisms associated with a Juicebox treasury.

  🔴 Used maliciously this can be used to cut off a community of token holders from their treasury while using the cashing out of a new token to reclaim treasury funds into an arbitrary wallet.

• 2.6 Pause payments

  While payments aren't paused, the standard pay functionality will be accessible.

  If payments are paused to a project, the protocol will reject any inbound payments.

  🟢 Used productively this can be used to allow projects to creatively tune how its treasury can be accessed.

  🔴 Used maliciously this can be used to cut off a community of token holders from standard treasury functionality.

• 2.7 Custom treasury hooks

  If a project's rulesets have no data hook, pay hook, redemption hook, split hook, or ruleset approval hook attached, the consequences of each interaction with the protocol are predictable, consistent, and specified within these docs.

  If a project has attached one of the above hooks, the protocol will access information from them and call functionality within them at specific moments during the execution of various transactions within the regular operation of the protocol.

  🟢 Used productively this can be used to customize what happens when a treasury receives funds, what happens when the treasury pays out funds, under what conditions funds can leave a treasury, and under what conditions ruleset reconfigurations can take effect.

  🔴 Used maliciously this can be used to mint excess tokens, rug the treasury into an arbitrary wallet, trick users into compromising their individual wallets, create arbitrary unwanted and extractive behavior, brick transactions that should otherwise work, or introduce smart contract bugs into otherwise productive extension designs. Do not interact with a project that is using an untrusted hook.

• 2.8 Add and remove payment terminals

  While setting payment terminals isn't allowed, a project can only receive funds and offer token cash outs from within the payment terminals it has already attached.

  If setting payment terminals is allowed, projects can begin managing inflows and outflows of funds from new contracts, or remove current contracts where they are doing so.

  🟢 Used productively this can be used to create totally custom treasury behavior.

  🔴 Used maliciously this can be used to cut off a community of token holders from their treasury, create arbitrary unwanted and extractive behavior, or introduce smart contract bugs. Do not interact with a projects using untrusted payment terminals.

• 2.9 Add accounting contexts to a terminal

  While allowing new accounting contexts to a terminal, a project can start accepting new tokens as payments, using new tokens for payouts, and allowing new tokens to be reclaimed from the treasury from cash outs.

  🟢 Used productively this can be used to diversify a treasury's reserve asset.

  🔴 Used maliciously this can be used to cut off a community of token holders from their treasury, create arbitrary unwanted and extractive behavior, or introduce smart contract bugs. Do not interact with a projects using untrusted accounting contexts.

• 2.10 Setting the controller

  While setting the controller isn't allowed, a project can only operate according to the rules of its currently set controller.

  If setting the controller is allowed, projects can bring new rules according to which it'll operate.

  🟢 Used productively this can be used to create totally custom treasury behavior.

  🔴 Used maliciously this can be used to cut off a community of token holders from their treasury, create arbitrary unwanted and extractive behavior, or introduce smart contract bugs. Do not interact with a projects using an untrusted controller.

• 2.11 Migrating funds between terminals

  While migrating funds between terminals isn't allowed, a project's funds in a terminal cannot be migrated to another terminal which may have alternate constraints.

  If migrating funds between terminals is allowed, a project can move its funds from one terminal to another.

  🟢 Used productively this can be used to move a treasury into a totally custom environment, or to trusted upgraded versions of the protocol.

  🔴 Used maliciously this can be used to cut off a community of token holders from their treasury, create arbitrary unwanted and extractive behavior, or introduce smart contract bugs.

• 2.12 Cross-chain risk

  If a project is operating using V4's cross-chain utilities (called Suckers), it should make sure its rulesets have a data hook added that allow its funds to be transfered from one network to another without incurring the cash out bonding curve.

  🟢 Used productively this can be used to synchronize a project's dynamics across several blockchains, allowing it to receive funds and operate widely.

  🔴 Used maliciously this can be used to cut off a community of token holders from their treasury, create arbitrary unwanted and extractive behavior, or introduce smart contract bugs.

• 2.13 Multi-hook risks

  If a project is using multiple individually trusted extensions or terminals, there's a chance they could affect one another in a way that requires re-auditing expectations.

  For example, if a Swap Terminal is used alongside the 721-hook, credits cannot be used to mint NFTs. See this audit finding for more information.

• 2.14 721-hook cash out risk

  If a project is using the 721-hook for cash outs, it likely also wants to have made sure outstanding NFTs map cleanly to underlying treasury funds. Otherwise, NFT may be able to access more.

  🟢 Used productively this can be used to allow a treasury to issue NFTs when it receives funds, and offer refunds or access to the treasury according to expected rules.

  🔴 Used maliciously this can be used to cut off a community of token holders from their treasury, or create arbitrary unwanted and extractive behavior.

• 2.15 Buyback-hook pool risk

  If a project is using the buyback-hook, it must choose a fee option for a pool which it cannot change afterwards without using a new buyback hook during a subsequent ruleset. This limits a project owner from forcing issuance instead of buybacks by switching to a low-liquidity pool in real time, but may also prevent buybacks going to a pool with deeper liquidity if it's not the one programmed into the hook. The expectation is that liquidity will form around the pool that is guarenteed to be used for buybacks.

• 2.16 Identitcal locked splits risk

  If a project includes two identical splits that are both locked, only one lock will be honored. To fulfill the same intent, the project should instead combine the two splits into one locked split.

3. Price oracle risk

The protocol uses price oracles to normalize prices throughout the its standard operations. These oracles are smart contract mechanisms external to the core Juicebox protocol. Projects using multiple currencies for certain functionality bare the risk of these external oracle systems misreporting price values, or halting all together. To avoid this risk, projects should account distribution limits in the same currency as the token being collected.

https://www.reuters.com/graphics/USA-ELECTION/RESULTS/zjpqnemxwvx/

https://www.oceanicrefractions.org/?article=the-ear-of-the-storm

https://www.oceanicrefractions.org/?article=the-ear-of-the-storm

https://open.spotify.com/album/0KKT859rTA4Ip7zUzIrTGL?si=Lt_fvedRQNiatl7BNpZfPg

https://open.spotify.com/album/0KKT859rTA4Ip7zUzIrTGL?si=itvGHCt4TI2UldPknsVIiA

https://revnet.app

https://open.spotify.com/track/27sNZ0TFyRsCVOfYfLg6eq?si=0f970bb08d31463d

https://open.spotify.com/album/7vQRJ5q9b0c4gKrsh9yIhE?si=bhb2I3sMSuiWf_Y8t47jog

https://open.spotify.com/track/0JcM1fd4sa1Ij9Od9d8pDh?si=9e2991af6e274e51

https://juicebox.money/v2/p/742?tabid=cycle_payouts

shop.banny.eth.sucks

https://open.spotify.com/album/7GaAXgbFSpcJOiLlFGYyOL?si=OXDIbEIjQAG5CH72PqhjDQ

https://open.spotify.com/album/0iDASlJ6faB4ZDVkKlqbHj?si=soMW8yDBTN6yaUMUDPWRfw

https://open.spotify.com/track/7cRSISnGc51oMUeOfrF601?si=f593cc6e5588469d

https://open.spotify.com/album/6Fxk1WMWok0y7Um4KStNmN?si=tFHQK9lrSo-1vOLm0VhK4w

https://app.infinex.xyz/

rev.eth.sucks

croptop.eth.sucks

https://open.spotify.com/album/4v4g6O8ZNvtxpSKfBQvXDu?si=vOV9pmP_R1Sz0XXZy1y6MA

This post is part of an ongoing series introducing Juicebox V4, the omnichain version of Juicebox, through various lenses.

As discussed in the Juicebox V4 Auditors Guide, Juicebox v4 is made up of several components, each in their own repo.

They each have their own deploy scripts, and should be deployed asynchronously in a preceise order to ensure a correct dependency graph. The grouped repos can be deployed synchronously.

1. [Core, Address Registry, Project Handles]
   • https://github.com/Bananapus/nana-core/blob/main/script/Deploy.s.sol
   • https://github.com/Bananapus/nana-address-registry/blob/main/script/Deploy.s.sol
   • https://github.com/Bananapus/nana-project-handles/blob/main/script/Deploy.sol
2. [721 Hook, Buyback Hook, Swap Terminal, Suckers]
   • https://github.com/Bananapus/nana-721-hook/blob/main/script/Deploy.s.sol
   • https://github.com/Bananapus/nana-buyback-hook/blob/main/script/Deploy.s.sol
   • https://github.com/Bananapus/nana-swap-terminal/blob/main/script/Deploy.s.sol
   • https://github.com/Bananapus/nana-suckers/blob/master/script/Deploy.s.sol
3. [Croptop]
   • https://github.com/mejango/croptop-core/blob/main/script/Deploy.s.sol
4. [Revnet and $REV]
   • https://github.com/rev-net/revnet-core/blob/main/script/Deploy.s.sol
5. [$NANA Project]
   • https://github.com/Bananapus/nana-fee-project-deployer/blob/main/script/Deploy.s.sol
6. [$CROPTOP project]
   • https://github.com/mejango/croptop-core/blob/main/script/ConfigureFeeProject.s.sol
7. [$BANNY and Banny Looks Collection]
   • https://github.com/mejango/banny-looks/blob/main/script/Deploy.s.sol
8. [Banny Looks Drop 1]
   • https://github.com/mejango/banny-looks/blob/main/script/Drop1.s.sol

Each repo uses the same Sphinx process for deployment. Sphinx is an open source tool that deploys, verifies, and creates artifacts for forge-based deploy scripts across EVMs. It simplifies devops while making it easier to ensure consistent addresses for components across chains.

Sphinx requires a group of addresses to be signers on a Gnosis Safe multisig from which the contracts will be deployed. When deploying the protocol onto a new blockchain in the future, the same group of addresses must be used in order to ensure the contracts end up with the same addresses.

The protocol will initially be deployed on Ethereum Mainnet, Arbitrum, Optimism, and Base.

The 10/18 multisig that will deploy all Juicebox V4 components will consist of:

• jango
• 0xba5ed
• nowonder
• drgorilla
• peri
• filip
• jigglyjams
• twodam
• aeolian
• johnnyd
• wraeth
• pablo
• seanmc
• mioes
• matthew
• brileigh
• kmac
• livid

This blog post is part of an ongoing series introducing Juicebox V4, the omnichain version of Juicebox, through various lenses.

Juicebox V4 (codenamed NANA, or Bananapus) is made up of several semi-correlated code components. Since these components exist without strict dependencies, they are separated into their own scoped repositories.

Below are all codebases involved, including those of three applications built atop Juicebox V4, which help to illustrate the system-end-to-end.

Auditors should look to poke holes both in terms of code correctness and economic incentive correctness.

Read more about Juicebox V4 at https://nana.eth.sucks.

Infrastructure

Ownable

https://github.com/Bananapus/nana-ownable

An adaptation of Open Zepplin’s Ownable that allows for contract ownership based on a Juicebox project’s owner.

i.e. a contract can be owned by the owner of the project with ID #123 – which can change without having to reset the owned contract.

commit: 09dc2e64555cc8b7ad6ee71272e5778ec7ce1ab4

Address Registry

https://github.com/Bananapus/nana-address-registry

Allows the deployer contract of certain instance contracts, such as 721 Hooks, to register the relationship so that clients know which instances come from a trusted deployer.

commit: 6f2ab9d2ff6fda707eab05373cc5ca541447fe94

Project Handles

https://github.com/Bananapus/nana-project-handles

Allows attribution between a project ID and ENS handles, useful for plain-text routing.

commit: 4ec9d6b395c5b2b433e3e19d2becceea34633364

Permission IDs

https://github.com/Bananapus/nana-permission-ids

A simple library of permission indexes.

commit: bdc94dd02216f3157af74e144a96b8714b68ade3

Core

https://github.com/Bananapus/nana-core

The nuts and bolts of the Juicebox protocol, including Projects, Directory, Payment Terminals, Controllers, Rulesets (formerly called Funding Cycles in previous Juicebox versions), Splits, Tokens, Permissions, and Price Feeds.

commit: 621b4728594b015d227adf08d7af07a2ea0ba570

721 Hook

https://github.com/Bananapus/nana-721-hook

A hook that can be added to a project’s rulesets allowing inbound payments to mint NFTs that the project has made available.

commit: 6b2a1aa786f9beac3441873d103e555a08345552

Buyback Hook

https://github.com/Bananapus/nana-buyback-hook/

A hook that can be added to a project’s rulesets allowing inbound payments to be routed to an AMM if the AMM is offering a better rate to the payer than the project’s issuance rate.

commit: 9358af4eb2902bbe7e30426f114539f55c1a4b50

Swap Terminal

https://github.com/Bananapus/nana-swap-terminal

An auxiliary payment terminal that projects can use to accept inbound payments of any token, swapped into their preferred token for regular operations.

i.e. people can pay a project using their favorite shitcoin while the project issues its token backed by its preferred store of value.

commit: 961c2bc717dcc7adb363a4918bc498c6b0551902

Suckers

https://github.com/Bananapus/nana-suckers

Cross chain utility that sucks a project’s tokens and their underlying liquidity between supported chains. Allows a project to exist wholistically between blockchains, represented by separate Juicebox projects on each chain.

The codename Bananapus comes from the idea that a Juicebox V4 project can exist across tentacles connecting various blockchains together. The suckers of the tentacles are the contact points.

commit: e506bf3f3e86ec9c9e445d1e2c6ef62a3022e6b4

Applications

Croptop

https://croptop.eth.sucks

https://github.com/mejango/croptop-core

A 721 Hook utility that allows a project owner to grant other addresses permissions to post new items to their collection, so long as it adheres to a few tunable rules.

commit: d05216e8a341d475247a2ab0203635d18f5a145b

Revnet

https://rev.eth.sucks

https://github.com/rev-net/revnet-core

A deployer and project owner that restricts a Juicebox project's operations to a certain standard known as a revnet.

commit: 00a0cc678c9d8709d396a0f46ed972914a04c35d

Banny Looks

https://shop.banny.eth.sucks

https://github.com/mejango/banny-looks

A 721 Hook utility that renders NFTs as composite Bannys and outfits, experienced like a shop.

commit: 852bfe9f5b8e76cbea805e3ba75e20343c71bf36

https://open.spotify.com/track/3hAhmNXjtj6O3V0jthestZ?si=8ae2eeb2fcf34893

https://open.spotify.com/track/0OFzGWNvMR7qvRsD14dxIT?si=d9fc3866f8a940ac

This note gives guidance to investors on how to think about tokens in Juicebox V4, starting with explaining $JBX’s role. It’s my opinion only, not financial or strategic advice.

TLDR

If you generally like the promise of the Juicebox ecosystem and you have 100 dollars to allocate, you should put all 100 into $JBX and then help govern Juiceox DAO and its accumulating assets towards outcomes you find favorable. If you understand $REV, $BANNY, $SUCKS, $CROPTOP, or other revnets being built atop Juicebox V4, go and find another 200 dollars for allocating to the ones you like – which will in turn also benefit your $JBX.

Where we are

Juicebox is an ecosystem of projects, each with their own token – it’s always been a protocol of many tokens. $JBX has been the focal point for Juicebox DAO, issuing itself outward automatically as fee payments from the protocol came in to project ID #1, while also serving as a governance token to manage the accumulating fee payments and contributions.

As of Fall 2023, if an AMM offers a better price for $JBX than project ID #1's issuance price, incoming fees buy back $JBX instead of issuing more $JBX. Juicebox DAO soon after voted to stop $JBX issuance altogether, ensuring a fixed supply and buybacks only.

Where we are going

$JBX is mainnet-only and facilitated by Juicebox V3, it cannot serve as a fee collecting system accross multiple blockchains. In order to progress the ecosystem to be multichain, we need to evolve the roles tokens play in revenue accrual. Thus, $JBX will no longer be the fee-collecting token in the Juicebox V4 protocol, instead $JBX will remain a fixed supply governance token that manages a book of various fee-collecting token networks. The fee-collecting token for project ID #1 across all blockchains of the Juicebox V4 protocol is called $NANA, and it operates as a revnet – meaning revenue that comes in directly benefits Juicebox DAO with no other governance intermediary.

Juicebox DAO will govern a lot of $NANA initially, and continuouly more as revenue comes in. The rest of the $NANA distribution will go to fee payers, just like how the current $JBX system works. Fees are taken when a project’s raised funds are paid out or reclaimed by token holders. Every time anyone distributes a payout from a juicebox project or uses its funds, $NANA gets 2.5%. Every time anyone redeems tokens from a juicebox project, $NANA gets 2.5%.

Juicebox DAO can use this $NANA supply for airdrops, payouts, add liquidity to markets for the revnet to buyback from, sent to an automated redistributor claimed by $JBX holders, or anything that passes through its governance process.

Juicebox DAO will also govern a decent chunk of $REV, $BANNY, and other tokens from other revnets each with their own revenue stream and contributors.

$REV is a revnet that receives fees from usage of revnets themselves. Every time anyone cashes out from a revnet, $REV gets 2.5%. Every time anyone takes out a loan from a revnet, $REV gets 0.5%.
$BANNY is a revnet that receives fees from Banny fashiontech.

$JBX

As investors, $JBX is our easy “index” play. It’s currently got a 2.5 million USD market cap, all tokens circulating, and enough liquidity on Uniswap to interact. $JBX governance will have significant exposure to all application networks built atop Juicebox protocols now and into the future. $JBX’s biggest risk is its governance – it’s got to keep being directed well or figure out how to automate itself.

Keep in mind, Juicebox DAO and the Juicebox protocol have been live since July 2021. It has been fundamental to the making of Constitution DAO, Assange DAO, Shark DAO, Moon DAO, Cryo DAO, Juicebox DAO, the Tornado Cash developer legal defense fundraisers, and 1,331 other projects, facilitating over $186 million in ETH payments. It's just getting started.

As of Oct 13, 2024 (https://www.coingecko.com/en/coins/juicebox), there are 88m $JBX locked in AMM, with a $2.4 million spot market cap.

• 1 ETH (~2,500) => 1,858,070 $JBX
• 10 ETH (~$25,000) => 14,993,200 $JBX
• 100 ETH (~$250,000) => 50,774,800 $JBX
• 1,000 ETH (~$2.5 million) => 81,938,200 $JBX

A $2.5 million order would raise the market cap 44x to $110 million.

For investors looking to allocate in size $500mm+, Juicebox DAO might be willing to sell some of its 130 million $JBX OTC, subject to its proposal process. Work with Jango to broker this deal with the DAO.

Verdict: Must have.

$NANA

https://nana.eth.sucks

Investing in $NANA is a good way to get exposure only to the Juicebox V4 ecosystem, with no governance side effects. It’s unclear what a “fair” price for $NANA is from the jump, that’ll largely depend on Juicebox DAO, who will start out with a huge $NANA supply – essentially treating $NANA as a unit of account and extension of itself.

Verdict: The $JBX trade is better than the direct $NANA trade.

$REV

https://rev.eth.sucks

Investing in $REV is a great way to get exposure only to the revnet ecosystem which sits atop the broader Juicebox V4 ecosystem – though $NANA runs as a revnet so there is some broader exposure baked in. $REV – as an effective tokenization model – will play a meaningful part in the growth effort of the ecosystem – it’s ready to allocate the capital it receives to help more folks grow their fundraises and revenues.

Verdict: The $REV trade is a great trade to pair with a $JBX trade.

$BANNY

https://shop.banny.eth.sucks

Investing in $BANNY is a great way to get exposure only to banny fashion which sits atop the broader Juicebox V4 and revnet ecosystems and makes them inviting and easy to use. $BANNY – as a fashion icon – will also play a big part in the growth effort of the ecosystem - it’s also ready to allocate the capital it receives towards making and marketing great Banny fashiontech.

Verdict: The $BANNY trade also seems great to pair with a $JBX trade.

… etc for $SUCKS, $CROPTOP, etc.

https://eth.sucks
https://croptop.eth.sucks

Conclusion

$JBX is the mothership and is a no brainer must have, however bypassing governance and investing in a revnet directly is also enticing. I think $REV and $BANNY will make great use of the capital to support their own networks and $JBX as a whole, making them great allocations alongside $JBX.

https://open.spotify.com/album/1OX13GiQwogtWBmNng9JmO?si=-qwNqccOQOq49X8HL-AJ3w

This short memo introduces Juicebox V4, the next generation protocol of the Juicebox ecosystem that serves as programmable token-backed treasuries for people and projects.

$JBX holders, fear not. There are no rebrands, token migrations, or impending conflicts of interst. $JBX remains the mothership of the Juicebox ecosystem and will stand to benefit as V4 projects themselves succeed. That said, Juicebox is an ecosystem of projects, each with their own token, some of which will be presented below. Income to the protocol’s project with ID #1 will always accrue to $JBX, the community that has made this all possible.

For introductions geared towards specific intents, see:

• Auditor's Guide
• Deployment Guide

Overview

As is usually the case with Juicebox protocols, there is no intent for there to be further versions after V4 – versions are reserved for extraordinary circumstances.

The circumstance that motivates V4 is the possibility for omnichain projects:

• Each project can accept and custody funds of any kind on any blockchain (starting with those running Ethereum Virtual Machines).
• Each project can issue one unified token between all chains it exists on. The project’s token remains backed by the project’s composite funds accross all chains.
• As new chains emerge and prove legitimate, a project can grow to accept funds and issue its tokens on them as well.

Despite this omnichain capability, most projects might prefer to exist simply on one chain. More extensive projects may want to exist on any possible chain. An example of an extensive project is the V4 protocol’s fee-collecting project, which will assume the ticker $NANA.

Just as previous versions of the Juicebox protocol have encoded a fee from each projects’ outbound funds into a $JBX-issuing project itself running on the protocol, V4 takes a fee into a $NANA-issuing project. Unlike $JBX, $NANA is not a new governance unit presiding over its investments and income, it is instead simply a unit of account that accrues revenue, modeled as a revnet owned and operated predominantly by $JBX governance. Like $JBX, fee-payers also get $NANA automatically as revenue comes in.

It is important to note that the Juicebox experiment, from the start, has been guided by the core value that revenue-regenerating, openly-accounting-for, and autonomous businesses will outcompete private, extractive alternatives. It is our view that fees are good, so long as they motivate an ecosystem of builders, creators, investors, and retail users alike to self propegate.

Revnets are a financial structure that try to capture these values with as few risks and externalities as possible – no governance, scoped management. They are modeled using the Juicebox protocol itself – an expression of the Juicebox language. Understanding revnets is key to understanding the dynamic between $JBX, $NANA, and various other revenue-regenerating projects being planned for V4 deployment. They are detailed in this memo.

The $NANA revnet will abide by the following terms:

Price increases by 50% every 90 days. 38% of issuance and buybacks to Revnet Research Group. Automint an initial supply to acknowledge pre-net work. Cashing out leaves some money on the table.

We’re going to get really good at mirroring internet culture back to it. Letting it appreciate itself while teaching it about itself. Surfacing its appeal and ideals to a broader audience, while pointing to its hypocrisis and uncomfortable truths.

We’ll do this in two ways:

1. Fashion. We will drop seasonal pseudo-intellectual outfit collections that Banny owners can buy and wear. We will use outfits to educate and tell stories about niche subcultures throughout history, memorialize our moment’s trends and oddities, and aspire us towards the future.

2. Character development. We will release animated shorts that accompany Banny and friends as the confront and try to overcome an ever-more connected and uncertain world.

Everything we do will be guided by the question: What are we trying to show internet culture about itself?

Our biggest challenge will be keeping up with rapid cultural changes: Internet culture evolves quickly, so staying relevant will require focus: an ability to both be inside the culture to react quickly to timely themes, while patiently looking from above to elucidate trends as they take shape between the lines.

https://x.com/dankvr/status/1826788593366401062/photo/3

https://x.com/me_jango/status/1826410336527769878

Figure out ways to win when markets go up, and win when markets come down, at the expense of loosing when things dont change much. Not because of a preference for instability, but because change is natural and is very likely to occur. Some changes are amazing, others tragic, some slow evolving, others a quick shift of consciousness. As we feel, we change, create, transform.

https://x.com/_juliettech/status/1824154588347339005

Screenshot 2024-08-05 at 16.08.06.png

https://ultrasound.money/

https://open.spotify.com/track/3EX1r5bKbzE8XmNeY0ScaI?si=2f859fca9ce94b51

https://open.spotify.com/track/3EX1r5bKbzE8XmNeY0ScaI?si=41eef5f484ec40a8

Cash Stash

Not allocated. The other 3 accounts can borrow if they are at risk of liquidation, but they must return the funds.

1. Gut

Long, Shorts, Puts, Calls all on the table, all based on gut. No rules.

Last week when ETH dropped under $3100, I bought a lot of long puts.

2. Tail Only

Every morning I buy $80 worth of long puts at 0.01 - 0.05 delta (about 20-40% below spot) with 60-90 days DTE.

Peace of mind. Bleed a little every day, in exchange for loving the inevitable ~20-40% crypto volitility drops.

The hard part is selling the puts. I'm still figuring it out, I try to roll the puts when they have 40-20 DTE, I usually get back 20-50% of my initial spend.

When the market tanks, I haven't got a strategy down yet, I just start making markets that exponentially follow the price down. I'm trying this out for the first time right now. I'm going to start selling if the market falls another 10% this week, for 1000-4000% gains. If the market doesnt drop, I'll instead continue to bleed. I'm going to keep waiting for the big 30%+ total drop. I know they happen, I've suffered from them in the past.

If the market does drop, I'll take a good chunks of the money and buy spot ETH at its discounted price.

3. 1-1-2

Every Wednesday and Saturday I sell 1 short put around 10% below spot price, and 2 short puts around 40% below spot, in order to fund a long put around 5% below spot, all 30-60 DTE. I let them all ride till expiry. I win some change if the market ends up above 5% below spot, I win a decent chunk if it ends up above 40% below spot, and I loose big if the market ends up below 40%. The bottomless downside risk means this strategy takes a lot of collateral; if the market dives way before the position is closed, i risk liquidation if I’ve got too many positions open.

In four months, I went from $7.3k to $8k, a ~10% gain in a choppy ETH market.

The past week, comign up to Aug 4 2024, the ETH market fell 20%. During the most volitile periods, I risked liquidation and had to borrow from the Cash Stash account to keep peace of mind.

An hour ago, I sold all my shorts and just kept my long puts. I feel a thousand times better. I dont think the exposure is worth the ~10% yield.

The spikes are the periods of borrowing from the Cash Stash.

##4: Tail hedge

Sell a 3 short puts at 20-40% below spot whenever the market dropped 5%+. Immediately submit an order to buy 5 long puts at the next available option price beneath the short put sold, at a price indicated by this trading chart: https://docs.google.com/spreadsheets/d/1yCBAS0M91uKTzPdB69xqbQWxqLfyMkjOTcwCAVRjUxg/edit?gid=689809103#gid=689809103.

As the price rises, or as time goes by without a large drop, the orders for the 5 long puts become more likely to be filled, resulting in a net tail hedge. The starting position is dangerous with ulimited downside, requiring a lot of callateral. As the long puts get purchased, they give create net long positions that make you feel safe, but usually that just means I bite more at price drops, I get greedy, I sell more shorts at a 10% price drop but the price keeps dropping and I'm exposed.

I've made 30% in the past 4 months. An hour ago, I sold all my shorts and just kept my long puts. I feel a thousand times better. I dont think the exposure is worth the ~30% yield. Which is a lot of yield to compound.

The spikes are the periods of borrowing from the Cash Stash.

https://open.spotify.com/track/0hvIfKJWggqYmhFLPEGBiT?si=2b8fe5cb18f04421

https://x.com/Rainmaker1973/status/1819599075907371068

Feelings cannot be false, they can only exist as private conscious moments drenched with internal meaning. I may sense a particular feeling of the planets revolving around the earth, and this feeling would be entirely true despite contradictions found in data. The truthiness of feelings exists unequivocally to a conscious being, but nowhere and in no one else. A feeling has nothing objective to conclude about external realities, it is unknowable to all but its coupled conscious moment.

Data, on the other hand, cannot prove truths, they can only point out aspects of reality in agreement or disagreement with previous probabilistic conceptions. We’ve surfaced data showing planets do not revolve around the earth, but we cannot say for certain that they revolve around the sun… we’ve just never come across data that suggests otherwise – though always be open to new expanding data.

Feelings, being private, cannot affect external reality. In order for beings to communicate an approximation of experienced feelings – to others and to our future selves – we need the means to create symbolic data, and we need to trust our desired recipient to be equipped with the needed faculties to interpret this data. This blog post is an organized amalgamation of energized particle physics as data that approximates my current feelings towards this topic and distributes them as renderable copies, but cannot prescribe the unique feeling anyone will gather from its reading.

Data, lacking intimacy, cannot comfort our internal reality. No quantity or quality of new materialized information will bring peace to a being who is not open to such an outcome. A poem and mathematic equation can be regurgitated to every elementary school student, which may move its observers to tears, curiosity, euphoria, or leave them entirely apathetic to the new data.

I therefor am drawing conclusions about consciousness based on both feelings and data. I am feeling an urge to understand, attending to how self manifests, seeking data recorded by others following similar urges time immemorial, questioning their origin and contextual priors, and interpreting the feelings that led to their production through my own felt experience. I am humble to not lean on contradicting data, eager to process new information that further orients or adds unforeseen dimension, and excited for the privilege to participate in our evolution of self appreciation.

Our creative obligation may be occupied with the urge to capture and persist, lossy as memories and artifacts may be. Just as it may be occupied with the urge to spend a creative now preparing for creative future moments, predicatably looming yet with unknowable specifics.

Just as it may be occupied with the urge to create unencumbered by temporal expectations, or creating as much nothing as possible, for no reason other than because we must.

https://open.spotify.com/track/7orl9NDs2qiWmJpSx8zoWB?si=ff7dc69b509f4ff3

https://apexmovement.com/asr

Updated Sep 14, 2024

Currently reading

• The (Mis)behavior of Markets by Benoit Mandelbrot and Richard L. Hudson
• The Origins and History of Consciousness by Erich Neumann
• Decoherence and the Quantum-to-Classical Transition by Maximilian Schlosshauer
• The Theoretical Minimum by Leonard Susskind

Recently finished

• Irreducible: Consciousness, Life, Computers, and Human Nature by Federico Faggin (gahd damn)
• Chaos Kings by Scott Patterson
• Against the Gods by Peter L. Bernstein
• Stillness is the Key by Ryan Holiday
• Safe Haven: Investing for Financial Storms by Mark Spitznagel

Continue to leave an impression

• Janus: A Summing Up by Arthur Koestler
• Architecture of Happiness by Alain de Botton
• DAO of Capital by Mark Spitznagel
• Mans Search For Meaning by Viktor Frankl

Consciousness is the awareness that everything happening beyond the current moment can only be described as a probability.

Us conscious beings are interactive vessels privileged with a sensory moment, and some degree of free will to choose each subsequent sensory moment. Everything outside of this series of moments is unknowable. We host conciousness as an imagination that renders this vast unkown with vivid concerns.

A conscious being is confined to one sensory moment at a time, the awareness of it is all we know to be certain. We cannot come to know everything that has happened, is happening, or will happen outside of it, but can improve our judgment over the probabilities of these intertemporal happenings. We sometimes recount the past with uniform consensus or predict the future with astounding accuracy, other times less so. Either way there is nothing any of us have more confidence over than the reality of our own current moments.

We are concerned with this deficit of confidence because our vessels are fragile and we tend to appreciate their feel. While we surf the emotions that arise within our sensory moments and recollect prior ones, we are motivated to accumulate new information and methods that improve our judgment of various happenings around us.

Conscious beings are also concerned with the fact that we are not a certainty in the awareness of other conscious beings. We appeal to the sensory moments of others to seek acknowledgement of our realness, but no matter how close we get, we are never a certainty to anyone but ourselves.

We strive to devise communicable symbols to make our reality more interpretable, just as we strive to gain the means to interpret more realities. We are prone to wishing we are the topic of others' concern just as we are prone to concern about the world beyond our moment.

Though us conscious beings enjoy realizing shared moments because we get to absolve our concerns by learning from each other, exploring the depth of feeling, and appearing as more than just a probability, we are each ultimately seeking peaceful terms with our own privilege of being. We can connect conscientiously, but conscious beings are really alone.

Without access to sensory moments, consciousness is left as the imagination concerned only with itself, an awareness tending towards cascading uncertaintly of what was and what will be. An awareness of the moment that is memoryless and speculativeless, senseless and timeless.

Everything not yet noticed is in superposition

https://open.spotify.com/album/1p4Q0pUvvURdCwC842Abjn?si=rPhxvHqaS5KFjfGcsiq3sQ

https://open.spotify.com/album/1p4Q0pUvvURdCwC842Abjn?si=Y0LOCn_QSgeRrO2u2rM6Lg

https://open.spotify.com/track/2nBD6A9Ex6ySTxTlca08Mr?si=fd8f41d003e44b78

A particle is merely a disturbance which propegates within a field.

In Rainy Puddle reality, where is the light source on a rainy day? We could only concieve of its position as a probability function, drawn by the scatter of ongoing raindrops. The lightsource is most where it is consistently brightest, but it might also be in the flickering gradient surrounding it.

In Rainy Puddle reality, people were blinded by a light they couldn't explain, so they went looking for stories. Some stories inspired joy, love, community, others motivated religions, egos, and wars. And yet others prefered to relate to the light not as any more or less holy than other bits of reality, but as a mystery that we have the opportunity to observe and probe – in turn questioning the omniscient ultimatums of the other stories.

These Rainy Puddle contrarians began flirting with the possibility that there might be stuff outside this puddle we couldn't yet see or measure – the reason for the scattering of light might be just around the bend, and it might take leaving the familiar puddleverse to come to terms with what that dimension might be.

Sharing precise ideas about other dimensions became hard with common language, each time words were usurpted by competing storytellers to conveniently give credance to tales of devine spirits also inhabiting unseen realms. Convenient echos of "there's more to reality than the puddle and the rain" were used to stoke the spiritual, while inconvenient ones like "the extra dimension might host a lamppost that illuminates a nearby road" were ignored as unnecessary and too confusing for mainstream hearts who had no reference to such things as lampposts and roads.

The moon as light source => The moon as movements => The moon as God => The moon as system => The moon as spacerock => The moon as destination => The moon as gravitational slingshot. Each expands the holography of our relationship with moon if we're capable of growing to hold more stories within our appreciationsphere. Moon is still light source as much as it is gravitational slingshot, though there will always be egos who choose not to grow into the language that explains this whole. Instead, these egos treat discovery – both of the new and of the forgotten – as too complicated, or as an offense to stories they've already grown comfortable with and whose sanctity they feel must be protected. Growing aint easy, but our predicament gives us no choice.

Math turned out to be a great language for the reality-curious storytellers, escaping the romance and logomachy of surrounding epics. But mathematical hypothesis of a lamppost were unlikely to win the hearts of the Rainy Puddle masses to whom light was God. Most people don't feel math. Most feel the beauty of a church more than they feel "a^2 + b^2 = c^2". Most feel the dopamine from social networks more than they feel "2^n". Most feel the sun's warmth moreso than they feel "mc^2". Most feel the word "death" more than they feel "1 x 1 = 2".

As language-making beings surfing reality waves, we are all capable of relating to the substrate in ways that isn't yet explicable to others, let alone ourselves, yet we must still agree on sufficient common truthful touchpoints to make palpable progress to our collective wellbeing. In Rainy Puddle reality, we may have long developed a common language around ways to describe "light" as it effects our day-to-day health – the way it can burn our skin if overexposed. We may also have started blueprints of other esoteric empirical truths – flickering probabilities and all. But light-as-lamppost remains speculative until we venture past the untouchable stories of the devine to find new language that is so clear and awe-inspiring that it forces those proposing naive truths to cede and adapt.

Knowing lamp allows us to grow our language, our world, and tell wilder stories of more powerful gods.

https://open.spotify.com/track/70go4o4H5PlkYFJxXNof2x?si=2c1084d12ffa448c

https://open.spotify.com/track/1zsC9fbdILIE03SjA56zLU?si=a4f043b721674897

https://open.spotify.com/album/1O13lf2AQFlTxGUhH3J2Di?si=07v4VPHmRXabLZMqnYfv8g

Wednesday Oct 9, 2024

• Joscha Bach: Artificial Consciousness and the Nature of Reality | Lex Fridman Podcast #101 =>

Wednesday Sept 18, 2024

• Tekedra Mawakana | All-In Summit 2024 =>

Saturday Sept 14, 2024

• Peter Thiel | All-In Summit 2024 =>

Thursday Sept 12, 2024

• Universa's Bernoulli for Portfolio Simulation: Correcting the Empirical Distribution =>

Wednesday Sept 11, 2024

• In conversation with Sergey Brin | All-In Summit 2024 =>

Tuesday Sept 10, 2024

• LIVE: ABC News Presidential Debate: Harris and Trump meet in Philadelphia =>

Sunday Sept 8, 2024

• How This Japanese Architect Makes Use of a Small Site in Tokyo =>

Sunday August 25, 2024

• Quantum Consciousness Debate: Does the Wave Function Actually Exist? | Penrose, Faggin & Kastrup =>
• Quentin Tarantino Returns Part 1 | Club Random with Bill Maher =>

Tuesday August 20, 2024

• WATCH: NBA coach Steve Kerr tells Trump ‘night night’ at 2024 Democratic National Convention =>

Friday August 16, 2024

• Joe Rogan Experience #2190 - Peter Thiel =>

Monday August 5, 2024

• Global Stock FREE FALL As Recession Indicator Flashes Red =>
• US Troops FLOOD Middle East As Iran War Looms =>

Thursday August 1, 2024

• John Wheeler, Peter Putnam, and the Problem of Multiple Observers => ?si=Jb1N-dWox5rw6JY0
• FULL INTERVIEW: Donald Trump takes questions from NABJ panel =>

Wednesday July 31, 2024

• Four Tet on Collaborating with Fred Again.. & Skrillex + His Top Production Tips! =>

Tuesday July 30, 2024

• Jon Stewart on Why GOP Doesn't Know What To Do With Kamala Harris Replacing Biden | The Daily Show =>
• Four Tet On His Career and Why He Doesn't Give Interviews =>

Monday July 29, 2024

• Pharrell Williams’ $1 Billion Plan For Black And Hispanic Entrepreneurs =>
• From C-Student To CEO: Creating An "Uninterrupted" Path For Entrepreneurs =>
• Pharrell Opens Up About Louis Vuitton, Dreams & Fashion Design | Vogue =>
• How matter becomes life, in 7 minutes | Lee Cronin =>
• Four Tet Breaks Down His Creative Process: the Power of Laptops and the Importance of Listening =>

Saturday July 27, 2024

• Stuart Hameroff: Anesthesia, Consciousness, Bohm and Penrose (EmQM17) =>

Friday July 26, 2024

• Scott Patterson's Chaos Kings, Part 2 =>
• Kamala Harris holds 1st presidential campaign rally since Biden's withdrawal from the race =>
• Krystal And Saagar DEBATE: KAMALA IS DEI Candidate =>
• Mind-Blowing Footage: Buffett's Origins =>

Thursday July 25, 2024

• "Secrets to Optimal Client Service," With Jim Donovan =>
• Experimental Evidence No One Expected! Is Human Consciousness Quantum After All? =>
• First Ever Image of Atoms Turning Into Quantum Waves...Is Kinda Mind-Blowing! =>
• How to Make Temaki Sushi (手巻き寿司) =>
• How to make Temaki Sushi - Manu Shows you how to make Temaki =>
• Clarifying the Tubulin bit/qubit - Defending the Penrose-Hameroff Orch OR Model (Quantum Biology) =>

Wednesday July 24, 2024

• A Discussion With Scott Patterson's About His Book Chaos Kings, Part 1 =>
• The Mystery of Spinors => &t=2390s
• LIVE: Biden gives Oval Office speech after dropping out of 2024 election =>

Tuesday July 23, 2024

• Hamas and Fatah hold reconciliation talks in Beijing =>

Sunday July 21, 2024

• Groundbreaking Consciousness Theory By Microprocessor Inventor | Federico Faggin & Bernardo Kastrup => ?si=ac1dq0u4xSGv5Iqk
• The Crazy Mass-Giving Mechanism of the Higgs Field Simplified =>
• Why do "Useless" Neutrinos Exist? =>
• Quantum Fields: The Most Beautiful Theory in Physics! =>

Saturday July 20, 2024

• The Experiment that Proved Einstein Was Wrong | Quantum Eraser =>

Wednesday - Thursday July 17-19, 2024

• RNC on CSPAN

Tuesday July 16, 2024

• The Little Tech Agenda: Biden vs. Trump =>

Monday July 15, 2024

• Energy Free Cooling through Physics =>

Sunday July 14, 2024

• President Biden addresses the nation after attempted assassination of Donald Trump =>
• The Spectral Spectrum | How do "Photons & Electromagnetic Waves" Work? =>
• Understanding Light and Why it exists. =>
• Quantum Field Theory visualized =>

Friday July 12, 2024

• Biden chaos, Soft landing secured? AI sentiment turns bearish, French elections =>
• I did the double slit experiment at home =>
• How to learn Quantum Mechanics on your own (a self-study guide) =>
• What is a photon? =>
• I Disagree with Doctors about Posture =>
• How we see color - Colm Kelleher =>
• Can Light Bump Into Other Light? =>
• Key Concept: Photon Energy =>
• Knocking Electrons With Light—The Photoelectric Effect =>

Thursday July 11, 2024

• Peter Thiel | Cambridge Union =>
• Salmon Cutting Skills 鮭魚切割技能 How to Cut a Salmon for Sashimi =>
• $10,000 Luxurious Bluefin Tuna Otoro Cutting - A Masterpiece in Sashimi! =>
• I Caught A Huge Fish and Cooked It in a Big Tandoor! Fish Day in the Village =>
• Tucker Carlson LOVES Nicotine =>

Wednesday July 10, 2024

• Josh Johnson Asks Black Voters: “Do We F**k With Trump?” | The Daily Show =>
• French VS English Men | Tatty Macleoda =>
• England vs Netherlands, Euro Cup.
• Reza Pahlavi | Iran: Ending the Islamist Caliphate and Returning to the Nation State | NatCon 4 =>
• What is a family office and why might you consider one?
  =>
• پیام به ملت بزرگ ایران در ارتباط با سیرک انتخابات رژی -
  =>

Tuesday July 9, 2024

• "America Is About To Crash Into A Brick Wall"- Wealth, Rising War, AI & Elon Musk | David Friedberg =>
• Jon Stewart Examines Biden’s Future Amidst Calls For Him to Drop Out | The Daily Show =>
• LIVE: President Biden delivers remarks on the 75th anniversary of NATO — 7/9/2024
  =>
• Sage Steele | Club Random with Bill Maher =>
• Spain vs France, Euro Cup.

Monday July 8, 2024

• 'GOODEST JOB': Biden STUNS Dems With Why He Won't Drop Out
  =>
• Quantum Entanglement, Bell Inequality, EPR paradox =>
• The difference between bonds, notes and bills =>
• Gold: A Journey With Idris Elba =>

Saturday July 6, 2024

• DEFIANT BIDEN: 'Not Dropping Out,' REFUSES Cognitive Test =>
• Philosophy of Physics =>
• WATER & THE ANCIENT MYSTERIES WEBINAR =>
• 309 Walter Russell The Secret of Light Part III the Universal Octave & Biogeometry
  => &t=1107s
• Donal O'Connell | The double copy from Coulomb to Kerr =>
• Joe Rogan Experience #2171 - Eric Weinstein & Terrence Howard =>
• Edward Witten - What are Breakthroughs in Science? =>
• The Mouse Utopia Experiments | Down the Rabbit Hole =>

Friday July 5, 2024

• President Biden sits down for interview with George Stephanopoulos l ABC News exclusive =>
• New Rule: Music Materialism | Real Time with Bill Maher (HBO) =>
• Lex Fridman’s Problematic Interview With Ivanka Trump =>
• Spain vs Germany, Euro Cup.
• Portugual vs France, Euro Cup.

Thursday July 4, 2024

• Quantum Physics – list of Philosophical Interpretations =>
• Waves: Light, Sound, and the nature of Reality =>
• Vitalik & Noah Smith: Can Authoritarianism Win the 21st Century? =>
• Hot Swap growing, donors revolt, President Kamala? SCOTUS breakdown: Immunity, Chevron, Censorship => &t=2s

Wednesday July 3, 2024

• Ivanka Trump: Politics, Family, Real Estate, Fashion, Music, and Life | Lex Fridman Podcast #436 =>
• Delayed Choice Quantum Eraser Explained =>
• FERNANDINHO | Podcast Denílson Show #104 =>

Tuesday July 2, 2024

• President Biden delivers remarks on the Supreme Court's immunity ruling — 7/1/2024 =>
• Reggie Watts | The Sage Steele Show =>
• Congressmen Wesley Hunt & Byron Donalds | The Sage Steele Show =>
• Brazil vs Columbia, Copa America.

https://open.spotify.com/artist/4URLjSfWtdArslMrlA5suJ?si=7q6WiOZEQQelTSg-fMzBaw

https://open.spotify.com/track/3d5fDnLCo71IJkOiZxBQPd?si=69348e5ad21f4d12

https://nance.app

https://open.spotify.com/album/2jotDXhKd5px6kOEaxPUcK?si=eck72mo2Tom5DqHqCGAnWg

https://open.spotify.com/track/0aHk7VMGvIyWTbnOTPqywy?si=6d5b9beeae794bef

Looking from beneath, I see forces manipulating towards each conceivable direction of a flat surface above. Seek more context, to discover new beneaths, to add ever more dimension.

Looking from above, I see forces manipulating towards each conceivable direction of a flat surface beneath. Seek more context, to discover new aboves, to add ever more dimension.

https://www.experienceform.com/

https://open.spotify.com/track/0fWqIbWJcfITkbWAa5i5hO?si=fa31c7210ddd46be

Banana Box Office Entertainment (BBO)

We're starting BBO Entertainment LLC and a $BANNY revnet to grow Banny fashion.

BBO Mission

Build Banny's relatability by reflecting the ambitions and ironies of internet fashion back to it. We're aiming for a $1m $BANNY revnet in the first year, and $100m in 4 years.

Bottom line

BBO will achieve its mission in three ways: sell original naked banny NFTs and seasonal outfits through shop.banny.eth.sucks, producing Into The Bannyeverse and potentially other multimedia storytelling ventures, and building a bold, tasteful marketing presence in alignment with JuiceboxDAO's values from which Banny originates, that anyone can participate in.

While doing so, BBO will accumulate $BANNY. The $BANNY revnet receives all revenues from NFT mints. The revenue is used to either issue new $BANNY from its revnet or buyback $BANNY from the market, depending on which is a better deal. BBO receives a portion of both $BANNY issuance and buybacks as the fees come in. More on this below.

Pitch to investors

We encourage investors to participate directly through banny NFTs from their favorite EVM chain, see below for details. The first 90 days of revnet will favor grassroots investors.

For those investors who prefer interacting with a corporation in fiat instead of accessing $BANNY directly, RRG can facilitate access.

Structure

BBO is an LLC owned by Jango, Peri, Sage, Mieos, and Lurkmoth. BBO is a $BANNY token holder alongside other holders.

Onchain management

Onchain, BBO will manage its $BANNY with a 3/6 multisig at bbo.eth. The multisig is controlled by:

• breadfruit.eth (jango)
• peri.eth (Peri)
• mieos.eth (Mieos)
• filip.eth (Filip)
• dao.jbx.eth (JuiceboxDAO)
• openesquire.eth (Robert Leonhard)

Offchain management

Offchain management of the LLC will be led by Jango, Peri, Sage, Mieos, Robert, and other members of the Juicebox community:

Jango cofounded and has developed the Juicebox protocol to support organizational money experiments on the public internet.

Robert Leonhard is the co-founder of Open Esquire, a group of legal engineers serving Ethereum projects and many Juicebox projects.

... [add Peri, Sage, Mieos, and Lurkmoth blurbs].

Ideal partners

Anyone is welcome. Get you a banny to get started.

We want to invite both token-confortable people to interact directly from their favorite EVM blockchain, and token-curious people to interact through RRG.

Spend

BBO will use the bulk of the $BANNY it earns to support the launch and marketing of banny shopping experience, and of $BANNY. We will use some of the $BANNY to staff jango (project/tech lead), peri (consumer/tech lead), sage (art lead), mioes (curation lead), lurkmoth (animation lead), rob (legal).

$BANNY

$BANNY runs on its own as a revnet according to the rules below – there is no governance. BBO is a token holder alongside other token holders and has no special powers. Anyone can participate in $BANNY at any time.

All banny NFT revenue will go to the $BANNY revnet.

Anatomy of a revnet

Each revnet has a token and is defined in stages. Each stage specifies five rules which dictate how the revent operates:

• Duration: How long does the stage last? A revnet’s final stage lasts forever.
• Price:
  • Starting price: How much does it cost to buy a single token when the stage begins? The payment's value stays within the revnet and can only be accessed by token holders who cash out.
  • Price increase: How frequently, and by how much, does the token's price increase within the stage?
• Split: What percentage of token issuance (and buybacks) are set aside for a list of recipients, and which address is the split operator? The split operator can add, remove, or modify recipients from that list, changing how the split is allocated within the fixed percent set for the stage.
• Automint: How many tokens get minted to a list of recipients at the start of the stage? This functions like a "pre-mint" only accessible once the stage has started.
• Cash out tax: How much does the revnet's next potential cash out value increase each time a token holder cashes out?

If token holders add liquidity to an AMM and it offers a better price than the revnet, the revnet will route incoming payments to that market instead of issuing new tokens. The revnet's split is applied to these buybacks as well.

Built using Juicebox v4, revnets can grow to accept money on new EVM-compatible networks as they emerge, and also offer cash outs on those networks. Holders can move their tokens between chains, and when they do, the revnet automatically moves funds to back those tokens to maintain those tokens' value.

$BANNY stage 1

Inaugural 90 day $BANNY sale. Automint the first of two batches of tokens to honor pre-launch work.

• Duration: 90 days.
• Initial price: 1 $BANNY costs 0.001 ETH.
• Price increase: None.
• Split: 38% split of issuance and buybacks operated by bbo.eth. 19% routed to bbo.eth (BBO), and 19% to dao.jbx.eth (JuiceboxDAO).
• Automint: 88_500 $BANNY to bbo.eth for pre-net work, split 25_000 to dao.jbx.eth, 10_000 to breadfruit, 10_000 to peri, 10_000 to sage, 10_000 to mieos, 10_000 to lurkmoth, 1_500 to rrg.eth, 1_500 to anissa, 1_500 to peel, 1_500 to 0xBa5ed, 1_500 to nowonder, 1_500 to burtula, 1_500 to juicecast, 1_500 to eden, 1_500 to openesquire.eth (rob).
• Cash out tax: Medium-high (0.6). The network consolidates when holders cash out.

$BANNY stage 2

The price of issuing new $BANNY is doubled every 180 days for 720 days.

• Duration: 720 days (~2 years).
• Initial price: 1 $BANNY costs 0.002 ETH, double the price of stage 1.
• Price increase: 100% (double) every 180 days, “halving”.
• Split: 38% of issuance and buybacks operated by bbo.eth. 8% burnt, 15% routed to bbo.eth, 15% to dao.jbx.eth.
• Automint: none.
• Cash out tax: No change. Medium-high (0.6).

$BANNY stage 3

Automint last $BANNY for pre-net work. The price of issuing new $BANNY is doubled every 360 days for 7_200 days.

• Duration: 7_200 days. (~20 years)
• Initial price: Where stage 2 left off.
• Price increase: Doubling every 360 days.
• Split: No change. 38% of issuance and buybacks operated by bbo.eth. 8% burnt, 15% routed to bbo.eth, 15% to dao.jbx.eth.
• Automint: 146_500 $BANNY to bbo.eth for pre-net work, split 35_000 to dao.jbx.eth, 20_000 to breadfruit, 20_000 to peri, 20_000 to sage, 20_000 to mieos, 20_000 to lurkmoth, 3_500 to rrg.eth, 3_500 to anissa, 3_500 to peel, 3_500 to 0xBa5ed, 3_500 to nowonder, 3_500 to tamar, 3_500 to juicecast, 3_500 to eden, 3_500 to openesquire.eth (rob).
• Cash out tax: No change. Medium-high (0.6).

$BANNY stage 4

End issuance and splits.

• Duration: Forever.
• Initial price: 0. No more issuance.
• Price increase: None, since there's no more issuance.
• Split: None.
• Cash out tax: No change. Medium-high (0.6).

Legal

Each revnet’s rules are defined up front, and all transactions are public. Once a revnet is deployed, no manager has the power to change how it works, no supervisor has special backdoor access, and no authority can stop it. There is no managerial effort attached to an expectation of profit.

BBO has it's own managerial efforts, but only engages with the $BANNY economy as a token holder.

REVNET RESEARCH GROUP (RRG)

Mission: Tokenize the fundraising and revenues of open source internet project.

Bottom line: Accumulate $REV and other promising revnet-based tokens, add value to them.

Legal: Incorporated in the USA as a Deleware C-Corp. 51% owned by Jango, 29% reserved for staff, 20% sold to investors.

Onchain Management: A multisig at rrg.rev.eth, 3/6 from:

• breadfruit (jango)
• filipv
• codalabs (aeolian)
• kmac
• juiceboxDAO
• openesquire (rob)

Offchain Management: Managed by Jango.

Operations: $REV runs on its own as a revnet according to the rules below. RRG is a token holder alongside other token holders and has no special powers.

$REV Stage 1:
Inaugural 77 day $REV sale ⏩. Your payments are worth 2.5x what they'll be worth in stage 2. Mint first of two batches of tokens to honor pre-net work.

• Duration: 77 days.
• Initial price: 1 $REV costs 0.001 ETH.
• Price increase: none.
• Split: 20% split of issuance and buybacks operated by rrg.rev.eth, 10% routed to rrg.rev.eth, 10% to dao.jbx.eth.
• Automint: 70_000 $REV to rrg.rev.eth for pre-net work, split 25_000 to dao.jbx.eth, 10_000 to breadfruit, 10_000 to filipv, 10_000 to codalabs, 4_000 to openesquire, 2_000 to kmac, 2_000 to 0xBa5ed, 2_000 to nowonder, 2_000 to peel, 1_000 to drgorilla, 1_000 to juicecast, 1_000 to peacenode, 1_000 to LJ.
• Cash out tax: Medium-high (0.6), the network consolidates when holders cash out.

$REV Stage 2:
The price of issuing new $REV is doubled every 77 days, forever.

• Duration: 770 days.
• Initial price: 1 $REV costs 0.002 ETH, double the price of stage 1.
• Price increase: 100% (double) every 77 days, “halvenings”.
• Split: 38% of issuance and buybacks operated by rrg.rev.eth, 19% routed to rrg.rev.eth, 19% to dao.jbx.eth.
• Automint: none.
• Cash out tax: No change. Medium-high (0.6).

$REV Stage 3:
Vest more $REV for pre-net work.

• Duration: Forever.
• Initial price: Where stage 2 left off.
• Price increase: Continue doubling every 77 days.
• Split: No change. 38% of issuance and buybacks operated by rrg.rev.eth, 19% routed to rrg.rev.eth, 19% to dao.jbx.eth.
• Automint: 128_000 $REV to rrg.rev.eth for pre-net work, split 35_000 to dao.jbx.eth, 20_000 to breadfruit, 20_000 to filipv, 20_000 to codalabs, 10_000 to openesquire, 5_000 to kmac, 5_000 to 0xBa5ed, 5_000 to nowonder, 5_000 to peel, 1_000 to drgorilla, 1_000 to juicecast, 1_000 to peacenode, 1_000 to LJ.
• Cash out tax: No change. Medium-high (0.6).

https://open.spotify.com/track/6t13IMt6jrQ5krmvgvKvKP?si=0913fad653824a8e

https://x.com/RJPinnell/status/1795520110771474496

nana.eth.sucks

https://open.spotify.com/track/5R1U7PCHVl9amefbyTUdNE?si=e600070536ff4d8d

North star:

$JBX governance should accrue valuable positions in growth-oriented open source and openly accounted-for token networks. Having shaped tools towards these ends, $JBX governance is in a unique position to identify, shape, and market such token networks. $NANA, $BANNY, $CROWD, $NANCE, $DEFIFA, $SUCKS, $REV, $CPN, $JBM are a few that have begun taking shape.

Why:

I think innovating at the organizational layer through experimentation focused on capital efficiency is the most assymetric bet $JBX can make. We should also acknowledge that folks tend to use Juicebox most for mechanically-simple fundraising. With the consideration of products like Juicecrowd or Juicebox.money, our concern should be both in the application of the protocol for crowdfunding and in the application of the protocol to sustain the organization building the crowdfunding experience. Shared ontology makes for greater interoperable productivity.

The onchain organizational layer is the most legally dubious, I think this is because "onchain" is currently misinterpreted by incumbant laws. Onchain internet organizations need not disclose quarterly reports because they disclose all data apriori for anyone to interpret. Disclosures are baked in at the $JBX protocol layer, the burden falls on clients to communicate risks to users and facilitate transactions within them. These clients need capital, and are positioned well to create and grow positive-sum revenue streams.

Roundabout:

In order to get the most out of the north star, it’s worth assessing how we will encourage and account for success with big bets we make. Revnets give us clear guidelines as capital allocators, and help builders quickly set up productive token networks that anyone can use. Omnichain $NANA protocol widens the surface area of the north star. $BANNY simplifies the delivery as we go to market.

They each also set examples others can study and iterate from.

Bottom line:

Whenever it decides, $JBX governance can liquidate positions and return proceeds back to the treasury that backs $JBX.

This is my blog. It's messy.

Look around, click if you're curious, mint if you like.

Click the + up top to make your own site.

https://open.spotify.com/track/1NOAzrOFuYcBa2obeas4WA?si=1871b7367ab84751

(6) Symbols are beautiful, but they only give things meaning only if you prefer for them to.

(6) At least 100,000 years of Homo Sapiens depended on visual symbology as their most precise form of ontology before vocal languages emerged and began to refine.

(11) On “symbolic fears”, does the recognition of a symbol presuppose the meaning? For example, “[dreams of] being chased or falling are commonly interpreted as symbolic of an individual’s fears of growing up” presupose that you’ve had fears of growing up if you have a dream of being chased or falling?”. Why should we be suggesting fears onto people?

(11) Haven’t we always had celebrities? Thespians go way back, charisma and comedy go way back, tragedy goes way back. Fame goes back, stories that instigate fame have just travelled progressively faster and farther with advent of boats, wheels, flight, internet, etc.

(11) If we choose to see them and give them meaning.

(230) Feelings as signs seems for honest than seeking signs to suggest feelings.

TABLE OF CONTENTS

Now:

• $JBX

Up Next:

• $NANA
• $BANNY

Coming Soon:

• $REV
• $SUCKS
• $CROPTOP
• $DEFIFA

$JBX

$NANA

$BANNY

$REV

$SUCKS

$CROPTOP

$DEFIFA

In this post, I’ll try taking us on the journey of why decisions were made and why it may matter to you.

Core Problem

Each Juicebox project should be able to exist across EVMs.

This means four things:

• Each project should be able to issue their token on whichever chains they choose to receive funds on.

• Each project’s holders should be able to move their tokens across chains.

• A project’s tokens should remain backed by its treasury as they move across chains, meaning they maintain a redemption value established by the project’s current rules.

• A project should be able to evolve onto new chains as they emerge.

Example

JuiceboxDAO faces this core problem head on.

The Juicebox protocol’s core philosophical assumption is that open source can have competative business models through income streams that are openly accounted for, fees which do not rent seek, and incentives that support widespread network growth.

To this effect, project #1 on the protocol takes a 2.5% fee of funds withdrawn from the protocol by projects and token holders. In exchange, $JBX is issued to the fee payer either via new issuance or buybacks from the open market, depending on which offers a better price to the fee payer.

This $JBX has a price floor which is the rate at which it can be redeemed to access project #1's treasury funds accumulated from fees and other contributed payments.

A percentage of this emitted $JBX stays governed by $JBX holders, contributing to a treasury used to motivate ecosystem support. $JBX governance can also use the treasury funds from project #1, reducing the token’s price floor.

The core problem is that, if the protocol were to simply be deployed on various EVM chains, we’d have disjointed project #1s, each issuing their own treasury-backed tokens. We’d need to increase the burden of off-chain management in order to cordinate across each economy — a forever-expense ultimately borne by fee payers. We want the opposite — reduce the burden of governance and push manegerial expenses toward zero, a feat only possible with blockchains.

Solution

$JBX was not designed to exist elegantly across chains. The first step of the solution was to come to terms with this, and realize we did not want to add risk to the tried and true $JBX mainnet system that works and has facilitated tens of millions in dollar-denominated value.

We forked the original Juicebox protocol to make this multichain idea work. As we did so, we were carried by a metaphor of an octopus with tentacles stretching between chains. Bananapus became its name, and $NANA became the leading choice of ticker for project #1’s omnichain treasury-backed token. Several folks also started colloquially calling this fork “Juicebox V4”.

Though the fork will be issuing $NANA, a separate $NANA governance process will not be needed. Unlike the $JBX treasury, the $NANA treasury will run a deterministic set of money input/output rules forever with no possibility of preferencial payouts — $NANA holders are the only ones who can access the treasury funds through token redemptions. We call this governance-free configuration of Juicebox project a revnet.

Though they are unowned and ungoverned, revnets allow for an Operator address that benefits from a subset of new token emissions. In the case of $NANA the Operator is JuiceboxDAO, meaning $JBX holders will govern a growing amount of $NANA via its preexisting governance process.

Bannyverse

If you’re confused by any of the above, fear not. A dead simple way to interact with these new ideas is to peruse the Bannyverse – a project on the protocol that sells naked banny NFTs and outfits, on any chain you’d like to buy them from.

If you're curious, you’ll then come to learn the revenue from each Bannyverse NFT mint goes to the $BANNY revnet, meaning you get $BANNY each time you make a purchase.

Going a little further, you’ll find that by redeeming your $BANNY right away, you’ll get some of your money back. If you wait for the Bannyverse to continue growing before redeeming, you can get more.

If you’re still curious, you may find that when you redeemed your $BANNY to retrieve some of the Bannyverse network’s revenue, a 2.5% fee was paid to project #1, issuing you $NANA in return according to the Bananapus revnet’s rules.

The bravest of the brave will dig one last level deeper and return face-to-face with $JBX, the JuiceboxDAO governing body whose $NANA holdings will increase in redemption value as the $NANA network grows.

Juicebox.money

Most people use Juicebox through juicebox.money (JBM). This site will continue to service the tried and true $JBX protocol exclusively. As the $NANA protocol proves its worthiness and safety, JBM will consider facilitating projects on this new stack instead, allowing folks to deploy open-ended Juicebox projects to any number of chains (or across chains).

For now, revnet.app is the destination for interacting with $BANNY and $NANA treasuries.

In the consumption or in the lack there of?

In the assumption that we can always find a way for more to fit, or in the act of appreciating without incorporating?

Probably somewhere in the abundant inbetween?

https://soundcloud.com/rinsefm/jensen-interceptor-with-crazed-br-17-may-2023?si=fc55cbe04a544e2eaa714a1c354c798c&utm_source=clipboard&utm_medium=text&utm_campaign=social_sharing

https://bannyverse.eth.limo

Our goals are:

• Run $NANA and $BANNY omnichain testnet revnets for 7 consecutive days bug free.

• Get people to play with omnichain revnets and bannyverse mints on testnets through clients such as the revnet app, juicescan, and the bannyverse minter, and through contract APIs directly.

• Spend a month code complete, focusing entirely on security, risk mitigation, documentation, and stress testing integrations with a bug bash contest and a hackathon.

• Grow the launch anticipation through distribution of cherishable cultural Bannys to those who're putting in the love.

• Thorough subgraph database for applications to use.

• By giving away a chunk of JBDAO's assets to folks who will steward their narrative, it's doing a service to the portion of the assets it's keeping.

Of the assets JuiceboxDAO will receive by contributing 40 ETH to Bannyverse and from the $NANA and $BANNY premints, we’re asking $JBX for:

• 17 Alien Bannys (out of 30 Alien Bannys it will have ~ 30 ETH)
• 49 Pink Bannys (out of 80 Pink Bannys it will have ~ 8 ETH)
• 80 Orange Bannys (out of 200 Orange Bannys it will have ~2 ETH)
• 29,000 $BANNY tokens (out of 80,000 $BANNY tokens it will have from premint and from contributing 40 ETH)
• 76,000 $NANA tokens (out of 37,000,000 $NANA it will have)

We’re also asking for

• $69k USD of ETH

• 10m $JBX

We'll allocate:

• 4 Alien Bannys, 12 pink Bannys, 12,000 $BANNY, 32,000 $NANA, and $24k of ETH to contract crew (jango, DrG, 0xBa5ed, nowonder) to manage the month of stress tests – bug finding contest, test writing, and a hackathon. We'll be full throttle for the month. These assets are only cherishable if the $NANA infrastructure being tested holds.

• 1 alien, 2 pink Bannys, 2,000 $BANNY, 4,000 $NANA, $5k of ETH to making a sturdy subgraph for the core stack + revnets (peri).

• 2 aliens, 2 pink Bannys, 2,000 $BANNY, 4,000 $NANA, $5k of ETH to great documentation for those learning and using the core stack (filip, jango).

• 3 aliens, 6 pink Bannys, 3,000 $BANNY, 6,000 $NANA, $9k of ETH to heavily recruit curiosity and involvment for bug finding contest and hackathon, and helping tell the story of whats going on with $NANA and $BANNY and the NFTs. (matthew & brileigh & sage)

• 4 aliens, 14 pink Bannys, 50 orange Bannys, 5,000 $BANNY, 5,000 $NANA as rewards for bug bashers, auditors, and hackathonists managed by contract crew. Returned to JuiceboxDAO if unused. Part of the fun for bug hunters is learning how all these assets fit into the stack they're auditing.

• 1 Alien, 3 Pinks, 5,000 $BANNY, 5,000 $NANA as a raffle/airdrop or other recruiting/marketing effort by brileigh and matthew.

• Alongside testing the code, we’ll be stress testing the Revnet UX, and omnichain & omnitoken interop UX. Each of these projects will get$13k, 10k $NANA, 5 pink bannys, and 10 orange bannys managed by Jango. Revnet research will also get 2 Aliens. Revnet already has a milestone based budget that stays in effect, and Bananapus has had a budget of ~$120k that it's used. This additional budget is a top up for both of these projects.

We’ll also be testing the Bannyverse minter UX, but that has it’s own incentive structure.

We'll go to production as soon as we get to the other side of the month bug free.

Total accounting

Banny walks onto the beach with a beach bag, a beach chair, and a beach sun umbrella. huming along. The square sun is out and beaming.

He picks a spot and sets up shop. Staking the umbrella, unfolding the beach chair. Smearing sunscreen on himself. Struggling a bit with it all. Humming along, mumbling random shit thats on his mind.

He’s finally done and relaxes back in the chair under the umbrella. Lights a J.

After 10 seconds of just banny chillin smoking a J and enjoying the beach, Banny digs into his bag and takes out his apple vision pro and puts it on.

End scene.

https://open.spotify.com/track/4c2t8GQrZFMv0pKENyEv5O?si=726fb4c5adff4978

https://harpfeeder.bio/

https://open.spotify.com/track/5h9DOVwUB0JNCFfraUnHi2?si=2d50ff094de746ce

https://open.spotify.com/track/67Cs1ZAGIzy0m2iiF7UuQF?si=b02f2ef090fb4d59

https://open.spotify.com/track/6DHb14gwhqTDrLqDFgqjkh?si=6621bcde2f004fea

https://open.spotify.com/track/72cg4aDkmGG6jnUhlRtGHc?si=1ce67bd42f5447e4

Tokens in the Juicebox Ecosystem

$JBX

• Address: 0x4554cc10898f92d45378b98d6d6c2dd54c687fb2
• Function: $JBX is a revenue-backed governance body supporting the Juicebox ecosystem. Collects investments, fees from Juicebox V3 protocol, and governs other assets.
• Access: https://juicebox.money/@juicebox
• Key Features:
  • Mint $JBX using ETH based on the current issuance rate (~50,000 $JBX/ETH).
  • Option for $JBX buybacks if market price is better than new issuance.
  • $JBX buybacks and issuance split 50-50 between fee payers and $JBX governance.
  • Redeemable for accumulated revenues.
  • Governance rights to allocate shared treasury revenues, adjust issuance and redeem strategy.

$NANA

• Address: soon
• Function: $NANA is like $JBX but with no governance, no payouts, and with multi-chain support. It collects investments and fees from the Juicebox V4 protocol across chains.
• Access: soon
• Key Features:
  • Mint $NANA using ETH or other coins.
  • Option for $NANA buybacks if market price is better than new issuance.
  • Majority of $NANA buybacks and issuance governed by $JBX.
  • Redeemable for accumulated fees.
  • No governance, treasury runs as a revnet.
  • V4 adds multi-chain multi-token and multi-fork conveniences, verbiage changes, removal of rarely used functions, the ability to schedule multiple rulesets ahead of time, and other niceties and optimizations. It is experimental and not yet as stable as V3.
  • $NANA is a treasury-backed token across Ethereum Mainnet, Optimism, and any number of L2s into the future.

$REV

• Address: soon
• Function: $REV bets on the revnet ecosystem. It manages donations, investments, and revenues from building revnet tools and allocating to revnets.
• Access: soon
• Key Features:
  • Mint $REV using ETH or other coins.
  • Option for $REV buybacks if market price is better than new issuance.
  • $REV buybacks and issuance split 50-50 between fee payers and the revnet.eth multisig.
  • revnet.eth uses its balance to bet on revnets, making them more accessible, useful, and investible through apps, tools, and storytelling.
  • Redeemable for accumulated revenues.
  • No governance, treasury runs as a revnet.
  • $REV is built on the Juicebox V4 ($NANA) protocol.

https://open.spotify.com/track/72cg4aDkmGG6jnUhlRtGHc?si=80121d0a59a84968

October 30, 2023

$JBX is directly backed by the ETH balance in its Juicebox treasury, and also governs JuiceboxDAO and all its assets.

In this post, I’ll give my perspective on both of these value propositions. I’ll include some context as to how we’ve arrived at the current state of affairs, and where things appear to be headed.

$JBX's current distribution looks like this:

$JBX as an ETH-Backed Asset

$JBX has always been issued by its Juicebox treasury when receiving new ETH revenues or investments, at a slightly decreasing rate every 2 weeks. The protocol was deployed issuing 1m JBX/ETH, and now issues ~50k JBX/ETH. $JBX has also always been backed by unused ETH funds in this treasury via redemptions, at a rate determined by the project's current configuration.

This dynamic creates a price ceiling at which the protocol is willing to issue new $JBX when receiving new ETH, and a price floor at which the protocol is willing to disburse ETH as $JBX is burned.

As long as JBX/ETH liquidity providers exist, $JBX has also been tradeable on AMMs at a price between its floor and ceiling.

Before October 2023, all inbound ETH investments and revenue into JuiceboxDAO via the Juicebox protocol went into the treasury and new $JBX was issued at the issuance rate. As of October, the protocol routes inbound ETH payments to the source willing to provide the most $JBX possible to the payer. If the AMM quotes a better price than the issuance rate, inbound ETH will be used to swap on the open market instead of being absorbed by the treasury to issue new $JBX.

There are several implications to this recent change:

• Projects on the protocol paying a 2.5% fee into the JuiceboxDAO treasury from outbound payments now receive $JBX at the market rate, often leading to significantly better yields.
• JuiceboxDAO's reserved token recipients also now receive $JBX at the market rate, often leading to better incentives.
• Unless the market price approaches the issuance rate, JuiceboxDAO now forgoes revenue in order to buyback $JBX from the open market. If it prefers to take in revenue, it must raise its issuance rate.
• Investors who want the best deal for $JBX while the AMM price is better than the issuance rate should buy directly from the AMM as it will bypass the reserved allocation – buying from the Juicebox will always incur the reserved rate.

Meanwhile, JuiceboxDAO has been spending from its treasury to fund protocol development and ecosystem support in adherence to its governance process, reducing the value that backs outstanding $JBX. As of this writing, there's about $1,000,000 USD worth of ETH in the treasury.

$JBX as a Governance Token

$JBX is also responsible for governing the operations of JuiceboxDAO and its multisig. This includes administering its Juicebox treasury – tuning $JBX issuance and redemption criteria, specifying payout cadence, etc – as well as other assets that it holds.

Apart from its meaningful $JBX balance, the most potent of these assets is an upcoming allocation of $NANA tokens, an experimental Juicebox fork trying its hand at supporting cross-chain projects. $NANA is the token of this fork's protocol project, and therefore works the same as $JBX with one major caveat: it runs as a revnet, meaning its treasury is fully automated with no possibility of tuning $NANA issuance and redemption criteria or specifying payouts. The rules it sets from the get-go will be the rules it follows forever.

If $NANA is successful in driving revenues, $JBX will manage a meaningful portion of tokens that can access this revenue. $JBX might even consider its role in making $NANA successful by wielding its initial allocation productively.

My observations and suggestions

Now that the Buyback component has been successfully installed, $JBX should realize that its mission-critical development work is complete. It will now operate squarely in the realm of experimentation for the sake of growth.

As such, it should consider its expenditures wisely.

• I think it's more likely to find growth from reducing payouts rather than expanding payouts, empowering $JBX to grow itself rather than taking from its bottom line. I think growth is more likely instigated at the network level rather than centrally-strategized by a team paid in a currency other than $JBX.
• All payouts being considered from JuiceboxDAO should be framed as an investment. For each proposal to pull funds from the treasury backing $JBX, JuiceboxDAO should expect to receive an asset to govern in return that represents this investment.
• Instead of spending the ETH that backs $JBX, JuiceboxDAO should consider spending its $JBX balance.
• Instead of allocating reserved tokens to individual entities, JuiceboxDAO should consider allocating to itself only for proposal-based distribution, or to $NANA staking rewards once those prove successful.
• In general, $JBX should consider operating more and more like a revnet in order to empower $JBX and minimize operations. A $JBX revnet stands a chance at soliciting new investments, new builder participation, and new fee-paying customers.
• As its operational needs are reduced, $JBX should consider moving from using a multisig proxy to being governed onchain directly by holders.
• A renewed focus on $JBX to grow the protocol benefits from having significant unspent ETH backing it in the treasury.

Versions

It's worth noting there are two versions of $JBX in circulation, an old one and a current one. The current one is issued from the latest version of the protocol where all JuiceboxDAO funds are custodied. The old version was issued from the initial version of the protocol which no longer custodies funds for JuiceboxDAO. Old $JBX can be exchanged for new $JBX at any time.

JBX: 0x4554CC10898f92D45378b98D6D6c2dD54c687Fb2

Old JBX: 0x3abf2a4f8452ccc2cf7b4c1e4663147600646f66

Migration instructions

https://www.swisstypefaces.com/fonts/simplon/#font

https://github.com/rev-net/revnet-writing/blob/master/whitepaper/revnet.pdf

A group of folks are formalizing Retailistic ideas into deployable contracts and easy to use web interfaces. We're calling these things Revnets. Below is some contextual positioning based on other well known business models. Join in https://discord.gg/nT3XqbzNEr.

A Revnet serves as a productive place for organizations to point their revenues, encouraging:

1. Growth-oriented participation from investors, builders, and customers alike.
2. Sustainable fee structures that work for all participants.
3. Transparent, public-facing operations without priviledged powers or governance burdens.

Revnets are great for monetizing and growing open source applications, collecting fees from onchain mechanisms, managing loyalty credits, and potentially many domains not yet explored. They are an efficient evolution of capitalism only expressible through blockchain contracts.

Unlike corporate cap-tables:

1. Revenues flow into a smart contract, not a company bank account.
2. Shares are fully backed by revenues and issued when new payments are received.
3. Access to revenues requires the forfeiture of shares by those choosing to prioritize immediacy over more valuable access later.

Unlike governed DAOs:

1. Entry and exit conditions are immutable, set during network deployment.
2. Tokens are backed by a common treasury, motivating collaboration by self-interested participants.
3. Hostile takeovers and rug pulls are prevented.

Unlike revshare agreements:

1. Retail customers participate in the network's revenue growth alongside the "creator class".
2. Access to revenue is distributed, not actual revenue – those who wait to access share more.
3. Future generations of investors and customers support earlier generations via scheduled price increases.

Unlike orderbook markets:

1. Price stability is maintained through ceiling and floor mechanisms, both contributing to increased network value.
2. Long-term holders are prioritized over those timing market peaks.
3. Pump and dumps benefit the network rather than exploit it.

Unlike builder-owned companies:

1. A percentage of newly issued shares can be reserved for builders, decided at project inception.
2. Builder shares function like all other shares, and so must be excersized to access the network's revenue.
3. Strong contractual guarantees protect investors and customers against scams.

Unlike pyramid schemes:

1. Revenue is generated through genuine value-adding business activities instead of relying on recruitment.
2. Operations are transparent and within legal frameworks, allowing participants to understand how revenue is generated and distributed.
3. Debt is assumed by fee-paying customers and voluntary investors, and is passed incrementally, predictably, and ceremonially from one generation of voluntary participants to the next, without need to orient towards retail extraction.

Unlike retail extractive businesses:

1. Customers are rewarded for network growth efforts.
2. Network shares are returned to customers with every fee payment.
3. Investors and customers are treated equally if they engage at a similar point in time.

For specifics on how Revnets operate, see these posts https://jango.eth.limo/?tags=retailism

https://mern.eth.limo/

https://arxiv.org/pdf/2307.12008.pdf

Settings

• Settings > Trackpad > Tracking speed = fast
• Settings > Trackpad > Click = light
• Settings > Trackpad > Tap to click = true
• Settings > Keyboard > Key repeat rate = fast
• Settings > Keyboard > Delay until repeat = short
• Settings > Keyboard > Keyboard navigation = true
• Settings > Keyboard > Keyboard shortcuts… > Modifier keys > Caps Lock Key = Control
• Settings > Keyboard > Keyboard shortcuts… > Modifier keys > Control Key = Caps Lock
• Settings > Keyboard > Keyboard shortcuts… > Default everything to false
• Settings > Keyboard > Keyboard shortcuts… > Mission Control > Mission Control = control+k
• Settings > Keyboard > Keyboard shortcuts… > Mission Control > Application windows = control+j
• Settings > Keyboard > Keyboard shortcuts… > Mission Control > Mission Control > Move left a space = control+h
• Settings > Keyboard > Keyboard shortcuts… > Mission Control > Mission Control > Move right a space = control+l
• Settings > Keyboard > Keyboard shortcuts… > Mission Control > Mission Control > Switch to Desktop 1 = control+g
• Settings > Keyboard > Keyboard shortcuts… > Keyboard > Move focus to active or next window = command+control+l
• Settings > Keyboard > Keyboard shortcuts… > Keyboard > Move focus to the Dock = control+;
• Settings > Keyboard > Keyboard shortcuts… > Keyboard > Move focus to the floating window = command+control+j
• Settings > Keyboard > Keyboard shortcuts… > Keyboard > Move focus to next window = command+control+h
• Settings > Keyboard > Keyboard shortcuts… > Screenshots > Save picture of screen as file = command+3
• Settings > Keyboard > Keyboard shortcuts… > Screenshots > Copy picture of screen to the clipboard = shift+command+3
• Settings > Keyboard > Keyboard shortcuts… > Screenshots > Save picture of selected area as file = command+4
• Settings > Keyboard > Keyboard shortcuts… > Screenshots > Copy picture of selected area to the clipboard = shift+command+4
• Settings > Keyboard > Keyboard shortcuts… > Screenshots > Screenshot and recording options = command+2
• Settings > Keyboard > Keyboard shortcuts… > Spotlight > Show Spotlight search = control+space
• Settings > Appearance > Appearance = Dark
• Settings > Appearance > Accent color = Pink
• Settings > Sound > Play sound on startup = false
• Settings > Sound > Play user interface sound effects = false
• Settings > Notifications > Show previews = Never
• Settings > Notifications > Allow notifications when the screen is locked = false
• Settings > Notifications > Application Notifications = turn them all off
• Settings > Control Center > Wi-Fi, Bluetooth, Airdrop, Display, Sound, Keyboard brightness, show battery percentage = Show in Menu Bar, On
• Desktop & Dock > Size = smallish
• Desktop & Dock > Position on screen = Right
• Desktop & Dock > Minimize windoes using = Scale effect
• Desktop & Dock > Animate opening applications = false
• Desktop & Dock > Show recent applications in Dock = false
• Desktop & Dock > Automatically hide and show the menu bar = Always
• Desktop & Dock > Default web browser = Brave
• Desktop & Dock > Automatically rearrange Spaces based on most recent use = false
• Desktop & Dock > Group windows by application = true

System

• Install capsules font
• Install homebrew
• Install xcode
• Install vscode
• Install zsh
• Install Oh My Zsh
• Change shell to zsh
• Import .zshrc
• Install zsh-autosuggestions custom plugin
• Import .vimrc and install plugins
• Customize terminal settings
• Install gpg Suite
• Install pinentry (pinentry-mac)
• Install gitHub CLI
• Configure gpg key with gitHub
• Configure gitHub authentication token
• Set .gitconfig user name and email
• Install node
• Install nvm
• Install yarn
• Download croptop
• Download brave
• Clear all items from dock except finder, croptop, brave, discord, terminal, quicktime, settings, and vscode.

Dev

• [] Install forge
• [] Install Solidity VSCode Extension
• [] Add the following VSCode Settings:

  // Terminal scrolls back farther.
  { "terminal.integrated.scrollback": 100000 }
  

• []

My observations and understandings of how networks generally behave in nature. Those of atoms, cells, organisms, groups.

TLDR this is how a network forms:

... once instigated, the network eventually will fade away. When it does, it as a living energy owes more to those participants who dance until the network's very end than it does to those who correctly called the top and left before everyone else.

A money and marketplace that recognizes this and figures out how to express these values might end up being the backbone of very attractive and resilient networks.

Networks

A network is a complex interplay of participating things. It is the energy that makes coordination more than the sum of its parts.

A network is productive so long as it is actively participating with its out-of-network environment. This is true if the network has 2 participants, or 1,000,000. If a network’s participants are in motion — either entering or exiting — it is alive, in a state of creation, a structure giving new shape to the moment's energy. Without motion, it's left scheming as to how it may eventually catalyze productivity, or be made productive by the whims of its external environment.

A network's energies

A network thus has kinetic and potential energy. Its kinetic energy is this rate of its participants’ motion, entering and exiting — how alive a network is at any point in time. Its potential energy is in its number of participants who can exit at any time, and in the communication between participants as their behavior can motivate new entries and exits. It takes more focused energy or chance to attract/repel the 3rd participant than it does the 1,000,000th participant.

Minimum viable network

At 2 participants, a network’s potential is at its lowest — the hardest state to muster any motion from since no one has a good reason to enter or to exit. Agency, responsibility, and communication are consolidated as much as possible. The “upside” potential is limitless in theory, but tangibly its potential is insignificant since one kinetic act would dissolve it entirely. Any potential energy that does exist is derived entirely from the behavior and relationship of the 2 participants, otherwise much is left to the unlikely chance of interaction with the external environment.

Network expansion is very productive

When a new participant enters a network, the network distances itself from its lowest energy state. More energy is now required to blow it all up, agency and responsibility spread out a little, there's more multi-dimensional communication throughout, it becomes clearer to others how and why they should join too, and the probability of chance interactions with the broader environment increases. In this moment of kinetic energy, the network also gains in potential since there now exists the requisite for motion when this new participant eventually exits the network. This kinetic energy turns some extrinsic potential energy into intrinsic potential energy — which will have to be spent as kinetic energy later. Win for the current network and win for the future network.

Network contraction is also productive

When a participant leaves, the network consolidates its energy. It becomes easier for the resulting smaller network to renegotiate its direction. Agency and responsibility increase for remaining participants, communication streamlines, and participants considering entering might reconsider the move. All are now less motivated to enter or exit as there is less going on, less stress. The network turned some of its intrinsic potential energy into kinetic energy. Win for the current network, but its future is now a little less determined.

Take away

The manner with which our human network allocates resources might can learn something from how networks deal in energy. A money and marketplace that expresses the value found in the organic motion between the ebbs and flows of the network it facilitates might outcompete those more immediate-growth-at-all-costs, after all.

Retailism hints at a how such a network could manifest: https://jango.eth.limo/3EB05292-0376-4B7D-AFCF-042B70673C3D/

Retailist networks blur the lines between different types of network participants, but can still mean different things for people with different intents.

For context as to why the following statements apply, look through these short posts introducing Retailism, understanding Retailism through the lens of CAC and LTV, and modeling Retalism.

Devs and Entrepreneurs

Deploying a Retailist network in support of a project can be productive for devs and entrepreneurs who:

• are building open source software or smart contracts, and are unsure how to monetize its use to support themselves, their network, and their product’s evolution.

• believe a network of their product’s fans is more capable of growing itself rather than growing through their strategic efforts.

• prefer to spend their time building rather than shilling.

• prefer encouraging their network to teach each other, troubleshoot issues, and contribute to solutions alongside them.

• prefer to scope down the burden of management and treasury governance, or absolve these burdens altogether.

• prefer letting anyone invest from the get-go.

• prefer adhering to smart contracts rather than legal contracts.

• prefer relating to a network’s value on equal terms alongside all investors and customers.

• prefer working alongside their users rather than extracting from them.

It is not recommended for builders who:

• are making products which by their nature require centralized operation or the maintenance of secrets.

• want to remain in control.

• prefer building exclusive relationships with investors.

Investors and Capital Allocators

Chipping in to a project’s Retailist network can be productive for investors who:

• want strong guarantees as to what might happen to their money given a few tractable projections.

• want to have their allocations derisked, with clear time horizons, success conditions, and failure signals.

• want strong guarantees as to how they’ll be able to access their money once allocated.

• want to be among a broader network of incentivized parties working towards a shared goal.

• prefer adhering to smart contracts rather than legal contracts.

• prefer relating to a network’s value on equal terms alongside all devs and customers.

It is not recommended for investors who:

• want to remain in control.

• want to operate within familiar corporate structures.

• prefer building exclusive relationships with devs and entrepreneurs.

• prefer orienting towards retail extraction.

Customers and Users

Paying fees to a project’s Retailist network can be productive for customers who:

• wish to be treated as investors.

• believe their word-of-mouth and feedback have value.

• don't mind paying for things but want to know exactly what they're paying for and where the money is going.

• do not want their choices to be taken advantage of.

• prefer relating to a network’s value on equal terms alongside all devs and investors.

Related Links

Intro to Retailism: https://jango.eth.limo/9E01E72C-6028-48B7-AD04-F25393307132

A Retailistic View on CAC and LTV: https://jango.eth.limo/572BD957-0331-4977-8B2D-35F84D693276

Modeling Retailism: https://jango.eth.limo/B762F3CC-AEFE-4DE0-B08C-7C16400AF718/

Retailist networks are deterministic, meaning all networks configured the same way will have the same trajectory.

Each network is defined by fixed rules that change in fixed ways over a fixed time frame known as a “generation”.

Rules

Configuring a retailist network requires making three choices, and allows for five additional optional choices:

• Currency (optional)

  In which currency will the network store its value? ETH is used by default.

• Initial issuance rate (optional)

  At the network’s onset, how many $TOKENs will be issued when it receives 1 ETH? The default is 1.

• Generation duration (required)

  How long is a generation? Everyone who joins the network during a generation will receive the same amount of its $TOKENs when they pay ETH.

• Generational tax rate (required)

  By what percent will the network's $TOKEN issuance rate be reduced between generations?

• Exit tax rate (required)

  How much less does a $TOKEN holder receive when accessing the network’s ETH immediately before any another $TOKEN holder does?

  This is specified as a percent that’ll be input into the formula t / s * ((1-r) + r / s), where t is the network’s ETH balance, s is the total $TOKEN supply, and r is the tax rate. 0% suggests no tax, 100% suggests $TOKEN holders can never access the treasury because they’re taxed entirely.

• Deploy tax (optional)

  The amount of $TOKENs to mint at the time of deployment for the deployer.

• Boost duration (optional)

  The amount of time to apply a boost for, which pre-allocates a percentage of newly issued tokens to some beneficiary as the network receives ETH.

• Boost rate (optional)

  The percentage of newly issued $TOKENs to pre-allocate when the network receives ETH during the boost period.

Tensions

As it unfolds, each network will have a generation-over-generation growth rate which describes how much ETH a network receives over time, and an exit rate which describes what percentage of $TOKEN holders leave during each generation.

Tensions arise when considering how a network’s rules will affect these two tendencies:

• networks with longer generations or a flatter generational tax rate leave room for more equal access over time to entice newcomers, but may lack energy from incumbent participants whose contributions are less recognized.

• networks with a larger exit tax reward more committed network participants, but may dissuade someone from making a commitment to the network in the first place since they’ll have less freedom to leave.

• networks with a deploy tax or boost can acknowledge the non-financial forms of participation which are often the subjects around which they revolve, but may also create governance burdens and spoil fair launch narratives.

Each network should consider its own unique circumstances when navigating these trade-offs, keeping in mind that each new $TOKEN holder will eventually become an elder one.

Playground

Play around with these levers in this spreadsheet. Adjust the rules and set a few projections at the top to see how the outcome changes.

• the first graph shows the amount of ETH each $TOKEN can be redeemed for at any point in time. Notice how this number can only go up or stay still, depending on how much motion (new entries, new exists) there is in the network.

• the second graph shows the amount of ETH that guarentees to back the last $TOKEN left in the network after everyone else has exited, at any point in time.

• the third graph shows the percent rebate that all payments into the network over time would yield if the $TOKENs the payment produced were immediately redeemed. Notice how the amount converges on a percentage, approaching from the bottom as preminted $TOKENs get diluted or from the top if no preminted $TOKENs are specified.

• the last shows the total value of all the $TOKENs allocated to boosting over time, if none were redeemed. Notice how even after boosting stops, the potential value of the allocated $TOKENs continues to rise as their redemption value rises.

• the table gives all context and calculations from which the graphs are derived. It shows how the network's dynamics change over time given the provided projections.

Related Links

Intro to Retailism: https://jango.eth.limo/9E01E72C-6028-48B7-AD04-F25393307132

A Retailistic View on CAC and LTV: https://jango.eth.limo/572BD957-0331-4977-8B2D-35F84D693276

The Software-as-a-service business world loves to consider the cost per acquisition of a customer (CAC) and compare it to the lifetime value of that customer (LTV). It follows that if LTV > CAC, the business owners make money and can therefor spend money doing work to improve this ratio in order to make more money, etc. The bigger the LTV and the smaller the CAC, the more leverage the business has.

Imagine a software product, virtually free to serve once created. Traditionally, businesses are willing to pay some amount of CAC, say $0.99, to Twitter for showing someone an advertisement who ends up paying an LTV of $1 for access to their software, a $0.01 profit for the business owners. They must do this instead of simply charging $0.01 for the software because the customer would have otherwise never contemplated the exchange. If instead the customer pays the $1 after having been convinced of the software’s benefits from other customers’ posts they see on their feed, the business owners profit the full $1 at the expense of the customers.

Retailistic software distribution encourages growth differently by presuposing a networked environment where participants share the things they like with one another, help one another learn how to use things, and troubleshoot problems together. Instead of treating CAC as an input that yields LTV — i.e. spending less-than-$1 on Twitter ads yields a $1 purchase, the “CAC” incurred by the network is paid out at the time the “LTV” is paid in — i.e. the network issues less-than-$1 worth of its $TOKEN to whoever pays in $1.

Now, why would anyone make a fuss about exchanging their $1 for $0.99 back? Isn’t that just like paying the network $0.01? How is this encouraging anyone to spread the word about the software?

The fuel comes from the fact that the $0.01 in profit is being paid to the network owners who are the current $TOKEN holders. Although someone’s newly issued $TOKENs are only redeemable for a less-than-100% rebate at the time of their payment, their $TOKENs begin to be backed by the accumulation of future $0.01 contributions to the network. The more that is paid over time, the more the elder $TOKENs are worth, encouraging the network supporting the software to propegate itself.

Distributing software through a Retailist framework encourages people who appreciate the body of work to pay its fees even when free alternatives are available, since what’s being sold isn’t access to the software-as-a-service, but rather support of the software-as-a-network. At the least, the framework makes for a more compelling donation option for open source. More optimistically, it can supplant how we think about business models and sustainability in a networked world.

Related Links

Intro to Retailism: https://jango.eth.limo/9E01E72C-6028-48B7-AD04-F25393307132

WHAT

A business framework where wealth is exchanged programmatically over time from newer participants to elder ones, and where investors and customers are treated as alike participants. The “bag”, or the debt, is passed incrementally, predictably, and ceremonially from one generation of voluntary participants to the next, without need to orient towards retail extraction. Nothing is free, but things reliably tend towards being free as a network grows over time.

WHY

Retailism is neither corporate capitalism, which defines generations through the passing of a bag along Series A, B, and C investors, eventually selling to retail who continues this cycle of amplifying narratives that pump and dump bags. Nor is it corporate non-profitism, which obfuscates risks and incentives altogether.

These are both increasingly fragile forms of production within internet-native markets since their requisite delineation between capital and labor becomes fuzzy – does an AI assist you or do you assist it? Does your crypto currency work for you or do you work for it? Do your social networks serve you or do you serve them? Hard to say, on the internet the act of investing and consuming are often intertwined, and tail-risks of a network's failure are spread throughout it.

Retailism hints at a progression of the status quo that can outcompete within a broader capitalist marketplace of -isms by empowering the producer-consumer.

WHO

Devs and communities will choose a Retailist business structure when they prefer their outcome to be oriented towards maximizing the network's self-propagation while minimizing the growth potential of any party with privileged access and exploitable liabilites. They'll understand their work to have value while also understanding a network's preference to work for itself once instigated.

WHEN

The Retailism framework is too fragile to exist if a rent-seeking feduciary facilitating the handling of money and the generational handoffs is required. It can only outcompete as an encoded contract between network participants enforced by a blockchain, a recent breakthrough.

It is now possible to encode this without any new code at all through onchain protocols like Juicebox.

HOW

For each network, the framework depends on only three variables:

• Entry tax

  How much does the cost to enter the network change from one generation to the next, and how often are generations?

  This is encodable from the Juicebox protocol by kicking off the treasury with a $TOKEN issuance rate, and using a discount rate with funding cycles to consistently decrease the issuance rate of $TOKEN forever forward, tending toward zero in quantized chunks.

• Exit tax

  How much is the tax for opting out of the system?

  This is encodable from the Juicebox protocol using a redemption rate, leaving those $TOKEN holders who stick around with proportionally more as others redeem their $TOKENs for a chunk of the treasury.

• Dev tax

  How will the startup work be valued? How much boosting should the network start with, favoring whom, and for how long?

  This is encodable from the Juicebox protocol using a premint of $TOKENS, and a reserved rate to devs and $TOKEN stakers effective until a future date when it is auto-removed via a scheduled funding cycle reconfiguration.

Once in motion, there is only one access point to the $TOKEN-issuing public treasury. Network fees should be routed to this alongside any future investments.

If a liquidity pool with a better price than the current issuance rate exists, inbound payments should be routed to it instead. The issuance rate dampens upward hyperbolic price manipulation of this pool by setting a price ceiling, and the redemption rate dampens downward manipulation by setting a price floor that increases with each subsequent redemption. These ensure participants a window of opportunity for each generation, with a frame that can only progress upward over time.

The rules should be as permanent as the blockchain on which they are encoded, making the Retailist framework management-free and governance-free.

There are no perfect numbers for these variables – it is impossible to know a priori what fair market values are for any particular network. A Retailist strategy should become successful if and only if its initial configuration encourages devs to dev and networks to network in peace.

Related Links

A Retailistic View on CAC and LTV: https://jango.eth.limo/572BD957-0331-4977-8B2D-35F84D693276

Modeling Retailism: https://jango.eth.limo/B762F3CC-AEFE-4DE0-B08C-7C16400AF718/

Retailism for Devs, Investors, and Customers: https://jango.eth.limo/3EB05292-0376-4B7D-AFCF-042B70673C3D/

https://open.spotify.com/album/5ooM43VDBakFiWWnD5tfxg?si=ayEzA81PRCCKs2dVGjpa-A

https://open.spotify.com/track/6Mhgvrv4zd82FrCeuASW44?si=7b3c6d40332e46ed

A version 3.1.1 of payment terminals was deployed today on Mainnet, Goerli, and Sepolia for Juicebox projects to use. The PR is here https://github.com/jbx-protocol/juice-contracts-v3/pull/44.

This 3.1.1 terminal:

1. is fully backward compatible with the 3.1 terminal interface.

2. uses a new 3.1.1 Payment Terminal Store, whose views are fully backward compatible with the 3.1 Store interface.

3. enforces the JBX membership fee when funds leave a treasury through redemptions while the project’s redemption rate or ballot redemption rate is less than 100%. This is currently a 2.5% membership fee, changeable by JBX holders up to 5%.

4. adds the ability for data sources to pass arbitrary bytes to the delegates it specifies.

5. fixes a low severity bug - there was still one case where a project’s payouts could be reverted if sent when a recipient project didn’t have a terminal installed.

6. optimizes gas further - the fee property was being loaded from storage often, and is now cached better.

7. improves all contracts’ natspec documentation.

8. specifyies all imports explicitly in the files from which they’re used.

9. removes the leading underscore from function argument names in interfaces.

Clients can choose to deploy new projects with this 3.1.1 terminal, and admins of active projects can add this terminal and migrate funds to it so long as the project’s allowSetTerminals and allowTerminalMigration flags are currently true.

The code and tests were authored by Jango, Dr Gorilla, Viraz, and 0xBa5ed. It will be published on NPM as verison 4.0.0 at @jbx-protocol/juice-contracts-v3.

https://open.spotify.com/track/4sLti16iYoXH4l8egkD6KM?si=bcddf8a819c846e7