{"id":"a748d9bd-49c9-4ab1-8e94-18cee3243dbf","arxiv_id":"2412.19256","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":0,"one_line_summary":"Swarm Contract replaces on-chain smart contract logic with TEE-resident agent consensus that settles through a multi-signature wallet.","lead":"This paper proposes Swarm Contract, a mechanism where off-chain software agents running in trusted hardware collectively sign a multi-sig wallet to execute tasks like an NFT auction. It is a conceptual design without implementation, formal security proof, or comparison to existing TEE-blockchain systems, so the claim that it is trust-minimized rests on unvalidated assumptions.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Trust minimization is not established: the on-chain multi-sig step proves only that enough enclave keys signed, not that the signed off-chain result is correct; Section 6.2 explicitly assumes no majority compromise.","rationale":"I read the paper's strongest claim as saying that off-chain multi-agent consensus plus an on-chain multi-sig wallet is a trust-minimized replacement for a monolithic contract. That claim is load-bearing but not derived. The reader's weakest assumption, that TEEs are trustworthy and that no majority is compromised, is indeed acknowledged in Section 6.2. However, my concern is slightly broader: even if all TEEs are trustworthy and no majority is compromised, the protocol still does not provide a way for an external observer to verify that the signed transaction reflects the correct off-chain computation. The consensus described in Sections 4.1 and 5.3 is internal to the agent cluster; it produces no publicly checkable evidence. The on-chain multi-sig wallet only proves that threshold signatures were collected, not that the signed state is the result of the auction rules. Therefore the trust anchor is an unquantified assumption about enclave compromise and operator honesty, not a property established by the architecture. The paper itself concedes in Section 6.1 that a colluding majority can produce fraudulent results. With no implementation, no formal proof, and no parameter count, the central assertion is not substantiated. The reader's REJECT is justified, and my read does not change that verdict. A concrete adversarial simulation would settle whether the design can be made verifiable or whether the trust-minimization claim must be weakened to a federated-TEE trust model.","tokens_in":4221,"tokens_out":5229,"duration_ms":55470,"concrete_test":"Deploy a 3-agent implementation of the Section 4.1 NFT auction on a testnet. Have two of the three agents collude to alter the sorted bid list and sign a transaction that mints to the wrong top-10,000 and refunds incorrectly. Then run an independent verifier that reads only on-chain data and the multi-sig wallet. If the verifier cannot detect the deviation without trusting the enclaves, the trust-minimization claim fails as stated; if the design includes an attestation or state-root proof that lets the verifier detect it, that mechanism must be added to the paper and tested.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that off-chain multi-agent consensus plus an on-chain multi-sig wallet achieves 'trust minimization' (Section 3.2). But the architecture makes the off-chain computation unverifiable on-chain: the final transaction signs outputs (mint/refund), and no attestation proof, state root, or consensus transcript is posted. In Section 4.1, cross-validation is only agents comparing merkle roots; in Section 5.3, agents simply sign if results are consistent. An external observer therefore cannot distinguish a correct settlement from one produced by a colluding threshold of enclaves. Section 6.1 concedes that 'if more than the threshold (e.g., 2-of-3) collude, they could produce fraudulent results,' and Section 6.2 lists 'adversaries cannot compromise a majority of enclaves simultaneously' as a trust assumption. Thus the only guards are TEE remote attestation and a statistical assumption about independent compromise, not a cryptographic consensus guarantee. In a conventional on-chain smart contract, correctness is enforced by executable code visible to all; here correctness is merely asserted by a small set of attested signers. Consequently, 'trust minimization' reduces to 'a majority of enclave operators are honest,' which is neither derived nor quantified. The on-chain multi-sig actually weakens auditability relative to the single on-chain contract it replaces.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces 'Swarm Contract,' a multi-agent mechanism in which several 'Sovereign Agents' running in trusted execution environments (TEEs) collectively execute off-chain logic and settle on-chain via a multi-signature wallet. The authors argue that this moves most logic off-chain while achieving 'trust minimization through multi-agent consensus.' The paper includes a minimal NFT auction example, a short technical implementation sketch, and a brief security/trust analysis. It does not provide a formal security model, proofs of liveness or safety, an implementation, or experimental evaluation.","tokens_in":4481,"tokens_out":3047,"duration_ms":31947,"significance":"The proposed architecture could, in principle, reduce on-chain costs and allow data-heavy dynamic workflows that are difficult to express in deterministic on-chain smart contracts. The paper clearly assembles known building blocks (TEEs, remote attestation, multi-sig wallets, threshold consensus) and states its assumptions explicitly, which is helpful for a conceptual proposal. However, the central claim of 'trust minimization' is not established: the mechanism does not make off-chain computation verifiable on-chain, and the security posture is explicitly predicated on the absence of majority enclave compromise. If the claim were revised to a more modest 'trust reduction under explicit TEE and majority-honesty assumptions,' the contribution would be incremental but not negligible as a position paper. As it stands, the significance is limited by the lack of formal analysis and the unsupported core assertion.","major_comments":[{"comment":"The central claim of 'trust minimization through multi-agent consensus' is not supported by the described mechanism. The on-chain multi-sig wallet only proves that a threshold of enclave keys signed the final transaction; it does nothing to verify that the off-chain computation (e.g., sorting bids, determining the clearing price) was correct. The paper does not post attestation proofs, state roots, or a consensus transcript on-chain. Consequently, an external observer cannot distinguish a correct settlement from one produced by a colluding threshold of enclaves. This gap is load-bearing because the paper's main contribution is the claim that trust is minimized.","section":"Abstract; §3.2"},{"comment":"The trust analysis reduces the security of the whole system to the assumption that 'adversaries cannot compromise a majority of enclaves simultaneously' (§6.2). Section 6.1 explicitly concedes that if more than the threshold colludes, they 'could produce fraudulent results.' This means the architecture's guarantee is not a cryptographic consensus guarantee but a statistical/operational assumption about TEE and operator independence. The paper neither quantifies this assumption nor compares it with the trust assumptions of a conventional on-chain contract. As written, 'trust minimization' is an assertion, not a derived property.","section":"§6.1, §6.2"},{"comment":"The consensus procedure described for small clusters is only a 'request-and-ack' scheme in which agents sign if their locally computed merkle roots match. The paper does not specify what happens when agents disagree, how the threshold (e.g., 2-of-3) interacts with conflicting results, or whether a temporary disagreement can cause liveness failure. The sentence 'For larger clusters, byzantine-fault-tolerant protocols (PBFT, Tendermint) may be employed' is not a protocol description; no concrete adaptation to the Swarm setting is given. Since the paper is about a consensus mechanism, this is a central technical gap.","section":"§5.3"},{"comment":"The paper reports no implementation, simulation, or tests. The auction workflow is described in high-level bullet steps, with no pseudocode, no data structures, no adversary model beyond a paragraph, and no measured gas costs or latency figures. Without any evaluation or at least a formal specification, the feasibility and scalability claims in §4.2 and §7 are unsupported. This is especially important because the stated motivation includes 'high-frequency operations' and 'large participant lists,' both of which require empirical or analytical backing.","section":"§4, §5"}],"minor_comments":[{"comment":"The references to Enigma and TEE-based computation are appropriate, but the paper does not clearly explain how Swarm Contract differs from prior TEE-plus-blockchain designs beyond executing multiple enclaves; an explicit comparison table or focused discussion would improve the positioning.","section":"§2.3"},{"comment":"The auction example assumes that the same address cannot submit multiple bids, but this is not stated. If multiple bids per address are allowed, the 'top 10,000 contributors' procedure needs a rule for aggregating contributions from the same address; otherwise the protocol is ambiguous.","section":"§4.1"},{"comment":"The figure is informative but could be improved by labeling the consensus step (e.g., 'check merkle roots') and by showing what data is signed by each agent before the multi-sig transaction is broadcast.","section":"Figure 1"}],"recommendation":"reject","confidential_remarks":"The paper is a short positional proposal with no formal security analysis, no implementation, and an unsupported core claim. The load-bearing issue is not an easily fixable local flaw: the architecture as described cannot provide the claimed 'trust minimization' because on-chain verification of off-chain correctness is absent. A revision would need to either substantially weaken the central claim or add a verifiable computation mechanism, which would change the paper's scope. Additionally, the novelty relative to existing TEE-blockchain and multi-sig work is not established. I therefore recommend rejection, though the paper could be reconsidered as a substantially revised position paper or workshop note."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things you should know. First, the architecture is coherent: TEE-resident agents, a small consensus step, and a multi-sig wallet on-chain is a reasonable pattern for moving complex logic off-chain. Second, the paper's central claim — that this yields 'trust minimization' — is not supported. What the design actually gives you is a majority-of-enclaves trust assumption, not the cryptographic guarantee a smart contract provides.\n\nWhat it does well: the problem statement is genuine; monolithic on-chain contracts are a poor fit for data-heavy, dynamic workflows. The auction example is easy to follow, and the threat model in Section 6 is honest, explicitly acknowledging majority collusion and TEE vulnerabilities. The paper also correctly points to Enigma and Tendermint as prior art, so it doesn't claim a blank slate.\n\nWhat is new: essentially the terminology. 'Sovereign Agents' and 'Swarm Contract' are label changes over the components already in the cited literature. There is no implementation, no data, no formal proof, and the auction workflow is a toy — it does not exercise any of the claimed generality.\n\nThe soft spots are in proportion to how soft they are. The big one is the trust-minimization claim, and the stress-test note is right: the on-chain multi-sig verifies only that a threshold of enclave keys signed, not that the off-chain result is correct. No attestation proof, state root, or consensus transcript is posted on-chain, so an external observer cannot distinguish a correct settlement from one produced by colluding enclaves. Section 6.2 explicitly assumes no majority compromise. That reduces 'trust minimization' to 'a majority of enclave operators are honest' — which is a meaningful trust assumption, not a minimization. This is not a minor gap; it is the load-bearing assertion of the paper. The paper would need to either post enough evidence on-chain for third-party verification or formally analyze the adversary necessary to break the claimed property.\n\nWho benefits: researchers working on off-chain decentralized computation might find this a useful sketch, or a foil for formalizing what trust minimization can mean in TEE-based settings. The writing is clear and the citations are appropriate. But as a research preprint it doesn't substantiate its main claim.\n\nRecommendation: desk reject for a mainstream venue. I would only consider sending it to peer review if the venue explicitly invites short position papers and the authors agree to present it as a proposal rather than a result. As it stands, the gap between the abstract's promise and the evidence is too wide.","headline":"A coherent design sketch with an honest threat model, but the 'trust minimization' claim is asserted not demonstrated — the real trust anchor is TEE attestation plus a no-majority-collusion assumption.","tokens_in":5006,"tokens_out":3575,"would_cite":false,"duration_ms":32375,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Swarm Contract replaces a monolithic on-chain smart contract with a cluster of TEE-resident agents that agree off-chain and settle through a single multi-signature wallet.","keywords":["Swarm Contract","multi-agent consensus","Trusted Execution Environment","multi-signature wallet","off-chain computation","Sovereign Agents","digital life forms","NFT auction"],"falsifier":"A concrete refutation would be a TEE exploit that lets an attacker extract a signing key or forge remote attestation, or an experiment in which two of three colluding enclaves produce and sign a false auction result without detection; either outcome would violate the stated trust assumptions and collapse the trust-minimization claim.","tokens_in":4011,"feed_emoji":"🐝","tokens_out":6934,"duration_ms":63454,"temperature":0.7,"pith_summary":"This paper introduces Swarm Contract, a coordination mechanism in which a group of autonomous software agents — called 'Sovereign Agents' or 'digital life forms' — runs a decentralized application's logic off-chain inside Trusted Execution Environments (TEEs). The agents jointly sign a single on-chain transaction through a multi-signature wallet only after reaching consensus, so a complex workflow such as an auction can be executed with a minimal on-chain footprint. The intended result is a 'trust-minimized' alternative to monolithic smart contracts: lower gas costs, flexibility for iterative or data-heavy logic, and the ability to process private or large off-chain data while still settling assets on-chain.","feed_headline":"A swarm of secure-hardware agents can replace a smart contract","feed_subtitle":"Off-chain agent consensus settles through one multi-signature wallet, cutting gas and unlocking data-heavy dApps.","key_machinery":"The load-bearing pair is the TEE enclave and the multi-signature wallet. Each Sovereign Agent holds its private key inside a Trusted Execution Environment — a secure processor area that isolates code and keys from the rest of the machine — so key isolation and remote attestation protect against single-agent compromise. An ordinary multi-signature wallet, with a threshold of m-of-n, is the only on-chain component, and it prevents any agent from finalizing a state change alone. The off-chain consensus step, for small clusters a request-and-ack protocol and for larger clusters a byzantine-fault-tolerant protocol, determines shared results (for example, a Merkle root of the sorted bids) before signatures are produced.","core_discovery":"The central claim is that a multi-agent 'contract' can reproduce the trust properties of a smart contract without putting the logic on-chain. Multiple independent agents run in TEEs, compute and agree on outcomes (for example, the clearing price and winners of a 10,000-NFT auction), and only then co-sign a transaction on a standard multi-signature wallet that mints or transfers tokens and issues refunds. Trust is minimized by requiring the agents to cross-validate results and by making final state changes impossible without the required signatures. The paper is explicit that this is not absolute trustlessness: it relies on TEE attestation and on the assumption that no adversary controls a threshold number of enclaves.","pith_inferences":["Testable extension: a direct head-to-head deployment of a three-enclave Swarm running a 10,000-bid auction against an equivalent on-chain contract would quantify the gas, latency, and liveness trade-offs.","The design assumes enclaves remain available; a crashed or unreachable enclave would stall settlement until replaced, so adding an agent-rotation or watchtower protocol is a natural follow-up.","Because the only on-chain component is a generic multi-sig wallet, the same swarm could settle several independent workflows in a single batched transaction, amortizing gas even further — something the paper leaves implicit."],"forward_implications":["An application such as the NFT auction would run with only one or a few on-chain transactions, so gas costs no longer scale with the number of bids.","Applications handling large, private, or off-chain data — DAO analytics, cross-chain state, machine-learning inputs — become compatible with trust-minimized settlement because the heavy computation happens inside enclaves.","The protocol can adapt or upgrade logic without redeploying a contract: the agents' code is updated off-chain, while the on-chain wallet stays fixed.","If a threshold majority of enclaves agrees, the on-chain wallet will execute their decision; the system is as strong as the weakest trusted component, which is the enclave layer."],"supporting_citations":[{"why":"establishes the smart-contract baseline that Swarm Contract aims to replace with off-chain agent consensus.","marker":"[2]"},{"why":"supplies the foundational notion of blockchain-based trust via cryptographic proofs, which the design inherits.","marker":"[1]"},{"why":"provides the byzantine-fault-tolerant consensus model referenced for larger swarm clusters.","marker":"[3]"},{"why":"documents the trusted-execution-environment hardware interface on which the enclave trust assumption rests.","marker":"[6]"},{"why":"describes an earlier TEE-plus-blockchain decentralized computation platform that this approach extends.","marker":"[7]"},{"why":"documents a real TEE side-channel attack, motivating the threat model's caveat that enclaves require patching.","marker":"[10]"},{"why":"supplies the multi-agent systems foundation for agent collaboration that Swarm Contract builds on.","marker":"[4]"},{"why":"offers a taxonomy of autonomous agents that informs the definition of digital life forms.","marker":"[5]"}],"fun_headline_variants":["Swarm of TEE agents replaces smart contract logic","Multi-agent swarm settles contracts without on-chain logic","Trust via multi-agent consensus, not monolithic contracts","Agent swarm uses TEEs and multisig to replace smart contracts"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The design's security rests on Trusted Execution Environments being genuinely trustworthy and on no adversary ever compromising enough enclaves at the same time.","fun_headline_variants_meta":{"raw":{"variants":["Swarm of TEE agents replaces smart contract logic","Multi-agent swarm settles contracts without on-chain logic","Trust via multi-agent consensus, not monolithic contracts","Agent swarm uses TEEs and multisig to replace smart contracts"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00021,"raw_usage":{"total_tokens":1385,"prompt_tokens":893,"completion_tokens":492,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":509,"completion_tokens_details":{"reasoning_tokens":428}},"tokens_in":509,"tokens_out":492,"duration_ms":4897,"temperature":1.0,"reasoning_tokens":428,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T00:46:36.043500+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A concrete refutation would be a TEE exploit that lets an attacker extract a signing key or forge remote attestation, or an experiment in which two of three colluding enclaves produce and sign a false auction result without detection; either outcome would violate the stated trust assumptions and collapse the trust-minimization claim.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"establishes the smart-contract baseline that Swarm Contract aims to replace with off-chain agent consensus."},{"cited_title":"Tendermint: Consensus without Mining","cited_arxiv_id":null,"evidence_quote":"provides the byzantine-fault-tolerant consensus model referenced for larger swarm clusters."},{"cited_title":"Intel 64 and IA-32 Architectures Software Developer Manual s","cited_arxiv_id":null,"evidence_quote":"documents the trusted-execution-environment hardware interface on which the enclave trust assumption rests."},{"cited_title":"Zyskind, O","cited_arxiv_id":null,"evidence_quote":"describes an earlier TEE-plus-blockchain decentralized computation platform that this approach extends."},{"cited_title":"V an Bulck, M","cited_arxiv_id":null,"evidence_quote":"documents a real TEE side-channel attack, motivating the threat model's caveat that enclaves require patching."},{"cited_title":"Franklin and A","cited_arxiv_id":null,"evidence_quote":"offers a taxonomy of autonomous agents that informs the definition of digital life forms."}],"review_version":1}