TACo

• Name: TACo
• URL: https://docs.taco.build/
• Category: threshold authorization-and-access-control middleware / programmable signing-and-decryption policy layer
• Summary: TACo is a threshold policy layer. It lets an app or user say when private data may be decrypted or when a payload may be signed, then pushes that decision through a node cohort instead of one hosted gatekeeper. The important parts are not the SDK gloss; they are cohort selection, DKG, condition language, external-data checks, and who controls the cohortAuthority.
• What it does:
  • Uses distributed key generation to form node cohorts that hold secret shares while exposing a public key for encryption or signing workflows
  • Supports Access Control flows where data is encrypted client-side, conditions are attached to ciphertext, and qualified requesters collect threshold decryption fragments to recover plaintext or a symmetric key
  • Supports conditions over time, contract state, RPC responses, JSON endpoints, JWT validation, and other composed checks
  • Introduces Action Control, currently documented as alpha / DEVNET, where a cohort threshold-signs data or ERC-4337-style operations when signing-object and environmental conditions are satisfied
  • Frames the system as reusable middleware for guarded decryption, guarded execution, attestations, and account-abstraction policy enforcement rather than as a single-purpose encryption product
• Key claims:
  • The docs describe TACo as decentralized cryptographic infrastructure for enforcing access and action policies without a single custodian.
  • The protocol-flow materials make the real sequence explicit: a cohortAuthority governs the cohort, DKG creates the shared cryptographic material, producers attach conditions, nodes evaluate those conditions, and the client finishes reconstruction only after collecting enough fragments.
  • The conditions reference matters because TACo is not limited to one narrow trigger surface; it can depend on chain state, web data, JWTs, and logical composition, which is where a lot of the practical policy power sits.
  • The docs make the governance choke point unusually plain: the cohortAuthority sets or delegates cohort selection, parameters, and rotation policy, and can hand that power to a multisig or DAO.
  • The Action Control docs show TACo is trying to become a threshold signing policy plane as well, including ERC-4337-style flows and ERC-1271-compatible verification through cohort-linked multisig contracts.
  • The maturity caveat matters: threshold signing is still alpha and DEVNET-only, so the decryption path is the more mature part of the stack.
• Whitepaper: No single canonical TACo whitepaper dominated this pass. The clearest current primary materials were the official TACo docs, protocol-flow pages, conditions reference, and the active node-runtime repository; see ../whitepapers/taco-primary-sources-2026-05-12.md.
• Sources:
  • https://docs.taco.build/
  • https://docs.taco.build/getting-started/key-concepts/access-control
  • https://docs.taco.build/getting-started/key-concepts/action-control
  • https://docs.taco.build/reference/architecture/protocol-flow
  • https://docs.taco.build/for-developers/taco-sdk/references/conditions
  • https://docs.taco.build/for-product-leads/action-control
  • https://github.com/nucypher/nucypher

Internal linkages

• Best comparison points: lit-protocol, shutter-network, and erc-4337.

Control surface

• Practical authority sits in cohortAuthority control, cohort membership and rotation, condition-language scope, offchain data sources, and whether downstream apps trust TACo cohorts instead of a hosted authorization service.

• The useful split is simple: Access Control is the live threshold-decryption policy layer; Action Control is the more ambitious threshold-signing layer, but still early.

• Last reviewed: 2026-06-03 UTC