foggy nymph
A few days ago we rolled-out an update for https://stellar.expert which provides the ability to analyze all Soroban transaction effects, including contract state changes, contracts call tree (contract sub-invocations are populated from diagnostic events), asset mint/burn effects, contract-generated events, etc. This functionality is available for Testnet transactions. Hope it will be useful for Soroban developers.
Please let me know if you have any feature requests.
lyric goblet
This is amazing! Great job @foggy nymph 👏🔥
lament mountain
Awesome!
chilly lily
Oh wow! That’s nifty.
chilly harbor
A few days ago we rolled-out an update for https://stellar.expert which provides...
I’m liking the sample of function names I’m seeing there - very defi-esque.
Just a couple years ago the thought of smart contracts on Stellar was almost a joke. But look at us now! Almost to the start line.
stoic kiln
Great work
torpid mirage
This is awesome! Thanks @foggy nymph. One idea for a future release - It'd be helpful to link to the Stellar Asset Contract page for existing assets. It might also be helpful to see a directory of popular contracts (maybe ranked by number of invocations? This might be complex to avoid being gamed).
foggy nymph
Hey everyone!
A quick update on Soroban-related features we've rolled out recently.
New contract interface viewer (located next to the contract history tab) provides access to functions, structs, enums, unions, etc. declared in the contract WASM file. Apart from that, it shows RustLang and SDK versions of the environment that compiled the contract. Also, there is a link to download a raw WASM binary at the bottom of the page, in case if you want to analyze byte code more closely.
The binary analyzer is written in JS, very lightweight, works in the browser, doesn't rely on the CLI, and has only one dependency -- @stellar/stellar-base package. The code is open-source, feel free to use it if you want to parse interface on the client side.
https://www.npmjs.com/package/@stellar-expert/contract-wasm-interface-parser
From now on you can utilize StellarExpert to browse through all Soroban data stored by any contract or account. Including persitent, expired, and temporary storage entries that don't exist on-chain anymore. The data itself is presented in a human-readable format.
foggy nymph
In collaboration with https://sorobanexp.com we recently introduced contract <-> source matching service, targeting smart contract developers in the first place. Developers can provide a link to the Github repository containing source code of the contract to be validated. After that a fully-automated system fetches code from the repository, compiles it, and compares resulting WASM hash with the contract code hash stored in the blockchain. If hashes match, we can safely assume that the provided repository contains a valid source code for the contract being validated. So if the validation succeeds, we associate the contract with the particular Github repository and show this information in the interface.
Please bear in mind that the repository is linked with the WASM code, not the contract itself. So if you upgrade the contract, there is no more association between the contract address and the repository, and you'll need to initiate the verification routine again. On the other hand, once you finish the source code verification procedure for a contract, all other contracts instantiated from the same WASM will be automatically associated with the same repository, which comes in handy in case of mass-deployment of uniform or templated contracts.
Primary goal of this service is to establish a verifiable trust link between on-chain contracts and corresponding codebase to make Soroban execution runtime truly trustless.
New Soroban-related functionality of StellarExpert explorer
lament mountain
In collaboration with https://sorobanexp.com we recently introduced contract <->...
This is the best thing since Soroban!
It's been a thought/concern on my mind for a while, 'how does one know a contract does what it says?'
I figured compiling the source and comparing hashes works, but the main challenge would be to make it available for generic users.
And you solved that
novel urchin
This. Is. Awesome.
terse nova
😍
terse nova
@foggy nymph Is there a way to view for a contract specific types of historical changes to contracts, such as upgrades?
foggy nymph
Not at the moment, but it's definitely a good idea. I'll try to add this feature asap.
rugged sigil
Hello @foggy nymph this is great!
I was experimenting with Stellar Classi Assets and Soroswap, and I see that when some balance is locked into a Smart Contract, Stellar.Expert does not considers the contract as a holder
foggy nymph
Hello <@788100508463398974> this is great!
I was experimenting with Stellar Clas...
Hey! My apologies for the delay with reply.
We track stats for Classic and Soroban assets separately. You can click the "Wrapped Soroban asset" link and check assets holders of your token there.
terse nova
Hey! My apologies for the delay with reply.
We track stats for Classic and Soro...
This is cool!! Might want to drop the word wrapped, but it’s not actually wrapped and unwrapped, the contract provides direct access to the asset.
The wrapped terminology in the docs was a hang over from a prior design. We’ve been updating the docs to remove it though.
rugged sigil
Hey! My apologies for the delay with reply.
We track stats for Classic and Soro...
Following what @terse nova says ... it should be the "same asset" but just with 2 ways of calling it, right?
I think it will be confusing for people coming from other ecosystems to have this "two separated assets"
@foggy nymph
Also yesterday I posted #🔸｜general message
That Soroban TX is still not being showed in Stellar Expert... but I can see it on Stellar Chain.
For us is important because we show to our users "See TX in explorer"...
foggy nymph
<@788100508463398974>
Also yesterday I posted https://discord.com/channels/8975...
The link you posted is malformed. The network name should be public instead of mainnet:
https://stellar.expert/explorer/public/tx/061b7b2a26376aa52ee4bcc3584a6ba3cb7ca4b98ded7b77faf240af262e7361
foggy nymph
Following what <@731713301746286613> says ... it should be the "same asset" but ...
Technically, these are two different assets in different realms, because Soroban and Classic environments are not interoperable. Some aspects do not apply to Soroban SAC assets, for example DEX market statistics.
We were planning to conduct research on the possibility of merging stats for both Classic and SAC assets in the interface. But at this point we still don't have the final vision of how DeFi trading stats will look for SAC assets. So can't start working on it yet.
rugged sigil
Technically, these are two different assets in different realms, because Soroban...
I get it!
We are working on having stats for Soroswap. I will let you know when we have our stats ready so you can use them!
foggy nymph
The "wrapped" terminology is well established across a wider blockchain community, and I think it really fits here. The notion about interoperability of Classic and SAC assets sounds good, yet it's more a marketing statement at this point. It's impossible to work with an asset without wrapping, balances are stored in different places, there is no option to trade on Classic DEX and Soroban DeFi protocols in the same transaction, etc.
terse nova
It's impossible to work with an asset without wrapping
No wrapping is necessary though.
If I have XLM in a Stellar account, I can send an XLM payment to another Stellar account with the Payment operation, or with a Soroban operation. I don't have to wrap the asset first to perform the Soroban operation, I can just send it.
Classic ops and Soroban calls are just different APIs accessing the same asset.
lament mountain
Provided that someone has deployed the asset contract, correct? That's only a one off, but as I understand is required
terse nova
Yeah anyone can do that. It's just enabling soroban for the asset.
lament mountain
True. I think there was some misinterpretation between you and orbitlens though.
He said 'it's impossible to work with an asset without wrapping'
I get that the term 'wrapping' was phased out, but the initial action has to be that deploy/wrap before further actions
terse nova
balances are stored in different places
Balances of assets for Stellar accounts are stored in the same places, in the Stellar account for native (XLM) and in trust lines for issued assets. Balances for the new types of accounts (contracts) are stored in new places (contract data). Detailed here: https://soroban.stellar.org/docs/tokens/stellar-asset-contract
A transfer in Soroban with a Stellar asset using Stellar accounts, debits the senders trust line, and credits the recipients trust line. The ledger state changes outputted by stellar-core in the transaction meta are the same for a transfer of a native or issued asset on Soroban or a payment on Stellar.
terse nova
True. I think there was some misinterpretation between you and orbitlens though....
The term wrapping in other ecosystems usually involves exchanging one token for another, i.e. exchanging ETH for wETH, transacting with wETH, then exchanging back to ETH. That's not what happens on Stellar when interacting with issued assets on Soroban. Soroban provides a contract API to transact with the actual Stellar asset, not a wrapped copy of it.
Some examples of this:
novel urchin
Some historical context: in the beginning of our Soroban journey the SAC was indeed more separated from classic and accounts had to explicitly wrap and unwrap assets (including XLM) between Stellar trustlines and Soroban balances. We eventually migrated to a single balance system in preview release 6 (jan 2023) after overwhelming feedback that it was too confusing. And I'm glad we did that!
twin copper
Some historical context: in the beginning of our Soroban journey the SAC was ind...
So amazing
rugged sigil
Yes, this can be a bit confusing.
So I'm experienting with Soroswap and USDC in Mainnet.
And I have
THe (CODE:ISSUER) page: https://stellar.expert/explorer/public/asset/USDC-GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN
The [Associated Contract] Asset page:
https://stellar.expert/explorer/public/asset/CCW67TSZV3SSS2HXMBQ5JFGCKJNXKZM7UQUWUZPUTHXSTZLEO7SJMI75
And the [Associated Contract] Contract page: https://stellar.expert/explorer/public/contract/CCW67TSZV3SSS2HXMBQ5JFGCKJNXKZM7UQUWUZPUTHXSTZLEO7SJMI75
I think that 1 and 2 should be in the same page; and just having a contrat page to show Soroban contract txs
foggy nymph
The term wrapping in other ecosystems usually involves exchanging one token for ...
@terse nova with all due respect, your arguments are misleading in this case. You guys coded this logic, and you know better than anyone else that what really happens when you transfer any Classic asset to Soroban contract, is that the original asset is essentially burned (the record disappears from trustlines), and SAC tokens get minted instead (new record in the contract_data table get created). There is no direct interoperability between Classic and Soroban realms, and the case you described above (using XLM in Soroban runtime) in a nutshell comes down to bridging XLM to Soroban runtime. Soroban and Stellar are in fact two separate networks run by the same validators with a built-in bridge. Soroban transactions processed differently, they emit different metadata (that's why I mentioned token burning/minting earlier), balances stored in different tables and in different format, fee model is different.
You've done great job by adding low-level optimizations, creating a built-in bridge, and hiding implementation details to provide a more seamless experience than Ethereum. But I don't understand why you are denying the obvious and trying to persuade everyone that SAC and Classic assets are the same and there's no difference between them.
wooden stag
Late to the party here.
First: thank you for iterating on this so quickly @foggy nymph ; I really like where we are. I tend to only respond to messages when I have questions which gives a false sense of bias towards being "that guy" (trying to better myself).
Now for my question 🥳
I am a bit confused by this thread:
• Leigh's using WETH to describe how things work, but this was the old design that was abandoned because of the duplicated balances (at the time we replicated the pattern that WETH is minted when some ETH is locked, burned when unlocked).
• Orbit talks about a bridge analogy, but I don't see what is getting bridged. It seems we have some nomenclature disconnect here: "minting" should only be used when talking about the action that an issuer (that can be a contract) performs to add new tokens to the total supply.
I do think that this conversation and naming are important: if we're not describing certain concepts in our docs/specs we need to fix this as it creates ambiguity in applications, including block explorers like Orbit's.
Maybe the confusing piece of the puzzle is that the "Stellar Asset Contract" is not a contract (sorry, I'm part of the problem) but contained in the core protocol, and as such provides very different set of guarantees.
I guess to help move this forward, I'd like to understand if some concept is missing in our docs/CAPs, or if it should be only be used in a subset of layers, or (the simplest) if that concept is redundant somehow because it doesn't really help explain something
foggy nymph
Now for my question 🥳
I am a bit confused by this thread:
• Leigh's using...
Yes, I understand how it works internally (as I'm one of a few people outside of SDF who actually look into the Core source code, as well as all underlying XDR serialization types) and what you mean by saying that SAC is not a contract.
However, if we look into this from a broader perspective, this whole design of SAC looks like a bridge between two chains, and treating it like a bridge simplifies things a lot. I'll try to explain more detailed.
Let's take a simple example. For instance, I'm depositing 10 USDC from Classic account to some Soroban contract or my Soroban balance. What happens after the contract transfer() function execution?
account_debited effect).asset_burned effect happened). Anyone can easily check this by running query over PostgreSQL db.asset_minted effect).code:issuer pair). Second, if any developer tries to check the balance for my account, they will need to utilize much more complex approach. And if my funds are locked in, say, a liquidity pool smart contract, this complicates everything even further. So, from the developer's perspective SAC≠asset. From the end user perspective, this is not so obvious because the difference can be partly obfuscated by the wallet abstraction. Again, in some situations, a user inevitably faces interoperability problems. For instance, I can see my USDC in the Soroban balance, but if I decide to sell it for XLM using Classic DEX offers via StellarX or simply swap via PathPayment, the wallet won't allow me - I will have to convert this balance to Classic asset first and perform a swap in the second transaction.To summarize it. From the ecosystem developer's point of view, we have a classic situation of two "chains" connected by a "bridge". That's the abstraction layer we have to deal with, because the API/interface you exposed doesn't allow us to treat a Classic asset and the matching SAC token as the same asset. Even if you've done multiple optimization under the hood, even if both "chains" are synchronous and controlled by the same consensus, even if the "bridge" is fully integrated, for us the situation closely resembles ETH/wETH logic.
foggy nymph
@wooden stag @terse nova Does it make sense to you?
wooden stag
good that we're talking about this! When we went with this approach, we actually tried to replicate semantics from classic: specifically, locking something into a Soroban pool is no different than locking funds into a claimable balance. Assets disappears from a trustline (or account for XLM), and get moved into a CB, the exact same thing is at play when moving a balance to a contract (that will be held by the SAC).
So the total supply went from "sum(trustlines) + sum(claimable_balances)" to "sum(trustlines) + sum(claimable_balances) + sum(sac_balances)"
use cases it's the same thing: you can't do anything with a CB until you claim it (so a CB is just a hardcoded contract in a way)
your third point is interesting. it's possible that UIs should never tell people that it's a different asset if making the distinction is not useful to a user (that distinction is not useful for sure if the balance is held by the account); the question of how to report liabilities is probably contract dependent
kindred walrus
if we want to get really philosophical about this, then we can say that transfers don't exist at all - Core always 'burns' and then 'mints' XLM or assets. so the question is rather about where to draw the boundary between burns/mints and actual transfers. that's why I would define burn/mint in terms of ledger-wide supply.
I also would much rather prefer to not distinguish between classic accounts and contracts at the user level where possible. while contracts are indeed limited in some classic functionality (which may or may not change in the future), they often have similar semantics (especially when talking about account contracts).
to be clear, I don't insist that's the only correct semantics - that's just what makes sense to me.
foggy nymph
use cases it's the same thing: you can't do anything with a CB until you claim i...
As I see it, the key difference is that I can claim a CB or withdraw my stake from the pool and use it in the same transaction to transfer/trade or do whatever I want with the balance. In atomic fashion.
With Soroban it doesn't work that way. I can't put Soroban and non-Soroban operations in the same transaction. I requested this functionality multiple times, talked with different people in person during the Meridian in Rome, and a year later in Madrid. And with time responses slowly drifted from "why not?" to "maybe later" to "no, we are never going to do that".
At this point I can't perform operations across Classic and Soroban atomically without "wrapping/unwrapping". If we are talking about the wallet interface, I don't see any viable option on how to make this bridging completely transparent.
Example: I want to swap USDC->XLM on Classic DEX because price is better there, but I have my USDC tokens in Soroban. I need to do it in two transactions. A wallet can request the user to sign both transactions at once, and hide the implementations details, but my swap will still take at least 2 ledgers instead of one, with much higher chance of a failed transaction. Because the price has changed over the span of 2 ledgers, fee surge pricing may delay it even more. The account may have 10 USDC in Classic and 100 USDC in SAC, which may further complicate the task for wallet developers.
foggy nymph
if we want to get really philosophical about this, then we can say that transfer...
My philosophy regarding minting/burning is simple. If after the transaction application tx meta shows me that 10 USDC were debited and 10 USDC credited (regardless whether it's the same trustline or different), then it's a transfer. If 10 USDC debited and not credited - asset burn happened, if 10 USDC credited but not debited anywhere - the minting happened. SAC (and custom asset contracts also) do not generate trustline meta changes, so the logic there must be different.
I agree with you, I would also prefer to not distinguish between classic accounts and contracts. But they are very different in many ways, and achieving this transparency in UX is very challenging.
kindred walrus
I agree, non-atomicity between classic and soroban indeed might be an issue for some scenarios. I think it might be worth of a separate discussion.
The account may have 10 USDC in Classic and 100 USDC in SAC, which may further complicate the task for wallet developers.
I'm not sure I understand this point. an account may have 10 USDC in trustline and 100 USDC held by some contract, sure. and the user will need to interact with the respective dapp in some fashion in order to get the remaining funds back. but it's not obvious to me why should this impact wallets.
foggy nymph
I agree, non-atomicity between classic and soroban indeed might be an issue for ...
It impacts wallets because for many actions between Classic <-> Soroban realms the wallet needs 2 transactions instead of one. That's why I'm pulling the virtual "bridge" analogy -- the UX is very similar.
If we'd imagine that ClaimableBalances were implemented in similar way (creating/claiming a claimable balance could be done only from/to user's account balance, without an option to swap/transfer/stake the asset in the same transaction) then I'd also say that ClaimableBalances looks like a separate virtual chain, bridged to the main Stellar ledger.
kindred walrus
If 10 USDC debited and not credited - asset burn happened, if 10 USDC credited but not debited anywhere - the minting happened
so if contracts had the respective trustline entries, would you consider the SAC transfers the same way as the classic transfers? also, if we supported atomic Soroban+classic transactions, but with the current data layout, then these would still not be transfers? again, I feel like atomicity is an orthogonal issue to the original discussion.
foggy nymph
Soroban runtime config changes block now has two tabs. The first tab shows only diff view for the parameters that have been updated during the protocol upgrade. The second tab shows content of the Soroban runtime settings update entry in JSON format, including fields that haven't been altered (where new values match the previous Soroban runtime config).
https://stellar.expert/explorer/public/protocol-history
Staged Soroban config upgrade now has identical interface, showing by default only those parameters that will be modified once validators vote for the upgrade.
Also, we created a repo here: https://github.com/stellar-expert/staged-soroban-upgrades
It contains a very simple json file containing information about the staged Soroban settings upgrade and planned update application timestamp.
e.g.
{
"upgrade": "2aLVwNcvW1...+grDoGlDA==",
"timestamp": "2024-02-27T17:00:00Z"
}
Our Protocol history page (https://stellar.expert/explorer/public/protocol-history) automatically fetches the data from this repository and if there is a staged update in the repository that has not been applied yet, it shows the reference to the page with specific Soroban parameters modifications (see screenshots above).
So far I granted edit permissions for this repository to @torpid mirage from SDF to provide an easy way to notify wider public about staged Soroban runtime parameter upgrades. Happy to add other SDF representatives to this repository as well. If this works out well, we can transfer this repository ownership directly to the SDF org on Github later on.
Other downstream systems (blockchain explorers, wallets, etc.) can utilize the data directly in their frontends since the repository is fully open. Raw data is available here: https://stellar-expert.github.io/staged-soroban-upgrades/staged-public.json
cc @strong wharf
foggy nymph
Following community feature requests, we created new Soroban statistics interface, containing basic Soroban runtime metrics and historical activity charts. It is available here: https://stellar.expert/explorer/public/network-activity?tab=soroban
That's the first version with a limited information, but we are working on a much more comprehensive set of statistics that will be available in a few weeks.
kindred walrus
it seems like there are more Wasms uploaded than the contracts instantiated, which is surprising (especially given that non-zero fraction of the contracts are SAC).
foggy nymph
it seems like there are more Wasms uploaded than the contracts instantiated, whi...
Some contracts were updated several times with different WASM versions. Also, we show only unique WASMs. Many of them were uploaded several times by different accounts (e.g. contracts from Soroban examples Github repo).
kindred walrus
right, so that's even more weird, but I guess it is what is 🤷♂️
kindred walrus
I've just checked and we only have 112 Wasm entries in the ledger at the moment. that doesn't allow with the graph, so could you maybe take a look at the data you're using for it?
foggy nymph
I've just checked and we only have 112 Wasm entries in the ledger at the moment....
Yes, you are right. The underlying data is correct, but my colleague swapped chart titles in UI, so that "Contracts created" and "Unique WASM uploads" has wrong titles.
I rolled out a fix.
Thanks for the heads up!
🤝
kindred walrus
great, thanks for the quick fix!
rugged sigil
@foggy nymph quick feedback.
I am checking the Soroswap USDC-circle / EURC-circle LP contract
https://stellar.expert/explorer/public/contract/CAM7DY53G63XA4AJRS24Z6VFYAFSSF76C3RZ45BE5YU3FQS5255OOABP
And it appears that the current liquidity is
It seems like we have a lot 😆 , but in fact is not considering the 7 decimals
lament mountain
<@788100508463398974> quick feedback.
I am checking the Soroswap USDC-circle / E...
One of those is the native assets token tho?
rugged sigil
One of those is the native assets token tho?
Hehe. Sorry. You are right. Is USDC / XLM
rugged sigil
One of those is the native assets token tho?
terse nova
@foggy nymph Are there rules about when balances for contracts show, or are hidden? One thing I noticed is that sometimes balances don't show.
For example, this contract address: CAFRE77725EPX4ISTZHEDVMGHASMLBM35PURHMQXRDOWWDJLSND76NS6
is holding a balance of ABC:GCYLVLL2FC7VGFHNU4MCSQ4GP3LFVK5NPSGH5HVMLHBBWJ56WOAVSIPY
Confirmable with:
$ soroban contract invoke \
--id $(soroban contract asset id \
--asset ABC:GCYLVLL2FC7VGFHNU4MCSQ4GP3LFVK5NPSGH5HVMLHBBWJ56WOAVSIPY) \
-- \
balance \
--id CAFRE77725EPX4ISTZHEDVMGHASMLBM35PURHMQXRDOWWDJLSND76NS6
"3"
But https://stellar.expert/explorer/testnet/contract/CAFRE77725EPX4ISTZHEDVMGHASMLBM35PURHMQXRDOWWDJLSND76NS6 shows no balances.
foggy nymph
<@788100508463398974> Are there rules about when balances for contracts show, or...
From what I see, CAFRE77725EPX4ISTZHEDVMGHASMLBM35PURHMQXRDOWWDJLSND76NS6 is an SAC contract address for the CDE:GCYLVLL2FC7VGFHNU4MCSQ4GP3LFVK5NPSGH5HVMLHBBWJ56WOAVSIPY asset, it's not the WASM contract. I checked the testnet database directly and I don't see only one data entry - scvLedgerKeyContractInstance. There's no balance records. Am I missing something?
terse nova
Any contract can hold a balance, even a SAC contract, although yeah utility of doing that is pretty slim given it can't do anything with it. I was doing some testing and just happened to send some balance to a SAC contract in this case.
But there should still be a balance.
The balance ledger entry is on the ABC:GCYLVLL2FC7VGFHNU4MCSQ4GP3LFVK5NPSGH5HVMLHBBWJ56WOAVSIPY contract.
Because CAFR holds the ABC:GCYL token.
foggy nymph
So, I analyzed the scvLedgerKeyContractInstance value, and it shows that the balance is stored as the instance data, in the instance storage itself. I didn't even know something like this might be possible. For all other accounts and contracts balances are stored in separate persistent data entries in the database.
Is this a special case that applies only to scAddressTypeContract?
terse nova
I don't see a balance in that output.
There are three instance entries:
Admin
METADATA
AssetInfo
All SACs have them.
foggy nymph
Ah, sorry, right, it's the SAC meta.
But I don't see any other data entries attached to the CAFRE77725EPX4ISTZHEDVMGHASMLBM35PURHMQXRDOWWDJLSND76NS6 in the database
stoic kiln
Hey @foggy nymph what about making a database of verified contract code, so that when a contract shows up in aa transaction we can identify it
terse nova
You need to look at the CAJYT5MKWQK2DTWVKX3FJRQJ3BIL6PDDMK6PWD4BZ7QOB63L3EABPVS6 data.
The balances that hold a token, are stored in the token's data storage, not the holder's data storage.
foggy nymph
The balances that hold a token, are stored in the token's data storage, not the ...
Ok, found the data entry, thanks for the heads up on this. 🤝
Will debug and fix tomorrow.
It's midnight here, I'm loosing focus. Spent a ton of your time because I was looking at the wrong contract. My apologies.
foggy nymph
Hey <@788100508463398974> what about making a database of verified contract code...
Already implemented. Far from ideal. We came up with an interesting idea, check this thread for the context: https://discord.com/channels/897514728459468821/1218934322745315389
Currently working on the prototype for this.
stoic kiln
Already implemented. Far from ideal. We came up with an interesting idea, check ...
Ill take a look. Me and @strong wharf were discussing it earlier today.
tired jetty
If possible, I would like to see a chart showing the bucket list size.
The write fees have been quite volatile lately: the fee for similar contract invocations went from 0.36 XLM (immediately after the phase 2 vote) to 1.2 XLM (yesterday) and now is about~~ 0.7 XLM~~ 0.83 XLM.
kindred walrus
definitely - BL size is actually exported directly in tx meta, so it's a matter of someone putting together a chart. but I'm also adding the write fee itself.
I think we'll want to revisit the write fee formula in p22 (unlikely to fit this in p21) - volatility is indeed really annoying
rugged sigil
Hello @foggy nymph when a contract holds assets, still appear without taking into account the decimals:
Also something very strange happens when the contrract holds also the native XLM:
Example: Pool USDC / XLM
https://stellar.expert/explorer/public/contract/CAM7DY53G63XA4AJRS24Z6VFYAFSSF76C3RZ45BE5YU3FQS5255OOABP
And from stellar expert:
(CAS3.. is the native XLM)
(CCW6 is USDC)
(CAM7 is the contract that holds these 2 assets)
The correct amount is splitted between "USDC" amount and "CCW6" amount 14072202679+91551229359 = 105623432038 --> 10,562 USDC
The same for the native XLM
Is strange, sometimes does not appear:
I think that I know why. For example take this one:
https://stellar.expert/explorer/public/contract/CAURS6NIANW7PQEZX35NBZZFGQFTULHREJFP44YWNBR33KGKJLOASZIW
And from the historic I see that:
I still dont know 😆 , but there is a clue
I guess it has to be how you index the events, or something like that?
foggy nymph
Hello <@788100508463398974> when a contract holds assets, still appear without t...
Fixed. Now we have a consistent look-and-feel across contract balances and account balances for Classic assets.
Plus estimated fiat value for every contract balance and overall contract holdings in general.
rugged sigil
Fixed. Now we have a consistent look-and-feel across contract balances and accou...
This is great @foggy nymph . Thanks a lot! 
rugged sigil
Fixed. Now we have a consistent look-and-feel across contract balances and accou...
Hello @foggy nymph this still happens with native!
Here the pool USDC/XLM
https://stellar.expert/explorer/public/contract/CAM7DY53G63XA4AJRS24Z6VFYAFSSF76C3RZ45BE5YU3FQS5255OOABP
stoic kiln
nice
rugged sigil
Hello @foggy nymph I still see some strange things appearing when contract hold a soroban-based token.
Example. The XLM-USDx Soroswap LP Contract
https://stellar.expert/explorer/public/contract/CDJDRGUCHANJDXALZVJ5IZVB76HX4MWCON5SHF4DE5HB64CBBR7W2ZCD
On Stellar Expert appears as it holds 305,770.2065732 of its own token.... which for me was very strange... It should hold only 1,000 stroops unless someone "burnt" LP tokens sending them to the LP pool/token contract
foggy nymph
Hello <@788100508463398974> I still see some strange things appearing when contr...
Yep, we cannot properly track Soroban contract token balances. Some tokens not follow or only partially follow SEP41 in terms of method signatures and generated events, so we cannot automatically calculate contract balances. I guess we'll just have hide all contract token balances in the explorer since this results in controversies.
rugged sigil
However, if I check the Ledger Entries, I see that is working as expected
The ledger entries is showing what I was expected, the contract holds only 1,000 stroops-untis of its own token
rugged sigil
Yep, we cannot properly track Soroban contract token balances. Some tokens not f...
Ok! I see! But this LP token was written following the SAC estandar, and the token example in stellar repo 🥲
Is there any documentation I can check so we can avoid this in the future?
foggy nymph
Ok! I see! But this LP token was written following the SAC estandar, and the tok...
https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md
Our engine validates invoked method signatures and generated events according to the standard.
terse nova
Are we confident the above inaccurate balance is a result of events not being emitted for some movements of value?
Or is that a theory that needs validation?
terse nova
Ok! I see! But this LP token was written following the SAC estandar, and the tok...
@foggy nymph @rugged sigil which contract is it that we think isn’t emitting the right events?
Oh sorry I realise you already shared the address above.
torpid mirage
@foggy nymph I believe you process the mint event, but you mind sharing how? It's currently missing from SEP-0041 but will be added soon. I'm curious if the topics aren't handled correctly.
stoic kiln
I think i encountered that before