Cortensor Portal V1 – Auth, API Keys, Usage, Free Plan & Payment Direction
Status: Draft Scope: User access model, API key behavior, usage visibility, free-plan logic, and early payment direction
1. Overview
Portal V1 needs a clean user/account layer on top of Cortensor’s backend infrastructure.
This includes:
login / authentication
API key issuance and management
usage and quota visibility
free-plan / rate-limit behavior
early payment direction
This document focuses on the product-side access model, not router internals.
2. Auth Direction
Auth is still being finalized, but the current direction is that Clerk looks stronger than Supabase Auth from an early product-surface point of view.
The current thinking is that Clerk appears attractive because it looks:
more configurable for product UX
cleaner for combining Web2 and Web3 login options
more specialized as an auth surface
This is not finalized yet, but it is the stronger current direction.
Practical framing
Portal V1 should choose an auth layer that supports:
simple signup/login
session handling
account identity
future team / org membership
potential Web2 + Web3 login compatibility
The auth choice should support a clean SaaS-like product experience from the first release.
3. API Key Product Model
API keys are one of the most important Portal V1 primitives.
Users should be able to:
create API keys
revoke API keys
view active keys
associate keys with account/project context
understand basic usage and limits per key
The Portal should treat API keys as Portal-native product keys, not as raw router credentials.
Desired key behavior
Portal V1 should support:
key issuance
key revocation
metadata association
usage tracking
rate-limit enforcement
future scope expansion
A clean UX should make Portal feel like a real hosted API product rather than an infra experiment.
4. Usage / Quota Visibility
Portal V1 should expose simple visibility into:
current usage
remaining free or paid allowance
reset windows
whether a key/account is limited or exhausted
This should be easy to understand from the user’s point of view.
Portal V1 does not need a highly sophisticated billing dashboard at launch, but it does need clear product messaging around:
what the current usage is
what the limits are
when they reset
what happens if the user exceeds them
5. Free Plan & Rate-Limit Direction
One of the clearest current V1 ideas is that the Portal should likely reuse the same general sliding-window / allocation-style logic already used in staking-as-payment.
This means Portal V1 likely should not invent an entirely separate mental model for free-plan limits.
Current direction
Portal free-plan / key-plan behavior will likely reuse the same ideas around:
window-based limits
request/task caps
reset windows
simple usage visibility
This gives Portal V1 a more grounded starting point and reduces system fragmentation.
6. Sliding-Window Mental Model
The likely free-plan / key-plan logic is:
usage is counted inside a rolling or defined window
each account/key has an allocation cap for that window
once the cap is reached:
requests are denied or degraded depending on policy
once the window resets:
the allowance becomes available again
This supports product behaviors like:
“X requests per window”
“Y tokens/tasks per window”
“reset every N hours / daily / monthly”
This also aligns well with:
anti-abuse controls
simple product messaging
straightforward user understanding
7. Why Reuse Existing Allocation Logic
Reusing the same sliding-window / allocation-style approach as other Cortensor systems is valuable because it:
avoids inventing an entirely separate Portal-specific limit model
gives the team a known implementation mental model
makes operations easier to reason about
helps keep free-plan and future paid-plan semantics coherent
Portal V1 should benefit from existing proven ideas where possible, especially for limit/accounting primitives.
8. Usage Data & Backend Thinking
Beyond auth, current scoping work also includes ongoing thinking around:
data models
request / usage flows
API key metadata
quotas / usage visibility
feasible implementation timeline
backend shape needed to support this cleanly
This is intentionally early blocker-finding work.
The goal is to discover early:
what durable data needs to exist
what request-time checks need to happen
where usage should be recorded
what minimum product semantics are required before implementation starts
9. Payment Direction
Payment is currently one of the least-settled areas of Portal V1.
The current direction is:
research first
likely start with stablecoin if the core Portal logic works well enough in V1
So payment is not yet a finalized part of the product spec, but the rough direction is:
Stablecoin is the most likely early payment primitive once the core Portal surface is proven out.
Why payment is later in confidence than auth/rate-limits
Compared to auth, API keys, model routing, and free-plan logic, payment is less settled because it depends on:
how coherent the first Portal usage model becomes
how durable metering ends up being
what actual user demand looks like
how much billing complexity V1 should carry
That means payment should remain an explicitly open scoping area until the product core is clearer.
10. Suggested V1 Rollout Shape
A reasonable rollout path for Portal access and monetization is:
V1
auth/login
API key create/revoke
free-plan style access with sliding-window limits
clear usage visibility
no overly complex billing surface yet
V1.x / V2
stablecoin payments or credits
stronger quota / paid allowance model
clearer billing history
better account-level metering and reporting
This keeps the first release simple while still pointing toward a monetizable product model.
11. Current Direction Summary
Portal V1 access and usage behavior is currently shaping up as:
auth/login first
API keys as a core product primitive
usage / quota visibility from the beginning
free-plan behavior likely reusing sliding-window allocation logic
stablecoin as the most likely first payment direction
billing/payment still less finalized than auth and routing
In one sentence:
Portal V1 should launch with simple login, API keys, and clear usage limits first, likely using a reused sliding-window free-plan model, while stablecoin payments remain the most likely but not-yet-finalized monetization direction.
Last updated