determinitic multi‑package deployment on Aptos

[yeap-oneke]

Why multi‑package deployment on Aptos is hard

Modern Aptos apps often split logic across multiple packages.Doing this with vanilla account-based publishing has several pain points:

• Address planning and funding overhead
  • Each package normally lives at an account address; coordinating many accounts or resource accounts (funding, key/capability handling) is cumbersome.
• Poor cross-environment parity
  • Stable addresses across dev/test/prod are hard without deterministic derivation; small changes (key, funding order) shift addresses.
• Operational risk during upgrades
  • No uniform admin model; ad‑hoc processes increase the chance of misconfig or accidental loss of control.
• Discoverability and integration friction
  • Integrations need addresses up front. Without deterministic addressing, off‑chain systems and partners must wait for deploys to finish to learn final addresses.

object‑based multi‑package deployments — challenges and patterns

Even with object-based publishing, coordinating many packages brings unique pitfalls:

• Named-address drift and linking
  • Each package compiles against concrete addresses. If an object’s address isn’t known at build time, linking fails or tests point at the wrong target.
• One package per object (by design)
  • Code objects are intended to hold a single package. Multiple packages => multiple objects => more seeds to manage and version. Establish naming conventions for seeds (e.g., //).

We developed Yeaptor addresses these issues with two packages:

• Deterministic object deployment (object-code-deterministic-deployment)
  • Publish to Aptos Objects at addresses derived from (publisher, seed). Predict addresses before deploy; upgrade or freeze later. No per‑package funding/account juggling.
• Admin‑gated resource deployer (deployer)
  • Centralizes authority in a single resource account. Admin calls seed‑based publish/upgrade/freeze; the module derives the correct object and signer internally. Safer handovers via two‑step admin transfers.

Result: repeatable, scriptable multi‑package rollouts with predictable addresses, simpler signer management, and a clear path to finalize (freeze) when ready.