Team

Overview

Smart Engines is built by a dedicated team with deep expertise in blockchain technology, distributed systems, and enterprise software development.

Core Team

Leadership

Tomachi Anura - Founder & CTO

• Architect of SmartNode technology
• Designer of cross-chain burning mechanisms
• Expert in distributed systems and cryptography
• 10+ years software engineering experience

Topachi - Founder & COO

• Full-stack development lead
• Treasury management and operations
• Business development and partnerships
• Enterprise integration specialist

Engineering

Development Team

• Smart App developers
• Backend engineers
• Mobile development
• UI/UX design
• QA engineering

Community

Community Specialists

• Discord/Twitter moderation
• Developer support
• Community events
• Educational content

Treasury Control

The protocol treasury has no human guardians. Its accounts on XRPL and Hedera are native multi-signature accounts whose signers are the validators’ DKG keys, and its published rule is the only authority over it:

• Prevents unilateral fund access: a payment needs a threshold of validators
• Pays only protocol roles (network fees, and activating protocol accounts such as deposit accounts and the runner pool), within monthly per-asset caps and above a minimum balance
• Ensures operational transparency: the rule is published on Hedera HCS and every payment is on-chain
• Is not controlled by DAO vote

What each validator checks before it co-signs:

1. The payment’s destination is a protocol role it resolves from its own reads
2. The amount stays within that asset’s monthly cap
3. The balance stays above the minimum
4. Any other payment is refused

HSuite DUNA governance

Public draft

This section follows the HSuite DUNA Transitional Governance Roadmap, version 0.1, a public draft. Its structure, timelines and terms may change as the governance process moves forward. The source is hsuite.app/governance, with the full roadmap as a PDF. It does not replace the DUNA’s governing documents.

The HSuite DUNA, legally Project X Suite - Wyoming DUNA (a Wyoming decentralized unincorporated nonprofit association) and also called the HSuite DAO, is the legal and institutional structure for community coordination, education, ecosystem participation, Treasury stewardship, and the transition toward broader governance.

Three layers

HSuite DUNA

Legal and institutional: community coordination, education, ecosystem programs, Treasury stewardship and governance administration.

Governance model

Participation and decisions: the rules and processes for proposals, participation, voting, delegation, execution and accountability.

HSuite protocol

Network and products: the technical network, infrastructure, products and services that builders and applications use, Smart Engines included.

The DUNA is the entity; the governance model defines how that entity is governed. The DUNA does not replace the HSuite protocol, and administrative work the DUNA performs does not make its Board the permanent technical controller of the protocol. The protocol has its own on-chain governance, the protocol DAO, and the Board does not sign for the protocol treasury described above, which moves only under its published rule with a threshold of validator signatures.

The XRPL issuer

Governance of the HSUITE issuer on XRPL is designed to pass to the HSuite DUNA, so the issuer’s rules and any changes to them answer to the community. That is about who decides the rules, not who holds a key. The issuer stays an XRPL account with its master key disabled, which only a threshold of validators can sign for (TSS-controlled issuer), and nobody, the DUNA included, can freeze or claw back HSUITE. See also the HSUITE migration FAQ.

Principles

• No unilateral control. No individual Board member may approve or execute a Board decision alone.
• Documented authority. Roles, approvals, delegations and material decisions are recorded.
• Distributed approval. Board decisions need the established multi-member threshold.
• Conflict transparency. Actual, potential and perceived conflicts are disclosed and managed.
• Treasury stewardship. Resources support HSuite’s nonprofit and ecosystem purposes.
• Progressive participation. Board authority narrows as the governance model becomes operational.

Transitional Board

The Transitional Board moves HSuite from informal coordination toward a documented, auditable and participatory governance structure. It is a stewardship and transition body, not the permanent final governance authority of the ecosystem.

• Members: 9.
• Decision threshold: 5 of 9 affirmative votes, for ordinary Board decisions and Treasury authorizations, unless a governing document sets a stricter requirement.
• Conflicted matters: the 5 approvals must come from non-conflicted members.
• Transition target: March 31, 2027.

No signature, transaction or technical action replaces the underlying approval.

The Board’s mandate:

• Maintain an authority map
• Oversee mission-aligned Treasury stewardship
• Establish membership and voting rules
• Define proposal, approval, execution and reporting processes
• Maintain conflict-of-interest procedures
• Support community, education and ecosystem initiatives
• Prepare the handover to the broader governance model

Decision Log. Every material governance and Treasury decision is recorded with the matter considered, the date, the approvals received, any declared conflicts or abstentions, and the resulting action and its evidence. Public summaries keep decisions understandable while protecting keys, security procedures, confidential agreements and personal data.

Conflicts of interest

1. Disclose. The member discloses the conflict before deliberation or approval.
2. Record. The disclosure is recorded in the Decision Log.
3. Inform. The conflicted member may give factual information when asked.
4. Recuse. The conflicted member does not vote on the matter.
5. Approve. The five affirmative votes must come from non-conflicted members.

If five non-conflicted approvals are not available, the matter is deferred or submitted to an independent review process. This applies especially to related-party payments, grants, compensation, commercial arrangements, Treasury transactions, and decisions involving entities connected to a Board member.

Treasury stewardship

The DUNA’s Treasury is held and administered for mission-aligned purposes. It is not the personal property of Board members, token holders, contributors or service providers. It serves:

• protocol and ecosystem development;
• infrastructure and operational continuity;
• community education and engagement;
• grants and builder programs;
• security, audits and professional services;
• mission-consistent partnerships and initiatives.

Treasury activity follows documented approvals, role separation, appropriate security controls, and an auditable record from decision to execution.

Membership and voting

Holding a token is not the same as being a member:

• Token holder: a person or entity that holds HSUITE.
• Member: a participant who meets the eligibility and validation requirements set by the DUNA’s governing rules.
• Voting participant: an eligible member authorized to vote on a specific decision under the applicable voting and record-date rules.

Holding HSUITE does not, by itself, create legal membership, voting rights, profit or dividend rights, or a claim on Treasury assets. The membership framework will define eligibility, validation, participation rights, record dates, dispute procedures, and how token-based participation relates to legal membership.

Limits on Board authority

The Transitional Board must not:

• become a permanent, unelected control layer;
• let a single member control decisions or Treasury actions;
• override the governance model after authority has been transferred;
• create undocumented economic rights or claims against the Treasury;
• use resources for purposes that are not mission-aligned or are undisclosed;
• represent HSuite governance as fully decentralized before the relevant processes are operational.

Transition roadmap

Target: March 31, 2027.

1. Governance foundation (current). Formally confirm the nine-member Board; record responsibilities and conflict disclosures; maintain the authority map and Decision Log; operate the 5-of-9 approval process.
2. Participation framework. Publish membership and voting eligibility rules; establish participant validation; define the proposal, discussion, voting and delegation processes; implement record-date or snapshot procedures where applicable.
3. Operational governance. Activate the initial governance workflow; connect approvals to execution and evidence; publish community-facing governance reporting; review Board authority and delegations.
4. Handover or sunset, by March 31, 2027. A transition assessment recommends one of: sunset the Transitional Board; narrow its remaining responsibilities; transfer its responsibilities to the operational governance model; or propose a limited extension with a defined scope, justification and end date. Any extension should be approved through a documented governance process.

The objective is not decentralization by declaration, but accountable governance demonstrated through rules, participation and verifiable operations.

Strategic Partnerships

Technology Partners

OM (One Management)

• Enterprise tokenization
• RWA and institutional DeFi
• Regulatory compliance expertise

Banqua

• EU-regulated financial services
• RWA tokenization platform
• Fixed-yield products ($BNQ)

Integration Partners

IKAD

• Government-scale DID solutions
• Malaysian education credentials
• Identity-as-a-Service

Ecospheres

• Environmental RWA tokenization
• Carbon credit management
• Sustainability tracking

Bludev

• Supply chain tokenization
• Food authenticity (BluDev)
• “Made in Italy” certification

SilkSuite DEX

• Decentralized exchange on Hedera
• Formed by the merger of the HSuite DEX and SilkSwap

Advisory Network

Smart Engines benefits from advisors across:

Blockchain Technology

Protocol design, security, scaling.

Enterprise Software

Integration, compliance, operations.

Finance

Tokenomics, treasury, institutional relationships.

Legal

Regulatory navigation, corporate structure.

Team Growth

Scaling Strategy

As the ecosystem expands, the team grows proportionally:

Per-Chain Additions:

• 1-2 chain-specific engineers
• 1 community manager (native speaker)
• 0.5 FTE support engineer

Cross-Functional Growth:

• Security specialists
• DevRel engineers
• Technical writers
• QA automation

Transparency Commitments

1. Public Salary Ranges: Team compensation disclosed
2. Role Announcements: New hires announced to community
3. Quarterly Reports: Team growth and allocation
4. Community AMA: Regular Q&A sessions

Contact & Community

Official Channels

• Website: hsuite.network
• Discord: Community hub for developers and users
• Twitter/X: Announcements and updates
• GitHub: github.com/HSuiteNetwork

Developer Resources

• Documentation: docs.hsuite.network
• SDK Reference: TypeScript SDK documentation
• API Playground: Interactive API testing (planned)
• Support: [email protected]

Business Inquiries

• Partnerships: [email protected]
• Enterprise: [email protected]
• Media: [email protected]

Careers

Smart Engines is always looking for talented individuals passionate about multi-chain infrastructure:

Open Positions (Typical)

• Blockchain Engineers (Rust, TypeScript)
• Full-Stack Developers
• DevOps / SRE
• Technical Writers
• Community Managers
• Business Development

Benefits

• Remote-first culture
• Competitive compensation
• Token allocation
• Flexible hours
• Conference sponsorship

---

Continue to ConclusionThe final summary.