Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-13 · Instrument version 1.0.0
What Matters
- Two agents can have separate strategies and still compete for the same on-chain input. Inspect object ownership, read/write access and versions before submitting their work together.
- Shared read-only data is different from a shared writable pool or reused gas coin. A party object changes version coordination, not the need to order mutations.
- The DN ledger checks user-declared relationships. It makes no chain requests and produces no throughput estimate, fee forecast or security certification.
DN Alpha Thesis
An agent desk plans three actions: rebalance one position, execute another swap and distribute proceeds. The prompts differ. The operators differ. The transactions may still touch one pool, one capability object or the same coin selected for gas. Counting agents says little about the dependencies between their instructions.
Sui makes those dependencies particularly visible because transactions use objects with defined ownership and access rules. Its documentation distinguishes address-owned, shared, immutable and party objects. Those categories are useful design inputs; none turns an incomplete transaction inventory into a performance guarantee. [1]
DN’s practical question is narrower than “Which chain is best for agents?” Before parallel submission, can the operator identify which inputs are reused, which operations write them and which versions are actually available? The accompanying ledger helps answer that declared-input question. It does not execute a trade or inspect a wallet.
DN Evidence Block
Source review: 13 November 2026. Sui Foundation documentation and Mysten Labs’ current TypeScript SDK pages support the ownership, versioning, shared-object congestion and executor distinctions below. The SDK documentation labels its parallel executor experimental. [5] No RPC request, transaction simulation, mainnet experiment or comparison with Ethereum or Solana was performed. Worked numbers count a fabricated dependency graph, not observed chain performance.
Original DN instrument · version 1.0.0
DN Sui Object Contention Ledger
Map declared object reuse across a small planned batch. Counts overlapping transaction pairs and preserves unknown ownership, versions and gas scope.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Enter inputs or load an illustrative example.
No chain lookup, transaction simulation, signer check, performance measurement or security certification. Use aliases and no confidential data.
Separate ownership from concurrent execution
Ownership answers who may use an object under the applicable rules. Access mode describes how the transaction uses it. Version information identifies the state being referenced. Keep all three in the plan: “our agent owns it” does not explain whether another process is already using it.
| Declared object type | What the design review asks | What the label does not prove |
|---|---|---|
| Address-owned | Which exact input version is used, and who coordinates reuse? | That two independently built transactions can reuse it concurrently. |
| Shared | Which operations read it, and which mutate the common state? | That every reference has permission to perform a privileged action. |
| Immutable | Is the referenced object actually immutable? | That the rest of the transaction has no mutable dependencies. |
| Party | Which permitted owner acts, and how are mutations sequenced? | That concurrent submission means concurrent writes. |
The ownership guide supplies these distinctions. The worksheet uses simplified labels, not a complete Sui transaction format. Wrapped objects, dynamically accessed children and other dependencies require examination through the actual parent and call path. [1]
An owned version is a dependency, not a reusable ticket
Sui’s versioning documentation says modifications produce a newer version of the same object identifier; conflicting uses of the same mutable owned version are rejected. Consensus-managed inputs follow a different version-assignment path. The shared object’s initial shared version is not a manually selected current write version. [2]
Consider two fabricated workers that both build a write using POSITION@7. Their common reference is a coordination problem even if they intend different trades. If one action produces the state needed by the other, the second should be built against the appropriate resulting state rather than treated as an unrelated parallel job.
The ledger therefore preserves versions as exact integer strings. It does not round a large version through a floating-point number. It also accepts ? for an unknown owned version. An unknown is a review gap; it is not evidence that the inputs differ.
One writable shared object can concentrate a workflow
Sui’s local fee-market documentation describes per-object scheduling limits. Transactions writing the same shared object must execute sequentially; read-only uses do not consume that object’s congestion budget. Deferred work can ultimately be cancelled with a shared-object-congestion error. Priority and available capacity are separate questions. [3]
For an agent application, inspect where business state converges. Many independent agents can still update one global accounting object. Splitting agents across workers does not split that object. Conversely, a common immutable configuration does not create the same write dependency.
Changing the object layout can also change the application. Dividing one pool or ledger may require new coordination, accounting or liquidity rules. The worksheet exposes a dependency worth examining; it does not recommend redesigning a protocol merely to make a graph look less connected.
Party objects change coordination, not mutation order
The current party-object documentation describes consensus-managed versions and multiple inflight transactions, while mutations of one object still execute one at a time. At this review, its public transfer functions support a single-owner party; broader membership is described as future work. Party coins cannot be used directly as gas-payment coin objects. [4]
This distinction matters when an agent owns a frequently used resource. A version-coordination mechanism can make submission easier without making conflicting state changes independent. The ledger groups party and shared write overlaps for review but retains their different ownership labels.
Do not infer production support solely from a type name. Record the deployed package, network, SDK release and actual authorization checks. A proposal to change ownership form is a separate implementation decision, not a result the browser worksheet can approve.
Gas inputs belong in the dependency map
The SDK parallel executor documents gas-coin management and scheduling around reused object identifiers. It warns that other processes or multiple executors using the same source coins can disrupt that coordination. Its experimental status means integration assumptions need the installed version attached. [5]
Current SDK documentation also distinguishes versioned coin objects from address balances. A balance-funded path can avoid coin-object dependencies introduced by funding, but other versioned inputs may remain. The ledger offers separate coin-object, address-balance and unknown scopes rather than assuming every transaction uses a gas coin. [6]
Sponsorship adds another payer and approval path. In the documented coin-payment flow, sender and sponsor signatures cover the transaction data, including gas data. The agent’s lack of a native-token balance does not identify who coordinates sponsored inputs. [10]
If coin objects are declared as the complete gas scope, every transaction needs at least one gas row. If the scope is unknown, the tool keeps that omission visible. Neither selection checks balances, sponsor limits or an actual gas service.
A worked example: three transactions, two review pairs
The first labelled example contains three transactions and nine reference rows. Each reads CONFIG. T1 and T2 write POOL. T1 and T3 both name GAS_A@7 for gas. T2 uses a different gas coin, while T3 also writes its own capability object.
There are five distinct object aliases and three possible transaction pairs: T1–T2, T1–T3 and T2–T3. The ledger finds two pairs requiring coordination review. One pair overlaps on the writable shared pool; the other reuses the same declared gas object and exact owned version. The common immutable configuration adds no write overlap.
Do not add the category totals. The gas pair is already an owned-input pair and a write-overlap pair. Adding those labels would count the same relationship repeatedly. The overall result is the union of qualifying pairs, not the sum of columns.
The second example has two writes to an owned object with unknown versions. It reports one review pair and two unknown reference rows, while the exact-known-version-match count is zero. That zero is deliberately narrow: it means no equal known versions were established, not that the two submissions are compatible.
The third example gives each transaction its own gas object and declares only reads of the common pool and configuration. The declared review-pair count becomes zero. Undeclared inputs, actual calls, authority and network conditions remain outside the result.
Use a transaction block when the business action is one unit
A programmable transaction block can pass one command’s result into later commands. Its command effects apply atomically; if a command fails, those command effects do not apply. This is a transaction boundary, not a promise that an attempted action has no cost or that external business effects are reversed. [7]
That gives the operator a useful design question: are these independent opportunities, or steps of one action that requires a common result? Artificially separating a dependent sequence can create intermediate-state management work. Combining independent actions can instead enlarge a failure boundary. Choose based on the actual acceptance rule.
The ledger does not construct a PTB, infer transaction order or estimate the minimum number of execution rounds. Its counts cannot decide whether combining commands is semantically valid. The application must still define what should happen when one step cannot complete.
Turn the map into a controlled integration check
Build the review from the resolved transaction inputs and the intended calls, not from an agent’s natural-language plan alone. Shared-object access still requires appropriate Move authorization checks; merely referencing a public object does not grant a privileged operation. [8]
Then compare the intended inventory with actual execution evidence. The SDK documents simulation and explicit success/failure results; a resolved execution call is not itself proof of business success. Simulation settings can affect validation and gas assumptions, so preserve the settings and reported effects with the test. [9]
For a bounded trial, change one feature at a time: reuse a gas input, separate it, replace a shared write with a read where the application permits, or sequence an owned-object update. Record attempted, rejected, aborted and accepted transactions separately. DN has not run those trials; this is a proposed validation procedure.
Only a completed observation can support a latency or cost statement. Keep submission time, observed execution result and the time downstream readers can use the resulting state distinct. The object map tells the engineer where to investigate. Receipts and controlled comparisons establish what actually happened.
Methodology and limits
DN Sui Object Contention Ledger v1.0.0. Enter one row per transaction/object pair: transaction | object | ownership | access | version | role. Use nonpersonal, case-sensitive aliases; ownership is owned, shared, party, immutable or unknown; access is read or write; role is state or gas. Consolidate multiple uses within one transaction, recording write if any use writes. Owned versions accept an unsigned 64-bit integer or ?; other types use - because this worksheet does not compare their version references.
For n declared transactions, possible unordered pairs equal n(n−1)/2. A pair enters coordination review when it shares an object with a declared write, reuses an owned input, or shares an object of unknown ownership. Separate categories identify shared/party write overlap, owned reuse, equal known owned versions with a write, and gas-object overlap. Each pair is counted once within a category and once in the overall union. Categories overlap and must not be added.
The tool accepts up to 12 transactions and 60 rows. It rejects duplicate transaction/object rows, inconsistent ownership labels, writable immutable objects, invalid versions and contradictory gas declarations. It neither verifies input completeness nor treats a sequenced plan as a simultaneous incident. All three examples are synthetic.
This is a declared-input review, not Sui’s scheduler or a security audit. It does not resolve objects, inspect Move code, check signatures, enumerate dynamic children, observe mempool ordering or establish account balances. Read/write overlap is a conservative review signal, not a count of inevitable failures. A zero count is not permission to submit. Source pages are living documentation; where versioning or funding terminology differs, check the exact installed SDK and deployed protocol instead of relying on a generic fastpath or gasless label.
Machine-readable record schema · 1.0.0
This JSON Schema documents the downloadable record, including input provenance, missing-value handling and method versions. The creation timestamp records the calculation time; it does not certify when the underlying evidence was observed.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:dn:record:dn-sui-object-contention-ledger:1.0.0",
"title": "DN Sui Object Contention Ledger record",
"type": "object",
"additionalProperties": false,
"required": [
"schemaVersion",
"recordType",
"createdAt",
"articleSourceReviewDate",
"inputEvidenceStatus",
"inputBasis",
"exampleLabel",
"engineVersion",
"inputs",
"result"
],
"properties": {
"schemaVersion": {
"const": "1.0.0"
},
"recordType": {
"const": "dn-sui-object-contention-ledger"
},
"createdAt": {
"type": "string",
"format": "date-time"
},
"articleSourceReviewDate": {
"const": "2026-11-13"
},
"inputEvidenceStatus": {
"const": "user_entered_not_independently_verified"
},
"inputBasis": {
"enum": [
"user_entered",
"illustrative_example",
"illustrative_example_modified"
]
},
"exampleLabel": {
"type": [
"string",
"null"
]
},
"engineVersion": {
"const": "1.1.0"
},
"inputs": {
"type": "object",
"additionalProperties": false,
"required": [
"ledger",
"gasMode",
"timing"
],
"properties": {
"ledger": {
"type": "string",
"maxLength": 16000,
"minLength": 1
},
"gasMode": {
"type": "string",
"enum": [
"unknown",
"coin_objects",
"address_balance"
]
},
"timing": {
"type": "string",
"enum": [
"unknown",
"concurrent",
"sequenced"
]
}
}
},
"result": {
"type": "object",
"additionalProperties": false,
"required": [
"summary",
"metrics",
"findings"
],
"properties": {
"summary": {
"type": "string"
},
"metrics": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"label",
"value"
],
"properties": {
"label": {
"type": "string"
},
"value": {
"type": [
"number",
"string",
"null",
"boolean"
]
},
"unit": {
"type": "string"
},
"note": {
"type": "string"
}
}
}
},
"findings": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"level",
"text"
],
"properties": {
"level": {
"enum": [
"note",
"warning",
"error"
]
},
"text": {
"type": "string"
}
}
}
}
}
}
},
"allOf": [
{
"if": {
"properties": {
"inputBasis": {
"const": "user_entered"
}
}
},
"then": {
"properties": {
"exampleLabel": {
"type": "null"
}
}
},
"else": {
"properties": {
"exampleLabel": {
"type": "string",
"minLength": 1
}
}
}
}
]
}Related DN research
Frequently asked questions
Does sharing an object always prevent parallel work?
No. Common read-only inputs differ from writes to shared state. The ledger reports declared overlap and preserves the possibility of omitted dependencies; it does not certify parallel execution.
Why can separate agents still contend?
Their transactions can reference the same object, owned version or gas input. Separate prompts and processes do not establish separate on-chain dependencies.
Does a party object make writes simultaneous?
No. The reviewed documentation supports multiple inflight transactions with consensus-managed versions while mutations of one party object remain ordered. Check the current implementation and permissions.
Does address-balance gas remove every conflict?
No. It changes the funding path; a transaction can still use other owned or shared inputs. The worksheet accepts the funding scope as a user declaration.
Does the calculator measure Sui speed or gas prices?
No. It counts a graph supplied by the user. Throughput, latency, fees, failures and successful outcomes need observed transactions under a disclosed test.
Sources and review dates
- [1] Sui: Types of Object Ownership. Ownership categories and access/versioning distinctions. Living documentation; no page-specific revision date shown. Reviewed 2026-11-13.
- [2] Sui: Object Versioning. Exact owned references, mutable version conflicts, consensus-managed references and wrapped/dynamic-child boundaries. Reviewed 2026-11-13.
- [3] Sui: Object-Based Local Fee Markets. Per-object write scheduling, read-only budget treatment, deferral and cancellation; no DN measurements. Reviewed 2026-11-13.
- [4] Sui: Party Objects. Inflight versus mutation semantics, current single-owner limitation and gas-coin restriction. Reviewed 2026-11-13.
- [5] Mysten SDK: Transaction Executors. Current TypeScript SDK executor documentation; experimental parallel executor, gas modes and external coordination warnings. Reviewed 2026-11-13.
- [6] Mysten SDK: Coins and Balances. Versioned coin objects versus address balances and resolved funding dependencies. Reviewed 2026-11-13.
- [7] Sui: What Is a PTB?. Ordered commands and atomic command effects; no claim about all external effects or zero failure cost. Reviewed 2026-11-13.
- [8] Sui: Shared Objects. Explicit authorization for privileged operations on shared objects. Reviewed 2026-11-13.
- [9] Mysten SDK: Executing Transactions. Explicit failed results, effects, indexing/readback and simulation configuration. Reviewed 2026-11-13.
- [10] Sui: Sponsored Transactions. Documented coin-payment sponsorship roles and signatures over transaction/gas data; not a universal claim that every funding path needs coin objects. Reviewed 2026-11-13.
Turn the finding into a decision
For a bounded review of the evidence and unresolved questions behind a specific operational decision, contact the DN Research Desk. Scope, feasibility, fee and delivery terms must be agreed before work begins.
Disclosure: This is independent DN editorial research. The instrument evaluates entered assumptions and does not independently verify your evidence or approve transactions. Illustrative examples are labelled. Any affiliate placement is identified where it appears; a commercial relationship does not determine the findings. No provider endorsement or guaranteed outcome is implied.
