tldr

• sory i deleted your profile images. you’ll need to reupload them
• if you have CCs, you will save more sats and spend CCs more often now
• territory revenue is paid out when the action is paid for, ie immediately
• satistics has autistic (ie excellent) levels of detail about how you’re spending and earning money
• every payment on the SN has a transaction page, and if you’re involved in the transaction, you can see relevant details about your involvement in the transaction (click on a row in satistics to check it out)
• payment retries are less buggy
• zap retries fallback to CCs automatically if the receiver’s wallet fails enough times
• the analytics pages, for the site, territories, and your account, have more detail (and much more will come soon that isn’t exposed in the gui yet)

what

My first professional mentor taught me that “no one cares how you did it, just what it does.” My goal with this release was to upgrade SN’s guts while maintaining parity otherwise. Some advantages of the new guts can be experienced immediately, but the main what of this change is easing system malleability by an order or two of magnitude.

what it does so far

1. territory revenue is paid to the territory founder immediately, when the transaction happens
2. you can now pay for things on SN with mixed assets, e.g. if your post costs 100 sats and you have 20 CCs and 50 reward sats you’ll only need to pay a 30 sat invoice noncustodially
3. depending on where the splits are sent, we can use a different, preferred asset for each destination, e.g. if you’re zapping someone 100 sats and have 30 CCs, the CCs are used to pay the sybil fee, and you only pay a 70 sat invoice noncustodially
4. satistics records not only how much of which asset you spent or earned on an action, but also the effect of the spending or earning on each “asset” balance. Basically, at a glance, you can audit that things are working as you expect them to.
5. Every payment, aka transaction, has a transaction page with a visualization of the incoming asset splits and the outgoing destinations. Again, at a glance, you can audit that things are working as you expect them to.

what it will do over time

1. this micropayment engine is agnostic to the payment method. previously we assumed all payments would use bolt11s, but we can now add bolt12 and possibly even onchain payments without hacks or other dysfunction.
2. we’ll be able to fine tune the incentives and side effects of existing behaviors to better fit with what we learn over time
3. we can make better use of CCs to get you more sats
4. we can make noncustodial splits while maintaining our existing retry UX
5. we can add new payment and earning related experiments with relative ease

why

1. When we zap someone noncustodially on SN, or merely withdrawal money, it’s possible that the payment doesn’t succeed for weeks afterward. If the payment fails, it could take up to two weeks for us to learn that too.
2. When we pay for something noncustodially on SN, it’s possible that the payment fails for reasons outside of our control. When that happens, we don’t want to lose the related work.
3. When we pay for anything on SN, we would like to know which source of money we spent, all the places it’s sent to (potentially many), and what effect it had on our reward sat and cowboy credit balances on SN.
4. When we pay for things on SN, we want to prioritize spending our cowboy credits over our sats. We also want to not use noncustodial payments if we have reward sats that can be used instead.
5. The game theory of certain actions on SN are effected by the context and who is performing them. We want to be able to adjust, conditionally, the incentives of an action depending on the context and who is performing them.
6. We want to add new paid features and incentives, or refine existing ones, with some regularity, so adding new paid features should be almost as easy as adding other feature.
7. Most of the things we pay for on SN have side effects conditional on SN receiving money (potentially two weeks in the future), e.g. a zap ranks an item higher relative to other items, the UI of every stacker needs to reflect the new amount, money needs to be sent to the territory founder, money needs to be sent to the OP (and forwards), excess estimated routing fees need to be refunded, push notifications need to be sent, the rewards pool needs to be populated, etc.

Put together, this means that we need to remember a lot of non-payment things in relationship to our payments, do detailed accounting, retry payment failures, make arbitrary and numerous fine adjustments to the effects of payments depending on the context, refund money when we don’t get what we pay for, and anticipate and respond to payment events weeks in the future. Automatically.

That’s what this thing I call a micropayment engine aims to do. I think of the requirements like an N-set venn diagram and the mircopayment engine is the middle where they all overlap.

sorry

1. As a result of this change, I accidentally deleted all of your profile images. When we delete things, we try to delete them as deeply and permanently as possible for the sake of your privacy, and it appears I’ve shot us in our feet. You’ll need to reupload them.
2. The site speed has been sluggish for the last few weeks, a dimension I neglected while working on these changes. These changes in many ways worsen performance, but I’ll be tuning things over the week and things should be back up to snuff soon.
3. We’ve neglected most nonwallet and nonpayment dimensions of the site. Using bitcoin The Right Way is hard and a lot of what we’re doing is on a weird little bleeding edge no one yet cares about. We’ve been having to invent stuff and learn the hard way as we go. This change is intended to encapsulate the wallet and payment stuff we’ve learned and get it out of the way so that we can move fast on the stuff that matters again.

what’s next

1. I’m going to be fine tuning the performance of the micropayments engine and fixing all the bugs I introduced

2. Broadly, my next mission is to greatly simplify and reduce the complexity of the site

3. all of our complexity budget is spent on doing bitcoin The Right Way, so everything else needs to be that much more intuitive

4. e.g. our onboarding and introductory UX is a disaster

5. in this vein, one of the first things I’m going to work on next, in addition to onboarding, is No Trust November - where we remove trust from ranking and downranking while also fixing/aligning the incentives of boost and downzaps.

6. then we proceed with the grand plan of making territories great again

7. ek is getting some R&R, so give him a break would ya

8. sox is preparing a grandmother f’ing amazing upgrade to the editor which we have plans for that you probably wouldn’t believe if I told ye and i want to keep secret for extra mindblow factor