Cortensor

🧪 Reminder – Testnet Phase #4 Starts in ~48h Quick reminder that Testnet Phase #4 is expected to kick off in ~48 hours. 🔹 Ops note (today) We’ll be doing a one-time indexer/dashboard reset later today to prep for the Phase #4 cycle. If you’re participating, please keep an eye on updates and ensure your nodes stay stable through the transition window. #Cortensor #Testnet #Phase4 #NodeOps

🛠️ DevLog – Follow-Up on Portal Router Pool Direction A quick follow-up on the Portal-side router pool work. 🔹 Current status We’ll likely defer the fuller router pool work into the next phase, since that part becomes more infra/configuration-heavy than the other Portal V1 research items. 🔹 What’s already there At least in rough form, we’ve already put together the Nginx / reverse-proxy shape for the current set of 4 open-model groups. 🔹 Why defer the rest The remaining work is less about product flow now and more about: - infra configuration - pool grouping details - router-node connectivity - operational behavior under real traffic So it makes more sense to keep that as a next-phase item rather than forcing it into the current week. 🔹 Current takeaway So for now: - rough proxy/pool shape is there - deeper router-pool execution work is deferred - next phase is where we’ll likely pick this up more seriously #Cortensor #DevLog #Portal #RouterPool #Nginx #Infra

🧪 Testnet Phase #4 – Preview Recap (Kicks Off This Weekend) Phase #4 docs are now live: docs.cortensor.network/community-and-… Phase #4 is less about adding isolated features and more about tightening the full pipeline under realistic conditions - data → quality → routing, reliability under load, and Mainnet Lite readiness. 🔹 Kickoff note (this weekend) - We expect to kick off this weekend after a one-time indexer reset. - Most major research/design items are now done, so Phase #4 shifts from planning → execution. 🔹 Infra readiness (new RPC / server path is ready) - L2 testnet/mainnet RPC path and L3 testnet/pre-mainnet RPC path are now fully set up on new servers. - During Phase #4 we’ll test against this path more directly and then move toward switching over to the newer server setup. - L2 mainnet RPC is ready as well - Phase #4 will begin bringing up Mainnet Lite pieces on top (dashboard, indexer, oracle-related path). 🔹 Portal readiness (key path proven → gateway→router pool is next) - API key issuance + consumption experiments are working: issue key → consume key → verify via Unkey → record usage/state via Supabase. - Portal focus now shifts to the main product question: the Portal/API Gateway → managed router pool execution path (simple, stable, clean). 🔹 1) E2E Scope Lock (Phase #3 → Phase #4) - Finalize the full end-to-end test plan + order + pass/fail metrics (latency/throughput, recovery, drift, data integrity/offchain correctness) 🔹 2) Deeper Stress Testing (Data → Quality Path) - Longer-duration, higher-volume tests that hit real failure modes (churn, partial outages, RPC degradation, queue spikes) 🔹 3) Privacy + Offchain Storage Stress Tests (Optional / Heavier) - Heavier testing where enabled: encryption paths + offchain correctness + edge cases (timeouts, stale keys, partial writes) 🔹 4) SLA / Quality Signals – Deeper Validation (#3 Signals) - Validate SLA signals under churn/load (drift detection, reliability weighting vs uptime, disagreement/arbitration behavior) 🔹 5) Portal V1 (Design → Early Implementation) + Product Boundary - Portal becomes a real product layer: client → Portal backend → router pool → sessions - Scope: API keys, usage visibility, managed router pools, auth/rate limits, billing hooks + metering 🔹 6) PyClaw (Early Dev Release Track) - Move from design into early dev release: landing page + docs + initial runtime scaffolding aligned to router/session primitives 🔹 7) Mainnet Lite Infra Planning (Execution Readiness) - Servers/RPC/monitoring/ops + validate runbooks under realistic failure scenarios #Cortensor #Testnet #Phase4 #DevUpdate #Portal #PyClaw #InferenceQuality #AIInfra #DePIN #L3

🛠️ DevLog – Portal Focus Shifts Toward Gateway → Router Pool Path Given that the API key issuance and consumption experiment is now working in rough form, the Portal focus shifts a bit for the rest of this week. 🔹 Current result At this point, the Portal-side key path looks workable enough: - issue key - consume key - verify through Unkey - record Portal-side usage/state through Supabase 🔹 What’s next For the remaining week, the main Portal focus will be: - API / Portal Gateway - how that gateway should connect cleanly into router pools underneath 🔹 Why this matters Now that the auth/key/data side is clearer, the next bigger question is how the actual hosted request path should flow from the Portal Gateway into managed router pools in a way that stays simple, stable, and productized. 🔹 Current takeaway So the Portal work is narrowing down further: - auth flow looks okay - data sync looks okay - key creation + consumption looks okay - next main area is gateway → router pool execution shape #Cortensor #DevLog #Portal #Gateway #RouterPool #API

🛠️ DevLog – New RPC / Infra Path Is Ready for the Next Phase Both the L2 testnet/mainnet RPC path and the L3 testnet / pre-mainnet RPC path are now fully set up on the new servers. 🔹 Current status The new infra path is now ready enough that, during the next phase, we’ll start testing against it more directly and then move toward switching over to the newer server setup. 🔹 L2 mainnet side The L2 mainnet RPC is also ready now, so one of the next steps is to start bringing up the Mainnet Lite product-side pieces on top of it. 🔹 What’s next During the next phase, we’ll likely start setting up and testing: - Mainnet Lite dashboard - indexer - oracle-related path 🔹 Why this matters This is part of getting the newer infra path in place early enough that we can validate it properly before relying on it more heavily for the next stage. #Cortensor #DevLog #MainnetLite #L2 #L3 #Infra

🛠️ DevLog – Base RPC / Infra Setup Is Underway for Testnet + Mainnet Paths Over the last day, we’ve been setting up more of the base RPC and infra pieces needed for both testnet and mainnet-related paths. 🔹 Current progress So far, the RPC setup for Arbitrum mainnet and testnet has been re-established on new servers. 🔹 Current direction Right now, the path is still mostly L2-focused for the immediate setup and prep side. 🔹 L3 note The L3 side still needs more migration/testing work around infra setup and readiness, so that part is not treated as fully settled yet. 🔹 Mainnet Lite direction For now, the Mainnet Lite prep path is already underway. The likely first focus there is getting: - dashboard - indexer up first, then continuing into broader infra/testing from there. 🔹 What’s next More setup, migration checks, testing, and stress testing will continue over the next few days as these environments come together further. #Cortensor #DevLog #MainnetLite #L2 #L3 #Infra #RPC

🛠️ DevLog – Portal API Key Consumption Path Is Working in Rough Form Follow-up on the earlier Portal V1 research item around the API Gateway path. 🔹 Current result The current experiment now shows the basic consumption path is working in rough form: - Portal API key is created and recognized - request flows through the Portal-side API Gateway path - Unkey sees and verifies the key / request usage - Supabase records the Portal-side usage event data 🔹 Why this matters This means the full early data path is now working at a basic level: - API key - API Gateway - Unkey - Supabase So this is no longer only about key creation or metadata. We now have the first rough signal that the actual request/usage path can be tracked across the main Portal layers. 🔹 Current takeaway At least from this experiment, the API-key consumption path looks workable enough that it is no longer the main unknown. 🔹 What’s left The main remaining Portal research areas now are: - router pool setup - how the Portal API Gateway should use those router pools cleanly 🔹 Current direction So the Portal work is narrowing down: - auth + identity sync looks okay - key creation + consumption path looks okay - the next bigger area is how gateway-to-router-pool execution should be shaped underneath #Cortensor #DevLog #Portal #Gateway #Supabase #Unkey

🛠️ DevLog – Portal V1 Remaining Research Items Before Phase #4 Before Testnet Phase #4 starts, there are still a few remaining experimental / research items we want to touch on the Portal V1 side this week. 🔹 1. API Gateway path We want to make sure the Portal API Gateway can actually consume the API key path correctly and track it cleanly across both: - Unkey - Supabase data model The important part here is not only verification, but also confirming the request/usage path is recorded properly enough for quota, rate limits, and Portal-side usage visibility. 🔹 2. Router pool setup We also want to experiment more with the router-pool side: - configure router pools behind Nginx / reverse proxy - think through how to group them - decide how those router groups should connect cleanly into the Portal API Gateway path 🔹 Why this matters These are two of the more practical remaining Portal V1 areas before heavier execution starts: - gateway/key/usage path - router-pool / routing shape underneath 🔹 Reminder Also a reminder that we’ll be kicking off Testnet Phase #4 this weekend. #Cortensor #DevLog #Portal #Gateway #Nginx #Phase4

🛠️ DevLog – Portal Web App → Supabase → Unkey Flow Is Taking Shape We’ve now pushed the Portal V1 experiment a bit further on the key-management side. 🔹 Current progress At least for the current key-creation path, we were able to test the flow across: - Portal web app - Supabase data model / tables - Unkey key creation 🔹 What this means So far, the basic data flow is starting to make sense in practice: - user triggers key creation from the Portal surface - metadata / product-side entry gets written into the Portal-side data model - actual key creation happens through Unkey 🔹 Why this matters This is one of the more important early Portal checks, because it starts connecting: - user-facing product flow - durable Portal-side state - actual API-key infrastructure instead of keeping those as separate mock pieces only. 🔹 What’s still left The next important part is actually using the created key in the request path and confirming that the real usage/request data gets recorded properly. That part matters because it is what eventually enables: - rate limiting - quota tracking - usage visibility - durable metering on the Portal side 🔹 Current status Still a work in progress, but the basic data flow is there now and gives us a better read on how Portal web app, Supabase, and Unkey should fit together. 🔹 Current direction We’ll keep iterating from here, but this is a useful step forward for making the Portal-side key-management path more concrete. #Cortensor #DevLog #Portal #Supabase #Unkey #API

🛠️ DevLog – Portal V1 Remaining 2 Experimental Areas Now that the auth + data-model sync path looks reasonably clear, the 2 bigger Portal V1 areas left to experiment with are: 🔹 1. Portal Gateway This is the thin business/product layer in front of the infra path. The Portal Gateway should own: - receiving the customer-facing OpenAI-style request - verifying Portal API keys, likely through Unkey - checking quota / rate limits - mapping requested model aliases to the right router pool - recording usage / latency / status into Supabase - returning a stable product-facing response So the gateway is where the product logic lives: - auth semantics - quota semantics - model entitlement - request IDs - error shaping - usage writeback 🔹 2. Router Pool For V1, the router-pool side can likely stay simpler and more infra-oriented: - Nginx / reverse proxy in front - upstream groups per model or router pool - each upstream pointing to one or more managed router nodes - router nodes already configured with their own sessions/env - Nginx handling basic load balancing, stable internal URLs, TLS, and simple failover behavior So the rough V1 path becomes: Customer → Portal Gateway → Unkey verify / rate-limit → Supabase usage + product state → Nginx router pool → managed Cortensor router node 🔹 Why this split matters The important distinction is: - Nginx/router pool stays boring infra routing - Portal Gateway owns the product/business logic That is likely the cleaner V1 shape because it lets us iterate product rules without needing to touch router infra every time. 🔹 Current direction So for the rest of this week, these are the 2 main Portal areas we want to experiment with more directly after the auth/data-sync side. #Cortensor #DevLog #Portal #Gateway #Nginx #API

🛠️ DevLog – Portal Gateway Is Taking Shape One of the more important Portal V1 areas is the Portal Gateway layer, and the rough PoC for that is now there. 🔹 What Portal Gateway is Portal Gateway is the thin business/product layer that sits between customer API requests and managed Cortensor router pools. Its job is not to run inference itself. Its job is to make the hosted API behave like a real product layer in front of Cortensor infra. 🔹 What the gateway should own At a high level, the gateway should handle: - receiving customer-facing OpenAI-style requests - verifying Portal API keys, likely through Unkey - checking quota and rate-limit policy - mapping requested model aliases to the correct router pool - forwarding requests into the managed Cortensor router path - recording usage, latency, and request status into Supabase - returning a stable, product-facing response 🔹 Where the product logic lives This is the main place where Portal-specific business logic should live: - auth semantics - quota semantics - model entitlement - request IDs - error shaping - usage writeback That is an important boundary, because we do not want raw router nodes to become the place where all product logic gets mixed in. 🔹 How the supporting pieces fit The rough V1 split still looks like: - Portal web app for the user-facing product surface - Unkey for API key verification and rate-limit enforcement - Supabase for durable Portal-side product/account state - Portal Gateway for Cortensor-specific product logic - managed router pools for actual inference execution underneath So the gateway does not need to own low-level key validation from scratch, and router nodes do not need to own product/business-layer concerns. 🔹 Why this matters This keeps the first version simpler and cleaner: - users talk to Portal - Portal Gateway owns the product boundary - router nodes stay focused on inference execution That separation should make it easier to evolve product rules later without having to keep touching raw router infrastructure every time. 🔹 Current status The rough PoC is now there, and we’ll test it more later today to see what is still missing, awkward, or needs refinement. #Cortensor #DevLog #Portal #Gateway #API #ProductDesign

🛠️ DevLog – Portal V1 Remaining 2 Experimental Areas Now that the auth + data-model sync path looks reasonably clear, the 2 bigger Portal V1 areas left to experiment with are: 🔹 1. Portal Gateway This is the thin business/product layer in front of the infra path. The Portal Gateway should own: - receiving the customer-facing OpenAI-style request - verifying Portal API keys, likely through Unkey - checking quota / rate limits - mapping requested model aliases to the right router pool - recording usage / latency / status into Supabase - returning a stable product-facing response So the gateway is where the product logic lives: - auth semantics - quota semantics - model entitlement - request IDs - error shaping - usage writeback 🔹 2. Router Pool For V1, the router-pool side can likely stay simpler and more infra-oriented: - Nginx / reverse proxy in front - upstream groups per model or router pool - each upstream pointing to one or more managed router nodes - router nodes already configured with their own sessions/env - Nginx handling basic load balancing, stable internal URLs, TLS, and simple failover behavior So the rough V1 path becomes: Customer → Portal Gateway → Unkey verify / rate-limit → Supabase usage + product state → Nginx router pool → managed Cortensor router node 🔹 Why this split matters The important distinction is: - Nginx/router pool stays boring infra routing - Portal Gateway owns the product/business logic That is likely the cleaner V1 shape because it lets us iterate product rules without needing to touch router infra every time. 🔹 Current direction So for the rest of this week, these are the 2 main Portal areas we want to experiment with more directly after the auth/data-sync side. #Cortensor #DevLog #Portal #Gateway #Nginx #API

🧪 Testnet Phase #4 – Draft Update (Locking Soon) We’ve now pushed a fuller Phase #4 early draft, and at this point it’s increasingly close to what we expect to lock in as the final Phase #4 scope. Doc: docs.cortensor.network/community-and-… 🔹 Current status - Scope is being tightened now, but the major tracks are set (E2E scope lock, stress testing across data→quality→routing, Portal V1, PyClaw, Mainnet Lite readiness). - We expect Testnet Phase #4 to start within ~1 week. More updates soon as we finalize the start window and execution details. #Cortensor #Testnet #Phase4 #DevUpdate #AIInfra #DePIN

🛠️ DevLog – Portal V1 Auth + Data Sync Looks Good So Far A quick progress update on the Portal V1 side. 🔹 Current result At this point, the auth flow with Clerk + Portal-side data sync is looking good so far — including wallet login/sign-up paths in the current experiment. 🔹 Why this matters This is useful because it gives us more confidence that these two areas are not likely to be the main blockers once execution starts more seriously: - auth / session flow - durable Portal-side identity + data-model sync 🔹 Current takeaway So at least from the current experimental pass, the Clerk auth path and the Supabase-side data association look workable enough that we do not expect major blockers there during the actual execution phase. 🔹 What’s left this week For the rest of this week, the next Portal areas we want to experiment with more directly are: - API / Portal gateway - router pool shape and routing path 🔹 Current direction So the Portal work is starting to narrow down a bit: - auth + identity sync looks reasonably clear - now the bigger remaining questions move more toward gateway behavior and managed router-pool execution underneath #Cortensor #DevLog #Portal #Clerk #Supabase #API

🛠️ DevLog – Progress on Portal V1 Auth + Data Model Sync We’ve now pushed the Portal V1 auth/data-model experiment a bit further, and so far the Clerk ↔ Supabase linkage and sync path looks to be working correctly. 🔹 Current progress At least in this experimental setup, the main flow is holding up so far: - Clerk auth/session flow - Portal-side user/account identity - Supabase-side data model linkage - basic sync/association between auth identity and Portal records 🔹 Why this matters This is one of the more important early checks, because it helps confirm that the auth layer and durable product/account layer can connect cleanly instead of staying as separate mock pieces only. 🔹 Current status Still experimental for now, but the Clerk → Supabase sync path is working well enough that we can keep pushing on it and play around a bit more before moving on. 🔹 What’s next After a few more tests here, we’ll shift more attention to the remaining 2 Portal areas we called out earlier: - router pool - API / Portal gateway 🔹 Current takeaway So this is a useful step forward: auth plus Portal-side data association is now more concrete, and once we’re comfortable enough with this path, the next experimental focus moves deeper into routing and gateway behavior. #Cortensor #DevLog #Portal #Clerk #Supabase #API

🛠️ DevLog – Portal V1 Data Model Progress at Supabase We’ve now put together a simpler Portal V1 data model in Supabase as an early starting point. 🔹 Current status This is still a rough first pass for now, but it gives us a concrete product-side data layer to begin experimenting against instead of only thinking about the schema on paper. 🔹 What’s next From here, we’ll start linking / syncing this with the Clerk identity path and do some rough experiments later today around how those pieces should connect in practice. 🔹 Why this matters The goal here is to move one step beyond UI/auth-only thinking and start validating how Portal-side users, profiles, API keys, and usage-related state should actually live in the durable product layer. 🔹 After this Once this data-model experiment is a bit clearer, the next 2 bigger Portal areas to focus on are: - gateway - router pool configuration / routing shape 🔹 Current direction So this is still early and rough, but it is the first more concrete step toward making the Portal backend/product layer real underneath the mock UI. #Cortensor #DevLog #Portal #Supabase #API #ProductDesign

🛠️ DevLog – Portal V1 Auth Direction Is Clearer, Next Focus Is Data Model Sync The rough Clerk/auth path is now better understood, and we’ve at least checked the basic flow enough to get a clearer feel for how it should work. 🔹 Current status The main auth flow now feels clearer in rough form: - sign in / sign up - session handling - protected Portal routes - basic account-entry flow 🔹 What’s next Now that the rough auth direction is better understood, the next focus shifts more toward: - adding the Portal-side data model in Supabase - linking/syncing identity between Clerk and Portal-side records - shaping how account/user state should be stored and resolved in the product layer 🔹 Why this matters The auth surface alone is not enough. Portal still needs its own durable product/account layer underneath, so the next step is making sure identity from Clerk maps cleanly into Portal-side users, account state, and future product logic. #Cortensor #DevLog #Portal #Clerk #Supabase #ProductDesign

🛠️ DevLog – Portal V1 Clerk/Auth Mock Prototyping As part of this week’s Portal V1 scoping work, we’ve started rough mock/prototyping on the Clerk/auth side - one of the 4 areas we wanted to touch more directly. 🔹 Current status This is still rough experimentation, but so far it looks like the Clerk/auth path works at a basic level. 🔹 Why this matters The goal here is not final auth implementation yet. It is to touch the real code/integration path early enough to surface: - blockers - awkward integration points - auth/session flow gaps - anything that may become painful later if left only as a paper design 🔹 Current direction So this is part of the broader “mock/prototype each service area first” approach: - understand the real shape - reduce unknowns early - make later execution smoother 🔹 Current takeaway At least from this first pass, the Clerk/auth direction looks workable enough to keep moving, while also helping us surface the next layer of integration details we’ll need for Portal V1. #Cortensor #DevLog #Portal #Clerk #Auth #ProductDesign

🛠️ DevLog – Scoping + Mock Prototyping Across Portal V1 Areas As a follow-up to the 4 main Portal V1 areas we’re looking into, the goal is not just to think about them abstractly. We’ll more likely try to mock or prototype each area enough to understand how each service actually behaves in practice. 🔹 Current direction The idea is to do lighter prototyping across: - Supabase / data model - Unkey / API key management - Clerk / auth - reverse proxy / Nginx + router-node pool config 🔹 Why we’re doing this The main reason is simple: we want to understand each service better early, not only on paper. That helps us surface: - awkward integration points - missing assumptions - data-flow issues - auth/key/rate-limit edge cases - infra or routing surprises before actual implementation starts more seriously. 🔹 This week’s focus This will be part of this week’s focus as well, alongside the other broader planning items already in motion. 🔹 Current takeaway So this next step is less about “finalizing architecture in theory” and more about doing enough mock/prototype work that we do not get unnecessary surprises later when we begin executing Portal V1 more directly. #Cortensor #DevLog #Portal #Supabase #Unkey #Clerk

🛠️ DevLog – Mainnet Lite Infra Prep Is Starting Another Phase #4 planning area is Mainnet Lite infra readiness. 🔹 Current focus This track is mainly about: - servers - RPC - monitoring - ops - validating runbooks under more realistic failure scenarios 🔹 What’s happening now We’ll likely start shopping / ordering some of the infra and server pieces today as part of that preparation path. 🔹 Why this matters The goal is not immediate rollout, but to start the prep work early enough that we can: - set things up properly - test them more realistically - stress test them over the coming months - surface operational gaps before they become blockers later 🔹 Current direction So for now, this is still mainly a prep / planning phase for Mainnet Lite infra, but it is the beginning of getting the actual environment and operational readiness in place. #Cortensor #DevLog #MainnetLite #Infra #RPC #Ops