Builder focused on blockchain infrastructure, post-quantum cryptography, AI systems, and developer tooling.
I use this GitHub profile as an engineering portfolio. The account contains 629 repositories spanning original products, research, hackathons, experiments, tutorials, mirrors, and upstream/reference material. Active projects are expected to show their real implementation status, reproducible verification commands, security boundaries, provenance, and deployment evidence. CI passing is engineering evidence—not a substitute for an independent security audit or production certification.
For a maintained-vs-reference project map and production criteria, see PORTFOLIO_STATUS.md.
| Project | Focus | Current public status |
|---|---|---|
| pq-rdl-blockchain | Post-quantum Layer-1 blockchain research/prototype, ML-DSA-65, BFT, node tooling | CI-verified operational devnet prototype; not represented as public mainnet |
| qton | TON testnet asset infrastructure, Jetton, PQC gateway research | TON testnet deployment evidence available; not represented as mainnet/market-proven |
| qmoosa-deep-tech-ai-quantum-platform | AI infrastructure, agentic systems, robotics/physical-AI experiments, PQC research | Experimental / hackathon-oriented engineering platform; production claims require independent validation |
| qmoosa-nexus-platform | Account-abstraction, policy-guardian and multi-chain agent research | Prototype; production/testnet claims require reproducible external evidence |
| solana-ai | Solana ecosystem growth and AI/blockchain project work | Early-stage project/research repository |
- Evidence before claims — distinguish prototype, simulation, testnet, production, and independently verified results.
- Fail closed — security-sensitive paths should default to denial when configuration or evidence is invalid.
- Reproducibility — prefer locked dependencies, documented commands, CI, tests, and machine-readable evidence.
- Security boundaries — do not treat a green build as a security audit.
- Operational readiness — production requires monitoring, rollback/recovery, secrets management, incident handling, and real deployment evidence.
- Responsible outreach — ecosystem growth and operator recruitment should be consent-aware and auditable.
Languages: TypeScript, JavaScript, Rust, Python, Solidity
Web / Runtime: Node.js, React, Vite, Express
Infrastructure: Docker, GitHub Actions, Linux, cloud deployment workflows
Blockchain: TON, Solana, EVM/Solidity, BFT/consensus research
Cryptography: NIST post-quantum cryptography research including ML-DSA / ML-KEM integration work
AI: multi-model application infrastructure, agentic workflows, local/edge inference experiments
The market-facing repositories are being standardized around:
- deterministic build/test commands
- dependency and vulnerability auditing
- CI quality gates
- clear README status sections
SECURITY.mdand responsible-disclosure guidance- environment templates without committed secrets
- production-safe defaults
- release/deployment evidence
- contributor documentation
- explicit separation of original projects from learning/fork/reference repositories
- provenance disclosures for imported or upstream-derived repositories
- a smaller, curated flagship surface instead of treating repository count as product count
The main blockchain implementation currently being hardened is:
Start with its README, node-operator guide, security policy, and verification commands. Treat repository status labels literally: prototype/devnet evidence does not imply a public mainnet or independently audited production network.
The best way to evaluate the work is through the repositories themselves: review the source, CI history, tests, security documentation, and deployment evidence. Open an issue or discussion in the relevant project for technical collaboration.
Build boldly. Verify the evidence. Ship only what the system can actually prove.