Jude Nelson

> I don't think this is true. With this proposal, you could write a proxy contract making a SIP10 contract upgradable - impossible with the constraints in place today. Allow...

> You implemented a contract proxying contract-calls to a SIP10 contract, however this is not an upgradable token. Yes it is -- just change the `token-contract` data var. You can...

> It is proxying contract calls, but your proposal is not an upgradable contract, in the sense that you would not be able to pass your "proxy" contract to a...

To be more blunt, I'm steadfastly against adding unchecked dynamic dispatch to Clarity, since that would break one of the core promises the language makes to smart contract developers --...

> This last contract is our bottleneck. If we want tokens to be standardized, tokens need to conform to a shared interface and the "internal kitchen" needs to be abstracted....

> I'm with you so far, with one nuance: it moves decidability from the Clarity Language specification, to the Clarity VM specification. The unstated caveat here is that execution path...

> @jcnelson the main point I'd want to speak to in your examples of "how this is doable today" is that a huge goal I have is to remove the...

Yes, for mockamoto tests. It really needs to be fixed everywhere, but it's not worthy of a hotfix since the only place it's called in prod is in a debug...

I've already fixed it in the downloader API PR On Wed, Feb 21, 2024, 12:10 PM Jude Nelson ***@***.***> wrote: > Yes, for mockamoto tests. It really needs to be...

To achieve this, one would need to modify the function `StackerDBs::create_or_reconfigure_stackerdbs()` in `stackslib/src/net/stackerdbs/mod.rs`. This function is responsible for synthesizing a `StackerDBConfig` struct for each of the node's StackerDB replicas using...