Token Flow

flowchart LR
    A[User pays fee] --> B[$CAPS settled on-chain]
    B --> C[Operators and validators]
    B --> D[Buyback and burn]
    D --> E[$CAPS removed from supply]

Revenue Streams

TIP Verification Fees

TIP (TEE Integrity Prover) provides runtime protection for smart contracts and Web3 infrastructure. Projects pay ongoing fees in $CAPS across three distinct services.

Runtime monitoring. TEE enclaves capture a cryptographic fingerprint of a project’s running code every 60 seconds, compare it against the expected state, and generate a ZK proof posted on-chain. Any deviation triggers an alert immediately. Fees accrue continuously as long as a project is monitored.

Source verification and audit. An AI agent continuously scans open-source dependencies for known vulnerabilities, license issues, and malicious packages. It also flags discrepancies between deployed bytecode and published source code, ensuring what is running on-chain matches what was audited. Each scan cycle costs $CAPS.

Autonomous pentesting. AI-driven penetration testing probes smart contracts and infrastructure for exploitable weaknesses on an ongoing basis. Each pentesting cycle runs against live services and costs $CAPS.

Pricing across all three services is tiered across Standard, Premium, and Enterprise plans.

CIFER Encryption Fees

CIFER is a zero-key post-quantum encryption network. Every encryption and decryption operation routed through its TEE enclave cluster requires $CAPS. As builders integrate and usage grows, the number of daily operations scales directly, and so does fee consumption.

Appchain Settlement Fees

Every TIP proof and every CIFER cryptographic commitment is anchored on the Ternoa appchain. Each on-chain write operation carries a micro-fee denominated in $CAPS. As proof and commitment volume grows with the builder ecosystem, settlement fees scale alongside it.

Projects with high security requirements can also use Ternoa directly as their settlement layer. By doing so, they inherit both the native yield generated through VaultBridge on every dollar they bring onto the chain and the full security stack that the appchain is built around. For these projects, Ternoa is not just a place to post proofs but the foundational layer their entire operation settles on.

Network Security

Network security on Ternoa is provided through stablecoin staking. When users bridge stablecoins onto Ternoa, those assets become vbAssets. For example, USDC becomes vbUSDC. Users can then optionally delegate their vbAssets to secure the two networks, similar to delegated proof of stake.

TIP validator staking. vbAssets delegated to TIP validator nodes power the 60-second TEE integrity checks and generate the ZK proofs posted on-chain. Validators earn rewards in $CAPS.

CIFER enclave operator staking. vbAssets delegated to CIFER enclave operators secure the geo-distributed Intel SGX/TDX and AMD SEV enclave network. These enclaves handle all key generation and usage in hardware-isolated environments. Operators earn rewards in $CAPS.

Rewards draw from an expanding fee base rather than from token emissions.

VaultBridge and Native DeFi

VaultBridge is an AggLayer technology integrated into the Ternoa appchain. When users bridge funds onto Ternoa, those funds generate yield for the sender automatically. Every bridging position becomes a productive DeFi position with no additional steps required from the user.

By default, bridged stablecoins pass through Morpho to generate yield. After this Morpho phase, users can optionally delegate their vbAssets to CIFER enclave operators to further secure the decentralized post-quantum zero-key encryption network and earn additional $CAPS rewards. 10% of all staking rewards from this delegation are burned, permanently reducing circulating supply each time rewards are distributed.

10% of all yield generated through VaultBridge is also allocated to buyback-and-burn. The remaining yield goes to the user who bridged the funds.

Buyback and Burn

10% of all yield flowing through the Ternoa ecosystem, from VaultBridge positions and from vbAsset staking rewards, is used to purchase $CAPS from the open market and permanently remove it from circulation.

The burn rate is a direct function of real economic activity. The more funds are bridged and staked, the more $CAPS gets burned. As ecosystem usage grows, supply contracts.

This is structurally different from scheduled or discretionary burns. The mechanism runs continuously and scales with actual usage.

Shield Score

Projects built on Ternoa’s security layer that launch their own token may allocate a portion of their supply to $CAPS holders, depending on each builder’s launch design. Distribution is weighted by Shield Score, a cumulative loyalty metric that reflects how long you have held $CAPS and how much you hold.

Shield Score accrues week over week and never resets. The longer you hold, the larger your potential share of each qualifying builder token distribution.

Examples

RWA Project Building Directly on Ternoa

A real-world asset platform tokenizing property, invoices, or commodities and settling natively on the Ternoa appchain is the most complete case for $CAPS demand generation.

Every dollar brought onto Ternoa passes through VaultBridge before anything else. This means the platform’s entire TVL generates yield automatically from day one, with no opt-in required. 10% of that yield is used to buy and burn $CAPS continuously. The larger the TVL, the more $CAPS gets removed from supply.

On top of that, the platform uses TIP to monitor its smart contracts in real time, paying $CAPS per 60-second verification cycle. If it relies on CIFER to encrypt sensitive asset data or investor credentials, every encryption and decryption operation costs $CAPS. Every proof and commitment produced by both services settles on the appchain, adding micro-fees in $CAPS.

A single RWA project building natively on Ternoa therefore contributes to $CAPS demand across four vectors simultaneously: VaultBridge yield burn, TIP fees, CIFER fees, and appchain settlement fees.

EVM Project Integrating TIP or CIFER

A DeFi protocol, bridge, or dApp deployed on Ethereum, Avalanche, or any EVM-compatible chain does not need to move to Ternoa. TIP and CIFER are available as external services.

If the team wants continuous runtime protection for their smart contracts, they integrate TIP and pay $CAPS per verification cycle. If they want to encrypt user data, function inputs, or on-chain state variables, they integrate CIFER and pay $CAPS per operation. Both services settle their proofs and commitments on the Ternoa appchain, contributing settlement fees as well.

The EVM project stays on its own chain. $CAPS is consumed purely through service usage.

Web2 Project or Open Source Repository

A traditional software company or an open-source project maintainer can use TIP’s AI scanning and autonomous pentesting without any blockchain deployment.

If they want to verify that their published packages have not been tampered with, or continuously audit their dependencies for vulnerabilities, they pay $CAPS per scan cycle. If they want ongoing penetration testing against their infrastructure, they pay $CAPS per pentesting cycle.

For these projects, $CAPS usage is entirely fee-driven and scoped to the specific TIP services they activate.

What Is Live Today

The Ternoa ecosystem is already partially live across both public mainnet and private production environments.

Public mainnet. VaultBridge is live and the Ternoa settlement layer is active on mainnet. The network is DeFi-ready for bridged assets and productive positions. TIP Audit is available in alpha. CIFER Web3 Encryption is available in beta on Ethereum, Base, and Avalanche. CIFER Web2 Encryption is available in beta.

Private production. TIP Runtime is live in private production. TIP Audit is live for selected private integrations. Delegated funds to TEE operators are live in private production.

What Comes Next

The next phase focuses on opening private production features to broader public access, scaling TIP Runtime, growing CIFER adoption across Web3 and Web2, and deepening the connection between VaultBridge activity, network security rewards, and the $CAPS buyback-and-burn mechanism.

$CAPS Token Utility was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

The uncomfortable truth is that most of the money lost wasn’t taken by genius hackers finding exotic vulnerabilities. It was taken through attacks on problems that have been known for years — problems that the industry has chosen to patch around rather than solve at the root.

Let’s talk about why.

Smart contracts are open books — by design

When a developer deploys a smart contract on a public blockchain, everything about it becomes visible to the entire world. The logic, the state variables, the balances, the conditions that trigger transfers — all of it is readable by anyone with an internet connection. This is intentional. Transparency is part of the value proposition of public blockchains.

But that same transparency is also a gift to attackers. Before a team has even finished testing their deployment, adversaries can already be reading the contract, mapping its logic, and looking for weaknesses. The attacker has unlimited time and zero cost to study the target. The defender has to get it right once, under time pressure, on a live network where a mistake means permanent loss.

This asymmetry is brutal. And it doesn’t go away.

Audits are a snapshot. Code runs forever.

The standard response to smart contract risk is the security audit. Before launch, you hire a firm, they review your code, they publish a report, and you get a badge of approval. This has become table stakes — something every serious project does.

The problem is that an audit is a photograph. It captures the state of the code at a single moment in time. But software is not static. Dependencies update. Configurations change. New integrations get added. Libraries get patched. Teams iterate. And every single one of those changes potentially introduces a new attack surface that no auditor has ever looked at.

The gap between “audited at launch” and “running as audited” widens every day a project is live. In traditional software, this problem is mitigated by runtime monitoring — systems that continuously check whether what’s running matches what’s expected. In web3, almost nothing like this exists. Projects launch, collect the audit badge, and then fly blind at runtime.

An audit tells you what the code looked like before anyone cared about attacking it. It tells you almost nothing about what’s running in production six months later.

The supply chain is soft

Modern software is not built from scratch. It’s assembled from open-source libraries, third-party dependencies, forked repositories, and shared infrastructure. Every smart contract project exists inside a dependency tree that can stretch dozens of layers deep, touching code written by anonymous contributors in repositories that haven’t been reviewed in years.

This is the supply chain — and it’s one of the least-examined attack surfaces in crypto. A compromised dependency doesn’t trigger a smart contract audit. A malicious update pushed to an npm package doesn’t show up in a deployment review. A developer whose laptop is compromised doesn’t invalidate the audit report.

The published source code can look perfectly clean. The deployed bytecode can be something else entirely. Right now, most projects have no mechanism to verify that what’s running on-chain actually corresponds to what their team published on GitHub. That gap is exploitable — and it has been.

Runtime protection is nearly nonexistent

In traditional software security, there’s an entire discipline around what happens after deployment: runtime protection, anomaly detection, behavioral monitoring, integrity verification. These systems watch running code and infrastructure continuously, looking for deviations from expected behavior — signs of tampering, unauthorized modifications, injected code.

Web3 has essentially none of this. The culture of security in crypto stops at the audit. What happens at runtime — whether the infrastructure running a DeFi protocol is actually what the team thinks it is, whether the code being executed matches the audited version, whether the enclave handling keys has been tampered with — these questions go largely unasked and unanswered.

This isn’t a minor gap. For protocols managing hundreds of millions of dollars, the absence of runtime protection means that a successful infrastructure compromise can go completely undetected until the funds are already gone. By the time anyone notices something is wrong, the exploit has been live for hours, days, or longer.

And then there’s quantum

Most of the conversation about quantum computing and cryptography treats it as a distant, theoretical problem. Something for future generations to worry about. This framing is increasingly wrong.

Quantum computers capable of breaking current elliptic curve cryptography — the foundation of essentially every wallet, signature scheme, and key exchange in use across Web3 today — are no longer purely hypothetical. Research into error correction and qubit fidelity has been accelerating. The timeline for practically relevant quantum attacks is measured in years, not decades. And unlike most security threats, quantum attacks don’t announce themselves in advance. When the capability exists, existing encryption doesn’t degrade gradually — it breaks.

The entire cryptographic stack that underpins Web3 is built on assumptions about computational hardness that quantum computing will eventually invalidate. Migrating that stack is not a simple software update. It requires changes at the protocol level, the contract level, the wallet level, and the infrastructure level — changes that take years to design, test, and roll out.

The projects that start preparing now will have a path. The ones that wait for quantum attacks to become front-page news will not.

The gap nobody has filled

What makes this problem particularly acute is that no existing solution addresses it in a cross-chain, infrastructure-agnostic way. There are tools for auditing. There are tools for monitoring on-chain transactions. There are post-quantum cryptography libraries. But there’s no unified security layer that combines runtime integrity verification, post-quantum data encryption, and settlement into a service that any project on any chain can plug into without rebuilding their stack.

Builders deploying on Ethereum, Avalanche, or any EVM chain face a choice between cobbling together incomplete solutions or accepting that large parts of their security posture are simply unanswered. Most accept the gaps — not because they don’t care, but because the alternative doesn’t exist.

That’s the real problem. Not a lack of awareness. Not a lack of effort. A genuine absence of infrastructure that makes runtime security and quantum-resistant encryption available to the projects that need it, at the layer where it actually matters.

Until that infrastructure exists, the losses will keep coming.

Web3 has a security crisis. And the industry is still pretending it’s fixable with better audits. was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Ternoa team successfully built a system that removes these weak trust points — TEE-ISM, a hardware-backed verification layer that redefines cross-chain security.

What if we could remove them from the trust equation altogether?
That’s the idea behind TEE-ISM — a hardware-backed message verification layer that shifts cross-chain security away from external actors and toward cryptographic proofs and verifiable execution.

The Problem With Validator-Centric Trust

Today, the majority of ISMs work like this:

1. A message is emitted on a source chain.
2. Off-chain actors — validators, indexers, or relayers — observe it.
3. They sign or provide proof of its existence.
4. The destination ISM trusts their signatures to process the message.

This is simple, but it’s fragile.

• A compromised validator set can forge messages.
• Indexers can be manipulated or censored.
• RPC providers can return altered or stale data.

Every one of these layers expands the attack surface. We don’t just have to trust one party — we end up trusting several, and any one of them can break the system.

A Different Approach: Verifiable Hardware as a Root of Trust

TEE-ISM replaces these human or infrastructural trust anchors with a cryptographically verifiable enclave.

The core idea is simple:

• A TEE Oracle runs inside trusted hardware.
• It fetches and verifies the existence of messages directly from chain state.
• It returns a signed proof that the ISM contract can verify on-chain.
• No validator committees. No indexers. No third-party RPCs.

This shifts cross-chain verification away from actors you need to trust — to math and hardware you can verify.

Why TEE Can Be Trusted

A Trusted Execution Environment (TEE) is a secure area of modern CPUs designed to run code in complete isolation from the host operating system, hypervisor, and other applications.

What makes it powerful isn’t just isolation — it’s attestation.
Attestation allows anyone to cryptographically verify:

• Which code is running inside the enclave.
• That it’s running on genuine, tamper-resistant hardware.
• That its execution environment hasn’t been modified.

Private keys never leave the enclave, and even a compromised host can’t access its memory. This means the output of the enclave — like message proofs — can be trusted as if verified by math and hardware, not by an operator.

This creates a verifiable trust anchor without depending on validators, operators, or infrastructure providers.

SGX and TDX — Two Secure Flavors of the Same Design

TEE-ISM runs in two forms:

• SGX-based enclaves, which offer fine-grained enclave-level isolation and the ability to seal data securely inside the enclave.
• TDX-based isolated environments, which provide full-VM isolation with strong attestation and operational simplicity.

Both architectures are fully capable of:

• Event-based verification
• State delta verification
• Direct state proof verification (non-delta)

They share the same verification engine, security model, and trust assumptions.
The difference is primarily in operational trade-offs and infrastructure models, not in capability.

This dual-TEE approach gives flexibility. Some deployments may favor SGX’s tighter enclave model; others may prefer TDX’s broader isolation domain.

Verification Methods — How Truth Is Proven

TEE-ISM supports three verification paths. Each exists to minimize trust further and increase proof strength:

1. Event-Based Verification
   The enclave verifies message existence from emitted logs on the source chain.
   It’s simple, lightweight, and already removes validator and indexer trust.
2. State Delta Verification
   Instead of relying on logs, the enclave inspects the state at block B and block B-1.
   A verifiable change in state proves that the message was genuinely processed on-chain.
   This approach neutralizes replay attacks and indexer manipulation.
3. Non-Delta Direct State Verification
   The final form is the most trust-minimized: the enclave reads the storage proof from the mailbox contract and verifies message existence directly.
   No logs. No deltas. Just raw, cryptographic truth.

All three verification modes are fully enclave-contained.
No external validators, no RPC trust beyond the enclave itself — and in some cases, the RPC node is also running inside the TEE, cutting external dependencies entirely.

End-to-End Flow — What Happens Under the Hood

The overall message flow remains familiar but is radically more secure:

1. A user sends a message to a mailbox contract on the source chain.
2. A relayer picks up the message and identifies TEE-ISM as the ISM to use.
3. The relayer queries the TEE Oracle for a proof.
4. The TEE Oracle verifies the message’s existence via one of the verification methods, optionally using a TEE-hosted RPC.
5. The oracle returns a signed proof package.
6. The relayer submits this proof to the destination mailbox.
7. The ISM contract verifies the enclave’s proof and signature.
8. The message is delivered to the destination user.

This architecture keeps the structure of cross-chain messaging familiar for relayers and protocols — but removes the weakest parts of the trust model.

Trust Model Shift — Collapsing the Attack Surface

In the old model, trust is scattered across multiple actors: validator committees, indexers, RPC providers. Compromising any of them can undermine the entire system.

In the TEE-ISM model, the trust surface collapses to two things:

• The blockchain itself — the source of provable state.
• The enclave — whose code and identity can be attested cryptographically.

There’s no committee to bribe. No indexer to tamper with. No external RPC to poison.
If the enclave isn’t genuine, attestation fails. If the state isn’t real, the proof fails.

This is a measurable trust model — not a social one.

Why This Matters

Bridges and messaging protocols are critical infrastructure in a multi-chain world. When they fail, they don’t just take a dApp down — they can trigger cascading security incidents across ecosystems.

TEE-ISM is not about adding another actor.
It’s about removing actors entirely — and replacing them with something cryptographically verifiable.

This is a new trust foundation for cross-chain security:

• Verifiable execution instead of trusted validators.
• Cryptographic proofs instead of signatures from committees.
• Attestation instead of faith in infrastructure providers.

The result is a bridge architecture with a smaller, measurable, enforceable trust surface — and that’s the only kind worth building on.

TEE-ISM: A Trust-Minimized Verification Layer for Cross-Chain Messaging was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

About one year ago, in a context where the industry started consolidating on a handful of leading infrastructures, we made the strategic decision to expand the reach of our tech stack to the Ethereum ecosystem.

The last year offered the opportunity to broaden our R&D scope, leveraging 3 years of experience building with TEEs on Polkadot. We launched new research streams on use cases answering ETH scaling roadmap needs such as multi-proving, or integrity proofs.

In addition, becoming an EVM infrastructure gave us the opportunity to put our tech stack in the hands of many builders teams -as the Ethereum ecosystem is home to the largest community of builders in web3- and figure out use cases where we can make a real difference.

It was a year of learnings and growth leading us to this new milestone, and I’m thrilled to unveil Ternoa 2.0, “HORIZON”, the latest evolution of our blockchain.

Ternoa 2.0 foundational principles

Ternoa 2.0 is designed to become a leading PayFi infrastructure within Polygon / Ethereum ecosytems, built upon five core pillars:

1. Trust-minimized

Since the very beginnings, Ternoa is a TEE-centric infrastructure provider. In the same vein, Ternoa2.0 is a TEE-enhanced Layer 2 using integrity proofs to provide stronger guarantees to end users, with trust minimized offchain services. And native keystore primitives provided by our TEE key management system.

2. Cost-efficiency

Ternoa 2.0 posts data on Avail DA ensuring that transaction data is accessible to all network participants while remaining fast, at a reduced cost compared to Ethereum DA.

3. Instant transactions

Powered by Polygon CDK, Ternoa 2.0 relies on zero-knowledge validity proofs to provide fast pre-confirmations. This guarantees blazingly fast transactions to users.

4. EVM Compatibility

To ensure a smooth developer experience, Ternoa 2.0 is a fully EVM equivalent infrastructure where developers can deploy any EVM smart contract. This makes it easier than ever to onboard existing projects into our ecosystem.

5. Unification

Last but not least, Ternoa 2.0 is a Polygon Agglayer L2, enabling direct connections to multiple blockchain ecosystems. This unification makes cross-chain interactions effortless for developers and users alike, enabling liquidity to move seamlessly across unified ecosystems

A Vision for the Future

Ternoa 2.0 is a pledge to our vision of making decentralized payments, finance, and applications accessible, secure, and interoperable for all.

In parallel to this new roadmap Ternoa 1.0 remains the go-to gateway to our TEE key management system, “the Fortress”, where privacy-first dapps can be deployed with very little efforts using our JS SDK.

As we step into this exciting new phase, I invite you to join us in shaping the future. Whether you’re a developer, business, or user curious about Web3, Ternoa has something to offer.

Let’s build the future of finance and decentralized applications — together.

What’s your take on Ternoa 2.0? Let me know your thoughts in the comments, and feel free to connect if you’d like to learn more!

#Web3 #Blockchain #DeFi #DataAvailability #zkProofs #EVM #Innovation

Introducing Ternoa 2.0, “HORIZON” was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Problem: Fragmentation in Web3

Current blockchain architectures often fall into two categories:

1. Monolithic: Single chains attempt to scale by increasing node sizes, but this compromises decentralization and sovereignty.
2. Modular: Sovereign chains (e.g., Layer 2 solutions) are independent, but they fragment liquidity and create a poor user experience.

Neither approach fully addresses the need for scalable, unified ecosystems. Fragmentation leads to higher costs, inefficiencies, and a fractured user experience.

The Solution: Aggregation Layer (AggLayer)

AggLayer is a decentralized protocol that sits between blockchain ecosystems, offering:

1. Unified Liquidity: Chains connected to AggLayer share liquidity, enabling seamless cross-chain asset transfers.
2. Low-Latency Interoperability: Chains can safely interact in near real-time without waiting for Ethereum finality.
3. Asset Fungibility: Native tokens remain native across chains, eliminating the need for wrapped or synthetic assets.

AggLayer is not a Layer 2 or a shared sequencer. Instead, it acts as an interoperability layer that prioritizes safety, sovereignty, and scalability.

How Does AggLayer Work?

AggLayer achieves its goals through three key phases:

1. Pre-Confirmation

When a chain submits a new block or batch, AggLayer accepts it as “pre-confirmed” after verifying dependencies. This step minimizes latency while ensuring dependencies are tracked.

2. Confirmation

Chains generate and submit validity proofs. Once verified by AggLayer, these proofs confirm the block or batch if all dependencies are also confirmed.

3. Finalization

AggLayer aggregates proofs from multiple chains into a single proof, which is then posted to Ethereum. This ensures consistency and trust across interconnected chains.

Key Features of AggLayer

1. Safety: AggLayer’s cryptographic guarantees prevent malicious actions like double-spending or invalid transactions from propagating across chains.
2. Atomic Interoperability: Enables cross-chain transactions to execute as a bundle — either all succeed, or none are included.
3. Asynchronous Interoperability: Chains can interact safely without waiting for Ethereum finality, reducing latency from minutes to seconds.
4. Modular Design: AggLayer doesn’t impose strict requirements on participating chains. It supports diverse architectures, tokens, and governance models.

Why AggLayer Matters

By solving the challenges of liquidity fragmentation and cross-chain inefficiencies, AggLayer creates a Web3 experience that feels unified — similar to how the TCP/IP protocol unified the internet. Developers gain more flexibility, users experience seamless transactions, and the ecosystem as a whole becomes more efficient and accessible.

Real-World Implications

Imagine having ETH on Polygon but needing to mint NFTs on Zora. With AggLayer, this happens in one transaction without using third-party bridges or wrapped tokens. This level of seamlessness is the future of blockchain interactions.

A Minimal yet Powerful Approach

AggLayer’s design is intentionally minimal, focusing on safety and interoperability. Chains retain their sovereignty and can choose how deeply to integrate with the layer — from fully embracing it to opting out of fast interoperability altogether.

Conclusion

AggLayer represents a significant step toward a unified blockchain ecosystem. By addressing core challenges like liquidity fragmentation and interoperability, it paves the way for a Web3 environment as intuitive and interconnected as the modern internet. As blockchain technology evolves, AggLayer could become the backbone of a truly unified decentralized future.

What is AggLayer? was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

🔒 zk-Proof: Confidentiality and Security

One of the key features of our zkEVM Layer 2 is the use of zk-Proofs (Zero-Knowledge Proofs). This cutting-edge technology ensures:

• Ultra-fast and cost-efficient transactions through off-chain computations.
• Enhanced confidentiality by proving data integrity without revealing the underlying information.
• Heightened security that safeguards data integrity without compromise.

This makes our zkEVM Layer 2 the ideal solution for use cases requiring a perfect balance between performance and data protection.

🌉 Seamless Integration with AggLayer

Our zkEVM Layer 2 is natively designed to integrate with AggLayer, providing unique benefits such as:

• Shared liquidity, enabling our users to access deeper markets.
• Advanced interoperability, facilitating seamless communication between blockchains.
• Future-proof scalability, ensuring our solution evolves with the ever-changing blockchain ecosystem.

⚡ Scalability Powered by Data Availability (DA)

Leveraging the Data Availability (DA) model, our Layer 2 delivers exceptional scalability with:

• Reduced costs: Transactions are faster and more affordable.
• Universal accessibility: A solution designed to democratize blockchain usage.
• Minimized Layer 1 congestion: Efficient synchronization with the base layer ensures seamless operation.

🛡️ Cutting-Edge Security with Ternoa’s TEE Network

Our Layer 2 gains access to Ternoa’s TEE (Trusted Execution Environment) Network, a state-of-the-art security infrastructure offering:

• Secure execution of sensitive data in an isolated and tamper-proof environment.
• Exclusive security services, including cryptographic signing, encryption, and integrity attestation.
• A trusted framework, guaranteed by a distributed and validated architecture.

By leveraging this network, our Layer 2 ensures maximum protection for users and developers while enhancing the reliability of operations.

💡 Innovation Backed by Ternoa Integrity Proofs (TIP)

Our system is also protected by Ternoa Integrity Proofs (TIP), a unique mechanism that:

• Verifies the integrity of every transaction.
• Ensures the deployed code matches its open-source version.
• Guarantees trustworthy and compliant deployments.

🎯 Why Choose Our zkEVM Layer 2?

To sum up, our zkEVM Layer 2 delivers:

1. An unmatched user experience with lower fees and faster transactions.
2. Exceptional interoperability and scalability with AggLayer and the DA model.
3. Uncompromising security powered by Ternoa’s TEE Network and TIP.

With Ternoa, you no longer have to choose between innovation, performance, and security.

🚀 Join the zkEVM Revolution

Our zkEVM Layer 2 isn’t just a technical solution — it’s a commitment to a decentralized, secure, and accessible future. Discover what’s next with Ternoa!

🌐 Learn More

Why Our zkEVM Layer 2 Stands Out was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

The goal? To leverage our breakthroughs and offer an unparalleled level of trust and security for every Web3 component — and beyond.

The Problem We’re Solving in Web3
In the current Web3 landscape, we are asked to place blind trust in Layer 2 solutions and their components — explorers, sequencers, indexers, and more. While many of these components are open-source, we often assume that what we see is what’s being deployed. But what if that isn’t the case?

What if the deployed code is different from the open-source version?
What if someone injects malicious code?
What if a bad actor modifies a core system file?

Real-World Examples
1 Imagine a blockchain explorer used by millions. A malicious or internal actor alters the indexer script to show fake transactions. This undermines the entire Layer 2’s credibility, rendering it untrustworthy.

2 You deploy your own Layer using Polygon, Arbitrum, or another solution. Once in control, you could easily edit the core source code — giving you full power over everything.

⠀Scary, right?
This isn’t just a Web3 problem — Web2 faces the same risks. Imagine trusting a P2P chat app based on its open-source code, only to find out the actual version running is compromised.

TIP to the Rescue
Ternoa Integrity Proof (TIP) solves this issue.

How does it work?

Anyone can deploy their script using our decentralized coprocessors, and TIP will prove that the code is 100% identical to the open-source, audited version — guaranteeing zero tampering.

Our secure enclave network will deploy with the highest level of security, continuously auditing and monitoring the integrity of every script in real time.

To ensure and maintain this integrity, users will need $CAPS, making it an essential asset in securing Web3’s future. But this is just the beginning. We have even more exciting advancements lined up, and we can’t wait to share them with you.

Stay tuned in the coming weeks for an in-depth look at how Ternoa is transforming the very foundation of digital trust, one block at a time. The future of secure and transparent Web3 starts now — and we’re building it together.

Say Hello to Ternoa Integrity Proof! was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ternoa is launching zkEVM+, a security and privacy-centric L2 on Ethereum built with Polygon CDK, following the 2023 release of a decentralized privacy stack available as a Polkadot sdk L1 chain.

A full EVM-equivalent infrastructure, zkEVM+ brings censorship resistance via integrity proofs, and native privacy to Ethereum ecosystem builders and users. Built on Polygon CDK, it combines hybrid coprocessor technologies and Avail Data Availability in a unique, best-of-breed architecture co-implemented with Zeeve RaaS.

Anurag Arjun, co-founder of Polygon and Avail, is a board advisor to the project. He shares his experience and insight to help Ternoa make a decisive contribution to Ethereum’s scaling roadmap.

Ternoa is already home to one of the largest blockchain infrastructure communities in France, with 200k social media members. And to an ecosystem Labs, supporting enterprise adoption since 2022, working with large French corporate accounts (such as Caisse des Dépôts & Consignations, Stellantis), Japanese studios (Toho) or gaming companies (Tap Nation).

Today, the Ternoa privacy stack is used by several dapps such as “Time Guardian”, a mobile app dedicated to digital inheritance management, or “Keeper Defi”, an abstracted wallet with built-in DeFi opportunities, now offering a 250k$ / 17 million CAPS incentive program.

To welcome EVM builders looking to launch apps on a high-security infrastructure, Ternoa is opening a $500k / 33 million CAPS grant program to onboard new developers and projects during the Testnet phase.

For press enquiries: press@ternoa.network

Ternoa launches Testnet of zkEVM+, built with Polygon CDK, bringing in anti-censorship, integrity… was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Ternoa Fortress infrastructure co-evolved with the Ternoa Secret-NFT solution. Fortress is an off-chain and chain-agnostic decentralized protocol based on the Trusted Execution Environment (TEE) technology which natively hosts the Secret-NFT. Secret-NFT is a radical approach for adding confidentiality to regular NFTs respecting transferability and transparent flexible ownership. Secret-NFT technology at its core is a Decentralized Key Management System (DKMS) where in Ternoa it is backed by tens of cryptographic layers. In this article, we explain the design decisions and implementation details of all these concepts and products.

Trusted Execution Environment (TEE)

Secure-hardware cryptography has always been the ultimate level of security, especially for financial and military-grade applications, because modern cryptography is based on mathematical algorithms that will eventually be executed in hardware, either conventional electronic CPU, GPU, FPGA, ASIC, or unconventional Quantum, Optical, Neuromorphic and biological computers. They all follow the same concept of computation known as the Turing machine. Computation inside the Turing machine hardware, in the hands of experts, can be manipulated, so we need verifiable computation at the micro level (proof system), and a fault-tolerant system at the macro level (state replication, error correction). Moreover, there are methods to eavesdrop on the running computation in hardware, in that case, we need to secure the processing and storage inside the hardware. Normally it has been done in expensive special-purpose microchips and secure modules like SRAM-based PUF, HSM, and TPM.

Recently main CPU manufacturers started a new line of powerful general-purpose processors as Trusted Execution Environment (TEE) which are both computationally impenetrable and verifiable. TEEs promise integrity (the program being run is exactly the one specified by the user) and confidentiality (the data processed by the program is not leaked outside of the enclave) against an actively malicious adversary with control over the operating system.

In the next article, we will investigate these processors' security measures and known vulnerabilities, and then show that TEE will be the best secure processing technology for the next decade.

Decentralized Key Management System (DKMS)

A decentralized key management system (DKMS) leverages cryptographic primitives and distributed ledger technology (DLT) to establish a trustless environment for managing cryptographic keys. Unlike centralized systems with a single point of control (below Image from Google Cloud), DKMS employs a distributed network of nodes to perform key/randomness generation, protection, storage, exchange, replacement, and use through decentralized cryptographic mechanisms. This paradigm offers enhanced security by eliminating a central point of vulnerability. It ensures resilience through Byzantine Fault Tolerance (BFT) protocols, allowing the system to function even in the presence of malicious actors. Furthermore, DKMS fosters transparency through immutable audit trails recorded on the DLT, providing users with a verifiable and tamper-proof record of all key management operations.

In Ternoa DKMS there is no root master key (Figure 2), whereas each TEE hardware is the key because nobody has access to it. Whenever data is encrypted by a data encryption key (DEK), it gets encrypted with the Key encryption key (KEK). The master key normally is used to encrypt a set of KEKs. In Ternoa for more security and forward secrecy, every key is temporary and partially accessible. To have a better vision, Ternoa KMS works like a very secure hardware wallet, but instead of putting it in a safe box, it is partitioned into smaller hardware wallets every one of which contains part of the data, moreover, these partial hardware wallets are replicable, if one of them lost we can still recover from other replicas. Additionally, key rotation happens in all of them regularly, which means even if this partial data is stolen, it will be useless after a short time, and if it is disconnected/isolated/outdated for a long time, it will be slashed off the system.

Secret NFT

NFTs (Non-Fungible Tokens) have gained popularity as a way to represent ownership of unique digital assets. They are often associated with blockchain technology where ownership records are transparent and cannot be duplicated or forged. In the context of a network society, shared economy, and decentralized identities, NFTs play a role in redefining ownership and enabling partial, temporary, and delegated shared ownership of digital assets. This means that ownership of an NFT can be transferred or shared among multiple parties, and it can also include time-limited access rights.

As the world becomes more connected with autonomous AI-powered IoT devices, managing assets, including keys, becomes crucial. This implies that in addition to managing the ownership of digital assets through NFTs, effective key management methods should be considered to maintain security and control over these assets.

While NFTs use decentralized technology, DKMS refers to the secure storage and management of cryptographic keys in a decentralized manner. NFTs and DKMS are used together to enable secure and transparent ownership and transfer of digital assets. However, it’s important to note NFTs themselves are not a direct application of DKMS. Instead, DKMS can be utilized to enhance the security and privacy aspects of NFT ownership. DKMS can be used to add confidentiality to NFTs by enabling secure and private ownership of the NFT media content:

1. Generation of Keys: Each user generates a pair of cryptographic keys — a public key and a private key. The private key is kept secret and is used to sign transactions, while the public key is shared publicly.

2. Ownership Verification: When an NFT is created, its ownership is associated with the owner’s public key. This linkage is stored on the blockchain or decentralized ledger, making it publicly verifiable.

3. Confidential Transactions: The private key allows the owner to prove ownership and transfer the NFT without revealing their identity or sensitive information. The transfer can be cryptographically signed with the private key and broadcast to the network.

4. Decentralized Storage: The NFT’s metadata and ownership details can be stored decentrally, ensuring resilience and availability without relying on a single point of failure.

5. Extensibility: Each confidential NFT can contain another private key, source code, or NFT for more complex applications.

The rest of this series is an explanation of Ternoa’s answers to technical questions :

• How is each private key kept secret?
• How can the user manage many private keys for different applications?
• How do we have a confidential market for encrypted assets?
• How do we transfer a private key to the new owner?
• How to keep all the required non-functional qualities: Resilience, Connectivity, Flexibility, Backward secrecy, Forward secrecy, Collusion resistance, Efficiency, and Scalability?

Ternoa Fortress: DKMS (Intro) was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unlocking the potential of NFTs has never been easier with the Ternoa SDK. Empowering developers with seamless integration, the Ternoa SDK revolutionises NFT operations. From minting to transferring, explore how this powerful SDK streamlines the creation and management of non-fungible tokens, shaping the future of digital ownership. Let’s dive right into the step-by-step process:

Step 1: Create your Ternoa wallet and claim Alphanet CAPS.

You can download the Ternoa Wallet app. It is available on the Google Play Store and the iOS App Store. To see detailed instructions, follow our documentation.

Step 2 : Install NodeJS v.14+, along with NPM.

Step 3: Generate IPFS key with Ternoa IPFS key manager

Step 4: Cloning the github repository

In this tutorial, we will be using the scripts available in the following GitHub repository:

git clone https://github.com/capsule-corp-ternoa/ternoa-sdk-starter
cd ternoa-sdk-starter

Step 5: Install Ternoa JS library and app dependencies using npm install

This is one of the most important steps in setting up our development environment. This step ensures that there are no dependency issues while compiling our scripts.

Execute the following commands to install the required libraries:

npm install ternoa-js
npm install

Step 6: Create a .env file with seed phrase and IPFS key

After you have generated the IPFS key, create a .env file in the project directory. You will need to specify the IPFS key and seed phrase of your wallet to execute the transactions:

SEED_TEST_FUNDS= "a b c d e f g"
IPFS_API_KEY= "pqrstuvwxyz"

Note: Make sure to not expose your private keys and IPFS key in a public github repository for safety reasons.

Step 7: In this tutorial, we will be interacting with the following files one by one:

• 01_mintNFT.ts
• 02_getNFT.ts
• 03_sellNFT.ts

Firstly, to prepare the basic NFT asset, we will create a new typescript file named createNFT.ts . Here we will specify the metadata for the NFT by adding the image file in your project directory. You will also need to specify the file name and file type.

import fs from "fs";
import { TernoaIPFS, File } from "ternoa-js";

const main = async () => {
  const file = new File(
    [await fs.promises.readFile("FILE_NAME")],
    "FILE_NAME",
    {
      type: "FILE_TYPE",
    }
  );

  const ipfsClient = new TernoaIPFS(new URL("IPFS_NODE_URL"), "IPFS_API_KEY");

  const nftMetadata = {
    title: "NFT TITLE",
    description: "NFT DESCRIPTION",
  };

  const { Hash } = await ipfsClient.storeNFT(file, nftMetadata);
  console.log("The off-chain metadata CID hash is ", Hash);
};

Once the script is ready, you will be able to execute it using:

cd ternoa-sdk-starter-main/src/basics
npm run start src/basics/createNFT.ts

You will see an output with an off-chain metadata CID hash, which we will need for the next steps. The next steps can be found in Part 2 of this tutorial.

Step 8: Make sure you copy and paste the CID hash at ‘offchainData’ created in the previous step.

import { createNft, getKeyringFromSeed, WaitUntil } from "ternoa-js";

const mintNFT = async () => {
 try {
  const keyring = await getKeyringFromSeed("//TernoaTestAccount");
  const nftData = await createNft(
   "IPFS_CID",
   0,
   undefined,
   false,
   keyring,
   WaitUntil.BlockInclusion
  );
  console.log("The on-chain NFT id is: ", nftData.nftId);
 } catch (e) {
  console.error(e);
 }
};

Once that is done, to mint the NFT, we need to execute this file by

cd ternoa-sdk-starter-main/src/basics
npm run start src/basics/01_mintNFT.ts

You will see an output saying the NFT has been successfully minted, and it will return the NFT ID.

Step 9: You can visit the Polkadot UI explorer to see recent events, where you can see the recently minted NFT like this:

Note: Make sure you have the explorer open before minting the NFT. In some cases, you might not be able to see your mint under the recent events if you load the ternoa alphanet polkadot explorer after minting NFT.

Step 10: Check the Ternoa wallet app and go to the NFT section to check if the NFT has been minted successfully. Along with the NFT, you’ll be able to see the NFT metadata.

Step 11: In this step, we will query the on-chain NFT data. Firstly, Copy the NFT ID and specify it under

const NFT_ID = 83179;

The final file would look something like:

import { u128 } from "@polkadot/types";
import { request, gql } from "graphql-request";

// Change the nftId provided by default with the one created in step one (01_mintNFT.ts).
const NFT_ID = ["NFT_ID"];

// The function below prepares a stringified query to get NFT data from a specific NFT id.
const query = (id: number) => gql`
    {
      nftEntity(id: "${id}") {
        owner
        nftId
        offchainData
        collectionId
        royalty
        isSoulbound
      }
    }
`;

const getNftData = async () => {
 try {
  console.log("Sending query to the indexer...");
  if (NFT_ID === undefined) throw new Error('Change the const NFT_ID with the one created in step one (01_mintNFT.ts).')

  // Here we make the request to our indexer by providing both the endpoint and the query.
  const response = await request<{ nftEntity: NftType }>(
   "https://indexer-alphanet.ternoa.dev",
   query(NFT_ID)
  );

  console.log(response);
  console.log("Step 2 is over! See you later 👋");
 } catch (error) {
  console.error(error);
 } finally {
  process.exit();
 }
};

getNftData();

type NftType = {
 owner: string;
 nftId: string;
 offchainData: string;
 collectionId: string;
 royalty: number;
 isSoulbound: boolean;
};

Then execute the 02_getNFT.ts file using the following command:

cd ternoa-sdk-starter-main/src/basics
npm run start src/basics/02_getNFT.ts

Here you will see an output like the following:

You can see the owner wallet address, nftId, offchainData, collectionId, royalty, and isSoulbound properties associated with the NFT.

Step 12: Head over to https://indexer-alphanet.ternoa.dev/ to access the graphQL indexer. Here we will be executing a simple query to check the NFT created and held in our wallet. You can specify your wallet address by replacing “YOUR_WALLET_ADDRESS”.

query {
nftEntities(
first: 5,
filter: {
owner: { equalTo: "YOUR_WALLET_ADDRESS" }
}
) {
totalCount
nodes {
nftId
owner
creator
collectionId
offchainData
}
}
}

Upon execution, we will be able to see the NFT IDs along with NFT data.

Step 13: In this step, we will be listing our NFT on a marketplace. For this, we will need the nftId and the marketplaceId. Firstly, specify the NFT ID, like: const NFT_ID = 83179;

Then fill out the required parameters, like Marketplace ID and selling price and then execute the file.

import {
 initializeApi,
 getKeyringFromSeed,
 WaitUntil,
 safeDisconnect,
 listNft,
} from "ternoa-js";
import dotenv from "dotenv";
dotenv.config();

const NFT_ID = ["NFT_ID"];

const sellNFT = async () => {
 try {
  if (NFT_ID === undefined) throw new Error('Change the const NFT_ID with the one created in step one (01_mintNFT.ts).')

  await initializeApi();
  console.log(
   "Ternoa-JS API initialized: you're connected to the Ternoa Alphanet Network"
  );
  
  const SEED_TEST_FUNDS = process.env.SEED_TEST_FUNDS;
  if (!SEED_TEST_FUNDS) throw new Error("SEED_UNDEFINED: Verify your .env variables")
  
  const keyring = await getKeyringFromSeed("leg system coach toss first wood dutch neither stable drift absorb squeeze");
  console.log("Keyring set and ready to use.");

  const listedNft = await listNft(
   NFT_ID,
   MARKETPLACE_ID,
   SELLING_PRICE,
   keyring,
   WaitUntil.BlockInclusion
  );
  console.log(
   `Your NFT ${listedNft.nftId} is now listed for sale at: ${listedNft.priceRounded} CAPS`
  );

  console.log(
   "Congratulation folks! This is the end of your journey with us! 👋"
  );
 } catch (e) {
  console.error(e);
 } finally {
  await safeDisconnect();
  process.exit();
 }
};

sellNFT();

cd ternoa-sdk-starter-main/src/basics
npm run start src/basics/03_sellNFT.ts

Upon execution, you will be able to see an output returning the NFT ID and the selling price with a confirmation message.

Step 14: You can verify the event by visiting the polkadot UI explorer and checking out the recent events. The 'sell’ event for your NFT will look like this:

Congratulations! You have completed all the steps and successfully minted your NFT. We encourage everyone to tweak different NFT properties to explore functionalities which we will be covering in the upcoming tutorials.

Getting started with the Ternoa SDK — easiest way to mint, query, and sell NFTs. was originally published in Ternoa on Medium, where people are continuing the conversation by highlighting and responding to this story.