Future Directions

This page collects longer-term directions. Other Concepts pages also describe planned capabilities where needed to explain a boundary, and mark those alongside the current implementation and deployment status.

These directions are not available as deployed protocol capabilities. A design proposal or local implementation does not establish that a user can use it.

Confidential compute

Confidentiality at rest is designed and not yet running — one key per dataset version, wrapped per grant and held custodially, with no deployed service releasing it (Access Control has its state). What is on this page is a further thing again, unaffected by that schedule: keeping data confidential while it is being used, which no custody arrangement addresses.

That gap is the interesting one. A consumer who is authorized to read a dataset holds the plaintext once they decrypt it, and nothing in the protocol constrains what happens next. Closing it means computing on data without the party doing the computing being able to see it.

Trusted execution environments are the direction we expect that to take: work runs inside a hardware-isolated enclave that can prove what code it is running, so a consumer can get a result without ever getting the inputs, and a data owner can verify which computation produced it.

Federated learning is the complementary shape for the case where data cannot move at all: training runs where the data already is, and only model updates travel. It suits contributors and institutions who can license the use of data without licensing a copy of it.

Both would change what a licence can mean — from "you may hold this data" to "you may compute this specific thing over it" — which is why they are a protocol question rather than an infrastructure one.

Market and licensing designs

Ownership exchange, usage-scoped licensing and delegated licensing authority have draft designs. They should be read as proposals, not as a deployed marketplace or a working metering and payment flow. Existing ERC-1155 transfers, royalty deposits and claims do not by themselves implement those products.

Earlier business and ecosystem pages were retired because they presented proposed mechanisms as available features. Their redirects lead to the current ownership, royalty and identity pages. Removing those pages did not mean that every underlying idea lacked a design.

Token utility directions

$XNY is a BEP-20 token on BNB Smart Chain and the protocol contracts run on Base. No deployed contract requires it, charges it, or grants anything in exchange for holding it — Token Utility sets out what is and is not there today, and why the two chains are the fact the rest follows from.

$XNY was stated as gas, as the currency a task launch deposit is posted in, as payment for metered access, and as the currency for listing and settlement on a dataset and ownership marketplace. None has an implementation, and they do not share one obstacle — a single answer about what stands in the way would be wrong about gas.

Deposits, metered access, and marketplace listing and settlement are the ones a contract could enforce. Each needs a contract that charges, meters or settles, and none is deployed: creating a campaign or task moves no tokens, the public API has one fixed rate limit rather than paid tiers, and ownership shares transfer freely with no exchange contract behind them. Once such a contract existed it would also need the token on that contract's chain, which means a bridged $XNY on Base or a protocol deployment on BNB Smart Chain. Neither exists.

$XNY as gas is a different thing and no bridge reaches it. Gas on Base is ETH and gas on BNB Smart Chain is BNB, as on any EVM chain; a token is gas only on a chain whose native token it is, and $XNY is native to none. A chain whose native token was $XNY would end that; nothing a bridge does would.

Governance is not on this list. What was stated was on-chain governance and a treasury, without saying what a vote would be weighted by or that $XNY would be the ballot. Token Utility records the present position: no contract holds a proposal, counts a vote or reads a stake weight, and there is no staking mechanism a weight could come from.

These were previously stated on a community roadmap page, which was retired: it committed to milestones across 2026–2028 at a level of detail the protocol could not stand behind, and its $XNY items were already described there as future work. They are kept here so the intentions remain on the record without a schedule attached to them.

Read all of this as directions, not as work in progress against a date.

Tokenomics distinguishes allocation intentions from governance and node incentives that are not running. Use each capability's stated implementation and deployment status when deciding what is available.