TXAI is the first pre-execution compliance layer for tokenized assets — built entirely on native TX primitives with zero custom smart contracts.
Tokenized real-world assets are one of the largest categories in crypto. Real estate, securities, private credit, commodities, and tokenized funds are arriving on-chain at every major blockchain. But every chain handles compliance the same way: after the fact. A non-compliant transfer settles, then someone tries to unwind it through a centralized authority, an off-chain oracle, or an application-level contract that can be bypassed.
That is not compliance. That is cleanup.
TXAI inverts the model. Compliance decisions happen before any tokens move. A live /validate API returns a deterministic PASS or FAIL in under 50 milliseconds, queries on-chain compliance state, and only allows transactions that satisfy the rules to settle. The result is real compliance, enforced at the protocol layer, with no off-chain trust assumptions.
This is only possible on TX. TX is the only L1 with native Smart Token clawback, mutable on-chain Smart NFTs, and the composability required to make pre-execution compliance practical without deploying any custom smart contracts.
For regular users and TX holders: this positions TX as the chain that captures the regulated tokenized-asset market — a market that no other chain can serve at the protocol level.
TXAI makes three claims that no other chain or protocol can match. Each is independently unprecedented. Together they form a category.
Every other tokenized-asset platform treats compliance as a cleanup problem. A non-compliant transfer settles, then a centralized authority, an off-chain oracle, or an application-level contract tries to unwind it. By that point the bad state is already on-chain. TXAI stops the transaction before it settles. The compliance decision is made first; the token movement is the consequence.
TXAI uses TX's native Smart NFTs in a way no one else has: as soulbound and mutable records of compliance state. Every relevant attribute — KYC status, jurisdiction, investor class, asset rules, enforcement history — lives on-chain in a Living Smart NFT that the issuer can update via a single transaction. Compliance is no longer "off-chain database synced to oracles." It is on-chain state, atomically queryable, deterministically enforced.
The entire compliance layer is built from native TX primitives — Smart Tokens, Smart NFTs, MsgUpdateData, and clawback. There is no Solidity contract, no CosmWasm contract, no custom virtual machine, and no smart-contract attack surface. What gets audited is the SDK and the protocol logic, not a sprawling contract codebase that needs re-auditing every time a rule changes.
These three claims compound. Pre-execution compliance is only practical because Living Smart NFTs make state queryable in a single read. Living Smart NFTs only work as a compliance state machine because TX has native primitives that don't require custom contracts. And the absence of custom contracts is what makes the whole stack auditable, deterministic, and cheap to operate.
The tokenized real-world asset market is exploding. BlackRock, Franklin Templeton, JPMorgan, and dozens of regional issuers are putting securities, funds, real estate, and private credit on-chain. Every major blockchain wants this market. But all of them hit the same wall: no native compliance infrastructure.
The shared failure mode: compliance state and transaction execution are not atomically linked. Compliance decisions are made off-chain or after the fact, and the chain has no way to enforce them at the moment of the transfer.
This is not a small bug. It is the reason regulated finance has not moved on-chain at scale. No serious issuer will tokenize a regulated asset onto a chain where the protocol cannot enforce who can hold it, who can sell it, and where it can move.
TXAI was built specifically to close this gap.
The Compliance Execution Layer (CEL) is the heart of TXAI. It is a live HTTP service that exposes a single primary endpoint:
POST /validateA caller submits a proposed transaction — sender, recipient, asset, amount, and any context — and CEL returns a deterministic PASS or FAIL decision in under 50 milliseconds, with the full reasoning attached. If PASS, the transaction can settle. If FAIL, the caller knows exactly which rule was violated and why.
An oracle pushes data on-chain and hopes a contract uses it correctly. CEL does the opposite: it reads on-chain state and returns a decision before any transaction is allowed to execute. There is no trust gap between "oracle says X" and "contract enforces X" — the decision and the enforcement are atomically linked because the issuer's Smart Token transfer is gated on a successful validate call.
The same architecture means CEL can be wrapped, mirrored, or run by anyone. Multiple operators can run the CEL service against the same on-chain state and get identical decisions. There is no "the" CEL — it is a deterministic function of the chain state.
Compliance state has historically lived in databases. TXAI puts it on-chain as a set of Living Smart NFTs: soulbound (non-transferable), mutable (the issuer can update fields via MsgUpdateData), and atomically queryable. Every compliance attribute that matters is one of these NFTs.
| Class | Owner | Purpose |
|---|---|---|
| KYC NFT | End user (soulbound) | Identity proofs, jurisdiction, investor class, KYC status |
| Asset NFT | Issuer | Per-asset rules, transfer restrictions, holding periods, eligibility |
| Provider Trust NFT | Provider | Approved KYC providers, trust levels, approval status |
| Rules NFT | Issuer or DAO | The active compliance rule set itself, versioned on-chain |
| Enforcement Log NFT | Issuer | Append-only record of every PASS/FAIL decision, on-chain audit trail |
Each schema is fully typed, versioned, and unit-tested. Every field has a defined index, an immutability flag (some fields like KYC issue date can never change after first write), and a validator. 206 of 206 unit tests pass across all five schemas.
Most NFTs are static — once minted, the metadata never changes. Living Smart NFTs are different. The issuer can update specific fields at any time using a single MsgUpdateData transaction. KYC status flips from pending to verified. Investor class upgrades from retail to accredited. Asset rules tighten in response to a regulatory change. All of these are on-chain state transitions, atomic, queryable, and instantly visible to CEL.
A KYC NFT that could be sold or transferred would be worthless as a compliance primitive. The whole point is that the NFT represents the identity of a specific wallet and cannot be detached from it. Soulbound means the NFT is permanently bound to its owner address and cannot be moved. Compliance state stays where it belongs.
Before TX's native Smart NFTs and MsgUpdateData, the only way to build a compliance state machine was a custom smart contract. Custom contracts mean custom audits, custom upgrade paths, custom security assumptions, and custom failure modes. Living Smart NFTs are native to the chain — the same audit that covers TX itself covers them. There is no separate contract codebase to maintain or compromise.
TXAI is delivered as three composable TypeScript SDKs. Each handles one layer of the compliance stack. They share types and on-chain primitives but are deployed and versioned independently.
The writer of compliance state. KYC providers, identity verifiers, and asset issuers use this SDK to mint and update Living Smart NFTs. It wraps the chain primitives for issuing KYC NFTs, attesting to identity, updating jurisdiction or investor class, and posting provider approvals. This is where compliance state enters the chain.
The enforcer. Asset issuers use this SDK to wrap Smart Token issuance with the rules that govern their asset. It binds an Asset NFT to a Smart Token, defines the transfer restrictions, and routes every proposed transfer through the CEL /validate call before allowing it to settle. If validate returns FAIL, the transfer is blocked at the protocol level. If validate returns PASS, the transfer proceeds and an Enforcement Log entry is written.
The reader and decider. This is the Compliance Execution Layer itself, packaged as an SDK so anyone can run it. It exposes the /validate HTTP service, the rule evaluator, and the on-chain state reader. Issuers can self-host CEL, mirror it across multiple operators for redundancy, or rely on a public CEL deployment.
Attestation writes the state. Issuer enforces against the state. Compliance reads the state and decides. Each SDK is independently testable and independently auditable, but all three speak the same on-chain primitives — Living Smart NFTs and Smart Tokens — so there is no impedance mismatch between layers.
A typical end-to-end flow:
/validate first.No custom smart contracts at any step. Every interaction is a native TX message.
Pre-execution compliance for tokenized assets requires three capabilities in one chain. No other production L1 has all three natively. Every other chain has to assemble them from smart contracts, off-chain services, and third-party integrations — which is exactly the problem TXAI exists to solve.
| Chain | Native Clawback | Mutable On-Chain NFTs | Pre-Execution Compliance Possible? |
|---|---|---|---|
| Ethereum | No | No (custom contracts only) | No — requires custom Solidity, post-execution unwinds |
| Solana | No | No (Metaplex extensions help, not native) | No — application-level enforcement only |
| Polygon / Arbitrum / Avalanche | No | No | No — same model as Ethereum |
| Cosmos chains (generic) | No | No | No — would require custom CosmWasm |
| Aptos / Sui | Partial (object model) | Partial | No — still requires custom Move logic |
| TX | Yes — native | Yes — native, via MsgUpdateData | Yes — natively, with no contract code |
Only TX is Yes / Yes / Yes. Every other row has at least one column where the capability has to be approximated through a custom contract — which reintroduces the exact attack surface, audit burden, and trust assumptions that pre-execution compliance is supposed to eliminate.
This is not a marketing claim. It is the reason TXAI is buildable on TX and not buildable anywhere else. The category is defined by the chain that can host it.
The compliance layer is built on TX's native Smart Token features. The most important of these for TXAI are clawback, freezing, whitelisting, and burn. Each is a single flag on the token at issuance — no separate contract, no application-level workaround.
Pre-execution compliance is the first line of defense. CEL blocks non-compliant transfers before they settle. But no system is perfect, and no pre-check can anticipate every edge case. Clawback is the safety net: if a transfer slips past the pre-check (a stale Living NFT, a race condition, an oracle delay), the issuer can recover the tokens using MsgClawback. The compliance system thus has two layers — block first, recover second — and both are native protocol features, not application logic.
A common concern with clawback is centralization. The answer is structural: every asset issuer controls clawback over their own token, and only their own token. A real estate company that issues a property token on TX has clawback authority over that token — not Solomente Labs, not TXAI, not a third party. The more assets tokenized on TX, the more enforcement authorities exist, each governing their own domain.
TXAI is the protocol layer — the rails, not the bank. It provides the SDKs, the schemas, and the validation engine. Each issuer brings their own enforcement through their own Smart Token.
Smart Tokens also support whitelist limits (an issuer can cap the maximum balance for any address) and freeze (an issuer can suspend transfers for a specific account). Both are native flags, both are issuer-controlled, and both compose cleanly with the Living NFT compliance state. A frozen account can still hold tokens; it just can't move them until the issuer unfreezes — useful for sanctions-list responses, dispute holds, and regulator-mandated stays.
Every TXAI transaction carries a structured memo that encodes the operation context. The format is simple and deterministic:
TXAI:v1:<action>:<params-json>Memos let any TXAI-aware caller submit a transaction whose intent is self-describing. CEL parses the memo to understand what is being requested, what the delivery terms are, and what proof is expected.
Compliance validation request:
TXAI:v1:validate:{"asset":"REIT-001","sender":"core1...","recipient":"core1...","amount":"1000"}Price oracle request:
TXAI:v1:price-oracle:{"pairs":["TX/USD"],"tolerance":"1.25%","minSources":2}Delivery proof:
TXAI:v1:delivery-proof:{"ref":"<payment-tx-hash>","proof":"<sha256>","action":"price-oracle"}v1 prefix lets the protocol evolve without breaking existing integrations.Memos are the connective tissue between the on-chain primitives and the application-level intent. The same memo format is used for compliance validation, agent payments, oracle requests, and delivery proofs. One protocol, one format, every layer.
The same primitives that make pre-execution compliance possible also make autonomous agent payments practical. The agent runtime is not a separate product — it is the same SDK pointed at a different problem. We mention it here because it is operationally proven and produces additional on-chain volume.
An autonomous agent (a price oracle, a data aggregator, a compute provider) listens for incoming TXAI token payments, parses the memo to understand the request, executes the work, and posts a delivery proof on-chain. If the agent fails to deliver within the agreed window, the issuer can clawback the payment using the same Smart Token primitive that backs the compliance layer.
Every agent has a provable trust score computed entirely from on-chain data: completion rate, staked collateral, penalty history, transaction volume, longevity, and counterparty diversity. Bad agents get clawed back, their score drops, and they get blocked from the marketplace. Good agents accumulate volume, stake more, and earn premium pricing. Trust is a function of behavior, not marketing.
Agents are how compliance scales. A human-only compliance team can review hundreds of transactions per day. An autonomous agent runtime can handle millions. The Compliance Execution Layer is the brain; agents are the hands. Every PASS/FAIL decision can be made instantly, every Enforcement Log entry can be written automatically, every state update can be propagated without human intervention.
The agent runtime is what proves the primitives compose. If we can run pay-for-data agents on Smart Tokens with clawback enforcement, we can run pay-for-compliance agents on the same primitives. The runtime is operational today, with a 2-agent payment demo and a 3-agent supply chain demo running live on TX testnet — both verifiable on the public block explorer.
TXAI was built for tokenized real-world assets first. Every other use case is a bonus that falls out of the same primitives.
A real estate platform tokenizes 50 properties as Smart Tokens on TX, each bound to an Asset NFT with the relevant transfer restrictions (jurisdiction limits, accredited-investor gates, holding periods). Each prospective buyer holds a KYC NFT issued by an approved provider. When a buyer attempts to purchase a token, the issuer's transfer flow calls CEL /validate first. CEL reads the buyer's KYC NFT, the property's Asset NFT rules, and the active Rules NFT, and returns PASS or FAIL in under 50ms. Non-compliant transfers never settle.
A broker-dealer issues tokenized private placements on TX under Reg D 506(c). The Asset NFT encodes the holding period, the accredited-investor requirement, and the maximum number of holders. The KYC NFT for each user encodes investor class and jurisdiction. CEL enforces all of it atomically — the Reg D rules are not "best effort by an off-chain compliance team," they are deterministic conditions on the transfer itself.
Every PASS and FAIL decision writes an Enforcement Log NFT entry. A regulator examining the issuer can query the on-chain log directly and see every compliance decision the issuer made, the rule that triggered, and the on-chain state at the moment of the decision. No off-chain logs to subpoena, no spreadsheets to verify, no auditor sampling — it's all on-chain and immutable.
The same primitives also support autonomous agent-to-agent commerce. A trading agent pays an oracle agent for live price data with clawback on stale or inaccurate feeds. A content agent hires a fact-checking agent and an image generation agent, both settled atomically with delivery proofs. These are operational demos today, not aspirations — but they are the bonus surface, not the lead use case.
TXAI is delivered as three composable TypeScript SDKs (see §6) plus a small set of supporting components. Everything is open by design: the schemas are public, the rule evaluator is documented, the memo format is versioned, and any developer can integrate without permission.
MsgUpdateData and provides typed schemas./validate HTTP endpoint, rule evaluator, on-chain state reader, and Enforcement Log writer.// 1. Issuer wraps the Smart Token with TXAI compliance
const asset = await issuer.issueAsset({
symbol: "REIT-001",
rules: assetRulesNftId,
initialSupply: "1000000",
});
// 2. Buyer attempts to receive — CEL validates first
const decision = await compliance.validate({
asset: asset.denom,
sender: issuerAddr,
recipient: buyerAddr,
amount: "1000",
});
// 3. Only if PASS does the transfer go through
if (decision.result === "PASS") {
await issuer.transfer({ asset, to: buyerAddr, amount: "1000" });
} else {
// FAIL — caller knows exactly which rule blocked it
console.log("Blocked:", decision.reason);
}The protocol is open by design. The schemas are public. The memo format is versioned. The rule evaluator is documented. Any developer, any issuer, any chain integration can plug in without permission. TXAI wins by being the most useful standard, not by locking anyone in.
/validate API — sub-50ms deterministic decisions@solomente/txai-attestation, @solomente/txai-issuer, @solomente/txai-complianceBuilding credible infrastructure requires acknowledging risks honestly. Here are the key risks and how TXAI addresses them:
CEL is deterministic, but a bug in the rule evaluator could allow a non-compliant transfer to pass. Mitigation: PASS/FAIL decisions are deterministic functions of on-chain state, so failures are bug-fixable rather than data-corrupted; clawback provides a post-execution backstop; the 206 unit tests cover every schema field; a third-party security review is funded by the community proposal.
If a KYC NFT is updated (e.g., a user's investor class is downgraded) but a transfer is in flight, there is a small window where the decision could be made against stale state. Mitigation: CEL queries the state at the moment of validation, not from a cache; transfer windows are short; clawback recovers any post-decision drift.
Each issuer controls clawback over their own asset. If an issuer's key is compromised, an attacker could mint, freeze, or clawback at will. Mitigation: issuers are strongly encouraged to use multi-sig or hardware-backed keys; the SDK supports both; this is the same risk model as any token issuer on any chain.
The operational agent runtime depends on AI models that can produce nonsensical results, fabricate data, or drift from instructions. Mitigation: delivery proof verification (SHA-256 hashes), multi-source consensus, tolerance thresholds, automatic clawback on failed delivery, and trust score penalties. The protocol does not trust agents — it verifies them.
Pre-execution compliance is a new category. Adoption depends on issuer education, partner integrations, and a credible track record. Mitigation: live working demos, public schemas, open SDK, and first-customer partnerships with regulated tokenization platforms.
Clawback is powerful — and powerful mechanisms attract scrutiny. Each asset issuer only has clawback authority over their own token; TXAI does not hold centralized enforcement power over other assets. For the TXAI token itself, mitigations include time-locked delivery windows, on-chain proof verification, trust score penalties for clawback abuse, and (for complex disputes) jury-based resolution.
Tokenized securities are inevitable. Every major financial institution is moving on-chain. But every chain they consider has the same blind spot: no native compliance. TXAI exists because that gap is the largest unsolved problem in regulated on-chain finance — and because TX is the only L1 with the native primitives to solve it.
TX does not need to compete with Ethereum for DeFi or with Solana for speed. It becomes the chain that other chains trust for regulated transactions. Pre-execution compliance is the moat. Living Smart NFTs are the state machine. Zero custom contracts is the audit story. Together they form a category that only one chain in the world can host.