Smart Contract — Optimisation
Summary
Every authorized call into the contract (approve, revoke, execute, and each governance proposal creation) checks the caller against the owner-weight map before doing anything else. This issue asks a contributor to measure exactly how much CPU and memory budget that check consumes at the maximum owner count, and confirm the contract stays comfortably inside Soroban's per-invocation resource limits.
Background
The owner-authorization check in contracts/accord/src/lib.rs loads the entire OWNERS persistent entry (an Address-to-u32 weight map) on every call and looks up the caller's weight from it. Because this runs at the start of nearly every entrypoint, its cost scales with the deserialization size of the owner map, which grows with the number of owners up to the MAX_OWNERS cap of 20. No benchmark currently exists showing what this actually costs in Soroban's CPU instruction and memory budget at that upper bound.
What Needs to Be Done
- Write a benchmark test that calls
env.budget().reset_unlimited(), initializes a contract instance with the maximum of 20 owners, and then measures CPU instructions and memory consumed by a representative authorized call (for example, approve).
- Compare the measured cost against a small-owner-count baseline (for example, 1 owner) to quantify how much of the cost is attributable specifically to the owner-map lookup as the owner set grows.
- Confirm the measured cost sits well within Soroban's published per-transaction resource limits, leaving headroom for the rest of the call's logic.
- Record the benchmark methodology and results — including the specific
env.budget() output — in ARCHITECTURE.md, alongside the existing storage cost documentation.
- If the measurement reveals the cost is unexpectedly close to the network's resource limits, flag this in the write-up as a follow-up concern rather than attempting a fix as part of this issue.
Acceptance Criteria
Files to Look At
contracts/accord/src/lib.rs — the owner-authorization helper (loads the full owner-weight map on every authorized call) that this issue measurescontracts/accord/src/test.rs — existing tests already call env.budget().reset_unlimited(), a useful reference for wiring up the benchmarkdocs/ARCHITECTURE.md — where the benchmark results should be documented
Difficulty: Medium
Smart Contract — Optimisation
Summary
Every authorized call into the contract (approve, revoke, execute, and each governance proposal creation) checks the caller against the owner-weight map before doing anything else. This issue asks a contributor to measure exactly how much CPU and memory budget that check consumes at the maximum owner count, and confirm the contract stays comfortably inside Soroban's per-invocation resource limits.
Background
The owner-authorization check in
contracts/accord/src/lib.rsloads the entireOWNERSpersistent entry (anAddress-to-u32weight map) on every call and looks up the caller's weight from it. Because this runs at the start of nearly every entrypoint, its cost scales with the deserialization size of the owner map, which grows with the number of owners up to theMAX_OWNERScap of 20. No benchmark currently exists showing what this actually costs in Soroban's CPU instruction and memory budget at that upper bound.What Needs to Be Done
env.budget().reset_unlimited(), initializes a contract instance with the maximum of 20 owners, and then measures CPU instructions and memory consumed by a representative authorized call (for example,approve).env.budget()output — inARCHITECTURE.md, alongside the existing storage cost documentation.Acceptance Criteria
MAX_OWNERS = 20usingenv.budget().ARCHITECTURE.md.Files to Look At
contracts/accord/src/lib.rs— the owner-authorization helper (loads the full owner-weight map on every authorized call) that this issue measurescontracts/accord/src/test.rs— existing tests already callenv.budget().reset_unlimited(), a useful reference for wiring up the benchmarkdocs/ARCHITECTURE.md— where the benchmark results should be documentedDifficulty: Medium