Crypto Basics

What Are Zero Knowledge Proofs and How Does it Work?

Learn everything about zero knowledge proofs and discover how this cutting-edge technology works and reshapes digital space.
S. Vishwa
7 Minutes
MIN

In today's data-driven world, privacy and security are of paramount importance. One emerging technology that addresses these concerns is zero-knowledge proofs (ZKPs). 

ZKPs allow for the verification of information without revealing the underlying data, providing a high level of security and privacy. 

This comprehensive guide will explore the fundamentals of zero-knowledge proofs, how they work, their applications, and the benefits they offer. So, let's dive in!

What are Zero-Knowledge Proofs?

Zero-knowledge proofs (ZKPs) are cryptographic protocols that enable one party, known as the prover, to convince another party, the verifier, that a statement is true without revealing any details about the statement itself. 

The concept of zero-knowledge proofs was first introduced in the early 1980s by researchers Shafi Goldwasser, Silvio Micali, and Charles Rackoff.

A good zero-knowledge proof should fulfill three criteria: completeness, soundness, and zero-knowledge. Completeness ensures that the verifier will accept the proof if the statement is true and both parties adhere to the protocol. 

Soundness guarantees that if the statement is false, no dishonest prover can convince an honest verifier otherwise. 

Zero-knowledge ensures that even after engaging with the prover, the verifier only learns the truth of the statement and nothing else about the secret.

How do Zero-Knowledge Proofs Work?

Zero-knowledge proofs allow a prover to persuade a verifier of the validity of a statement without disclosing any information about the statement itself. 

The prover and the verifier engage in multiple rounds of interaction. At the end of the protocol, the verifier gains confidence in the statement's truth without learning any additional information about the secret.

To illustrate how zero-knowledge proofs work, let's consider the "Three Color Problem," also known as the "Graph Coloring Problem." 

The goal is to color each map region with one of three colors so that no neighboring regions have the same color. The prover wants to convince the verifier that they know a valid three-coloring for the given map without revealing the actual colors assigned to each region.

The protocol consists of several rounds: setup, statement, commitment, challenge, response, and iteration. In the setup phase, the prover and verifier agree on the map's regions and connections. In the statement phase, the prover asserts to have a reliable three-coloring for the map. 

The commitment phase involves the prover choosing colors for each region in secret and providing commitments to the verifier without revealing the actual colors. The challenge phase requires the verifier to choose a random region and request the prover to open the commitment for that region, revealing its color. 

The response phase involves the prover proving the accuracy of the revealed coloring by demonstrating the color differences between adjacent regions. The iteration phase repeats the challenge and response steps multiple times to establish a high degree of trust in the validity of the prover's assertion.

Throughout the protocol, the verifier becomes confident that the prover possesses a valid three-coloring without learning the actual colors assigned to each region. 

This exemplifies the zero-knowledge property of the proof, as the verifier gains knowledge about the truth of the statement without obtaining any additional information.

Types of Zero-Knowledge Proofs

There are several types of zero-knowledge proofs, each suited for different use cases. Let's explore some of the most commonly used types:

Interactive Zero-Knowledge Proofs

Interactive zero-knowledge proofs require back-and-forth communication between the prover and verifier. They involve multiple rounds of interaction, as seen in the "Three Color Problem" example.

Non-Interactive Zero-Knowledge Proofs

Non-interactive zero-knowledge proofs provide a compact proof that can be verified in a single step. They eliminate the need for repeated back-and-forth communication between the prover and verifier.

Statistical Zero-Knowledge Proofs

Statistical zero-knowledge proofs offer computational soundness with a small probability of error. They allow for probabilistic verification, making them suitable for scenarios where a small margin of error is acceptable.

Proof-of-Knowledge

Proof-of-knowledge (PoK) is a subclass of zero-knowledge proofs that demonstrates the prover's possession of specific knowledge related to the statement. It shows that the prover knows something without revealing what that something is.

Proofs of Shuffle and Range

Proofs of shuffle and range are used in electronic voting systems and privacy-preserving transactions. They allow for the verification of the correct shuffling of votes or the validation of values falling within a specific range without disclosing the actual votes or values.

Sigma Protocols

Sigma protocols are a class of zero-knowledge proofs that involve three steps: commitment, challenge, and response. They are widely used in various applications, including digital signatures and secure authentication.

Bulletproofs

Bulletproofs are designed to provide efficient range proofs for large sets of values. They enable efficient verification of values within a specified range without revealing the actual values themselves. Bulletproofs have been successfully used in privacy-focused cryptocurrencies such as Monero.

These are just a few examples of the types of zero-knowledge proofs available. Each type has its characteristics and use cases, making zero-knowledge proofs a versatile tool for achieving privacy and security in various domains.

Applications of Zero-Knowledge Proofs

Zero-knowledge proofs find applications in a wide range of fields and address important privacy and security concerns. Let's explore some of the key applications of zero-knowledge proofs:

Privacy-Preserving Cryptocurrencies

One prominent application of zero-knowledge proofs is in privacy-focused cryptocurrencies such as Zcash (ZEC). Zero-knowledge proofs allow for anonymous transactions without revealing the transaction details or the identities of the users. This enhances transaction privacy and confidentiality in blockchain networks.

Authentication and Access Control

Zero-knowledge proofs can be used in authentication and access control systems to demonstrate knowledge of a password or cryptographic key without revealing the actual password or key itself. This provides secure and user-friendly authentication techniques while preserving privacy.

Electronic Voting Systems

Zero-knowledge proofs play a crucial role in electronic voting systems. They enable voters to prove the legitimacy of their vote without disclosing their actual vote. This protects both voter privacy and the integrity of the electoral process.

Secure Data Transfer and Verification

Zero-knowledge proofs allow for secure data transfer and verification. They enable one party to demonstrate the accuracy of computations performed on private data without revealing the data itself. This is particularly useful in scenarios where data privacy is paramount, such as healthcare or financial applications.

Central Bank Digital Currencies (CBDCs)

Zero-knowledge proofs can enhance transaction privacy in central bank digital currencies (CBDCs). Zero-knowledge proofs enable auditability without disclosing transaction specifics by balancing privacy and transparency. This can contribute to adopting and accepting CBDCs while upholding user anonymity.

These are just a few examples of the diverse applications of zero-knowledge proofs. The versatility of zero-knowledge proofs makes them a valuable tool for enhancing privacy, security, and confidentiality in various domains.

Disadvantages of Zero-Knowledge Proofs

While zero-knowledge proofs offer significant benefits, they also come with certain disadvantages. Considering these drawbacks when evaluating the suitability of zero-knowledge proofs for a specific use case is important. Let's explore some of the key disadvantages:

Computational Intensity

Developing and verifying zero-knowledge proofs can be computationally intensive, especially for complex proofs. This can result in longer processing times for transactions and increased computational workload, which may pose challenges for the scalability of blockchain systems.

Complexity and Auditability

Zero-knowledge proofs can add complexity to protocols, making them more difficult to audit and verify. The intricate nature of zero-knowledge proofs may raise concerns about potential security flaws or bugs in the implementation.

Potential for Illegal Activity

While zero-knowledge proofs enhance privacy by hiding information, they may also facilitate illegal activities in certain situations. This poses challenges for regulatory compliance and may require additional measures to prevent misuse of zero-knowledge proofs.

Limited Applicability

Zero-knowledge proofs may not be suitable for all use cases or sectors. They require expertise and experience to implement correctly, which may limit their widespread adoption across different fields.

While zero-knowledge proofs offer valuable privacy and security features, it is essential to carefully assess the associated trade-offs and challenges before incorporating them into specific systems or applications.

Conclusion

Zero-knowledge proofs are a powerful cryptographic tool that enables the verification of information without revealing the underlying data. 

They offer enhanced privacy, security, and confidentiality, making them valuable in various applications. From privacy-focused cryptocurrencies to secure data transfer and authentication, zero-knowledge proofs provide solutions to critical challenges in the digital era. 

However, it is important to consider zero-knowledge proofs' computational intensity, complexity, and potential limitations when evaluating their suitability for specific use cases. 

By leveraging the benefits and addressing the challenges, zero-knowledge proofs can unlock new levels of privacy and security in our increasingly interconnected world.

Disclaimer

The information provided on this website does not constitute investment advice, financial advice, trading advice, or any other advice, and you should not treat any of the website's content as such.

Token Metrics does not recommend that any cryptocurrency should be bought, sold, or held by you. Conduct your due diligence and consult your financial advisor before making investment decisions.

Build Smarter Crypto Apps &
AI Agents in Minutes, Not Months
Real-time prices, trading signals, and on-chain insights all from one powerful API.
Grab a Free API Key
Token Metrics Team
Token Metrics Team

Recent Posts

Research

Practical API Testing: Strategies, Tools, and Best Practices

Token Metrics Team
5
MIN

APIs are the connective tissue of modern software. Testing them thoroughly prevents regressions, ensures predictable behavior, and protects downstream systems. This guide breaks API testing into practical steps, frameworks, and tool recommendations so engineers can build resilient interfaces and integrate them into automated delivery pipelines.

What is API testing?

API testing verifies that application programming interfaces behave according to specification: returning correct data, enforcing authentication and authorization, handling errors, and performing within expected limits. Unlike UI testing, API tests focus on business logic, data contracts, and integration between systems rather than presentation. Well-designed API tests are fast, deterministic, and suitable for automation, enabling rapid feedback in development workflows.

Types of API tests

  • Unit/Component tests: Validate single functions or routes in isolation, often by mocking external dependencies to exercise specific logic.
  • Integration tests: Exercise interactions between services, databases, and third-party APIs to verify end-to-end flows and data consistency.
  • Contract tests: Assert that a provider and consumer agree on request/response shapes and semantics, reducing breaking changes in distributed systems.
  • Performance tests: Measure latency, throughput, and resource usage under expected and peak loads to find bottlenecks.
  • Security tests: Check authentication, authorization, input validation, and common vulnerabilities (for example injection, broken access control, or insufficient rate limiting).
  • End-to-end API tests: Chain multiple API calls to validate workflows that represent real user scenarios across systems.

Designing an API testing strategy

Effective strategies balance scope, speed, and confidence. A common model is the testing pyramid: many fast unit tests, a moderate number of integration and contract tests, and fewer end-to-end or performance tests. Core elements of a robust strategy include:

  • Define clear acceptance criteria: Use API specifications (OpenAPI/Swagger) to derive expected responses, status codes, and error formats so tests reflect agreed behavior.
  • Prioritize test cases: Focus on critical endpoints, authentication flows, data integrity, and boundary conditions that pose the greatest risk.
  • Use contract testing: Make provider/consumer compatibility explicit with frameworks that can generate or verify contracts automatically.
  • Maintain test data: Seed environments with deterministic datasets, use fixtures and factories, and isolate test suites from production data.
  • Measure coverage pragmatically: Track which endpoints and input spaces are exercised, but avoid chasing 100% coverage if it creates brittle tests.

Tools, automation, and CI/CD

Tooling choices depend on protocols (REST, GraphQL, gRPC) and language ecosystems. Common tools and patterns include:

  • Postman & Newman: Rapid exploratory testing, collection sharing, and collection-based automation suited to cross-team collaboration.
  • REST-assured / Supertest / pytest + requests: Language-native libraries for integration and unit testing in JVM, Node.js, and Python ecosystems.
  • Contract testing tools: Pact, Schemathesis, or other consumer-driven contract frameworks to prevent breaking changes in services.
  • Load and performance: JMeter, k6, Gatling for simulating traffic and measuring resource limits and latency under stress.
  • Security scanners: OWASP ZAP or dedicated fuzzers for input validation, authentication, and common attack surfaces.

Automation should be baked into CI/CD pipelines: run unit and contract tests on pull requests, integration tests on feature branches or merged branches, and schedule performance/security suites on staging environments. Observability during test runs—collecting metrics, logs, and traces—helps diagnose flakiness and resource contention faster.

AI-driven analysis can accelerate test coverage and anomaly detection by suggesting high-value test cases and highlighting unusual response patterns. For teams that integrate external data feeds into their systems, services that expose robust, real-time APIs and analytics can be incorporated into test scenarios to validate third-party integrations under realistic conditions. For example, Token Metrics offers datasets and signals that can be used to simulate realistic inputs or verify integrations with external data providers.

Build Smarter Crypto Apps & AI Agents with Token Metrics

Token Metrics provides real-time prices, trading signals, and on-chain insights all from one powerful API. Grab a Free API Key

What is the difference between unit and integration API tests?

Unit tests isolate individual functions or routes using mocks and focus on internal logic. Integration tests exercise multiple components together (for example service + database) to validate interaction, data flow, and external dependencies.

How often should I run performance tests?

Run lightweight load tests during releases and schedule comprehensive performance runs on staging before major releases or after architecture changes. Frequency depends on traffic patterns and how often critical paths change.

Can AI help with API testing?

AI can suggest test inputs, prioritize test cases by risk, detect anomalies in responses, and assist with test maintenance through pattern recognition. Treat AI as a productivity augmenter that surfaces hypotheses requiring engineering validation.

What is contract testing and why use it?

Contract testing ensures providers and consumers agree on the API contract (schemas, status codes, semantics). It reduces integration regressions by failing early when expectations diverge, enabling safer deployments in distributed systems.

What are best practices for test data management?

Use deterministic fixtures, isolate test databases, anonymize production data when necessary, seed environments consistently, and prefer schema or contract assertions to validate payload correctness rather than brittle value expectations.

How do I handle flaky API tests?

Investigate root causes such as timing, external dependencies, or resource contention. Reduce flakiness by mocking unstable third parties, improving environment stability, adding idempotent retries where appropriate, and capturing diagnostic traces during failures.

Disclaimer

This article is educational and technical in nature and does not constitute investment, legal, or regulatory advice. Evaluate tools and data sources independently and test in controlled environments before production use.

Research

Understanding APIs: A Clear Definition

Token Metrics Team
5
MIN

APIs power modern software by letting systems communicate without exposing internal details. Whether you're building an AI agent, integrating price feeds for analytics, or connecting wallets, understanding the core concept of an "API" — and the practical rules around using one — is essential. This article defines what an API is, explains common types, highlights evaluation criteria, and outlines best practices for secure, maintainable integrations.

What an API Means: A Practical Definition

API stands for Application Programming Interface. At its simplest, an API is a contract: a set of rules that lets one software component request data or services from another. The contract specifies available endpoints (or methods), required inputs, expected outputs, authentication requirements, and error semantics. APIs abstract implementation details so consumers can depend on a stable surface rather than internal code.

Think of an API as a menu in a restaurant: the menu lists dishes (endpoints), describes ingredients (parameters), and sets expectations for what arrives at the table (responses). Consumers don’t need to know how the kitchen prepares the dishes — only how to place an order.

Common API Styles and When They Fit

APIs come in several architectural styles. The three most common today are:

  • REST (Representational State Transfer): Resources are exposed via HTTP verbs (GET, POST, PUT, DELETE). REST APIs are simple, cacheable, and easy to test with standard web tooling.
  • GraphQL: A query language that lets clients request exactly the fields they need. GraphQL reduces over- and under-fetching but introduces complexity on server-side resolvers and query depth control.
  • RPC / WebSocket / gRPC: Remote Procedure Calls or streaming protocols suit high-performance or real-time needs. gRPC uses binary protocols for efficiency; WebSockets enable persistent bidirectional streams, useful for live updates.

Choosing a style depends on use case: REST for simple, cacheable resources; GraphQL for complex client-driven queries; gRPC/WebSocket for low-latency or streaming scenarios.

How to Read and Evaluate API Documentation

Documentation quality often determines integration time and reliability. When evaluating an API, check for:

  • Clear endpoint descriptions: Inputs, outputs, HTTP methods, and expected status codes.
  • Auth & rate-limit details: Supported authentication methods (API keys, OAuth), token lifecycle, and precise rate-limit rules.
  • Example requests & responses: Copy‑paste examples in multiple languages make testing faster.
  • SDKs and client libraries: Maintained SDKs reduce boilerplate and potential bugs.
  • Changelog & versioning policy: How breaking changes are communicated and how long old versions are supported.

For crypto and market data APIs, also verify the latency SLAs, the freshness of on‑chain reads, and whether historical data is available in a form suitable for research or model training.

Security, Rate Limits, and Versioning Best Practices

APIs expose surface area; securing that surface is critical. Key practices include:

  • Least-privilege keys: Issue scoped API keys or tokens that only grant necessary permissions.
  • Use TLS: Always request and enforce encrypted transport (HTTPS) to protect credentials and payloads.
  • Rate limit handling: Respect limit headers and implement retry/backoff logic to avoid throttling or IP bans.
  • Versioning: Prefer URL or header-based versioning and design migrations so clients can opt-in to changes.
  • Monitoring: Track error rates, latency, and unusual patterns that could indicate abuse or regressions.

Security and resilience are especially important in finance and crypto environments where integrity and availability directly affect analytics and automated systems.

APIs in AI and Crypto Workflows: Practical Steps

APIs are central to AI-driven research and crypto tooling. When integrating APIs into data pipelines or agent workflows, consider these steps:

  1. Map required data: determine fields, frequency, and freshness needs.
  2. Prototype with free or sandbox keys to validate endpoints and error handling.
  3. Instrument observability: log request IDs, latencies, and response codes to analyze performance.
  4. Design caching layers for non-sensitive data to reduce costs and improve latency.
  5. Establish rotation and revocation processes for keys to maintain security hygiene.

AI models and agents can benefit from structured, versioned APIs that provide deterministic responses; integrating dataset provenance and schema validation improves repeatability in experiments.

Build Smarter Crypto Apps & AI Agents with Token Metrics

Token Metrics provides real-time prices, trading signals, and on-chain insights all from one powerful API. Grab a Free API Key

Frequently Asked Questions

What is the simplest way to describe an API?

An API is an interface that defines how two software systems communicate. It lists available operations, required inputs, and expected outputs so developers can use services without understanding internal implementations.

How do REST and GraphQL differ?

REST exposes fixed resource endpoints and relies on HTTP semantics. GraphQL exposes a flexible query language letting clients fetch precise fields in one request. REST favors caching and simplicity; GraphQL favors efficiency for complex client queries.

What should I check before using a crypto data API?

Confirm data freshness, historical coverage, authentication methods, rate limits, and the provider’s documentation. Also verify uptime, SLA terms if relevant, and whether the API provides proof or verifiable on‑chain reads for critical use cases.

How do rate limits typically work?

Rate limits set a maximum number of requests per time window, often per API key or IP. Providers may return headers indicating remaining quota and reset time; implement exponential backoff and caching to stay within limits.

Can AI tools help evaluate APIs?

AI-driven research tools can summarize documentation, detect breaking changes, and suggest integration patterns. For provider-specific signals and token research, platforms like Token Metrics combine multiple data sources and models to support analysis workflows.

Disclaimer

This article is educational and informational only. It does not constitute financial, legal, or investment advice. Readers should perform independent research and consult qualified professionals before making decisions related to finances, trading, or technical integrations.

Research

API Gateway: Architecture, Patterns & Best Practices

Token Metrics Team
5
MIN

Modern distributed systems rely on effective traffic control, security, and observability at the edge. An API gateway centralizes those responsibilities, simplifying client access to microservices and serverless functions. This guide explains what an API gateway does, common architectural patterns, deployment and performance trade-offs, and design best practices for secure, scalable APIs.

What is an API Gateway?

An API gateway is a server-side component that sits between clients and backend services. It performs request routing, protocol translation, aggregation, authentication, rate limiting, and metrics collection. Instead of exposing each service directly, teams present a single, consolidated API surface to clients through the gateway. This centralization reduces client complexity, standardizes cross-cutting concerns, and can improve operational control.

Think of an API gateway as a policy and plumbing layer: it enforces API contracts, secures endpoints, and implements traffic shaping while forwarding requests to appropriate services.

Core Features and Architectural Patterns

API gateways vary in capability but commonly include:

  • Routing and reverse proxy: Direct requests to the correct backend based on path, headers, or other criteria.
  • Authentication and authorization: Validate tokens (JWT, OAuth2), integrate with identity providers, and enforce access policies.
  • Rate limiting and quotas: Protect backend services from overload and manage multi-tenant usage.
  • Request/response transformation: Convert between protocols (HTTP/gRPC), reshape payloads, or aggregate multiple service calls.
  • Observability: Emit metrics, traces, and structured logs for monitoring and debugging.

Common patterns include:

  1. Edge gateway: A public-facing gateway handling authentication, CDN integration, and basic traffic management.
  2. Internal gateway: Placed inside the trust boundary to manage east-west traffic within a cluster or VPC.
  3. Aggregating gateway: Combines multiple backend responses into a single client payload, useful for mobile or low-latency clients.
  4. Per-tenant gateway: For multi-tenant platforms, separate gateways per customer enforce isolation and custom policies.

Deployment Models and Performance Considerations

Choosing where and how to deploy an API gateway affects performance, resilience, and operational cost. Key models include:

  • Managed cloud gateways: Providers offer scalable gateways with minimal operational overhead. They simplify TLS, identity integration, and autoscaling but can introduce vendor lock-in and per-request costs.
  • Self-managed gateways: Run on Kubernetes or VMs for full control over configuration and plugins. This model increases operational burden but enables custom routing logic and deep integration with internal systems.
  • Sidecar or service mesh complement: In service mesh architectures, a gateway can front the mesh, delegating fine-grained service-to-service policies to sidecar proxies.

Performance trade-offs to monitor:

  • Latency: Each hop through the gateway adds processing time. Use lightweight filters, compiled rules, and avoid heavy transformations on hot paths.
  • Concurrency: Ensure the gateway and backend services scale independently. Backpressure, circuit breakers, and backoff strategies help prevent cascading failures.
  • Caching: Edge caching can drastically reduce load and latency for idempotent GET requests. Consider cache invalidation and cache-control headers carefully.

Design Best Practices and Security Controls

Adopt practical rules to keep gateways maintainable and secure:

  • Limit business logic: Keep the gateway responsible for orchestration and policy enforcement, not core business rules.
  • Token-based auth and scopes: Use scoped tokens and short lifetimes for session tokens. Validate signatures and token claims at the gateway level.
  • Observability-first: Emit structured logs, metrics, and distributed traces. Correlate gateway logs with backend traces for faster root cause analysis.
  • Throttling and quotas: Set conservative defaults and make limits configurable per client or plan. Implement graceful degradation for overloaded backends.
  • Policy-driven config: Use declarative policies (e.g., YAML or CRDs) to version and review gateway rules rather than ad-hoc runtime changes.

AI and analytics tools can accelerate gateway design and operating decisions by surfacing traffic patterns, anomaly detection, and vulnerability signals. For example, products that combine real-time telemetry with model-driven insights help prioritize which endpoints need hardened policies.

Build Smarter Crypto Apps & AI Agents with Token Metrics

Token Metrics provides real-time prices, trading signals, and on-chain insights all from one powerful API. Grab a Free API Key

What is an API gateway vs service mesh?

These technologies complement rather than replace each other. The API gateway handles north-south traffic (client to cluster), enforcing authentication and exposing public endpoints. A service mesh focuses on east-west traffic (service-to-service), offering fine-grained routing, mTLS, and telemetry between microservices. Many architectures use a gateway at the edge and a mesh internally for granular control.

FAQ: Common Questions About API Gateways

How does an API gateway impact latency?

A gateway introduces processing overhead for each request, which can increase end-to-end latency. Mitigations include optimizing filters, enabling HTTP/2 multiplexing, using local caches, and scaling gateway instances horizontally.

Do I need an API gateway for every architecture?

Not always. Small monoliths or single-service deployments may not require a gateway. For microservices, public APIs, or multi-tenant platforms, a gateway adds value by centralizing cross-cutting concerns and simplifying client integrations.

What security measures should the gateway enforce?

At minimum, the gateway should enforce TLS, validate authentication tokens, apply rate limits, and perform input validation. Additional controls include IP allowlists, web application firewall (WAF) rules, and integration with identity providers for RBAC.

Can API gateways aggregate responses from multiple services?

Yes. Aggregation reduces client round trips by composing responses from multiple backends. Use caching and careful error handling to avoid coupling performance of one service to another.

How do I test and version gateway policies?

Use a staging environment to run synthetic loads and functional tests against gateway policies. Store configurations in version control, run CI checks for syntax and policy conflicts, and roll out changes via canary deployments.

Is it better to use a managed gateway or self-host?

Managed gateways reduce operational overhead and provide scalability out of the box, while self-hosted gateways offer deeper customization and potentially lower long-term costs. Choose based on team expertise, compliance needs, and expected traffic patterns.

Disclaimer

This article is for educational and technical information only. It does not constitute investment, legal, or professional advice. Readers should perform their own due diligence when selecting and configuring infrastructure components.

Choose from Platinum, Gold, and Silver packages
Reach with 25–30% open rates and 0.5–1% CTR
Craft your own custom ad—from banners to tailored copy
Perfect for Crypto Exchanges, SaaS Tools, DeFi, and AI Products