Add pool_salt collision analysis and use contract-address-based salt

[prodbycorne]

Problem

The factory uses a simple 4-byte encoding of pool_id as the deployment salt:

fn pool_salt(env: &Env, pool_id: u32) -> BytesN<32> {
    let mut bytes = [0u8; 32];
    bytes[28..].copy_from_slice(&pool_id.to_be_bytes());  // only last 4 bytes are non-zero
    BytesN::from_array(env, &bytes)
}

This creates two issues:

1. Factory replacement collision

If the factory contract is redeployed (at a different address) and starts creating pools with the same pool_id values, the pool addresses will be different (since salt alone doesn't determine address — the deployer address matters). However, if a second factory is deployed at the exact same address via a different mechanism, pool address collisions become possible.

2. Salt is not human-readable or auditable

An auditor reviewing the on-chain salt has no way to know it corresponds to pool_id = 3 without knowing the encoding scheme.

Recommended Fix

Encode the full pool context into the salt using env.crypto().sha256:

fn pool_salt(env: &Env, pool_id: u32, asset: &Address) -> BytesN<32> {
    let mut pre_image = soroban_sdk::Bytes::new(env);
    pre_image.extend_from_slice(&pool_id.to_be_bytes());
    // Encode asset bytes into pre_image
    env.crypto().sha256(&pre_image)
}

This makes the salt:

• Unique per (factory_address, pool_id, asset) triple
• Collision-resistant by construction
• Reproducible deterministically

Also document the salt scheme in a comment so auditors can verify.

Acceptance Criteria

• pool_salt includes both pool_id and asset in the pre-image
• SHA-256 used to produce the final salt bytes
• Salt computation documented with a comment explaining inputs
• Test: same pool_id + same asset always produces same salt
• Test: different asset with same pool_id produces different salt
• Migration note: existing deployed pools are NOT affected (their salts were already used)

[midenotch]

Hello,

I would like to apply for the pool salt generation enhancement.

As a Fullstack and Smart Contract Engineer with experience building secure blockchain applications and deterministic deployment systems, I understand how seemingly small implementation details such as deployment salts can have significant implications for security, auditability, and long-term protocol maintainability.

After reviewing the issue, I agree with the proposed direction of replacing the current 4-byte pool identifier encoding with a SHA-256-based salt derived from the full deployment context. The existing implementation is deterministic, but it does not sufficiently communicate deployment intent, and it relies on a limited input space that can create unnecessary risk and complexity when reasoning about future factory deployments.

For this task, I would:

• Refactor pool_salt() to derive the salt from a pre-image containing both pool_id and asset.

• Use env.crypto().sha256() to generate a deterministic 32-byte deployment salt.

• Ensure the implementation remains reproducible and collision-resistant.

• Add clear inline documentation describing the salt derivation scheme, expected inputs, and security rationale so auditors can independently verify the deployment logic.

• Implement tests verifying:

  • Identical (pool_id, asset) inputs always produce identical salts.
  • Different assets with the same pool_id produce different salts.
  • Salt generation remains deterministic across executions.

• Include migration notes clarifying that previously deployed pools remain unaffected because deployment salts are consumed at deployment time and cannot be retroactively changed.

Beyond implementing the acceptance criteria, I would review related deployment paths to ensure the updated salt generation integrates cleanly with the existing factory workflow and preserves backward compatibility for all already-deployed contracts.

I enjoy working on protocol-level improvements where security, determinism, and developer experience intersect. This enhancement strengthens deployment guarantees while making the system easier to reason about during audits and future maintenance.

[clintjeff2]

Hello, I have 6 years of experience working on tasks like this and handling similar challenges across backend, frontend, and smart-contract development. I have carefully read and fully understood the task requirements, and I am confident I can deliver a clean, efficient, and well-tested solution promptly. I always ensure high-quality implementation, maintainability, and adherence to best practices.

Pull request in 5 hours.

[grantfox-oss]

🦊 GrantFox — @midenotch has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #29)
2. Your PR will be reviewed by the SmartDropLabs maintainers

Good luck! Track your progress on GrantFox.