A multi-app app: modularly catering to every risk profile

TLDR: Cater to heterogenous, evolving and (ex-ante) highly obscure user risk profiles/preferences, via the Threshold network simultaneously hosting multiple distinctly parametrized, similarly collateralized, and otherwise identical versions of the tBTC application.

The greatest unknown for virtually all decentralized products/services is simple to articulate; to what extent does the end-user value decentralization? Or, how strong is the reduction of trust relative to incumbent alternatives as a pull factor? Even if we take a trust reduction as a generally validated value proposition, the extent to which this is perceived by a target demographic is:

highly subjective (relying on both intuition and educated evaluation)
multi-dimensional (depends on in factors like the duration of trust burden, occurrence/non-occurrence of market events, or opinions about a given network's honesty gradient)
difficult to quantify (except when there is existing and similar behavior, such as public mixing-and-matching of renBTC & WBTC)

For tBTCv2, the product alternatives are concrete: (a) custodial, KYC required & (b) permissionless but essentially centralized. Along with (c) a well-populated future tBTCv2, these three models live along a trust continuum, with trust in reputation at one end, and trust in rationality, and a well-designed economic protocol, at the other.

It’s not straightforward for WBTC to spin up a decentralized bridge.   But it is feasible for tBTC to spin up as many permutations of itself as the market demands – or whatever is hypothesized to be tractable and/or profitable, based on signals from the market. This is particularly true in the context of a protocol authorization model, where stake can be efficiently reused for multiple applications, and staker/signer population is already primed for concurrent multi-app service-provision.

More formally, the dimension across which tBTC offers could offer this optionality is the degree of collusion-resistance, reflected in a predictable (though non-verifiable) probability of one's BTC being stolen by a malicious signer group (seefail below).

Making one tBTC app function with multiple simultaneous signer group sizes, thresholds and other heterogenous parameters would be a formidable – and unnecessary – undertaking. Instead, Threshold could spin out the following forks (read: products), distinctive only with respect to their parameters:

Note that the parameters (and product names) below are entirely illustrative. m = threshold of signers n = signer group p = total population selected from (i.e. max number of service-providers able to authorize to this app) min-stake = minimum amount of T authorized to app to be selected) fee = fee (commission in BTC) reward = subsidy (% of issuance allocated by council, assuming 3/4 of total minted is reserved for all tBTCv2 versions) fail = theoretical probability of absconding event assuming 52 annual wallet creation events, all p nodes are genuinely independent economic agents, 2/3 of p are honest, and there's zero reliance on the honesty of known trusted entities. Note that the assumption of 2/3 honest participants does not map perfectly onto small signer groups – for example, intra-node identification, communication and bribery is easier, at least from a mechanical perspective.

Good-Better-Best:

tBTC-StaaS m = 6 n = 9 p = 9 min-stake = 5m f = 0.001 i = 5% fail = 0.00%

tBTC-Classico m = 51 n = 100 p = 200 min-stake = 100k f = 0.05 i = 25% fail = 0.0000034%

tBTC-Myriad m = 101 n = 200 p = 1000 min-stake = 40k f = 0.1 i = 70% fail = 0.0000066%

Other forks:

tBTC-PrayCore m = 6 n = 9 p = 20 min-stake = 500k f = 0.001 i = 5% fail = 11.92%

tBTC-Andre3000 m = 301 n = 600 p = 3000 min-stake = 40k ( f = 0.3 i = ? fail = 0.00%

There are some issues to iron out with this approach:

Will stakers want to run nodes in 3 versions of the same app? Probably, if the effort/cost to do so is marginal over the minimum, and they get to hedge their exposure to unknown and evolving user preferences.
How should rewards be divvied up? This requires the Council and its advisors to do serious market research, and bet on certain versions of tBTC. However, this process will be aided by empirical data – i.e. actual user choices between the options presented to them, with everything else equal (i.e. a blockchain A/B/C test).
Does this mess with the TVL? Only if we fail to communicate the aggregate TVL across all versions.
Plenty of others I haven't thought about yet. Please complain below.

Note that user preferences and perceptions of risk are non-static. The longer tbtcv2-Myriad persists without failure (and solutions like it), the greater the everyday user (and the experts to which they listen) will feel comfortable moving from reputation-dependent products to [protocol+rationality]-dependent products.

Another evolving, non-static reality is the number of Threshold's pool of independent stakers (say, above some minimum level of competence). The distinct products listed above will become feasible (and perceived to be feasible) through the progressive decentralization and recruitment of stakers to the network over time. This also preempts early versions of tBTCv2 being misrepresented by tropes such '51-of-100' – where the lack of replacement in sortition, plus professional stakers running multiple nodes – means the true m-of-n is lower (and the fail value might be vastly different).

Hence, in concert with this approach, it's important that the level of decentralization, as is discernible anecdotally or through Etherscan analysis, is reported on with the maximum possible transparency, and this reporting process is itself decentralized. In other words, if we know that these 20 addresses are managed by staking provider X, this is earnestly tracked and publicly shared – ideally with data harvested and computed by both client teams, and multiple third-party/community contributors.

Also, the concept can also be extended to other design decisions that pertain to ex ante obscure user preferences, such as lower sweeping/minting times vs. increased risk of a fraudulent wallet.

Related notes from brainstorm with @beaushinkle that seeded this proposal

End-users are observed to mix & match centralized and semi-decentralized services in order to find a unique combination that fits their preferences and risk profile.
A related risk dimension in the context of BTC-ETH bridges is the perceived likelihood of immediate capitulation (depegging) vs. long-term failure.
These complex perceptions of risk are traded-off against simpler preferences like minting speed, commission cost or just avoiding a KYC step - One piece of evidence for this mix and matching happening in practice is that the WBTC/renBTC pool is the  5th largest on Curve.

What actually weakens the fungibility of a token? In the case of tbtc minted via multiple application versions, the argument is that there are non-uniform trust assumptions. The risk of the signer group absconding, the asset de-pegging, or any other kind of capitulation transpiring certainly varies version to version – though this risk is not easy to quantify and objectively rank. Indeed, the variance and unclear superiority/inferiority of each are the main reasons to offer this optionality in the first place.

And yet, the actual trust assumptions behind every single tbtc (batch) ever minted, in tBTCv1 and tBTCv2, are also non-uniform! Say the sortition mechanism selects 100 random signers to manage a wallet A (group A), and another 100 to manage wallet B (group B) – with some overlap, probably. The array/aggregate of intentions, degree of malice, endowment/access to capital, investment horizon, plus a million other attributes, are entirely different in group A compared to group B, even if both groups enabled the minting of an ostensibly equivalent tbtc asset. Even if the same 3 signers are responsible for a minting event, their attributes (intentions, capital, etc) evolve slightly from timestep to timestep.

That might sound a little abstract and opaque - because it is. But even more front and center is the undeniable fact that the presence of professional stakers (and whichever other entities choose to operates multiple stakes/signers) implies that all signer groups, despite being '100' signers, actually have highly varying group sizes (m) and thresholds (n) in practice, which is precisely the distinction between the tBTC versions proposed above. A group with 8 independent signers and 92 operated by a single provider has exactly the same m as the tBTC-StaaS product above, though of course the overall trust burden would be considerably worse.

In other words, non-uniform trust assumptions (and perhaps, theoretical/technical non-fungibility) are inescapable in reality. The only departure from the status quo would be making that non-uniformity more explicit and bucketed for the user to decide, as opposed to opaque and arbitrarily flung at the user.

The extent to which perceived fungibility overlaps with theoretical/technical non-fungibility is still an open question. However, this reality of non-uniform minting applies to many prominent tokens, almost all of which are functioning and being traded in practice as fungible assets.

Also, each tBTC version can be parametrized such that the total economic security (aggregate collateral, denominated in T) is identical – by tuning the minimum stake, maximum signer population size, signer group size and threshold. This straightforward design choice definitely increases uniformity of trust/security and therefore the technical fungibility. In fact, you could go even further in seeking to hold as many trust assumptions constant as possible, by choosing parameters such that the hypergeometric probability of a malicious signer group is the exact same percentage (assuming all groups are selected from a population that is 2/3 honest). In this way, the only variation between tBTC versions is a qualitative/subjective perception of security/trust, inferred from the explicit number of stakers involved.

And yet, the actual trust assumptions behind every single tbtc (batch) ever minted, in tBTCv1 and tBTCv2, are also non-uniform!

I don't believe this is correct, based on my understanding of how the v2 bridge works (although I could be wrong). Under the current v2 model, if a signer group absconds, the BTC is made whole via the coverage pool. But the particular BTC in a particular signer group does not correspond 1:1 with some particular tBTC token. It is a bucket and tBTC is redeemable against that bucket. A loss (whether made whole or not) is shared across all tBTC holders (or perhaps is stuck to whoever is "last out" if there's a bank run back to the native Bitcoin).

The proposed modular approach, does explicitly tie each BTC to a particular tBTC, making each tBTC non-fungible.

To be clear, I was referring to theoretical non-fungibiity arising from purely from minting/deposit/redemption steps, where the actual security of that asset is determined by the unique combined choices of a unique group of signers. What you point out is absolutely true: separate components of the system, like the coverage pool, address this variability to some extent by indiscriminately insuring all tBTC/BTC.

The proposed modular approach, does explicitly tie each BTC to a particular tBTC, making each tBTC non-fungible.

Unless I'm missing something, I don't see why the exact same recovery mechanism (coverage pool) could not be indiscriminately applied o all deposited BTC, regardless of which product version was chosen. Does it simply come down to the level of transparency with which we present the unavoidable variation in signers (and effectively group size/threshold)? Because by instituting a single coverage pool that uniformly insures tBTC-StaaS, tBTC-Classico etc, this increases the technical and perceived fungibility, just as it does for the status quo product.

Unless I'm missing something, I don't see why the exact same recovery mechanism (coverage pool) could not be indiscriminately applied o all deposited BTC

If risk is pooled then what is the point of choosing one version over another? Depositors are exposed to the blended risk profile across all the versions whether they choose Staas or Andre3000.

They're exposed to a blended/uniform risk profile only with respect to a buyer of last resort in the the worst-case scenario. Within the scope of the tBTC offering, that feature is a separate mechanism collateralized by a separate group of economic actors, and subject to a separate set of protocol rules – basically, that group has significantly less power to commit fraud or undermine the peg.

So the point of the multiple product offerings is to cater to a broader set of risk profiles with respect to the other components/steps in the tBTC offering; the back-and-forth depositing and redemption of BTC, and the holding and usage of tbtc.

I agree with your general point that optionality and fungibility are partially in conflict. However, being empowered to choose signer group parameters is still valuable to the end-user, because the alternative involves these parameters being somewhat arbitrary and opaque (in other words, less optionality and a comparable lack of technical fungibility).

Moreover, nobody wants a collusion event that leads to their BTC being stolen – even if they're theoretically covered. A loose analogy would be a car buyer completely ignoring their (partially subjective) perception of a given vehicle's safety, and being sold a random car, simply because they also get a one-size-fits-all insurance package.

threshold-network / threshold

A multi-app app: modularly catering to every risk profile #7