Social trading and copy trading in crypto run into a trust paradox. If you’re a trader, the only way to prove you’re consistently profitable is to expose your full history: entries, exits, timing, sizing, strategy, basically your edge. If you’re a follower, you’re forced to rely on screenshots, self-reported stats, and platform claims that can be faked, cherry-picked, or manipulated.
Obscura takes a different approach: verifiable reputation without exposure. Traders can prove aggregate performance cryptographically across exchanges while keeping individual trades and strategies private. Followers get a trust anchor they can verify. The standard shifts from “trust me” to “verify me”.
We are excited to highlight teams building confidential, verifiable applications on Horizen’s privacy-first infrastructure, projects that treat privacy as a default property of the stack, not an afterthought. Today we’re featuring Obscura, a privacy-preserving reputation layer designed for DeFi and cross-venue trading.
To go deeper into how Obscura works and the trade-offs behind “trade with proof, not trust,” we spoke with the team about verification, enclaves, threat models, and where on-chain reputation goes next.
Obscura is a privacy-preserving reputation layer for traders. The core problem we solve is this: in social and copy trading, you currently can’t prove you’re a good trader without revealing everything, your positions, your strategies, your edge. And if you’re a follower, you’re forced to trust screenshots and claims that anyone can fake. We break that paradox. With Obscura, traders can prove their track record cryptographically, across any exchange, without exposing the trades that built it. Followers get verifiable trust. Traders keep their privacy.
What’s being proven is aggregate performance: total PnL, win rate, risk-adjusted returns, over a specific time window. The ZK proof attests that a trader achieved those results based on real trades, verified by the protocol. What you no longer have to trust: screenshots, self-reported stats, or the platform operator’s word. The math doesn’t lie. If a proof verifies on-chain, the performance is real. You also don’t have to trust that we’re being honest about someone’s data, because we literally can’t see it. Credentials are processed inside hardware enclaves that even we can’t access.
Traders connect their exchange accounts, either through API keys (for CEXs) or wallet signatures (for DEXs). All sensitive data goes straight into a Trusted Execution Environment, a hardware-isolated enclave where even our servers can’t peek inside. From there, we normalize trades across venues into a common format, compute performance metrics, and generate a ZK proof that commits to those results. What ends up on-chain, and visible to followers, is the proof and the aggregate stats. Not the trades. Not the timing. Not the strategy. Just the verified outcome. That’s how we make reputation portable without making it transparent.
Users should think of enclaves as a very strong lock on a very secure room, but not magic. The guarantees are: your API keys are encrypted at the hardware level, never written to disk, never logged. Even if someone compromised our servers, they’d get ciphertext, not secrets.
The residual risks are real but narrow. First, you’re trusting the enclave hardware (AWS Nitro in our case) to behave as advertised; this is a bet on Intel/AWS security, not on us. Second, side-channel attacks exist in theory, though Nitro mitigates most known vectors. Third, the moment credentials are decrypted inside the enclave to sign an order, they exist briefly in protected memory. If the enclave itself were somehow breached mid-operation, that’s the exposure window. We treat this seriously: credentials are purged immediately after use, and we monitor for anomalies.
Bottom line: enclaves massively shrink the attack surface, but they don’t eliminate trust, they shift it to hardware attestation.
TEE attested means the trader’s credentials were handled inside a hardware enclave with cryptographic proof that the right code was running. It’s about how the data was processed: securely, privately, tamper-proof.
ZK verified means their performance stats were computed correctly and committed on-chain via a zero-knowledge proof. It’s about what was proven: aggregate results that anyone can verify without seeing the underlying trades.
You need both because they solve different problems. TEE handles the sensitive stuff (keys, raw trade logs). ZK handles the public claim (I made 40% this quarter). Without TEE, we’d have to see your secrets. Without ZK, you’d have to expose your trades to prove anything. Together, they let us verify reputation without ever touching the sensitive details.
Data normalization, hands down. Every exchange speaks a different dialect. Binance uses one fee structure, Hyperliquid another. Some venues report PnL natively; others require you to reconstruct it from fills. Timestamps, precision, rounding, none of it standardized.
The second challenge is provenance. On a DEX, trades are on-chain, so authenticity is easy to verify. On a CEX, the data is private, and you’re trusting an API response. We’re addressing this with ZK-proofs to cryptographically attest CEX data without trusting the exchange or the user. But that’s still early.
The hardest part isn’t any single integration; it’s building a system flexible enough to handle both worlds while producing a single, unified reputation score that means the same thing regardless of where the trades happened.
Today, traders can prove: total realized PnL, trade count, win rate, and per-symbol performance over a defined time window (30/60/90 days or custom). The ZK circuit commits to all trades in that window, not a subset.
Selective disclosure is prevented at the circuit level. The proof commits to a hash of the full trade set for the period. If a trader omits trades, the commitment won’t match. We also require time-bounded proofs with clear start and end timestamps, so you can’t just prove your best month and hide the rest.
Going forward, we’re adding Sharpe ratio, max drawdown, and rolling performance curves. But the core design stays the same: you prove the whole picture or nothing.
First, we require a minimum track record before a trader can be copied, no fresh accounts with one lucky trade. Second, we surface risk metrics alongside returns: drawdown, volatility, trade frequency. A 200% return with 80% drawdown tells a very different story than the headline number.
Third, copy trading on Obscura includes configurable risk limits: max position size, daily loss caps, symbol restrictions. Followers aren’t forced to mirror 1:1, they can scale down exposure or exclude certain asset classes.
Finally, we’re building reputation decay. A proof from two years ago shouldn’t carry the same weight as one from last month. Recency matters. We want the system to reward consistent performance, not one-time outliers.
Lending and credit. Today, DeFi lending is over-collateralized because there’s no identity, no track record. If a trader can prove consistent profitability and low drawdown, a lending protocol could offer better terms: lower collateral, higher limits, without taking on more risk.
Insurance is another. A verifiable track record of risk management could translate to lower premiums.
And then there’s governance. Protocols often want to weight voting power by contribution or expertise. Verified on-chain reputation gives you a Sybil-resistant signal for who actually knows what they’re doing.
We see ourselves as infrastructure. Obscura proofs could plug into any system that needs to answer: “Can I trust this address to perform?”
Verification depth vs latency. Our ZK circuits run on real trade data, which means the more trades you include, the longer proofs take. Right now we support up to 10 trades per proof with about 2 to 5 seconds of proving time. That’s fine for monthly reports but not for real-time verification.
We’re working on recursive proof aggregation, batching smaller proofs into one, to handle larger trade sets without blowing up latency. But it’s genuinely hard. Every added trade multiplies constraints. There’s no free lunch.
The good news: for reputation, you don’t need per-trade granularity in real-time. Monthly or weekly proofs are enough. But we’re honest that if someone wanted continuous verification, we’re not there yet. In the future our plan is to run a decentralized node of trade validators which could help achieve the result of continuous verification.
We’re a small team with backgrounds in trading infrastructure, security engineering, and zero-knowledge systems. Several of us spent years building execution systems and saw firsthand how broken trust is in social trading, platforms where anyone can fake a track record, where API key breaches are routine, where followers get burned by fraud. Some of us were once part-time traders who fell victim to trading scams.
The turning point was realizing that existing solutions all require exposure. You either reveal your trades to prove you’re good, or you stay private and can’t build a following. That’s not a technology gap, it’s a design failure. ZK and TEE gave us a way to break that trade-off. So we built Obscura.
Horizen has a long history with privacy, it started as a privacy-focused chain. The L3 infrastructure gives us cheap on-chain verification for ZK proofs without the gas costs of Ethereum mainnet. And the Thrive program gave us runway, ecosystem support, and access to a community that already gets why privacy matters.
Technically, the Horizen stack is EVM-compatible, which means our smart contracts are portable. But the real draw was alignment: we wanted to build on a chain where privacy isn’t an afterthought. Horizen’s identity is built around it.
In my opinion, it is a yes to all three.
Capital allocation: today, DeFi can’t distinguish a first-time user from a 10-year profitable trader. If reputation is verifiable, capital flows to proven performers, better rates for good traders, more efficient markets overall.
Risk pricing: insurance, lending, even liquidity provision can all be repriced based on verified track records. Protocols stop treating everyone as equally risky.
Reputation as an asset: we think OBSCURA_IDs, persistent, cross-chain identities with verifiable history, become something you build over years and carry with you. Switching costs go up because your reputation is non-portable to competitors. That’s a moat for traders, and it’s a moat for us.
If we get this right, on-chain reputation becomes as important as on-chain assets. Trust moves from “I believe you” to “I verified you.”
🌐: https://www.portal.obscura.finance/ 𝕏: https://x.com/UseObscura
Stay tuned for the next Builder Spotlight as we continue to highlight the teams building on Horizen.
Social trading and copy trading in crypto run into a trust paradox. If you’re a trader, the only way to prove you’re consistently profitable is to expose your full history: entries, exits, timing, sizing, strategy, basically your edge. If you’re a follower, you’re forced to rely on screenshots, self-reported stats, and platform claims that can be faked, cherry-picked, or manipulated.
Obscura takes a different approach: verifiable reputation without exposure. Traders can prove aggregate performance cryptographically across exchanges while keeping individual trades and strategies private. Followers get a trust anchor they can verify. The standard shifts from “trust me” to “verify me”.
We are excited to highlight teams building confidential, verifiable applications on Horizen’s privacy-first infrastructure, projects that treat privacy as a default property of the stack, not an afterthought. Today we’re featuring Obscura, a privacy-preserving reputation layer designed for DeFi and cross-venue trading.
To go deeper into how Obscura works and the trade-offs behind “trade with proof, not trust,” we spoke with the team about verification, enclaves, threat models, and where on-chain reputation goes next.
Obscura is a privacy-preserving reputation layer for traders. The core problem we solve is this: in social and copy trading, you currently can’t prove you’re a good trader without revealing everything, your positions, your strategies, your edge. And if you’re a follower, you’re forced to trust screenshots and claims that anyone can fake. We break that paradox. With Obscura, traders can prove their track record cryptographically, across any exchange, without exposing the trades that built it. Followers get verifiable trust. Traders keep their privacy.
What’s being proven is aggregate performance: total PnL, win rate, risk-adjusted returns, over a specific time window. The ZK proof attests that a trader achieved those results based on real trades, verified by the protocol. What you no longer have to trust: screenshots, self-reported stats, or the platform operator’s word. The math doesn’t lie. If a proof verifies on-chain, the performance is real. You also don’t have to trust that we’re being honest about someone’s data, because we literally can’t see it. Credentials are processed inside hardware enclaves that even we can’t access.
Traders connect their exchange accounts, either through API keys (for CEXs) or wallet signatures (for DEXs). All sensitive data goes straight into a Trusted Execution Environment, a hardware-isolated enclave where even our servers can’t peek inside. From there, we normalize trades across venues into a common format, compute performance metrics, and generate a ZK proof that commits to those results. What ends up on-chain, and visible to followers, is the proof and the aggregate stats. Not the trades. Not the timing. Not the strategy. Just the verified outcome. That’s how we make reputation portable without making it transparent.
Users should think of enclaves as a very strong lock on a very secure room, but not magic. The guarantees are: your API keys are encrypted at the hardware level, never written to disk, never logged. Even if someone compromised our servers, they’d get ciphertext, not secrets.
The residual risks are real but narrow. First, you’re trusting the enclave hardware (AWS Nitro in our case) to behave as advertised; this is a bet on Intel/AWS security, not on us. Second, side-channel attacks exist in theory, though Nitro mitigates most known vectors. Third, the moment credentials are decrypted inside the enclave to sign an order, they exist briefly in protected memory. If the enclave itself were somehow breached mid-operation, that’s the exposure window. We treat this seriously: credentials are purged immediately after use, and we monitor for anomalies.
Bottom line: enclaves massively shrink the attack surface, but they don’t eliminate trust, they shift it to hardware attestation.
TEE attested means the trader’s credentials were handled inside a hardware enclave with cryptographic proof that the right code was running. It’s about how the data was processed: securely, privately, tamper-proof.
ZK verified means their performance stats were computed correctly and committed on-chain via a zero-knowledge proof. It’s about what was proven: aggregate results that anyone can verify without seeing the underlying trades.
You need both because they solve different problems. TEE handles the sensitive stuff (keys, raw trade logs). ZK handles the public claim (I made 40% this quarter). Without TEE, we’d have to see your secrets. Without ZK, you’d have to expose your trades to prove anything. Together, they let us verify reputation without ever touching the sensitive details.
Data normalization, hands down. Every exchange speaks a different dialect. Binance uses one fee structure, Hyperliquid another. Some venues report PnL natively; others require you to reconstruct it from fills. Timestamps, precision, rounding, none of it standardized.
The second challenge is provenance. On a DEX, trades are on-chain, so authenticity is easy to verify. On a CEX, the data is private, and you’re trusting an API response. We’re addressing this with ZK-proofs to cryptographically attest CEX data without trusting the exchange or the user. But that’s still early.
The hardest part isn’t any single integration; it’s building a system flexible enough to handle both worlds while producing a single, unified reputation score that means the same thing regardless of where the trades happened.
Today, traders can prove: total realized PnL, trade count, win rate, and per-symbol performance over a defined time window (30/60/90 days or custom). The ZK circuit commits to all trades in that window, not a subset.
Selective disclosure is prevented at the circuit level. The proof commits to a hash of the full trade set for the period. If a trader omits trades, the commitment won’t match. We also require time-bounded proofs with clear start and end timestamps, so you can’t just prove your best month and hide the rest.
Going forward, we’re adding Sharpe ratio, max drawdown, and rolling performance curves. But the core design stays the same: you prove the whole picture or nothing.
First, we require a minimum track record before a trader can be copied, no fresh accounts with one lucky trade. Second, we surface risk metrics alongside returns: drawdown, volatility, trade frequency. A 200% return with 80% drawdown tells a very different story than the headline number.
Third, copy trading on Obscura includes configurable risk limits: max position size, daily loss caps, symbol restrictions. Followers aren’t forced to mirror 1:1, they can scale down exposure or exclude certain asset classes.
Finally, we’re building reputation decay. A proof from two years ago shouldn’t carry the same weight as one from last month. Recency matters. We want the system to reward consistent performance, not one-time outliers.
Lending and credit. Today, DeFi lending is over-collateralized because there’s no identity, no track record. If a trader can prove consistent profitability and low drawdown, a lending protocol could offer better terms: lower collateral, higher limits, without taking on more risk.
Insurance is another. A verifiable track record of risk management could translate to lower premiums.
And then there’s governance. Protocols often want to weight voting power by contribution or expertise. Verified on-chain reputation gives you a Sybil-resistant signal for who actually knows what they’re doing.
We see ourselves as infrastructure. Obscura proofs could plug into any system that needs to answer: “Can I trust this address to perform?”
Verification depth vs latency. Our ZK circuits run on real trade data, which means the more trades you include, the longer proofs take. Right now we support up to 10 trades per proof with about 2 to 5 seconds of proving time. That’s fine for monthly reports but not for real-time verification.
We’re working on recursive proof aggregation, batching smaller proofs into one, to handle larger trade sets without blowing up latency. But it’s genuinely hard. Every added trade multiplies constraints. There’s no free lunch.
The good news: for reputation, you don’t need per-trade granularity in real-time. Monthly or weekly proofs are enough. But we’re honest that if someone wanted continuous verification, we’re not there yet. In the future our plan is to run a decentralized node of trade validators which could help achieve the result of continuous verification.
We’re a small team with backgrounds in trading infrastructure, security engineering, and zero-knowledge systems. Several of us spent years building execution systems and saw firsthand how broken trust is in social trading, platforms where anyone can fake a track record, where API key breaches are routine, where followers get burned by fraud. Some of us were once part-time traders who fell victim to trading scams.
The turning point was realizing that existing solutions all require exposure. You either reveal your trades to prove you’re good, or you stay private and can’t build a following. That’s not a technology gap, it’s a design failure. ZK and TEE gave us a way to break that trade-off. So we built Obscura.
Horizen has a long history with privacy, it started as a privacy-focused chain. The L3 infrastructure gives us cheap on-chain verification for ZK proofs without the gas costs of Ethereum mainnet. And the Thrive program gave us runway, ecosystem support, and access to a community that already gets why privacy matters.
Technically, the Horizen stack is EVM-compatible, which means our smart contracts are portable. But the real draw was alignment: we wanted to build on a chain where privacy isn’t an afterthought. Horizen’s identity is built around it.
In my opinion, it is a yes to all three.
Capital allocation: today, DeFi can’t distinguish a first-time user from a 10-year profitable trader. If reputation is verifiable, capital flows to proven performers, better rates for good traders, more efficient markets overall.
Risk pricing: insurance, lending, even liquidity provision can all be repriced based on verified track records. Protocols stop treating everyone as equally risky.
Reputation as an asset: we think OBSCURA_IDs, persistent, cross-chain identities with verifiable history, become something you build over years and carry with you. Switching costs go up because your reputation is non-portable to competitors. That’s a moat for traders, and it’s a moat for us.
If we get this right, on-chain reputation becomes as important as on-chain assets. Trust moves from “I believe you” to “I verified you.”
🌐: https://www.portal.obscura.finance/ 𝕏: https://x.com/UseObscura
Stay tuned for the next Builder Spotlight as we continue to highlight the teams building on Horizen.
Subscribe to Horizen Blog
Subscribe to Horizen Blog
Horizen BlogBuild Smarter dApps with Real-Time Data on Horizen
Horizen BlogWelcome to Privacy on Base
A new chapter for onchain privacy begins today. Horizen has officially launched its mainnet on Base, bringing a practical and compliance-friendly path to private onchain activity - one that fits seamlessly into the Ethereum environment millions already use. This launch completes our transition from an isolated proof-of-work chain to a fully EVM-native chain that settles to Ethereum. For everyday users, this shift means faster transactions, lower fees, and access to tools and apps that feel fa...
Horizen BlogZenIP 42409: ZenIP 42407 Addendum, Horizen 2.0 Tokenomics Proposal
There is a new ZenIP Proposal that recently passed, ZenIP 42409, which is an Addendum to ZenIP 42407: Horizen Tokenomics Proposal. The timeline for the vote on ZenIP 42409 was that voting opened on Monday, April 21st, 2025, at 12pm EST, and closed on Thursday, April 24th, 2025, at 12pm EST. With a quorum of 142% and 99.39% (1.1M $ZEN) of the votes FOR, the proposal passed! The full results of the vote can be found on Snapshot here. Let’s review this ZenIP proposal below, and we’ll also remind...
Horizen BlogBuild Smarter dApps with Real-Time Data on Horizen
Horizen BlogWelcome to Privacy on Base
A new chapter for onchain privacy begins today. Horizen has officially launched its mainnet on Base, bringing a practical and compliance-friendly path to private onchain activity - one that fits seamlessly into the Ethereum environment millions already use. This launch completes our transition from an isolated proof-of-work chain to a fully EVM-native chain that settles to Ethereum. For everyday users, this shift means faster transactions, lower fees, and access to tools and apps that feel fa...
Horizen BlogZenIP 42409: ZenIP 42407 Addendum, Horizen 2.0 Tokenomics Proposal
There is a new ZenIP Proposal that recently passed, ZenIP 42409, which is an Addendum to ZenIP 42407: Horizen Tokenomics Proposal. The timeline for the vote on ZenIP 42409 was that voting opened on Monday, April 21st, 2025, at 12pm EST, and closed on Thursday, April 24th, 2025, at 12pm EST. With a quorum of 142% and 99.39% (1.1M $ZEN) of the votes FOR, the proposal passed! The full results of the vote can be found on Snapshot here. Let’s review this ZenIP proposal below, and we’ll also remind...
Share Dialog
Share Dialog
Horizen Blog
Horizen Blog
>6.6K subscribers
>6.6K subscribers
No comments yet