Tincta Autonomous Standard

A contract can live on a blockchain while its application still depends on a company to approve actions, supply essential data, run a private scheduler, or keep an image server online. Deployment alone does not establish autonomy.

TAS-1 proposes a common technical vocabulary and a set of testable requirements for systems that remain usable without their original publisher. Rules are fixed before participation. Authoritative state and essential content remain onchain. Every required lifecycle transition is available through a public transaction path, and participant rights can be exercised without an operator’s permission.

The standard applies to systems such as generative collections, collective publishing, and bounded coordination protocols. It does not prescribe a token, reward split, voting model, or business model. ERC-721 standardizes an NFT interface; TAS-1 addresses the architecture and continuing operation of a whole system. The two can be composed. [1]

If the publisher disappears, can participants still inspect the rules, advance the system, and exercise every right the contract promises?

Autonomy is the absence of indispensable privileged discretion. It does not mean the absence of people, transactions, infrastructure, or cost. Ethereum contracts execute in response to transactions and calls; a deadline does not wake a contract. Someone must submit an eligible transaction and pay gas. [2]

Immutable rules

No privileged party can replace the governing logic or rewrite rights already established under it.

Onchain completeness

The chain contains the state and data needed to validate actions and reconstruct the system’s essential outputs.

Permissionless progress

Any caller can perform required maintenance once its onchain conditions are met. Participant actions still require the appropriate ownership, balance, or authorization.

Recoverable failure

Unmet prerequisites lead to a predetermined safe outcome, rather than an indefinite wait for an administrator.

Here, 100% onchain describes the system’s authoritative rules, state, essential content, and enforcement. It does not describe the website or promise uninterrupted chain availability. The base chain’s consensus, censorship resistance, execution limits, and data availability remain assumptions.

In this proposal, MUST is a conformance requirement, SHOULD is a recommendation whose exceptions need justification, and MAY is optional. A claim must identify this exact revision and the deployed system it covers.

TAS-01 A conformance claim MUST cover the complete authority-bearing contract graph, including factories, registries, renderers, libraries, vaults, and dependency indirection.

An immutable entry point is insufficient if it delegates to replaceable code, reads an editable registry, or trusts an administrator-controlled verifier. The boundary follows authority and dependencies, not branding or repository folders.

Every dependency MUST disclose its address or deterministic derivation, chain, code identity, role, and any control plane. An address plus a runtime code hash alone does not establish immutability: proxy storage, initialization, delegate calls, and transitive authority also require inspection.

TAS-02 The governing graph MUST be initialized and irreversibly sealed before accepting participation or custody under a TAS-1 claim.

Sealing removes upgrade, arbitrary execution, discretionary pause, mutable renderer, and privileged rule-replacement paths. A timelock merely delays an upgrade; a multisig distributes authority. Neither makes that authority disappear. Renouncing one owner role is insufficient if another path can change the rules.

Immutable rules can still govern changing state. Participants MAY vote, transfer rights, or select parameters inside a domain fixed by the code. The option set, eligibility rule, snapshot, quorum, tie handling, default outcome, deadline, and effect of the result MUST be specified onchain. Before funds become committed to an instance, its applicable economic terms MUST be frozen.

Future instances MAY have different terms within that fixed domain. New software versions require new deployments and explicit opt-in. Migration cannot silently replace the logic securing existing positions or carry away their assets.

TAS-03 Every reachable nonterminal state MUST define its valid actions, guards, deadlines, and a finite path to completion or a safe exit under the declared chain and caller assumptions.

Model execution as S′ = δ(S, action, chain context). The same state, input, and chain context must produce the same result. Invalid actions revert without changing state. Events describe transitions; contract state determines whether an action is currently valid.

Boundary semantics MUST be exact: for example, admission is valid while block.timestamp < closeAt, and closing is valid at or after closeAt. A browser clock cannot establish either condition. Timestamp use must tolerate the timing and ordering properties of the selected chain.

Progress functions MUST tolerate competing callers. A stale call either does nothing safely or reverts; it cannot pay twice, duplicate a transition, or overwrite a completed result. Iterative work needs bounded batches, a durable cursor, a finite work set, and a measurable decrease in remaining work. Required settlement must not loop over an unbounded participant list.

TAS-04 Required progress MUST NOT depend on a publisher-only key, private scheduler, discretionary signature, or exclusive relayer.

Automation is a convenience layer. A keeper observes state and submits the same call that anyone else can submit. If it stops, another account can continue. User-authorized actions remain available directly or through a nonexclusive submission path; arbitrary callers do not gain the right to spend another user’s assets.

Permission to call is only one part of liveness. Implementations MUST state who can pay for progress, the maximum work per call, and what happens when operating reserves are exhausted. They SHOULD provide a bounded execution incentive where progress benefits users who may no longer be online. No incentive can guarantee execution at every future gas price.

Fees or bounties MUST be funded separately from protected liabilities, paid only for verified progress, and bounded against replay, fragmentation, and self-dealing. If continued operation becomes uneconomic, the precommitted safe-exit path must remain available without fresh publisher funding.

The liveness claim is conditional: the chain continues, valid transactions can be included, and at least one willing caller can fund the required calls. Autonomy removes the publisher’s veto; it cannot remove these conditions.

TAS-05 Essential data and outputs MUST be reconstructible from persistent onchain state or code, without a required external server, gateway, secret, or unpublished file.

For an NFT, ownership alone is insufficient. A fully onchain implementation returns complete metadata and media, or a complete deterministic recipe whose renderer and inputs are also onchain. An image URL, IPFS reference, or content hash is a reference or integrity commitment, not the underlying bytes. A hash cannot restore unavailable content.

SVG or other generated output MUST have no essential remote fonts, scripts, images, or mutable base URI. Compressed bytes are acceptable if the decoding rules and all inputs remain available. Immutable shared data contracts are acceptable when they are inside the verified dependency graph.

Critical execution data MUST be directly readable by contracts. Events can support indexing and historical inspection, but are not a substitute for state needed by a later transition. A Merkle root alone is also insufficient when users cannot reconstruct their own proofs from available data. Temporary blob availability does not satisfy permanent content storage.

Permanent identity and evolving status SHOULD be distinct. A token may keep fixed identifying traits while separate state records current rights or lifecycle results. If its appearance evolves, the permitted evolution, renderer, and inputs must already be governed by the sealed rules.

TAS-06 Every asset-moving transition MUST preserve solvency, authorization, and single-use claims in the asset’s native integer units.

Liabilities include all obligations that can coexist under the current state: refunds, vested claims, escrow, and committed operating reserves. Mutually exclusive settlement branches require a documented accounting model; the implementation must reserve enough for every still-reachable branch. Unsolicited transfers cannot be mistaken for participation or create claim rights.

Use exact integer arithmetic. Specify the rounding direction, residual dust destination, zero-participant behavior, and bounds on every multiplication and division. A treasury entitlement can be fixed in the rules, but its withdrawal cannot consume participant reserves.

Claims SHOULD use individual pull payments. Update the entitlement before transferring control, apply reentrancy protection where needed, and ensure one recipient’s failure cannot block others. If a transfer fails, the claim remains recoverable. If ownership conveys a claim, define precisely when ownership is checked and how transfers affect entitlement.

Asset assumptions are part of conformance. A pausable, upgradeable, rebasing, or fee-charging token can invalidate an otherwise sound accounting model. Strict conformance cannot hide this authority outside the boundary. Immutable contracts are still vulnerable to implementation bugs; ordinary security review remains necessary. [3]

TAS-07 Every external input MUST disclose both its integrity assumptions and its availability assumptions. Verifying an input onchain does not make its production onchain.

Strict TAS-1 conformance excludes indispensable offchain data authorities. A system using an oracle or externally produced randomness must identify that extension and cannot make an unqualified 100% onchain claim for the complete system. Even a correctly verified proof does not guarantee delivery. [4]

For a randomness extension, commit the participant set and request context before accepting entropy. Bind fulfillment to the correct chain, instance, and request. Accept one valid result; prohibit discretionary rerolls and selective cancellation after the outcome is known. A block timestamp, caller seed, or block value must not be described as unbiased randomness merely because it is onchain.

A failure policy MUST be fixed before participation. Specify the exact cutoff, the transaction that makes failure effective, how late responses are rejected, and which obligations survive. A timeout refund can introduce selective-abort incentives for a party able to withhold an unfavorable result. The threat model must acknowledge that tradeoff; a timeout alone does not solve fairness.

Likewise, an L2 deployment must disclose sequencer, upgrade, bridge, and data-availability assumptions. Cross-chain claims require an explicit trust and recovery model. A system’s strongest claim cannot exceed that of its weakest indispensable dependency.

TAS-08 A conforming root MUST expose the exact specification revision and an onchain manifest describing the system under assessment.

This draft proposes two functions for identifying the specification and its manifest. It complements application interfaces rather than replacing their mint, vote, transfer, or settlement functions. ERC-165 provides the interface-detection mechanism. [5]

// Proposed discovery surface — draft 0.1.0.
// An interface declaration, not a reference implementation.
pragma solidity ^0.8.24;

interface ITAS1 {
    function specification() external pure
        returns (bytes32);

    function manifestURI() external view
        returns (string memory);
}

For this revision, specification() returns keccak256(bytes("TAS-1:0.1.0")). The root also implements ERC-165 and reports support for type(ITAS1).interfaceId. These are proposed conventions, not an assigned ERC identifier or proof of correct behavior.

manifestURI() returns a self-contained data:application/json;base64, document. Its bytes MUST be immutable once the system is sealed. Runtime status belongs in separate getters. The manifest records:

• The specification revision, chain ID, root address, and deployment identity.
• The complete dependency graph, code identities, initialization constraints, and sealing conditions.
• State and action definitions, ABI signatures, guards, deadline semantics, and bounded progress paths.
• Asset assumptions, accounting invariants, rights, data reconstruction rules, and all declared extensions.

Self-reported data can lie. A verifier must independently compare the manifest with bytecode, storage, and actual behavior. To avoid a circular commitment, a contract need not embed a hash of itself or of the manifest containing that hash; deployment-specific runtime hashes belong in the external verification record.

The canonical manifest schema and executable conformance suite remain draft work. This interface is a reviewable starting point, not a finalized interoperability promise.

TAS-09 Conformance MUST be supported by a reproducible, deployment-specific evidence record. Interface support or source verification alone is insufficient.

Record the chain ID, root and dependency addresses, deployment transactions, finalized observation block and hash, runtime code hashes, compiler and optimizer settings, linked libraries, constructor inputs, and sealed storage state. Reproduce the build and verify the entire graph, including factory-created children and contracts not visible in the primary ABI.

Gas measurements MUST cover maximum supported bounds on the target chain. A finite algorithm can still be unusable if one required call exceeds the block gas limit. Source review, property testing, independent security assessment, and live deployment verification provide different evidence and must be reported separately.

No conformance statement should imply mathematical proof unless the relevant properties, model, assumptions, and proof artifacts are provided. Immutable bugs cannot be patched in place; review before sealing matters more, not less.

TAS-1 is proposed as a public technical standard, independent of any single Tincta application. This paper does not declare Tincta Rewards—or any deployed contract—conformant, and it does not modify existing contracts.

The next work is to stabilize the manifest schema, publish a minimal reference implementation, build adversarial conformance tests, and invite independent technical review. No completion date or external standards acceptance is implied. A future ERC submission would follow the Ethereum standards process and receive its own identifier through that process. [6]

Revisions must preserve their published history. Breaking semantics require a new specification revision and fresh deployment assessment; they cannot retroactively change the rules of systems already deployed. Compatibility means a precisely stated contract, not an automatically inherited label.

The objective is practical: make “autonomous” and “fully onchain” claims specific enough that an independent person can test them.

The requirements and TAS-1 identifier are proposed here by Tincta. These primary sources define the underlying interfaces, execution model, and security considerations.

1. ERC-721: Non-Fungible Token StandardToken ownership, transfers, and the optional metadata interface.
2. Ethereum: Anatomy of smart contractsExecution, functions, and transaction-triggered state changes.
3. Solidity: Security considerationsReentrancy, gas limits, randomness, and defensive design.
4. Ethereum: OraclesExternal data, verification, and oracle trust assumptions.
5. ERC-165: Standard Interface DetectionDiscovering supported interfaces through function selectors.
6. EIP-1: EIP Purpose and GuidelinesThe proposal lifecycle and Ethereum standards process.