Introduction
My name is Miguel Tavares, and I am applying for a seat on the Horizen Special Council.
I live in Portugal and have held ZEN since the ZenCash era. I have followed Horizen through several substantial changes, including decisions that were not always easy for long-term holders. I believe its current direction creates a credible opportunity to give ZEN a useful role within a modern, privacy-oriented application ecosystem.
Until now, I have participated mainly as a holder and technical observer rather than as a visible contributor to recent governance discussions. I do not want to suggest otherwise. If elected, I would commit to active participation, clear reasoning and public accountability.
Professional and technical background
I am a hands-on technology builder, former CTO and founder of Kotav Labs, where I work on AI-assisted cybersecurity and application-security systems.
My experience covers software architecture, applied cryptography, blockchain systems, AI agents and security engineering.
My most relevant Web3 work is SOS, where I was the architect and lead engineer. SOS is a public pre-mainnet research implementation created to explore what a blockchain designed for the post-quantum era could look like in practice. Its architecture includes ML-DSA-65 signatures, ML-KEM-1024 encrypted notes, opt-in shielded transactions, transparent STARK-based proofs and a proof-based, non-custodial bridge to Ethereum.
Building SOS required more than selecting cryptographic primitives. It meant defining trust boundaries, separating native post-quantum guarantees from the limitations of external chains, and considering how privacy, interoperability, governance and operational security interact in a working system. Development is currently halted, and I am no longer actively working on its implementation.
My other Web3 work has included contributions to AdamantFi, a privacy-oriented project on Secret Network, Veil—an experimental prediction-market prototype designed for Aztec that did not reach mainnet—and Veil11, an NFT-based fantasy football project on Sui. Together, these projects gave me practical exposure to different execution models, privacy technologies, bridge designs and developer environments.
That experience shapes how I evaluate technical proposals: by examining what the architecture actually guarantees, which assumptions it depends on, how it can fail and who remains accountable when theory becomes an operating system.
Experience with Horizen
My relationship with Horizen began as a ZEN holder during the ZenCash period. What kept my attention was the project’s continuing interest in privacy, security and useful infrastructure, even as its architecture and market position evolved.
Horizen is now operating in a different environment. Its move towards an EVM-compatible system on Base lowers some barriers for developers, while Vela and the wider work around confidential computation introduce important questions about privacy guarantees, infrastructure dependencies and trust assumptions.
The Special Council should be capable of examining those questions without reducing governance to either technical theatre or marketing. The community needs clear explanations of what a system protects, what it assumes and where its guarantees end.
Why I am applying
The Special Council is a stewardship and oversight body. Its members must review proposals, protect the interests of the DAO and respond when security concerns require urgent attention.
I believe I can contribute most where governance meets technical reality.
A proposal can be well written and still depend on an unsafe bridge, an unexamined trusted party, an unrealistic implementation plan or a privacy claim that does not survive closer inspection. Conversely, a technically sound proposal can fail because nobody defined ownership, delivery milestones or what happens after its initial funding.
My background allows me to examine both sides of that problem.
What I would bring to the Special Council
When reviewing a ZenIP, EONIP or treasury-funded initiative, I would focus on questions such as:
- Is the proposal technically coherent and sufficiently specified?
- Are its security and privacy assumptions explicit?
- What does the proposed system genuinely guarantee?
- Does it introduce trusted operators or central points of failure?
- Are external dependencies and bridge risks properly documented?
- Can its budget, implementation plan and milestones be verified?
- Who remains responsible after the initial delivery?
- Does it create useful demand for ZEN, or merely attach the token to a product?
- What happens if the system, supplier or integration fails?
I would also support clearer reporting for funded initiatives. A grant should not end with a launch announcement. Where appropriate, funding should be connected to observable milestones, working software, documentation and evidence of what was actually delivered.
During a security incident, I would favour a disciplined process: establish the known facts, separate confirmed impact from speculation, identify the available containment options and preserve the reasoning behind the final decision. Speed matters, but so does leaving a decision record that the community can later examine.
Priorities
Security-focused proposal review
Technical proposals should document their architecture, dependencies, trust assumptions, failure modes and security consequences before reaching a final vote.
Accountability for treasury-funded work
Funding decisions should define measurable deliverables and reporting expectations. The community should be able to distinguish completed work from activity that merely consumed a budget.
Precise privacy claims
Privacy and confidential-computing systems should explain what is protected, from whom it is protected, and which hardware, operators or network assumptions remain trusted.
Useful ZEN integration
Proposals involving ZEN should explain why the token is technically or economically necessary. Adding a token to a design does not automatically create sustainable utility.
Understandable governance communication
Council reasoning should be accessible to holders who are not protocol engineers. Technical accuracy should not require inaccessible language.
Community participation
I have not been one of the most visible contributors in recent Horizen governance discussions. That is a fair weakness in my candidacy.
My intention is not to appear during an election and then disappear. If elected, I would participate in proposal discussions, explain my decisions and remain available to the community throughout the term.
I would also try to make technically complex proposals easier to evaluate without oversimplifying them. Tokenholders should not need to trust a proposal merely because its authors understand the technology better than they do.
Disclosure regarding SOS
I previously served as the architect and lead engineer of SOS. The project is currently halted, and I am not actively developing or operating it.
SOS was created as an independent research and engineering exercise. It is not currently operating as a commercial blockchain network.
It may eventually progress to mainnet. If development resumes, the intended direction is for the project to move towards community governance through a DAO rather than remain under my control. I would not lead its future operations; my role was in the original architecture and engineering implementation.
I am disclosing SOS because it is relevant to my technical background and because the Horizen community should be able to assess any potential conflict openly. If its status or my involvement changes materially during a Council term, I would disclose that change and recuse myself from any decision where a conflict exists.
I am also the founder of Kotav Labs, a cybersecurity company developing technology for authorised security assessments. Kotav Labs is not affiliated with the Horizen Foundation and currently has no commercial relationship with Horizen.
Availability and commitment
I can attend the Council’s regular meetings, review proposals between meetings and participate in urgent security discussions when required.
I would approach the position as a stewardship responsibility, not as an operational role inside the Foundation. The Council should question, review and protect the DAO’s interests while respecting the authority of tokenholders.
Where confidentiality is required for legal, commercial or security reasons, I would respect it. In every other case, I would favour explaining my reasoning publicly, including when a decision is difficult or unpopular.
Country of residence
Portugal.
