Kraken

Kraken, operated primarily under the corporate umbrella of Payward Inc., represents a highly evolved shared financial infrastructure layer and digital asset exchange. Founded in 2011, the platform provides unified liquidity, centralized risk management, and a globally compliant infrastructure to serve diverse client segments.

General
Provider / Author	Kraken
Founded	2011
Type	High-Performance Digital Asset Exchange & Financial Infrastructure
Primary Architecture	Polyglot Microservices (Rust gRPC backend, C++ matching engine)
Website	https://www.kraken.com/en-gb/lp/platform
Developer Documentation	https://docs.kraken.com/
Open-Source Repository	https://github.com/krakenfx

Start building with Kraken products

Kraken provides an institutional-grade trading ecosystem capable of sub-2 millisecond round-trip latencies and handling up to 15,000 algorithmic orders per second. The underlying architecture utilizes a highly optimized microservices topology, with the ultra-hot path matching engine engineered in C++ for deterministic execution and the backend primarily built in Rust. Furthermore, Kraken offers developers the "Ink" Layer-2 blockchain, a scaling solution built on the Optimism OP Stack that seamlessly bridges centralized exchange liquidity with decentralized finance (DeFi). We highly encourage you to check out the innovative Web3 apps and algorithmic trading bots created with this technology during lablab.ai hackathons!

Key Platform Features

Polyglot Microservices: Utilizes Rust and the Tokio asynchronous runtime for highly efficient network I/O and routing, while relying on Python (Django) with strict static type checking (mypy) for API layer logic.
Deterministic Latency & Colocation: Offers dedicated colocation services through partnerships with the Beeks Group, allowing institutional traders to physically host their servers in the same data centers as the matching engine.
Dynamic Rate Limiting: Employs a sophisticated mathematical decay model that assigns penalty points based on computational burden and order resting time, rewarding efficient algorithmic behavior and detering malicious spoofing.
Cryptographic Proof of Reserves: Uses a mathematically verifiable Merkle Tree data structure, independently attested by a CPA firm, enabling clients to cryptographically verify their included balances without compromising privacy.
The Ink Layer-2 Blockchain: An optimistic rollup anchored to Ethereum that provides deep integration with Kraken's centralized infrastructure, empowering frictionless transitions to decentralized applications (dApps) without relinquishing private key custody.

Official Links and Resources

Kraken Developer Documentation: The central gateway for algorithmic integration and REST/WebSocket documentation.
Kraken GitHub Organization: The primary open-source repository for the developer community, offering maintained SDKs and tools under the MIT license.
Kraken Engineering Blog: Technical deep dives spanning architecture, performance, and security.

Libraries and SDKs

API Specifications (api-specs): Machine-readable open-source specifications utilizing OpenAPI for REST and AsyncAPI for WebSocket channels.
Golang Implementation (api-go): An officially maintained, highly concurrent Go module designed for rapid interaction with Spot and Derivatives API endpoints.
Python WebSocket Client (kraken-wsclient-py): A native Python client optimized for establishing robust, persistent WebSocket connections for real-time order book feeds.
python-kraken-sdk: A community-driven Python SDK featuring built-in handlers for automated nonce calculation, REST retries, and asynchronous handling of WebSocket feeds.
KrakenTools: A public utility toolkit offering mathematical helper functions for cryptographic payload signing and data structuring.

Boilerplates

Decentralized Web Wallet (wallet): A self-custodial wallet framework written entirely in TypeScript, foundational for Web3 integration.
Futures Trading Bot Template: A deeply documented template demonstrating complex algorithmic execution and advanced error handling.
Freqtrade Integration: An open-source crypto trading bot allowing developers to test and deploy machine learning models and statistical arbitrage strategies live against the Kraken API.

AgentRush — Blast Radius Zero

AgentRush is a sandboxed execution agent built for the Vultr Agent Rush hackathon. A user submits a task in the web UI; an LLM on Vultr Serverless Inference decomposes it into steps; URL fetches run on the orchestrator host with SSRF-pinned DNS; generated code executes inside a fresh Docker container per task: no network, read-only root fs, tmpfs workdir, capped memory/CPU/pids, all capabilities dropped, empty environment, wall-time kill, destroyed after the run. Every run returns a verifiable JSON record with per-step commands and sha256 of outputs. The demo video shows six live attacks — rm -rf, infinite loop, fork storm, env scrape, outbound curl, prompt injection — each dying at its intended boundary. Live public deployment on a Vultr VM (fra).

PayablesPilot

Companies lose money on supplier invoices in three quiet ways: paying the same invoice twice, paying for goods that never arrived or at a price nobody agreed, and paying a fraudster who swapped the bank details on an invoice. In a small finance team these checks are manual and easy to miss. PayablesPilot is an accounts-payable operations agent that runs the pre-payment control workflow end to end. Invoices arrive by web form or JSON API and are evaluated immediately. A deterministic three-way match compares each invoice with its purchase order and goods receipt: quantities are summed across all invoices on a PO, so it can never be billed beyond goods received, and unit prices are checked within a configurable tolerance (2% or £1.00). An exact invoice-number resubmission is blocked; a same-amount invoice from the same supplier within 7 days is held as a possible duplicate. The bank account on the invoice must equal the supplier master record — a mismatch is held as a possible payment-diversion attempt. Every failure lands in an exception queue with the rule, the observed value and the expected value, plus a drafted supplier follow-up (draft only). Matched invoices are grouped into a payment pack ordered by due date for HUMAN approval; the agent never executes payments. Every decision is written to an audit trail; each invoice page shows every check, so a decision can be re-performed by hand. On the live demo (fictional data, labelled): 9 invoices, 2 payable, 6 held with exact reasons, 1 duplicate blocked; payment pack £860.00, human approval recorded in the audit trail. Approval is simulated and initiates no transfer. Vultr usage: a Vultr Cloud Compute VM in London (1 vCPU / 1 GB) is the central control point — it hosts the app, database and audit trail and serves the public demo. Python 3 standard library only, SQLite, integer cents, 14 unit tests. Serverless Inference is intentionally not used: payment verdicts must be deterministic, never an LLM's opinion.

CanonGuard · Living Canon

Writers' rooms and AI image pipelines for Fractured Code / The Neural Wars keep breaking continuity (coil on the wrong wrist, scar on the wrong cheek, readable badges). An agent that fixes this needs canon access — and that access is exactly what a prompt injection would abuse. CanonGuard separates planning from permission. The planner plans whatever the prompt asks — including overwrite canon.json, read ../../etc/passwd, curl it out, run bash. A policy layer (allowlist of two read-only tools + path jail to /canon) decides; allowed calls run in a one-shot container (--network=none --read-only --cap-drop=ALL --no-new-privileges --user 65534, canon :ro). Each answer carries a blast-radius report: executed vs blocked calls, host writes 0, network none. Deterministic canon rules produce the verdict with evidence spans; Vultr Serverless Inference writes the critic note (demo runs MOCK Inference labelled in UI and /api/health — live path wired, credits skipped for this submit). How Vultr is used: Vultr Cloud Compute VM hosts the Node app + Docker sandbox (demo path on GoalWorld behind Caddy). Vultr Serverless Inference OpenAI-compatible client is wired; submitted demo is MOCK INFERENCE (honest). Containment moment in video: escape prompt tries ../../etc/passwd and write/fetch/shell — all blocked, host_writes 0, network none.

SRE Incident Agent — Blast Radius Zero

The problem. An on-call SRE facing a cryptic 500-line log spends 20–40 minutes of manual grep/correlate work to know what broke and what to do first. LLM assistants can draft guesses, but executing LLM-generated code on a real system is the classic blast-radius problem: run it blind, with network access and secrets in the environment, and a hallucinated diagnostic becomes an incident itself. What we built. SRE Incident Agent closes the loop safely. Paste a log — the LLM plans a diagnostic step, the step runs as real Python in an isolated Docker container, the verified stdout and exit code feed back into the agent's context, and after ≤5 steps it returns a triage report: findings backed by numbers from executed code, three ranked root-cause hypotheses, and an ordered runbook. Nothing the LLM claims is trusted unless an executed snippet printed it. Blast radius zero. The LLM-written code is the attack surface, closed in layers: a static guard refuses subprocess, sockets, URL fetches, file writes, eval/exec and host paths before anything runs (shown as BLOCKED · contained); each snippet runs in a one-shot container with --network none, 256 MB RAM, 1 CPU, 64 pids, read-only rootfs, uid nobody, no-new-privileges — destroyed after every run; secrets never enter the container; a hard 20 s kill per step. The video shows a live containment moment: a hallucinated exfiltration snippet blocked pre-execution. On Vultr. The full backend runs on a Vultr Compute VM (Amsterdam): FastAPI, the Docker sandbox runner, Caddy/TLS. All LLM calls go to Vultr Serverless Inference — primary deepseek-v4.1-flash-1017, whole-step fallback retries on mimo-v2.6-flash. Business case. The author supports storage systems and virtualization fleets already off vendor support, where every incident is triaged manually: this cuts incident triage from ~30 min to ~60 s, with evidence attached.

Agent_Trap_Evals

The problem: agents rarely fail hard questions. They fail chores. They report "backup verified" because the log says success, while the archive is truncated. These false claims slip out during routine work, and a real shell makes them dangerous. What Receipts does: you give it a real task, like checking a backup or triaging a failing build. A control layer plans the work and runs every action in an isolated Vultr sandbox [gVisor pods on VKE]. The sandbox has no secrets, has time and memory caps, and is destroyed after each task. Every command's output, exit code, and files become a receipt. Before any claim reaches you, a verifier checks it against those receipts: did the agent check the layer that matters, or just the easy one? An unsupported claim is blocked and sent back to be verified, or reported as unverified. You get the answer together with its proof. Containment: [demo moment, e.g. the agent runs rm -rf / and the sandbox absorbs it; the host is untouched]. Measured: we score Receipts with agent-trap-evals, an open-source trap set we built before the hackathon from real agent incidents. Verifier off vs. on: [X/Y vs. X/Y caught], [n] false alarms on honest controls. For: platform and DevOps teams putting agents on operational work, where a confident false "done" costs more than a slow answer. Sandboxes like E2B contain actions but don't check claims. Eval tools score offline but don't stop a bad claim at runtime. Receipts does both, live. [Business model; next steps.] All LLM calls use Vultr Serverless Inference.

Jarvis

It is a very powerful ai chatbot which can run using your hand movements and run on various environments to perform your various tasks visually using 3D visualisation and remind you of anything anytime just using commands and many more to come.JARVIS is not just an AI assistant; it is an ambitious step toward building a futuristic digital intelligence inspired by the possibilities of Tony Stark’s legendary technology. Designed as an expanding ecosystem of intelligent environments, JARVIS combines conversational AI, futuristic interfaces, visual intelligence, scientific simulations, and centralized command capabilities into one powerful web-based platform. Its six environments—Main JARVIS, Velve, Terranexus, Command Centre, Vision Intelligence, and Ultron—represent different dimensions of an interconnected digital universe. From exploring scientific experiments and mechanical simulations to visual intelligence and advanced system interaction, every environment expands what a personal AI ecosystem can become. JARVIS aims to transform the way humans interact with technology, bringing multiple intelligent capabilities together through a unified interface. Its long-term vision reaches beyond answering questions toward helping users interact with digital tools, navigate complex information, and manage technological workflows. Built with the ambition to evolve continuously, JARVIS represents a bold vision of a world where AI is not merely something you talk to—it becomes the intelligent interface connecting you to your digital universe. JARVIS: One Intelligence. Multiple Environments. An Entire Digital Universe at Your Command.