Marlin
Marlin (POND) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).
Marlin / Oyster — an AI/Compute | Infra project: a TEE‑based verifiable computing / “coprocessor” layer (Confidential VMs + Serverless) for deploying and calling complex offchain workloads (including AI models/agents) with attestation and onchain control (staking/escrow/slashing).
Disclaimer
Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.
TL;DR (for readers who are not into AI)
- What it is: a “decentralized cloud” layer where applications run in a TEE (a CVM or a serverless sandbox), and users get verifiability of the environment (attestations) and protocol guarantees of uptime/quality.
- Who it’s for: developers who need verifiable offchain computation (a coprocessor for smart contracts, access to web2 APIs) and provider nodes (providers/executors/gateways).
- Why onchain/token: Tier‑1 describes that Oyster services are managed via smart contracts; POND/MPOND are used for staking/incentives (including the bootstrap/payment pool in serverless), while user serverless fees in the examples are paid in USDC.
- What you can actually touch (Tier‑1):
Oyster CVM Quickstart(deploy + verify remote attestation),Oyster Marketplace(deploy/manage), and the serverless tutorial “Periodic Automation of Contract Calls”.
How it works (very briefly)
- The user does: chooses a mode (CVM or serverless), prepares an enclave image/function and creates a request (job) via a web2 endpoint or a smart contract call.
- The system does: runs the workload in a TEE (with KMS/attestation), matches user↔provider via the onchain registry, monitors execution and uptime; on violations the provider can be penalized.
- The user gets: the computation result/service (API/endpoint) + the ability to verify the environment (attestation) and protocol guarantees.
- Where the blockchain is: Tier‑1 explicitly describes the management of Oyster services via smart contracts, and the addresses of the related contracts (including staking and the serverless relay/subscription relay) on the Arbitrum One network are published; the POND/MPOND tokens also exist on Ethereum/Arbitrum/BNB (Tier‑1).
- Token role: POND/MPOND are used for staking/delegation and protocol incentives; MPOND is a governance+staking token (Tier‑1).
Quick links: AI thesis fit
Project passport
| Field | Value |
|---|---|
| Project name | Marlin |
| Also known as (aliases) | Oyster; Marlin Oyster; Oyster CVM; Oyster Serverless |
| Logo (logo) | ../assets/71_marlin_logo.svg |
| Token symbol (ticker) | POND |
| Category | AI/Compute | Infra |
| Primary chain (chain) | Arbitrum One |
| Type | EVM |
| Network status | mainnet |
| Consensus (consensus) | L2 (Optimistic Rollup, Arbitrum One on Ethereum) |
| Launch date (launch_date) | — |
| Project status (status) | active |
| Token (standard) | ERC-20 |
| Token contract | 0x57b946008913b82e4df85f501cbaed910e58d26c |
| Token model (token_type) | utility (staking + governance) |
| Max supply | 10,000,000,000 |
| Issuance | capped |
| Tokenomics (tokenomics, brief) | total supply POND 10B; POND/MPOND — staking/delegation; MPOND — governance+staking token; for serverless, bootstrap/payment pool mechanics and a user fee (example) in USDC are described. |
| Governance | DAO |
| Admins/keys | — |
| Audit | yes |
| Bug bounty | yes |
| Team (team) | — |
| Funding (investors/funding) | — |
| AI component (ai_component) | verifiable compute for AI models (TEE) |
| Use‑case (use_case) | TEE coprocessor (CVMs + serverless) |
| DecAI Fit — AI thesis fit | 6/6 — high alignment with the Decentralized AI thesis |
| DecAI Fit component summary | ai_score 3 / onchain_score 3 / token_score 2 / evidence_score 3 |
| Last verified | 2026-02-11 |
Links (links_*)
| Type | Link |
|---|---|
| Website | https://www.marlin.org |
| Docs | https://docs.marlin.org |
| App / Demo | https://arb1.marlin.org/oyster/marketplace/ |
| GitHub | https://github.com/marlinprotocol |
| Releases / Changelog | — |
| Whitepaper | https://marlinlabs.xyz/research/papers/introducing-marlin-protocol/ |
| Roadmap | — |
| Security advisories | https://github.com/marlinprotocol/Contracts/security/advisories |
| Explorer | https://etherscan.io/token/0x57b946008913b82e4df85f501cbaed910e58d26c |
| X | https://twitter.com/MarlinProtocol |
| Discord | https://discord.gg/pdQZyyy |
| Telegram | https://t.me/marlinprotocol |
| Medium | — |
| Audit report(s) | https://docs.marlin.org/oyster/protocol/cvm/monitoring-protocol/auditing-mechanism |
| Bug bounty | https://docs.marlin.org/risks-and-security/audits |
| CoinGecko (profile, reference) | https://www.coingecko.com/en/coins/marlin |
| CoinMarketCap (profile, reference) | https://coinmarketcap.com/currencies/marlin/ |
General project overview
Marlin describes itself as a verifiable computing protocol based on TEEs (Trusted Execution Environments), which allows deploying complex workloads (including AI models) to a “decentralized cloud” and calling them both via web2 APIs and via onchain calls (a coprocessor for dApps). Computation is performed offchain in a TEE, while verifiability and protocol guarantees are achieved through attestation, monitoring and onchain stake/slashing mechanics.
The documentation distinguishes two Oyster modes:
- Oyster CVM (Confidential VM): a long‑lived confidential VM for backends and “heavy workloads” (Linux in a TEE).
- Oyster Serverless: request‑response execution of functions in a shared pool of machines (a JS/WASM sandbox in a TEE), including “subscriptions” (periodic execution — for example, for oracles or automation).
Features/modules
- Oyster CVM: a confidential VM (Linux in a TEE), networking (including TCP), persistent keys via KMS, remote attestations (Tier‑1).
- Oyster Serverless: on‑demand execution of functions, pricing/incentives, subscriptions for periodic jobs (Tier‑1).
- Onchain workflow: provider registration, escrow/job registry, staking/slashing and uptime monitoring (Tier‑1).
- AI guides: “AI models” are claimed as a use‑case; there are developer quickstarts/tutorials on deploying to Oyster CVM and serverless guides (Tier‑1).
Typical scenarios
- Scenario 1 (AI dev): deploys an LLM to Oyster CVM → gets verifiable inference (TEE) and privacy of the model/inputs (Tier‑1).
- Scenario 2 (dApp): offloads complex logic/automation to serverless and calls it on a schedule/on demand → gets an onchain‑managed service (Tier‑1).
- Scenario 3 (provider): registers as a provider/operator, stakes POND and serves jobs, receiving rewards (Tier‑1).
Getting started (wallet/network)
- What you need: an EVM wallet (Arbitrum One) for onchain operations; for CVM — prepare a docker/enclave image; for serverless — devtools/templates.
- Network/chain: the Oyster Serverless contracts and many protocol contracts — Arbitrum One; the POND/MPOND tokens also exist on Ethereum (Tier‑1).
- Fees: Arbitrum/Ethereum gas for onchain actions; in the serverless tutorial, user fee payments are shown in USDC (Tier‑1).
Architecture/tech (non‑AI)
- Components (compute): a CVM (Linux in a TEE) and a serverless sandbox (JS/WASM) (Tier‑1).
- Components (onchain): registries/escrow/job registry/relay/subscriptions and staking contracts (Tier‑1 contract addresses).
- Participant roles: users, providers/executors/gateways, auditors, governance.
- Where logic runs: computation — offchain in a TEE; economic guarantees and control — onchain.
- Dependencies: TEE hardware (SGX/TDX/Nitro and others in the description), Arbitrum/Ethereum, external storage of the enclave image (IPFS/URL).
Token/economics (expanded, no forecasts)
- Token utility: POND is the utility token of the Marlin protocol, used for staking/delegation (Tier‑1); MPOND is a governance+staking token for proposals/voting and is also required for running nodes (Tier‑1).
- Who pays fees: users pay gas for onchain transactions; serverless user fees (example) are paid in USDC (Tier‑1).
- Bootstrap/Payment Pool: Tier‑1 describes the bootstrap pool and payment pool mechanics of serverless; the bootstrap pool is funded with POND, and part of the user fees may replenish the payment pool according to protocol rules (Tier‑1).
- Issuance/burn: total supply POND = 10B (Tier‑1
marlinprotocol/contractsand Etherscan). - Distribution and token issuance schedule: — (not established per Tier‑1 within this card).
- Treasury: — (not established per Tier‑1 within this card).
Governance
- Who makes decisions: DAO (governance is mentioned in the incentive design; MPOND is a governance+staking token) (Tier‑1).
- How protocol parameters change: via governance (for example, payment pool parameters, target capacity, prices) (Tier‑1).
- Where decisions are discussed/made: —.
- Keys/multisig: —.
Security and incidents
- Audits: the docs have an audits section (Tier‑1) and the
contractsrepository has anaudits/folder (Tier‑1). - Bug bounty: there is a security/risks & audits section (Tier‑1).
- Incidents: —.
- Threat model: TEE risks (side‑channels/vendor dependence), risks of incorrect attestation verification, risks of an economic attack on staking/escrow/slashing.
Project status and timeline
- Current status: active (docs and contracts are available; there are production contract addresses).
- Key releases/milestones: Oyster as an upgrade that added TEE‑based general purpose compute (Tier‑1 docs).
- Roadmap: —.
Ecosystem/integrations
- Integrations: smart contract calls + web2 APIs; support for offchain APIs; a coprocessor for dApps (Tier‑1 docs).
- Partners: —.
- Where it’s actually used: developer quickstarts/tutorials on Oyster CVM + the serverless tutorial on automation of contract calls, as well as the staking portal (Tier‑1).
AI component of the project
- What is real AI here? Oyster is positioned as infrastructure for deploying/running AI models (for example, LLaMA) and AI agent services in a TEE (Tier‑1).
- What is truly onchain? Oyster services are described as managed via smart contracts; the addresses of the tokens/staking and the serverless contracts (relay/subscription relay) are published (Tier‑1).
- Why is a token needed? POND/MPOND — staking/incentives; MPOND — governance (Tier‑1). At the same time, user fees in the serverless guide are shown in USDC (Tier‑1).
- Red flags (based on the information found): AI‑washing — low (there are specific developer quickstarts/tutorials); onchain‑washing — low (there are addresses and an incentive model in Tier‑1); token‑washing — medium (part of the user fees may go in a stablecoin, while the tokens are primarily about stake/incentives/governance).
DecAI Fit component summary
- DecAI Fit: 6/6 — high alignment with the Decentralized AI thesis
| Component | Level | Score |
|---|---|---|
| AI reality | high | 3 |
| Onchain necessity | high | 3 |
| Token necessity | medium | 2 |
| Evidence | Tier‑1 present | 3 |
Details
AI reality
AI_0 — AI intent (Tier‑1 roadmap) (1/0)
- AI_0 (decision): 0
- Claim (one line): AI (deploy AI models) is described as a current part of the product, not as a roadmap intent.
- Evidence: Tier‑1 — https://docs.marlin.org
- Why sufficient / why not (one line): the intent flag is not needed.
- Conflict note (if any): —
AI_1 — what the AI does (1/0)
- AI_1 (decision): 1
- Claim (one line): Oyster allows deploying AI models/agents in a TEE (CVM) and obtaining verifiability/privacy of the computation.
- Evidence: Tier‑1 — https://docs.marlin.org , https://www.marlin.org/ai
- Why sufficient / why not (one line): Tier‑1 directly lists “AI models” as an example of workloads and the scenario “Develop, train and scale AI models”.
- Conflict note (if any): —
AI_2 — demos/examples (1/0)
- AI_2 (decision): 1
- Claim (one line): there are reproducible guides on deploying Oyster CVM (deploy + verify attestation) and serverless tutorials.
- Evidence: Tier‑1 — https://docs.marlin.org/oyster/build-cvm/quickstart , https://docs.marlin.org/oyster/build-cvm/tutorials , https://docs.marlin.org/oyster/build-serverless/tutorials/automation
- Why sufficient / why not (one line): the docs provide step‑by‑step guides/commands and a developer flow.
- Conflict note (if any): —
AI_3 — metrics/quality (1/0)
- AI_3 (decision): 0
- Metrics: —.
- Context (version/date/how measured): —.
- Evidence: Tier‑1 — https://docs.marlin.org
- Why sufficient / why not (one line): Tier‑1 has no reproducible AI quality metrics/inference benchmarks.
- Conflict note (if any): —
AI_4 — tech description/architecture/versions (1/0)
- AI_4 (decision): 1
- Claim (one line): CVM vs serverless, TEE/attestations/KMS and the onchain workflow of providers/users are described.
- Evidence: Tier‑1 — https://docs.marlin.org , https://docs.marlin.org/oyster/build-cvm
- Why sufficient / why not (one line): a sufficient high‑level technical description and protocol details.
- Conflict note (if any): —
Onchain necessity
OC_1 — contracts/addresses/chain (1/0)
- OC_1 (decision): 1
- Chain: Arbitrum One (main protocol contracts) + Ethereum (token/bridge).
- Addresses/identifiers: POND (Ethereum)
0x57b946008913b82e4df85f501cbaed910e58d26c; staking (Arbitrum)0xf90490186f370f324def2871f077668455f65253; serverless relay0xD28179711eeCe385bc2096c5D199E15e6415A4f5(and others). - Evidence: Tier‑1 — https://docs.marlin.org/oyster/contracts , https://etherscan.io/token/0x57b946008913b82e4df85f501cbaed910e58d26c
- Why sufficient / why not (one line): the docs publish the official contract addresses; the explorer confirms the token.
- Conflict note (if any): —
OC_2 — onchain beyond just a token (1/0)
- OC_2 (decision): 1
- What useful logic is onchain: provider registry, escrow/job registry, staking and the serverless relay/subscriptions contracts.
- Evidence: Tier‑1 — https://docs.marlin.org/oyster/protocol/cvm , https://docs.marlin.org/oyster/contracts
- Why sufficient / why not (one line): Tier‑1 directly states that Oyster services are “managed purely through smart contracts”, and the docs publish the addresses of the related contracts.
- Conflict note (if any): —
OC_3 — onchain is critical (1/0)
- OC_3 (decision): 1
- “Replace the blockchain” test: without smart contracts, trustless management of services/incentives and the economic guarantees break down (pricing/incentives are determined by governance, and the bootstrap/payment pool is part of the protocol).
- Evidence: Tier‑1 — https://docs.marlin.org/oyster/protocol/cvm , https://docs.marlin.org/oyster/protocol/serverless/smart-contract-requests/incentive-design
- Why sufficient / why not (one line): Tier‑1 ties service management and incentives to contracts and governance parameters.
- Conflict note (if any): —
Token necessity
TK_0 — no token (1/0)
- TK_0 (decision): 0
- Claim (one line): the project has the POND and MPOND tokens (ERC‑20).
- Evidence: Tier‑1 — https://docs.marlin.org/oyster/contracts , https://etherscan.io/token/0x57b946008913b82e4df85f501cbaed910e58d26c
- Why sufficient / why not (one line): the official addresses are published, the token is confirmed onchain.
- Conflict note (if any): —
TK_1..TK_4 (1/0)
TK_1 — payment for the service (1/0)
- TK_1 (decision): 0
- Claim (one line): user fees in the serverless tutorial are paid in USDC; “pay‑in‑POND” as a fee token is not confirmed in Tier‑1.
- Evidence: Tier‑1 — https://docs.marlin.org/oyster/build-serverless/tutorials/automation
- Why sufficient / why not (one line): POND is confirmed as a stake/incentives token, but not as a token for paying user fees.
- Conflict note (if any): —
TK_2 — incentives/collateral/penalties (1/0)
- TK_2 (decision): 1
- Claim (one line): POND/MPOND are used for staking/node operation; for serverless, bootstrap/payment pool incentives in POND to maintain latent capacity are described.
- Evidence: Tier‑1 — https://docs.marlin.org/oyster/contracts , https://docs.marlin.org/run-your-own-node/relay/staking , https://docs.marlin.org/oyster/protocol/serverless/smart-contract-requests/incentive-design
- Why sufficient / why not (one line): Tier‑1 records the role of POND/MPOND in staking and describes POND incentives for serverless capacity.
- Conflict note (if any): —
TK_3 — governance (1/0)
- TK_3 (decision): 1
- Claim (one line): the governance role belongs to MPOND (governance+staking token): creating proposals and voting.
- Evidence: Tier‑1 — https://github.com/marlinprotocol/contracts
- Why sufficient / why not (one line): the repo README describes MPOND as a governance token.
- Conflict note (if any): —
TK_4 — token is replaceable (1/0)
- TK_4 (decision): 0
- Claim (one line): the protocol economy is tied to POND as a staking/incentives token.
- Evidence: Tier‑1 — https://docs.marlin.org/oyster/protocol/serverless/smart-contract-requests/incentive-design , https://docs.marlin.org/run-your-own-node/relay/staking
- Why sufficient / why not (one line): Tier‑1 describes POND/MPOND as staking/incentives/governance tokens; alternative collateral as a replacement is not described.
- Conflict note (if any): —
Evidence (table)
| Tier | Source | What it proves |
|---|---|---|
| Tier‑1 | https://docs.marlin.org | that Marlin/Oyster is verifiable computing based on TEEs; AI models as an example of workloads. |
| Tier‑1 | https://www.marlin.org/ai | AI use‑case: deploying an AI model on Oyster and verifiable execution/privacy. |
| Tier‑1 | https://docs.marlin.org/oyster/build-cvm/quickstart | a reproducible developer quickstart: deploy on Oyster and verify remote attestation. |
| Tier‑1 | https://docs.marlin.org/oyster/build-cvm/tutorials | a list of step‑by‑step tutorials on Oyster CVM (deployment, attestations, update, etc.). |
| Tier‑1 | https://docs.marlin.org/oyster/protocol/cvm | the TEE rationale and the statement “services managed purely through smart contracts”. |
| Tier‑1 | https://docs.marlin.org/oyster/contracts | official addresses of the tokens/bridge/staking and the serverless contracts (Arbitrum One). |
| Tier‑1 | https://docs.marlin.org/oyster/protocol/serverless/smart-contract-requests/incentive-design | payment pool/bootstrapping incentives in POND to maintain latent serverless capacity. |
| Tier‑1 | https://docs.marlin.org/oyster/build-serverless/tutorials/automation | a reproducible serverless tutorial (smart‑contract automation) + an example of payment in USDC. |
| Tier‑1 | https://docs.marlin.org/run-your-own-node/relay/staking | POND/MPOND staking, migration to Arbitrum, staking portals. |
| Tier‑1 | https://github.com/marlinprotocol/contracts | Marlin smart contracts; MPOND as a governance+staking token; total supply POND 10B. |
| Tier‑1 | https://docs.marlin.org/risks-and-security/audits | a list of audit reports (Peckshield/Certik/Knownsec) and a description of bug bounty disclosure. |
| Tier‑1 | https://github.com/marlinprotocol/Contracts/security/advisories | security advisories (contracts). |
| Tier‑1 | https://etherscan.io/token/0x57b946008913b82e4df85f501cbaed910e58d26c | the onchain fact of the POND token (ERC‑20), max total supply 10B. |
No comments to display
No comments to display