-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compliance + Test #149
Compliance + Test #149
Conversation
…l addresses complied with OFAC sanctions
🦋 Changeset detectedLatest commit: aeb6303 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
New dependencies detected. Learn more about Socket for GitHub ↗︎
|
packages/cli/src/utils/helpers.ts
Outdated
// SANCTIONED_ADDRESSES is so well typed that if you call includes with a string it gives a type error. | ||
// same if you make it a set or use indexOf so concat it with an empty string to give type without needing to ts-ignore | ||
const SANCTIONED_SET = new Set([''].concat(SANCTIONED_ADDRESSES)) | ||
|
||
export function isSanctioned(address: string) { | ||
return SANCTIONED_SET.has(address) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to implement this using the recommended API call option, instead of the discouraged NPM import?
My thinking is:
If we use the NPM import option
- we will have to release a patch version of the CLI every time a new version of
@celo/compliance
is released. - users will have to update their CLI installation to the latest version to benefit from the OFAC update.
If we use the API call option:
- we won't have to release new versions of the CLI for every OFAC update
- users won't have to upgrade their CLI to benefit from the OFAC update (if they are above the minimum version that has the OFAC feature)
One downside from the API call option is that the CLI has to make a network call to fetch the latest addresses from https://celo-org.github.io/compliance/ofac.sanctions.json
every time a check is performed. Unless we include caching mechanism, which might be overkill.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah not loving making a call every request . but also not sure how to implement caching. it seems the way to persist something when building a cli is to save a file that seems like way overkill
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the end i decided we could at least make it so that only 1 request per cli invocation is required by storing the result in memory.
…nsitative dep so ok
add tests remove dangling console logs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall looks good, can't help but wonder if there was a way to remove all .isNotSanctioned(kit.defaultAccount)
at a more "root" level, so it applies to all commands but can't think of it right now
Description
Adds the @celo/compliance package to ensure commands which transfer tokens do not work with OFAC sanctioned addresses.
Other changes
As transfer commands did not have tests this adds tests for basic case and for non compliant case.
Tested
New Tests.
Related issues
Backwards compatibility
yep
Documentation
n/a