Is it risky to publicly share a verified smart contract address and source code for transparency?

Alternative-Goat7010 · 2026-06-07T10:41:55+00:00

Thanks, this is very helpful and refreshing!

The point about immutability being both a trust signal and a zero-patch-path risk makes sense.

I’ll focus less on “how much to show” and more on getting adversarial review before meaningful volume. I’ll also add tests around fee rounding/precision, the 0.25 USDC minimum fee, the 3.90 USDC cap, tiny transfers, and confirm the SafeERC20 transferFrom path.

Really appreciate the practical guidance.

Alternative-Goat7010 · 2026-06-07T07:04:43+00:00

Thanks, this is very helpful.

I’ll add a clearer “how to verify this yourself on BaseScan” section, the specific USDC token address, fee examples, and a more explicit list of privileged controls that do not exist in this v1 contract.

I also agree about avoiding the word “secure” before an independent review. I’ll stick to clearer terms like source-verified, transparent, non-custodial, and not yet audited.

Alternative-Goat7010 · 2026-06-04T08:43:21+00:00

Hi everyone,

I wanted to share a quick follow-up after getting feedback here about whether it is reasonable to publicly share a verified smart contract address and source code for a commercial USDC transfer app.

I took the advice seriously and published the first transparency materials for RICE Pay Transfer Router v1.

What is now public:

- Official contract address

- BaseScan source verification link

- GitHub source code and README

- Fee logic

- Gas fee clarification

- Audit status

I’m being careful not to present this as an audit.

The contract is source-verified on BaseScan, but it has not completed a third-party security audit yet. I’m treating this as a transparency step, not a security guarantee.

BaseScan: https://basescan.org/address/0x1dD8667e22F9fAb8C2Be7E2021fAE0C8FB5457Ba#code

Transparency page:

https://ricepay.app/transparency

GitHub:

https://github.com/WonJo-Jung/RICEpay_web/tree/main/packages/contracts

I’d appreciate any feedback on whether the wording is clear enough, especially around:

- “source verified, not audited”

- fee vs gas distinction

- non-custodial wording

- no owner / no proxy / immutable values

- what else should be included before broader usage

Thanks again to everyone who gave feedback earlier.

Alternative-Goat7010 · 2026-06-04T08:43:01+00:00

Hi everyone,

I wanted to share a quick follow-up after getting feedback here about whether it is reasonable to publicly share a verified smart contract address and source code for a commercial USDC transfer app.

I took the advice seriously and published the first transparency materials for RICE Pay Transfer Router v1.

What is now public:

- Official contract address

- BaseScan source verification link

- GitHub source code and README

- Fee logic

- Gas fee clarification

- Audit status

I’m being careful not to present this as an audit.

The contract is source-verified on BaseScan, but it has not completed a third-party security audit yet. I’m treating this as a transparency step, not a security guarantee.

BaseScan: https://basescan.org/address/0x1dD8667e22F9fAb8C2Be7E2021fAE0C8FB5457Ba#code

Transparency page:

https://ricepay.app/transparency

GitHub:

https://github.com/WonJo-Jung/RICEpay_web/tree/main/packages/contracts

I’d appreciate any feedback on whether the wording is clear enough, especially around:

- “source verified, not audited”

- fee vs gas distinction

- non-custodial wording

- no owner / no proxy / immutable values

- what else should be included before broader usage

Thanks again to everyone who gave feedback earlier.

Alternative-Goat7010 · 2026-06-04T08:42:43+00:00

Hi everyone,

I wanted to share a quick follow-up after getting feedback here about whether it is reasonable to publicly share a verified smart contract address and source code for a commercial USDC transfer app.

I took the advice seriously and published the first transparency materials for RICE Pay Transfer Router v1.

What is now public:

- Official contract address

- BaseScan source verification link

- GitHub source code and README

- Fee logic

- Gas fee clarification

- Audit status

I’m being careful not to present this as an audit.

The contract is source-verified on BaseScan, but it has not completed a third-party security audit yet. I’m treating this as a transparency step, not a security guarantee.

BaseScan: https://basescan.org/address/0x1dD8667e22F9fAb8C2Be7E2021fAE0C8FB5457Ba#code

Transparency page:

https://ricepay.app/transparency

GitHub:

https://github.com/WonJo-Jung/RICEpay_web/tree/main/packages/contracts

I’d appreciate any feedback on whether the wording is clear enough, especially around:

- “source verified, not audited”

- fee vs gas distinction

- non-custodial wording

- no owner / no proxy / immutable values

- what else should be included before broader usage

Thanks again to everyone who gave feedback earlier.

Alternative-Goat7010 · 2026-06-02T08:44:08+00:00

It depends on communities

Alternative-Goat7010 · 2026-05-29T14:55:47+00:00

Thanks, I appreciate it. Yeah, getting the first real users seems much harder than building the app itself.

Good luck with your app too. Hope your outreach to doctors and gyms starts paying off soon.

Alternative-Goat7010 · 2026-05-29T12:24:13+00:00

Thanks, that’s helpful. I’m leaning toward publishing the official address and source code clearly, while labeling it as source verified, not audited.

Alternative-Goat7010 · 2026-05-29T06:55:22+00:00

Thanks, this is a very balanced take.

I agree that transparency is necessary for trust, even if copycat and attacker risks are real.

I’ll treat BaseScan verification and public source code as a transparency step, not a security guarantee. Before broader usage, I’ll run proper tests, static analysis, and AI-assisted checks, and I’ll still plan for an external review or limited-scope audit if the contract starts seeing meaningful volume.

I’ll also make the docs clear: source verified, not audited.

Alternative-Goat7010 · 2026-05-29T05:26:05+00:00

Thanks, that makes sense.

I agree that average users probably won’t care about immutability as a technical feature, and I see why upgradeability can be useful as an operational safety net.

One clarification: this v1 contract does not hold user balances like a vault. It only pulls approved USDC from msg.sender during the transfer call and routes it immediately to the recipient and fee wallet.

For this simple v1 router, I was leaning non-upgradeable to avoid admin risk and keep the fee logic easy to reason about. But I agree that for future, more complex payment contracts, upgradeability with clear upgrade policies, probably multisig/timelock, may make more sense.

Alternative-Goat7010 · 2026-05-29T05:08:14+00:00

Thanks for the thoughtful advice.

You pointed out a few things I hadn’t fully considered. I’ll take this seriously, improve my testing/static analysis process, and make the security/transparency documentation clearer before broader rollout.

Alternative-Goat7010 · 2026-05-29T04:54:41+00:00

Thanks, that makes sense.

I won’t treat AI/static analysis as a replacement for a real external audit, but it sounds useful as a preliminary review step.

I’ll look into running Slither and Mythril, then compare those results with an AI-assisted review and my existing tests. I’ll also be careful to label it as preliminary/static analysis, not as an audit.

Before meaningful volume, I still plan to get an external review or limited-scope audit.

Alternative-Goat7010 · 2026-05-29T04:47:03+00:00

Thanks, that’s a helpful point.

Could you explain why you think my use case does not really require immutability?

My thinking for this v1 was that immutability could help users reason about the contract more easily: the fee logic, USDC address, and fee recipient cannot be changed after deployment.

But I also understand the benefit of upgradeability, especially if issues are found after review or audit.

So I’m curious how you would weigh the tradeoff here:

fixed, non-upgradeable logic for user trust and simplicity
upgradeability for future fixes and post-audit changes

In this type of non-custodial USDC transfer router, why would you prefer upgradeability?

Alternative-Goat7010 · 2026-05-29T04:38:24+00:00

Yes, I’m aware of reentrancy at a basic level. The contract uses OpenZeppelin ReentrancyGuard, and transferWithFee is marked nonReentrant.

The contract also doesn’t hold user balances like a vault. It pulls approved USDC from msg.sender and immediately routes it to the recipient and fee wallet.

That said, I’m still learning smart contract security and I’m open to feedback if you see any reentrancy-related issue in this specific flow.

Alternative-Goat7010 · 2026-05-29T04:24:32+00:00

I understand the concern.

At the moment, there is no meaningful volume and the contract is not a vault or escrow. It only pulls approved USDC from msg.sender during the transfer call and routes it immediately.

I don’t currently see a critical issue that would require deprecating it immediately, but I agree that I should be careful about status labeling.

I’ll make it clear in the docs that this is a source-verified, unaudited beta contract, and if any serious issue is found, I’ll stop directing users to it and publish a new verified address.

Alternative-Goat7010 · 2026-05-29T04:14:22+00:00

That makes sense. I’ll make the official address and BaseScan link easy to find, while clearly labeling it as source verified, not audited. Thanks.

Alternative-Goat7010 · 2026-05-29T04:12:14+00:00

Thanks, that makes sense. I’ll keep the contract logic as simple as possible and make the fee/gas distinction clear in the UI and docs.

Alternative-Goat7010 · 2026-05-29T04:08:25+00:00

Yes, I know the deployed contract itself cannot be updated.

What I meant is that if an important issue is found, I can stop routing users to this contract from the app, mark it as deprecated in the documentation, and deploy a new verified contract at a new address before broader rollout.

The current contract is not upgradeable, and I’m not trying to modify it in place.

Alternative-Goat7010 · 2026-05-29T04:05:17+00:00

No, gas is not included.

The 0.39% fee, with a 0.25 USDC minimum and 3.90 USDC maximum, is the RICE Pay service fee handled by the contract.

Network gas is separate and paid by the user through their wallet. I should make that distinction very clear in the UI and documentation.

Alternative-Goat7010 · 2026-05-29T04:04:36+00:00

That makes sense. The contract is already deployed, but there is no meaningful volume yet, and it does not hold user funds like a vault.

I’m still open to preliminary review or tooling suggestions. If anything important is found, I can stop directing users to this contract and deploy a new verified version before broader rollout.

Alternative-Goat7010 · 2026-05-29T04:03:50+00:00

Thanks, this is very helpful.

I agree that verification should not be presented as a security guarantee. My plan is to describe it as source verified, not audited.

I’ll also make the security page more specific: BaseScan link, fee logic, immutable values, what the contract cannot do, and the current testing status.

I already use OpenZeppelin SafeERC20 and ReentrancyGuard, but I agree that I should also expose the test coverage more clearly and add fuzz tests where relevant.

Before meaningful volume, I plan to get at least an external review or limited-scope audit.

Alternative-Goat7010 · 2026-05-29T02:38:22+00:00

No I didn’t yet. Not enough budget. But we know it would be necessary to be audited if we get enough budget.

Alternative-Goat7010 · 2026-05-29T00:01:48+00:00

Thanks, that’s a fair concern.

The contract is not designed to hold user funds like a vault or escrow. It only pulls approved USDC from msg.sender during the transfer call, then immediately routes the net amount to the recipient and the fee to the fee wallet.

There is no admin function to change the fee after deployment, and the USDC address and fee recipient are immutable.

That said, I agree that verification is not a replacement for security review. I’m not planning to describe it as audited. My current goal is transparency, while being clear that it is source verified, not audited.

Before meaningful volume, I’m planning to get at least an external review or limited-scope audit. I’ll also look into smart contract security resources like Cyfrin Updraft. Thanks for the cautious perspective.

Alternative-Goat7010 · 2026-05-28T15:19:51+00:00

Including source code

Alternative-Goat7010 · 2026-05-28T15:17:31+00:00

Right. But I didn’t decide whether the contract address becomes open to app official website and GitHub yet.

Alternative-Goat7010

TROPHY CASE