Skip to main content
The SDK monorepo is not the whole public developer surface. If you are maintaining browser integrations, validating real product behavior, or following app-launch flows end to end, you will usually need the public protocol repo alongside this one, plus the published npm package surface: Use this page as the quick map for when it matters and where developers should start.

​
Public Developer Surfaces

SurfaceReach for it when you need to…
../elata-protocolunderstand app launches, local chain setup, deployment outputs, ABIs, XP claim tooling, or protocol behavior that SDK-integrated apps depend on
@elata-biosciences/* on npmsend developers to the public install path, package docs, and canonical package entrypoints

​
Published Packages

When docs need public links for developers, prefer the package pages:
Packagenpm page
@elata-biosciences/create-elata-demonpm page
@elata-biosciences/eeg-webnpm page
@elata-biosciences/eeg-web-blenpm page
@elata-biosciences/rppg-webnpm page
Lead with these package pages when the goal is helping developers install or evaluate the SDK without cloning repos.

​
Example Applications

These browser apps are maintained as separate repositories and deploy to GitHub Pages. They are useful when validating real-world integration patterns, UX for neurofeedback, or multi-package composition:
AppDemoSource
Breathwork TrainerGitHub Pageswkyleg/breathwork-trainer
NeuroFlightGitHub Pageswkyleg/neuroflight
Monkey Mind: Inner InvadersGitHub Pageswkyleg/monkey-mind
Neuro ChessGitHub Pageswkyleg/neuro-chess
Reaction TrainerGitHub Pageswkyleg/reaction-trainer
Consumer-facing documentation for developers lives on Example Applications.

​
elata-protocol

This repo owns the on-chain protocol surface: app launches, bonding curves, fee routing, staking, governance, XP, and deployment or config generation. For SDK developers, the important question is usually not “how do I contribute to the contracts?” but “what does an app developer need to know about the protocol their app will launch against or read from?” That makes this repo relevant when browser or WASM work intersects with:
  • contract ABI changes that downstream apps consume
  • local environments that need deployed protocol addresses
  • XP claim and Merkle workflows
  • app-launch lifecycle assumptions reflected in docs, demos, or SDK examples
  • launch, staking, fee, or governance concepts that developers need to understand to build on the ecosystem correctly

​
Start Here

NeedStart with
Overview of protocol primitives and app-launch model../elata-protocol/README.md
Fast local chain setup../elata-protocol/QUICKSTART.md
App-launch lifecycle and developer assumptions../elata-protocol/docs/APP_LAUNCH_GUIDE.md
Contract math, fee routing, and protocol rules../elata-protocol/docs/PROTOCOL_SUMMARY.md
System design and contract relationships../elata-protocol/docs/ARCHITECTURE.md
Deeper local environment details../elata-protocol/docs/LOCAL_DEVELOPMENT.md

​
Common Developer Flows

cd ../elata-protocol
npm run local:up
npm run xp:generate
cat deployments/local.json

​
What SDK Developers Usually Need From It

  • npm run local:up brings up Anvil, deploys contracts, seeds test data, and produces the addresses and state that app developers need for local launch and integration testing.
  • docs/APP_LAUNCH_GUIDE.md is the best public place to understand what developers are actually launching into: app registration, token launch, vesting, graduation, and fee behavior.
  • docs/PROTOCOL_SUMMARY.md is the better source when SDK docs need to explain fee routing, launch parameters, or on-chain assumptions without copying logic into this repo.
  • If a developer report sounds like an SDK bug but only reproduces with real launches, fee routing, staking, or XP state, the protocol repo is usually the next place to verify assumptions.

​
Working Model

Use the repos together in this order when tracing developer-facing issues:
  1. Start in elata-bio-sdk for package APIs, docs, and browser-side behavior.
  2. Point developers to the published @elata-biosciences npm packages when the task is installation, evaluation, or package-level integration.
  3. Move to ../elata-protocol if the issue depends on contracts, addresses, launches, fee routing, staking, governance, or XP roots.

​
Keep The Default Path Clear

For consumer-facing docs, continue to lead with SDK packages and @elata-biosciences/create-elata-demo, ideally with links to the public npm package pages. The public protocol repo is supporting context for SDK and ecosystem developers, not the default onboarding path for SDK consumers.