TLDR
This proposal would see TACo officially become a Threshold application, with PRE services folded into TACo and discontinued as a standalone app. To motivate long-term service provision on TACo, one-off yield bonuses will be offered to stakers who authorize their tokens to be locked up for durations longer than the minimum deauthorization delay (6 months).
Watch the recent Staker Townhall for a deep dive into TACo, why it’s worthwhile staking on TACo, and a demo from three Web3 developer teams currently integrating this access control layer into their applications.
Proposal contents:
(1) Introduction
(2) Application contracts
(3) Fees
(4) One-off bonus for staking on TACo – 50m T
(5) Application trust profile
(1) Introduction to TACo
TACo (Threshold Access Control) facilitates end-to-end encrypted data sharing and communication in Web3 applications – without relying on a centralized authority, who might unilaterally deny service or even decrypt private user data.
It is the only access control layer available to Web3 developers that can offer end-to-end encryption that is end-to-end decentralized.
TACo is relevant to virtually any Web3 app/stack that handles private data. Early adopters are building and operating in domains where compromising on trust minimization simply doesn’t work for the core value proposition; recovering seed phrases, passing on crypto assets as inheritance, enforcing decryption rights for tokenized legacy media libraries, transferring sensitive model I/O to remote machines, concealing in-game assets, and other use cases. See the Townhall to understand these use cases better!
A TACo user flow is fairly straightforward. At encryption time, end-users specify conditions for accessing their private data (e.g. only share this video stream with the holders of a special purpose NFT). When those conditions are fulfilled and verified by a threshold of TACo cohort members, the cohort provides the data requester with sufficient decryption material to decrypt the data and view the plaintext. Otherwise, the private data remains inaccessible to everyone besides the original data encryptor.
Further resources:
(2) TACo’s application contracts
From a staking point of view, the TACo application is implemented through a set of smart contracts on both Ethereum Mainnet and Polygon Mainnet. The most important among these contracts is TACoApplication, which executes the authorization and deauthorization logic, and consequently, will be connected to the Threshold staking contract. TACoApplication will be upgradeable and owned by the Threshold Council.
The TACoApplication contract, as well as supporting contracts in Ethereum and Polygon, were audited by Cantina. No major issues were found, and the audit report will be published as soon as it’s ready.
(3) TACo’s fees at genesis
Duration-based fees will be paid at cohort creation (the ‘base fee’). Adopters will be charged in DAI, proportional to:
(i) the number of nodes they rent for the cohort (minimum: 15, default: 30).
(ii) the duration of the cohort’s existence (minimum: 6 months, default: 6 months).
The base fee is set to 0.35 DAI per node per day. For the recommended cohort size of 30, this generates 3,832.50 DAI per adopter per year. There is no free tier of service, besides the limited Tapir testnet.
Soon, adopters will be able to generate multiple cohorts to service different components or security levels within their applications, increasing the base fee revenue per adopter.
Revenue generated by TACo will go to the DAO Treasury. The DAO will decide exactly how to allocate this revenue in the near future – this proposal does not provide an opinion.
Finally, some combination of the following action-based fee mechanisms will be developed alongside early adopters and added to future versions of TACo on top of the base fee:
(i) Charging per authorization of encrypting device
(ii) Charging per decryption request and/or condition verification
(ii) Charging per condition creation
(iv) Charging per condition update
(4) One-off Bonus for Staking on TACo (50m T)
FOR UP-TO-DATE INFORMATION ON THE BONUS & LOCK-UP, PLEASE CHECK OUT → One-off Commitment Bonus - Threshold Docs
This proposal would see a special batch of tokens minted by the DAO to incentivize extended commitments to providing the TACo service. This is in addition to and independent from the universal minimum unbonding time (deauthorization delay) of 6 months for TACo stakers. The required extra mint is estimated to be 50,000,000 T tokens – see calculation below.
Rewarding longer lock-ups is beneficial to Threshold as a whole for the following reasons:
- TACo’s early adopters need assurance that the cohorts of nodes managing access to their users’ data will not deplete in number, and ideally retain well above the threshold (e.g. 16-of-30) for years. If a large proportion of TACo nodes have stakes locked for 12+ months, this not only improves the theoretical reliability of all cohorts (i.e. randomly populated), but also allows for custom cohort compositions with a minimum remaining commitment time as a prerequisite for participation.
- Although cohort members can be securely replaced, while maintaining a persistent public key to encrypt to, it is preferable for economic and security reasons to minimize the number of node replacement rituals. This is particularly true in the first year following service launch, given that the gas costs of cohort member replacement will decrease with optimization R&D, to be implemented and released in forthcoming versions.
- TACo will launch without a punishment mechanism in place, but the specter of slashing and/or compensation withholding for non-availability is a strong incentive to provide a reliable service. The more stakers have committed to long-term token lock-ups, the longer the possibility of punishment is a disincentive against unreliable behavior.
- Distributing a small number of extra tokens would be invaluable to TACo’s product-market fit, but have a negligible effect on the overall annual inflation of the supply. For example, in the scenario where 60 active stakers, each of average stake size, chose to lock their tokens for 12 months, this would only require minting an extra 1% yield for each staker, which would total ~7.5m extra T tokens, which would imply an inflation increase of 0.0713%. These 60 stakers’ commitment would have a profound impact on the perception and security of TACo, but would only slightly increase the supply’s annual dilution.
- Long TACo lockups will likely have a positive, synergistic effect on tBTC and Random Beacon participation. Although technically the lockup only affects authorizations to the TACo app, the yield-maximizing strategy for stakers is to remain operators for all applications until the lock-up expires, in order to earn the maximum 15% yield.
Functionally, stakers will be able to choose between discrete lock-up periods and receive a commensurate bonus:
9 months total (6 month deauth delay + 3 month extension): 0.5% extra yield
12 months total (6 month deauth delay + 6 month extension): 1% extra yield
18 months total (6 month deauth delay + 12 month extension): 2% extra yield
24 months total (6 month deauth delay + 18 month extension): 3% extra yield
The breadth of these parameters have been validated via an anonymous survey conducted over the past few weeks, the results of which are below:
The survey results can also be used as a guide for estimating the required sum of tokens to mint, to be distributed to TACo stakers who opt for an extended token lock-up duration. Note that we have no way of knowing for certain which stake sizes will choose which percentage yield bonus, so there may be tokens left over (or less probable; not enough tokens – requiring another minting event).
This simple estimate takes the total sum of staked tokens (~3.1bn) and breaks it down by the percentage of survey respondents that chose each bonus yield option. It then multiplies that by the corresponding bonus yield percentage. This assumes that each survey-taker has the same stake size, and that every staker has to make a decision on the bonus, neither of which are the case – but this method still provides a useful ceiling for the bonus mint sum. This (over)estimate assumes 1 in 3 stakers (equivalent to ~1bn T) will choose a 24-month lockup, which requires minting ~31m T. However, fewer are likely to choose this bonus option.
Hence, minting 50m extra T – to be distributed to longer committing stakers – seems to be a safe upper bound. Leftover tokens will be used in the next reward cycle.
Please note the following rules apply to the bonus:
- The bonus will be claimable in the first minting event following TACo’s launch – i.e. stakers will not have to wait for their stake to unlock to withdraw.
- TACo’s deauthorization delay – the time one must wait between initiating a withdrawal from TACo service provision and being able to complete that withdrawal – is set to 6 months (182.5 days). This delay is the default and is entirely independent from the bonus mechanism. For stakers who choose a lock-up extension period for the one-off bonus, they may only initiate the deauthorization delay once the bonus lock-up extension period has elapsed. Stakers will still earn TACo yield after initiating the deauthorization delay, until the moment they withdraw their stake.
- The bonus is a one-off incentive mechanism – stakers will commit to a single token lock-up duration prior to TACo’s launch, and post-launch this commitment will not be editable. The opportunity to earn a bonus will not be available post-launch. The deadline for participation in the bonus will be shared in a follow-up post and in the announcements channel on Discord.
- Post-launch, top-ups to one’s stake will not count towards increasing the bonus sum (this will have already been calculated and minted), but top-ups will be subject to the same unlock horizon. In other words, you cannot create multiple stake tranches that unlock at different times.
A more robust mechanism to incentivize longer commitments may be introduced in later versions, where stakers can freely and arbitrarily prolong their lock-up durations to earn extra yield.
(5) TACo’s trust profile at genesis
From day one, every byte of data encrypted via TACo will be collectively managed by a decentralized cohort of nodes. However, the first mainnet version of TACo comes with certain limitations. The following is not an exhaustive list, rather a focus on trust burdens that require a decision from, or can be optimized by, the Threshold community. For a more comprehensive overview, check out the Trust Assumptions section in the documentation.
Contract ownership
Certain TACo contracts will be upgradeable, and as such, they require an owner. This proposal suggests that the Threshold Council owns all upgradeable contracts.
Management roles
Certain TACo contracts have privileged roles:
(1) A “treasury role” to claim fees from the protocol.
i. This role interacts with Polygon contracts.
ii. This proposal suggests assigning the treasury role to the Treasury Guild.
(2) An “initiator role”, which will be the only one authorized to create cohorts during the private beta phase.
i. This role interacts with Polygon contracts.
ii. This restriction will be removed once the private beta phase is over and cohort creation becomes more permissionless. Note that the initiator doesn’t retain any administrative control over the cohorts after initialization – its utility is purely to restrict when cohorts are created, to avoid the network being griefed by (temporarily expensive) cohort generation.
iii. This proposal suggests assigning the initiator role to the Integrations Guild, but other options are feasible too.
Porter gateway
In order to facilitate secure end-to-end communication from users’ browsers and TACo nodes, an intermediary gateway is required. NuCypher will run one of these gateways, but this proposal encourages anyone from the Threshold community to run their own Porter gateways as a public good. TACo adopters can additionally run their own Porter gateways if desired. In any case, Porter gateways don’t have any privileged view over the communications since information is always encrypted end-to-end, although they can potentially be unavailable.
Note that Porter gateways are only required when the requesting user is using a web-based application because the nodes use self-signed certificates for HTTPs communication; if other means are used (e.g., a desktop application that uses the TACo Python API), then Porter is not required.
Ethereum and Polygon providers
TACo nodes need to query (and occasionally, transact in) both Ethereum and Polygon, and therefore need an RPC endpoint to access these blockchains. This proposal encourages node operators to avoid all choosing the same blockchain provider, as this presents centralization and DOS risk. In the future, it may be possible to customize cohorts for diverse providers, and therefore there may confer an economic benefit to nodes who proactively increase collective infrastructural redundancy.