Counterparty Community Chat - May 12th Notes #168
davestaxcp
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Counterparty Community Chat - May 12th Notes
Counterparty Community Chat Hosted by @davestaxcp using Twitter (X) Spaces
All are welcome to join next time, hosted (usually) on last Sunday of the month, usually at USA Pacific 1PM
Contact me if you'd like me to schedule a specific time for the next space to discuss any active protocol changes or future protocol proposals after they are documented in the Github!
Audio Link: https://x.com/i/spaces/1XGygmpQgQExM?s=20
3:45 space starts
10 year anniversary of rare pepe at BTC Vegas genesis stage w/ DJPEPE
https://youtu.be/BJgqnXXmBVk
https://x.com/NFCsummit
Counterparty artists featured at event hosted by DITA (https://x.com/ditacrypto):
https://x.com/PepeVault1/status/2058266352259866646
Events during Lisbon:
https://x.com/PepeVault1/status/2057183916037963900
https://github.com/CounterpartyXCP/counterparty-core/releases
https://github.com/CounterpartyXCP/counterparty-core/milestones
#167
Mainnet activation block: 952500 (approximately mid-to-late July 2026)
Testnet3 activation: 4961000
Testnet4 activation: 136000
Subterranean hosted panel w/ Shawn, Tommy and DJPEPE + recap of BTC Vegas 2026
Counterparty Firsts , Rare Pepe firsts, read letter of closing of Rare Pepe Directory
Scientists lore.... first Curators on Counterparty
ScarceCity + BMAG auctions - 99+ pieces of art
Concert with Afroman, Kane Mayfield, DJ Pepe, Riff Raff, Bobby Shmurda, Mr Mixx, Kid Lennon
https://x.com/FAKERARES_XCP/status/2046944438505586939
Pepe Penthouse Party w/ Bobby Zoo
focus on publicity for input and time for infrastructure providers
current proposal is modest
headline features:
Add AMM (Automated Market Maker) liquidity pools by Dan Anderson
Add support for indefinite DEX orders
MANY bugfixes, fairminters, utxo attachments, btcpay bugs, supports , multiple Electrs backends changes (warning for default settings etc)
Node is now more reliable for optional dependencies
happy to see Tatiana and Mr.BitcoinBeast help push forward some enhancements for using Counterparty Inscriptions + Ordinals w/ music files etc
everyone wanted indefinite DEX orders (limit orders), and max expiration now 455 days is just max number that can be put into code
Dan did comment on this later after the chat:
everyone is excited about it, and we are all pretty used to it
will NOT be for BTC pools like 'BTC/XCP people trade on exchanges'
ONLY for pairs like XCP/PEPECASH
instead of matching against DEX limit orders, you can match with pools
pools create a new token , can add to pool or withdrawl.
6000 lines of code
works for ALL pairs (excluding BTC)
so for divisible pairs (and high volume) pairs like XCP/PEPECASH makes sense... but what about lower liquidity or very small issuance pairs (FDCARD for example)
Adam discusses this minimaly in the space, but Dan Anderson explained it further later after the space:
"Here’s the combined, cleaned-up guide:
Liquidity Pools, LPs, Fees, and Pool Price
Think of an LP as someone willing to buy or sell at all times.
In a Uniswap v2-style AMM, the pool does not place manual bids and asks. Instead, it uses a reserve ratio and the constant product formula:
x * y = k
Where:
x = reserve of asset A
y = reserve of asset B
k = constant product
When someone buys one asset from the pool, they add the other asset to the pool. That changes the reserves, which changes the price automatically.
What an LP is really doing
An LP is not just “providing liquidity.” An LP is volunteering to be the market maker.
The pool is always willing to buy or sell. The LP earns fees for taking the other side of everyone’s trades.
A simple way to say it:
Key outcomes
1. The LP is always both buyer and seller
The pool is always available. If people want to buy TOKEN, the pool sells TOKEN. If people want to sell TOKEN, the pool buys TOKEN.
2. The LP accumulates the weaker asset
If everyone sells TOKEN for XCP, the pool ends up with more TOKEN and less XCP.
The LP is effectively buying the asset people are dumping.
3. The LP gives up the stronger asset
If everyone buys TOKEN with XCP, the pool sells TOKEN and accumulates XCP.
The LP is effectively selling the asset people are chasing.
4. LPs earn fees for taking inventory risk
The LP earns trading fees because they are taking risk. They are always exposed to both sides of the market.
Fees are compensation for being available as liquidity.
5. LPs do best with two-way volume
The best environment for LPs is lots of back-and-forth trading around a range.
One-way price movement is harder, because the LP keeps selling the winner or buying the loser.
6. LPs suffer impermanent loss when price trends hard
Impermanent loss means the LP may underperform simply holding both assets.
Plain English:
7. Pool depth controls slippage
A small pool creates large price movement from small trades.
A deep pool creates smoother trading and better price discovery.
A shallow pool is mostly symbolic. A deep pool is real liquidity.
Fees
The fee structure is:
So an XCP/TOKEN pool has a 0.5% fee.
A TOKEN/TOKEN pool without XCP has a 1% fee.
This makes sense because non-XCP pairs are probably more illiquid, more volatile, and harder to price. They need higher fees to compensate LPs for taking more risk.
Initial pool price
The creator sets the initial pool price by choosing the initial deposit ratio.
For example, if the creator deposits:
1,000 TOKEN
10 XCP
Then the starting pool price is:
1 TOKEN = 0.01 XCP
or:
1 XCP = 100 TOKEN
The pool does not know the “true” market price. It only knows the ratio of assets deposited.
What happens if the initial price is wrong
If the initial pool price is wrong, traders can buy or sell against the pool until the price corrects.
If TOKEN is too cheap in the pool, people will buy TOKEN from the pool.
If TOKEN is too expensive in the pool, people will sell TOKEN into the pool.
This arbitrage changes the reserves and moves the pool toward the market price.
So:
The person who created the pool may lose value if they set the initial ratio badly.
Depositing after the pool exists
Once a pool exists, future LP deposits must match the current pool ratio.
That means new LPs cannot choose their own price. They have to deposit assets according to the pool’s existing reserves.
Example:
If the pool currently has:
10,000 TOKEN
100 XCP
Then the ratio is:
100 TOKEN per 1 XCP
A new LP must deposit at that same ratio.
So if they want to deposit 10 XCP, they also need to deposit 1,000 TOKEN.
Why price correctionmatters before adding liquidity
Because future deposits match the current pool ratio, the pool should be price-corrected before more liquidity is added.
If the pool is mispriced and someone deposits more liquidity, they are adding liquidity at the wrong price.
That means they may be giving arbitrageurs more inventory to exploit.
Clean phrasing:
Complete simple explanation
A liquidity pool is an automated market maker. The LP deposits two assets into the pool, and the pool becomes willing to buy or sell either asset according to its reserve ratio.
The LP earns fees from trades, but takes inventory risk. If traders dump one asset, the LP accumulates that asset. If traders buy one asset aggressively, the LP sells that asset and accumulates the other.
For pools involving XCP, the trading fee is 0.5%. For pools not involving XCP, the fee is 1%.
The first LP sets the initial price by choosing the deposit ratio. If that ratio is wrong, traders can arbitrage the pool until the price corrects. After the pool exists, new LPs must deposit at the current pool ratio, so the pool should be price-corrected before additional liquidity is added.
Best concise version:
Dan added this disclaimer too:
and clarification:
glad we have a long window for this release
how long until we decide to release
how long until community upgrades during activation period (2 months!)
expressions, communications and open publishing of how the protocol is moving forward is improving greatly
#162
Adam thought it was a very good discussion, happy to see back and forth on solving this one
havent yet settled on what is the 'least ugly way to do it'
when do we aim for the next protocol change after? how frequent?
speak your mind or dont be heard
devs want to dev, users do want enhancements and improvements, many uncontested!
CounterpartyXCP/Website#7
CounterpartyXCP/Website#8
CounterpartyXCP/Website#14
CounterpartyXCP/Website#18
CounterpartyXCP/Website#13
CounterpartyXCP/Website#12
CounterpartyXCP/Website#11
CounterpartyXCP/Website#10
CounterpartyXCP/Website#9
focus website content for entirely new users or users comfortable with ETH, SOL or Ordinal environments
the way it is now was more directed for users 1 1/2+ years ago for questions asked then....
everyone is welcome to participate... thats why i do these notes/spaces and link to the places to comment for lurkers!
Adam really wants to push more discussion on Decimal Point
this one is an "example of a proposal that people disagree how risky it is, and general desire as well to estabalish some kind of metric of 'are people on-board with this'?
CounterpartyXCP/counterparty-core#2297
very similar to a 'stock split' - number changes - proposal doesnt print more xcp
personally I have contentions with this one! but is also a great example of a contested issue where we will define how the community moves forward
I want people to change my mind!
"adding LP's to the protocol no ones cares... but change the decimal point with 2 lines of code and we are all up in arms about the philosophy of it!"
"adding LP's is a huge economic change!.... but there was consensus"
"big concern is that broader social implications could cause chaos if not understood or aware"
Adam "this change will not go through if it is contentious!" ... "but lets estabalish some sort of metric for this discussion, if it ever ends!"
Milestones organization for issues was really helpful for normies to understand future things coming on the protocol.
Community members do feel listened to for features on this release (and past ones that people don't know to be honest... think Lock Description!)
CounterpartyXCP/counterparty-core#2297 (comment)
Adam: "we have coalesced around an implementation, not hard or complicated, just awkward"
similar to what the community used with easyasset
also influenced me to write up a new document for website 'Basics' docs "What is Enhanced Asset Information?"
All reactions