TIP-062 | TACo (Threshold Access Control) added as Threshold application + Lock-up Bonus + PRE folded into TACo

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)


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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.


Pretty excited about the introduction of TACo as Threshold application!

I would strongly support this proposal.

Thank you arj for the clarity.


Hey @arj, thanks for this detailed proposal and I am in strong support. I’m very excited that TACo is entering the private beta phase, and the scope that TACo unlocks for Web3 seems enormous. Congrats to the everyone involved for the work that has gone into this so far.

I think the lock-up bonus makes a lot of sense to support a robust launch, and is well thought out.

I have a few questions:

  1. How many beta participants are there and how many nodes are required to service their cohorts?
  2. How long do you expect the beta program to run?
  3. Is billing automated and enforced onchain at launch, or will there be a party responsible for managing payments and accounts? Do you have a sense of how this will operate long-term?

re (5), I think the proposed management structure makes sense, though would like to clarify some things.

  1. Which contracts would the Council manage?
  2. What kind of upgrades could the Council authorise and how sensitive are they?
  3. Who is responsible for cohort administrative control once initiated (if anyone)?
  4. What kind of volume of transactions should the IG expect?

Thanks Arj!


Hey @sap, thanks for the support! I think I can weigh in on your last questions:

  1. Three contracts: TACoApplication on Ethereum Mainnet, and TACoChildApplication and Coordinator on Polygon Mainnet. See “🌮 The UItimate Taco Recipe 👩‍🍳 (or TACo Application Contracts Checklist) · Issue #101 · nucypher/nucypher-contracts · GitHub” for additional information. A bit on each of these contracts:
    • TACoApplication deals with authorization of Threshold stakers, and hence, it’s the piece that’s connected to the Threshold staking contract
    • TACoChildApplication is a mere “mirror” of TACoApplication but on Polygon. We need it to have a canonical view of stakers’ information from Polygon, where TACo protocol contracts live.
    • Coordinator is, well, coordinating the nodes that participate in TACo protocol, mostly for DKG routines (or “rituals”)
  2. Ideally, no upgrades, but being realistic, we can expect bug fixes coming. With Coordinator in particular, we expect upgrades to improve the protocol. At the very least, an upgrade that allows to rotate participants in DKG cohorts (v7.1 of TACo). With regard to how sensitive, it’s hard to say. Upgrades to TACoApplication are probably the most sensitive since they have certain degree of control over Threshold stakes (even potentially to slash stakers); TACoChildApplication and Coordinator mostly affect the execution of DKG rituals, and don’t have a direct impact on e.g., what TACo nodes decide with respect to condition evaluation.
  3. Each cohort will have an “authority” role. Normally, this will be the adopter entity that triggers the creation of a DKG cohort, but in the private beta phase, it’s the initiator that triggers this. In any case, adopters will be the authorities of their cohorts, regardless who initiated the DKG.
  4. Not much, probably less than 5 during the first months. Note however that this requires a Polygon address, and it seems the IG doesn’t have one currently. To be honest, since the initiator role has practically no power (it’s just gate-keeping who can create DKG groups during the private beta phase, which we expect to run for a few months at most)

Thanks for the well thought out and super detailed proposal, as with your prior ones, @arj. This is super exciting.

That very small projected increase in emissions would have an outsized impact on Threshold for the reasons you outline.

Strongly support and looking forward to seeing teams building on TACo in Istanbul next month!


Thanks @sap, good questions! And I agree that TACo is a big deal for the capabilities of Web3 apps.

  1. How many beta participants are there and how many nodes are required to service their cohorts?

In the first stage of the beta, we will authorize three projects to generate their own cohorts of TACo nodes. You can learn more about them in the Staker Townhall, where two of the three demoed their technology. As it stands, they’re all planning to use the default cohort size of 30, which means the minimum number of nodes is technically also 30, but of course it would be preferable to have 2 or 3 multiples of that. It is perfectly fine for an individual node to be in multiple cohorts servicing different adopting applications, but the more nodes we have, the lower the collusion surface, the greater the redundancy, and the more cohorts we can generate over the medium-term (see below).

  1. How long do you expect the beta program to run?

Our adopters all have their own distinct roadmaps, so we’re trying to be as flexible as possible. It’s looking like the beta will probably have at least two stages – one for the first three adopters, and then a second for (i) projects we’ve been in touch with for a while but won’t be ready this year and (ii) the most promising projects that learn about and get interested in TACo following the launch. All that to say, we don’t have a hard deadline. I expect it will run for about 3-6 months.

  1. Is billing automated and enforced onchain at launch, or will there be a party responsible for managing payments and accounts? Do you have a sense of how this will operate long-term?

Billing will be manual from launch, inasmuch as beta adopters will first pay into a contract, which prompts a DKG ritual and the generation of a cohort. They will renew this ‘subscription’ by regularly paying upfront for 6 month’s worth of staker availability.

Onboarding developers won’t be automated for a while, because we can’t make it permissionless until we’ve driven down the gas cost of replacing operators. The larger the node population, the more cohorts we can generate and adopters we can serve, because the issue is much worse when a single staker is in too many cohorts (and if there’s a lot of attrition). Regardless, this economic burden will be lessened over the medium term via R&D, and stakers will be reimbursed for gas costs.

Regarding the distribution of fees collected, we will post a proposal to automate this fairly soon after launch. Until then they’ll sit in a contract likely controlled by the Treasury Guild.


Thanks a lot for the clarification on those points @arj and @davidnunez, it all makes a lot of sense. I can set the IG multi-sig up on Polygon. Good luck with the launch!


This proposal has been moved to Snapshot, and has been approved by the community with the following results:


  • YES: 572M T - 100%
  • NO: 0 T - 0%
  • ABSTAIN: 0 T - 0%
1 Like

What is the impact of this proposal on the legacy KEEP stakers who are in the process of transitioning their stake per Transition Guide for Legacy Stakers?


What is the impact of this proposal on the legacy KEEP stakers who are in the process of transitioning their stake per Transition Guide for Legacy Stakers?

IMO, extending the bonus deadline for the legacy KEEP stakers is only fair and in alignment with one of the major goals of TIP-062, which is not penalizing any legacy staker that’s following the transition process. This would require a minor upgrade to the TACo application contract to add an allowlist for these particular cases, with their deadline (February 23rd, 2024).