Trust Assumptions
As the only genuinely decentralized access control service on the market, Threshold Access Control may also claim to be the most 'trustless' solution available to Web3 app buidlers – or indeed, available to any developer seeking an unambiguous departure from the exploitative Web 2.0 trust paradigm.
Nevertheless, there is no such thing as a third-party integration that imposes zero additional trust burden onto an application's end-users. Rather, when choosing infrastructural technology, it is the nature and texture of the trust burden(s) – or the 'trust assumptions' – that truly matter.
In the case of Threshold Access Control, the trust assumptions are:
non-binary – i.e. not reducible to 'trustless' or 'trustful'.
non-static – i.e. they evolve over time based on in-protocol features and exogeneous phenomena.
tunable – i.e. adopting developers may select from a range of explicit trust assumptions on behalf of their user base, and/or surface that optionality for end-users to choose themselves.
This section serves to explain the implicit and explicit trust assumptions that are baked into Threshold Access Control, for the Mainnet and Proof-of-Concept versions. These assumptions are synthesized and exposed to the vast majority of adopting developers in the form of pre-configured Trust Packages.
Note that many projects in the Web3 infrastructure space seek to obscure this reality by loosely labelling their solution as 'decentralized', but fail to explain precisely what the trust implications are in practice. Beware of ambiguity!
Last modified 2mo ago